* Re: [PATCH v2] dt-bindings: nxp,pnx-i2c: Convert to dtschema
From: Animesh Agarwal @ 2024-03-20 8:32 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Conor Dooley, Vladimir Zapolskiy, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, linux-i2c,
devicetree, linux-kernel
In-Reply-To: <2b45017a-5a68-4c56-a1b3-ef17163139d4@linaro.org>
On Wed, Mar 20, 2024 at 1:23 PM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
> Yes.
>
> While at this:
> Please use subject prefixes matching the subsystem. You can get them for
> example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
> your patch is touching.
> missing i2c
Thanks for the support on this, I will be using proper subject
prefixes here onwards.
> This is an automated instruction, just in case, because many review tags
> are being ignored. If you know the process, you can skip it (please do
> not feel offended by me posting it here - no bad intentions intended).
> If you do not know the process, here is a short explanation:
>
> Please add Acked-by/Reviewed-by/Tested-by tags when posting new
> versions, under or above your Signed-off-by tag. Tag is "received", when
> provided in a message replied to you on the mailing list. Tools like b4
> can help here. However, there's no need to repost patches *only* to add
> the tags. The upstream maintainer will do that for tags received on the
> version they apply.
>
> https://elixir.bootlin.com/linux/v6.5-rc3/source/Documentation/process/submitting-patches.rst#L577
Yes, I'll follow these instructions for v3 of this patch.
Regards,
Animesh Agarwal
_______________________________________________
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/2] arm64: dts: S32G3: Introduce device tree for S32G-VNP-RDB3
From: Ghennadi Procopciuc @ 2024-03-20 8:24 UTC (permalink / raw)
To: Krzysztof Kozlowski, Wadim Mueller
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Greg Kroah-Hartman, Jiri Slaby, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Chester Lin, Andreas Färber, Matthias Brugger,
NXP S32 Linux Team, Tim Harvey, Alexander Stein, Marek Vasut,
Gregor Herburger, Marco Felsch, Joao Paulo Goncalves,
Markus Niebel, Matthias Schiffer, Stefan Wahren, Bjorn Helgaas,
Josua Mayer, Yannic Moog, Li Yang, devicetree, linux-kernel,
linux-serial, linux-arm-kernel
In-Reply-To: <018d1b9d-7957-4efb-903b-2e510db1ff80@linaro.org>
On 3/20/24 09:49, Krzysztof Kozlowski wrote:
> On 20/03/2024 08:00, Ghennadi Procopciuc wrote:
>> On 3/20/24 00:16, Wadim Mueller wrote:
>> [...]
>>> +++ b/arch/arm64/boot/dts/freescale/s32g3.dtsi
>>> @@ -0,0 +1,236 @@
>>> +// SPDX-License-Identifier: GPL-2.0-or-later
>>> +/*
>>> + * Copyright 2021-2023 NXP
>>> + *
>>> + * Authors: Ghennadi Procopciuc <ghennadi.procopciuc@nxp.com>
>>> + * Ciprian Costea <ciprianmarian.costea@nxp.com>
>>> + * Andra-Teodora Ilie <andra.ilie@nxp.com>
>>
>> This pollutes the content of the file. Please make them part of the
>> commit description using 'Signed-off-by' tags.
>>
>
> No, that's not how process works. SoB are part of DCO and Ghennadi is
> allowed to skip them. Just read the DCO. Don't add fake SoB tags just
> because someone wants...
>
> Nothing is polluted in the file. That's what this section you have (if
> someone wants).
>
I apologize for not getting it right earlier. After reviewing the
information available at [0], I noticed that it suggests using
Co-developed-by and Signed-off-by when a patch has multiple
contributors. However, I could not find any mention of the 'Authors'
section in the file although it seems to be a common practice.
[0]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst#n491
Regards,
Ghennadi
_______________________________________________
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/2] dt-bindings: thermal: convert st,stih407-thermal to DT schema
From: Krzysztof Kozlowski @ 2024-03-20 8:12 UTC (permalink / raw)
To: Raphaël Gallais-Pou, Rob Herring
Cc: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Krzysztof Kozlowski, Conor Dooley, Patrice Chotard, Lee Jones,
linux-pm, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <010698c5-de92-4c7b-a476-b961b7ae9c72@gmail.com>
On 19/03/2024 20:32, Raphaël Gallais-Pou wrote:
> Hi Rob,
>
> It's been a few weeks.
Just choose the value which is correct. If you have just one sensor,
then cells=0, like you suggested.
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 0/3] ARM: dts: renesas: Add more TMU support
From: Geert Uytterhoeven @ 2024-03-20 8:03 UTC (permalink / raw)
To: Wolfram Sang
Cc: Magnus Damm, Niklas Söderlund, linux-renesas-soc,
linux-arm-kernel
In-Reply-To: <ZfqLY8Ej6kNnAMQA@ninjato>
Hi Wolfram,
On Wed, Mar 20, 2024 at 8:08 AM Wolfram Sang <wsa@kernel.org> wrote:
> > APE6 (APE6EVM), and on R-Car H2 (Lager) and M2-W (Koelsch), except for
> > TMU3 on M2-W, which consistently fails the CLOCK_REALTIME test (why?).
>
> Huh? It works on Lager and fails on Koelsch? Do you have a log file?
Of course it succeeded on the next try...
When it failed:
# Running Asynchronous Switching Tests...
TAP version 13
1..12
# Mon Mar 18 13:47:43 2024
[...]
# 1710766103:513532480
# 1710766103:513532480
# 1710766103:513532480
# --------------------
# 1710766103:513784560
# 1710766103:513784559
# --------------------
# 1710766103:513784559
# 1710766103:513784559
# 1710766103:513784559
[...]
# Delta: 1 ns
# Mon Mar 18 13:48:23 2024
not ok 1 CLOCK_REALTIE
# Planned tests != run tests (12 != 1)
# Totals: pass:0 fail:1 xfail:0 xpass:0 skip:0 error:0
TAP version 13
1..1
not ok 1 clocksource-switch
# Totals: pass:0 fail:1 xfail:0 xpass:0 skip:0 error:0
Perhaps a subtle driver issue, or an issue with the test?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
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] dt-bindings: nxp,pnx-i2c: Convert to dtschema
From: Krzysztof Kozlowski @ 2024-03-20 7:53 UTC (permalink / raw)
To: Animesh Agarwal, Conor Dooley
Cc: Vladimir Zapolskiy, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-kernel, linux-i2c, devicetree,
linux-kernel
In-Reply-To: <CAE3Oz81-8tV2iJc7Jp3B-ooHvGeOSctxUAvd_1dA-3DQRUJFPQ@mail.gmail.com>
On 20/03/2024 01:53, Animesh Agarwal wrote:
> On Tue, Mar 19, 2024 at 11:27 PM Conor Dooley <conor@kernel.org> wrote:
>
>> You're missing a space before the <, but otherwise this looks fine.
>
> Should I send another version fixing this issue?
>
Yes.
While at this:
Please use subject prefixes matching the subsystem. You can get them for
example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
your patch is touching.
missing i2c
---
This is an automated instruction, just in case, because many review tags
are being ignored. If you know the process, you can skip it (please do
not feel offended by me posting it here - no bad intentions intended).
If you do not know the process, here is a short explanation:
Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions, under or above your Signed-off-by tag. Tag is "received", when
provided in a message replied to you on the mailing list. Tools like b4
can help here. However, there's no need to repost patches *only* to add
the tags. The upstream maintainer will do that for tags received on the
version they apply.
https://elixir.bootlin.com/linux/v6.5-rc3/source/Documentation/process/submitting-patches.rst#L577
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/2] arm64: dts: S32G3: Introduce device tree for S32G-VNP-RDB3
From: Krzysztof Kozlowski @ 2024-03-20 7:49 UTC (permalink / raw)
To: Ghennadi Procopciuc, Wadim Mueller
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Greg Kroah-Hartman, Jiri Slaby, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Chester Lin, Andreas Färber, Matthias Brugger,
NXP S32 Linux Team, Tim Harvey, Alexander Stein, Marek Vasut,
Gregor Herburger, Marco Felsch, Joao Paulo Goncalves,
Markus Niebel, Matthias Schiffer, Stefan Wahren, Bjorn Helgaas,
Josua Mayer, Yannic Moog, Li Yang, devicetree, linux-kernel,
linux-serial, linux-arm-kernel
In-Reply-To: <a5268bcc-144b-4e86-a13a-33d976368f06@oss.nxp.com>
On 20/03/2024 08:00, Ghennadi Procopciuc wrote:
> On 3/20/24 00:16, Wadim Mueller wrote:
> [...]
>> +++ b/arch/arm64/boot/dts/freescale/s32g3.dtsi
>> @@ -0,0 +1,236 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later
>> +/*
>> + * Copyright 2021-2023 NXP
>> + *
>> + * Authors: Ghennadi Procopciuc <ghennadi.procopciuc@nxp.com>
>> + * Ciprian Costea <ciprianmarian.costea@nxp.com>
>> + * Andra-Teodora Ilie <andra.ilie@nxp.com>
>
> This pollutes the content of the file. Please make them part of the
> commit description using 'Signed-off-by' tags.
>
No, that's not how process works. SoB are part of DCO and Ghennadi is
allowed to skip them. Just read the DCO. Don't add fake SoB tags just
because someone wants...
Nothing is polluted in the file. That's what this section you have (if
someone wants).
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 8/8] drm: zynqmp_dp: Add debugfs interface for compliance testing
From: Tomi Valkeinen @ 2024-03-20 7:49 UTC (permalink / raw)
To: Sean Anderson
Cc: Michal Simek, David Airlie, linux-kernel, Daniel Vetter,
linux-arm-kernel, Laurent Pinchart, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, dri-devel
In-Reply-To: <20240319225122.3048400-9-sean.anderson@linux.dev>
On 20/03/2024 00:51, Sean Anderson wrote:
> +/**
> + * enum test_pattern - Test patterns for test testing
"for test testing"? =)
> @@ -1655,6 +2321,9 @@ static void zynqmp_dp_hpd_irq_work_func(struct work_struct *work)
> u8 status[DP_LINK_STATUS_SIZE + 2];
> int err;
>
> + if (READ_ONCE(dp->ignore_hpd))
> + return;
> +
> mutex_lock(&dp->lock);
> err = drm_dp_dpcd_read(&dp->aux, DP_SINK_COUNT, status,
> DP_LINK_STATUS_SIZE + 2);
Why do you need READ/WRITE_ONCE() for ignore_hpd?
Tomi
_______________________________________________
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 2/2] dt-bindings: arm: fsl: Document missing s32g3 board
From: Krzysztof Kozlowski @ 2024-03-20 7:47 UTC (permalink / raw)
To: Wadim Mueller
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Greg Kroah-Hartman, Jiri Slaby, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Chester Lin, Andreas Färber, Matthias Brugger,
NXP S32 Linux Team, Tim Harvey, Alexander Stein, Gregor Herburger,
Marek Vasut, Hugo Villeneuve, Joao Paulo Goncalves, Markus Niebel,
Marco Felsch, Matthias Schiffer, Stefan Wahren, Bjorn Helgaas,
Josua Mayer, Philippe Schenker, Li Yang, devicetree, linux-kernel,
linux-serial, linux-arm-kernel
In-Reply-To: <20240319221614.56652-3-wafgo01@gmail.com>
On 19/03/2024 23:16, Wadim Mueller wrote:
> The nxp, s32g399a-rdb3 board is not documented.
Use full name of the board.
Subject: How is it missing? There is no such board in the kernel, so
binding is not missing. Also, you touch here serial...
>
> * Add entry for S32G3 based boards with nxp,s32g399a-rdb3 item
> * Add nxp,s32g3-linflexuart documentation
>
> Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
Bindings go before users.
> ---
> Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++++++
> .../devicetree/bindings/serial/fsl,s32-linflexuart.yaml | 3 +++
Split the patches. They will go via different subsystems.
> 2 files changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
> index 228dcc5c7d6f..23bf1d7f95b1 100644
> --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> @@ -1503,6 +1503,12 @@ properties:
> - nxp,s32g274a-rdb2
> - const: nxp,s32g2
>
> + - description: S32G3 based Boards
> + items:
> + - enum:
> + - nxp,s32g399a-rdb3
> + - const: nxp,s32g3
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 v4 02/18] pinctrl: pinctrl-single: move suspend()/resume() callbacks to noirq
From: Dhruva Gole @ 2024-03-20 7:44 UTC (permalink / raw)
To: Thomas Richard
Cc: Linus Walleij, Bartosz Golaszewski, Andy Shevchenko,
Tony Lindgren, Haojian Zhuang, Vignesh R, Aaro Koskinen,
Janusz Krzysztofik, Andi Shyti, Peter Rosin, Vinod Koul,
Kishon Vijay Abraham I, Philipp Zabel, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas, linux-gpio,
linux-kernel, linux-arm-kernel, linux-omap, linux-i2c, linux-phy,
linux-pci, gregory.clement, theo.lebrun, thomas.petazzoni,
u-kumar1, Andy Shevchenko
In-Reply-To: <20240102-j7200-pcie-s2r-v4-2-6f1f53390c85@bootlin.com>
Hi,
On Mar 04, 2024 at 16:35:45 +0100, Thomas Richard wrote:
> The goal is to extend the active period of pinctrl.
> Some devices may need active pinctrl after suspend() and/or before
> resume().
> So move suspend()/resume() to suspend_noirq()/resume_noirq() in order to
> have active pinctrl until suspend_noirq() (included), and from
> resume_noirq() (included).
>
> The deprecated API has been removed to use the new one (dev_pm_ops struct).
>
> No need to check the pointer returned by dev_get_drvdata(), as
> platform_set_drvdata() is called during the probe.
>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
> ---
I was planning to do this but didn't see particular benefit to it. Do
you see the benefit on your specific device? Can you help me understand
how? Not against the patch, just curious.
Reviewed-by: Dhruva Gole <d-gole@ti.com>
--
Best regards,
Dhruva
_______________________________________________
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/3] dt-bindings: remoteproc: add Versal-NET platform
From: Krzysztof Kozlowski @ 2024-03-20 7:40 UTC (permalink / raw)
To: Tanmay Shah, andersson, mathieu.poirier, robh+dt,
krzysztof.kozlowski+dt, conor+dt, michal.simek, ben.levinsky
Cc: linux-remoteproc, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <d112481b-4331-4c0c-9775-407ac4a601fb@amd.com>
On 19/03/2024 15:42, Tanmay Shah wrote:
>
>
> On 3/19/24 12:30 AM, Krzysztof Kozlowski wrote:
>> On 19/03/2024 01:51, Tanmay Shah wrote:
>>> Hello Krzysztof,
>>>
>>> Thanks for reviews. Please find my comments below.
>>>
>>> On 3/17/24 1:53 PM, Krzysztof Kozlowski wrote:
>>>> On 15/03/2024 22:15, Tanmay Shah wrote:
>>>>> AMD-Xilinx Versal-NET platform is successor of Versal platform. It
>>>>> contains multiple clusters of cortex-R52 real-time processing units.
>>>>> Each cluster contains two cores of cortex-R52 processors. Each cluster
>>>>> can be configured in lockstep mode or split mode.
>>>>>
>>>>> Each R52 core is assigned 128KB of TCM memory. ATCM memory is 64KB, BTCM
>>>>> and CTCM memoreis are 32KB each. Each TCM memory has its own dedicated
>>>>> power-domain that needs to be requested before using it.
>>>>>
>>>>> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
>>>>> ---
>>>>> .../remoteproc/xlnx,zynqmp-r5fss.yaml | 220 +++++++++++++++---
>>>>> 1 file changed, 184 insertions(+), 36 deletions(-)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>>>> index 711da0272250..55654ee02eef 100644
>>>>> --- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>>>> +++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>>>> @@ -18,7 +18,9 @@ description: |
>>>>>
>>>>> properties:
>>>>> compatible:
>>>>> - const: xlnx,zynqmp-r5fss
>>>>> + enum:
>>>>> + - xlnx,zynqmp-r5fss
>>>>> + - xlnx,versal-net-r52fss
>>>>>
>>>>> "#address-cells":
>>>>> const: 2
>>>>> @@ -64,7 +66,9 @@ patternProperties:
>>>>>
>>>>> properties:
>>>>> compatible:
>>>>> - const: xlnx,zynqmp-r5f
>>>>> + enum:
>>>>> + - xlnx,zynqmp-r5f
>>>>> + - xlnx,versal-net-r52f
>>>>>
>>>>> reg:
>>>>> minItems: 1
>>>>> @@ -135,9 +139,11 @@ required:
>>>>> allOf:
>>>>> - if:
>>>>> properties:
>>>>> - xlnx,cluster-mode:
>>>>> - enum:
>>>>> - - 1
>>>>> + compatible:
>>>>> + contains:
>>>>> + enum:
>>>>> + - xlnx,versal-net-r52fss
>>>>
>>>> Why do you touch these lines?
>>>>
>>>>> +
>>>>> then:
>>>>> patternProperties:
>>>>> "^r5f@[0-9a-f]+$":
>>>>> @@ -149,16 +155,14 @@ allOf:
>>>>> items:
>>>>> - description: ATCM internal memory
>>>>> - description: BTCM internal memory
>>>>> - - description: extra ATCM memory in lockstep mode
>>>>> - - description: extra BTCM memory in lockstep mode
>>>>> + - description: CTCM internal memory
>>>>>
>>>>> reg-names:
>>>>> minItems: 1
>>>>> items:
>>>>> - - const: atcm0
>>>>> - - const: btcm0
>>>>> - - const: atcm1
>>>>> - - const: btcm1
>>>>> + - const: atcm
>>>>> + - const: btcm
>>>>> + - const: ctcm
>>>>>
>>>>> power-domains:
>>>>> minItems: 2
>>>>> @@ -166,33 +170,70 @@ allOf:
>>>>> - description: RPU core power domain
>>>>> - description: ATCM power domain
>>>>> - description: BTCM power domain
>>>>> - - description: second ATCM power domain
>>>>> - - description: second BTCM power domain
>>>>> + - description: CTCM power domain
>>>>>
>>>>> else:
>>>>> - patternProperties:
>>>>> - "^r5f@[0-9a-f]+$":
>>>>> - type: object
>>>>> -
>>>>> - properties:
>>>>> - reg:
>>>>> - minItems: 1
>>>>> - items:
>>>>> - - description: ATCM internal memory
>>>>> - - description: BTCM internal memory
>>>>> -
>>>>> - reg-names:
>>>>> - minItems: 1
>>>>> - items:
>>>>> - - const: atcm0
>>>>> - - const: btcm0
>>>>> -
>>>>> - power-domains:
>>>>> - minItems: 2
>>>>> - items:
>>>>> - - description: RPU core power domain
>>>>> - - description: ATCM power domain
>>>>> - - description: BTCM power domain
>>>>> + allOf:
>>>>> + - if:
>>>>> + properties:
>>>>> + xlnx,cluster-mode:
>>>>> + enum:
>>>>> + - 1
>>>>
>>>> Whatever you did here, is not really readable. You have now multiple
>>>> if:then:if:then embedded.
>>>
>>> For ZynqMP platform, TCM can be configured differently in lockstep mode
>>> and split mode.
>>>
>>> For Versal-NET no such configuration is available, but new CTCM memory
>>> is added.
>>>
>>> So, I am trying to achieve following representation of TCM for both:
>>>
>>> if: versal-net compatible
>>> then:
>>> ATCM - 64KB
>>> BTCM - 32KB
>>> CTCM - 32KB
>>>
>>> else: (ZynqMP compatible)
>>> if:
>>> xlnx,cluster-mode (lockstep mode)
>>> then:
>>> ATCM0 - 64KB
>>> BTCM0 - 64KB
>>> ATCM1 - 64KB
>>> BTCM1 - 64KB
>>> else: (split mode)
>>> ATCM0 - 64KB
>>> BTCM0 - 64KB
>>>
>>>
>>> If bindings are getting complicated, does it make sense to introduce
>>> new file for Versal-NET bindings? Let me know how you would like me
>>> to proceed.
>>
>> All this is broken in your previous patchset, but now we nicely see.
>>
>> No, this does not work like this. You do not have entirely different
>> programming models in one device, don't you?
>>
>
> I don't understand what do you mean? Programming model is same. Only number
> of TCMs are changing based on configuration and platform. I can certainly
> list different compatible for different platforms as requested. But other than
> that not sure what needs to be fixed.
You cannot have same programming model with different memory mappings.
Anyway, please follow writing bindings rules: all of your different
devices must have dedicated compatible. I really though we talked about
two IPs on same SoC...
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 0/2] add uSDHC and SCMI nodes to the S32G2 SoC
From: Ghennadi Procopciuc @ 2024-03-20 7:38 UTC (permalink / raw)
To: Chester Lin, Shawn Guo
Cc: Andreas Farber, Matthias Brugger, Shawn Guo, Sascha Hauer,
Fabio Estevam, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Michael Turquette, Stephen Boyd, NXP S32 Linux Team,
Pengutronix Kernel Team, NXP Linux Team, linux-arm-kernel,
devicetree, linux-kernel, linux-clk, Ghennadi Procopciuc
In-Reply-To: <ZeKIjyFF0ftnr19q@linux-8mug>
On 3/2/24 04:01, Chester Lin wrote:
[...]
> Hi Shawn,
>
> Per the discussion in another thread, could you help to apply these two
> through the imx tree? Thanks!
>
> Chester
Hi Shawn,
I noticed that Chester's email was sent to you as a CC recipient, which
may cause it to be filtered out based on your inbox rules. This is why I
wanted to bring this thread to your attention and kindly ask you to
confirm whether these patches will be pulled through the imx tree.
Regards,
Ghennadi
_______________________________________________
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 7/8] drm: zynqmp_dp: Split off several helper functions
From: Tomi Valkeinen @ 2024-03-20 7:36 UTC (permalink / raw)
To: Sean Anderson
Cc: Michal Simek, David Airlie, linux-kernel, Daniel Vetter,
linux-arm-kernel, Laurent Pinchart, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, dri-devel
In-Reply-To: <20240319225122.3048400-8-sean.anderson@linux.dev>
On 20/03/2024 00:51, Sean Anderson wrote:
> In preparation for supporting compliance testing, split off several
> helper functions. No functional change intended.
>
> Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/xlnx/zynqmp_dp.c | 49 ++++++++++++++++++++++----------
> 1 file changed, 34 insertions(+), 15 deletions(-)
>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Tomi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] firmware: arm_scmi: perf: print domain name in error path
From: Peng Fan (OSS) @ 2024-03-20 7:42 UTC (permalink / raw)
To: sudeep.holla, cristian.marussi; +Cc: linux-arm-kernel, linux-kernel, Peng Fan
From: Peng Fan <peng.fan@nxp.com>
It would be easier to locate the problem if domain name is printed out.
And including a coding style update.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/firmware/arm_scmi/perf.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/firmware/arm_scmi/perf.c b/drivers/firmware/arm_scmi/perf.c
index 345fff167b52..e98ca6d15b0c 100644
--- a/drivers/firmware/arm_scmi/perf.c
+++ b/drivers/firmware/arm_scmi/perf.c
@@ -79,7 +79,7 @@ struct scmi_msg_resp_perf_domain_attributes {
__le32 rate_limit_us;
__le32 sustained_freq_khz;
__le32 sustained_perf_level;
- u8 name[SCMI_SHORT_NAME_MAX_SIZE];
+ u8 name[SCMI_SHORT_NAME_MAX_SIZE];
};
struct scmi_msg_perf_describe_levels {
@@ -387,8 +387,8 @@ process_response_opp(struct device *dev, struct perf_dom_info *dom,
ret = xa_insert(&dom->opps_by_lvl, opp->perf, opp, GFP_KERNEL);
if (ret)
- dev_warn(dev, "Failed to add opps_by_lvl at %d - ret:%d\n",
- opp->perf, ret);
+ dev_warn(dev, "Failed to add opps_by_lvl at %d for %s- ret:%d\n",
+ opp->perf, dom->info.name, ret);
}
static inline void
@@ -405,8 +405,8 @@ process_response_opp_v4(struct device *dev, struct perf_dom_info *dom,
ret = xa_insert(&dom->opps_by_lvl, opp->perf, opp, GFP_KERNEL);
if (ret)
- dev_warn(dev, "Failed to add opps_by_lvl at %d - ret:%d\n",
- opp->perf, ret);
+ dev_warn(dev, "Failed to add opps_by_lvl at %d for %s - ret:%d\n",
+ opp->perf, dom->info.name, ret);
/* Note that PERF v4 reports always five 32-bit words */
opp->indicative_freq = le32_to_cpu(r->opp[loop_idx].indicative_freq);
--
2.37.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v4 4/5] mikrobus: Add mikroBUS driver
From: Krzysztof Kozlowski @ 2024-03-20 7:33 UTC (permalink / raw)
To: Ayush Singh, open list
Cc: jkridner, robertcnelson, lorforlinux, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Nishanth Menon,
Vignesh Raghavendra, Tero Kristo, Derek Kiernan, Dragan Cvetic,
Arnd Bergmann, Greg Kroah-Hartman, Vaishnav M A, Mark Brown,
Johan Hovold, Alex Elder,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/TEXAS INSTRUMENTS K3 ARCHITECTURE,
open list:SPI SUBSYSTEM, moderated list:GREYBUS SUBSYSTEM,
Vaishnav M A
In-Reply-To: <89ec1649-5231-422e-9760-6e04b2a514fd@gmail.com>
On 19/03/2024 07:47, Ayush Singh wrote:
> On 3/19/24 11:34, Krzysztof Kozlowski wrote:
>
>> On 17/03/2024 20:37, Ayush Singh wrote:
>>> DONOTMERGE
>>>
>>> this patch depends on Patch 1, 2, 3
>> So none of your work should be reviewed? I don't understand this, but in
>> such case I am not going to review it.
>>
>> Best regards,
>> Krzysztof
>>
> I am a bit lost here. It was mentioned in the patch v3 that I should
> specify the interdependence of patches in v3. And now you are saying I
> should not?
>
> Here is the rationale for the dependence:
>
> 1. Any changes to the property names in dt-bindings patch 1 will need an
> appropriate change here.
>
> 2. This patch will fail to build without patch 2.
>
> 3. This patch will fail to build without patch 3.
This is a natural ordering of patches... but the point is that it makes
ZERO sense once applied to Git repo. Your commit *MUST* make sense in
the Git. Now it does not.
Explain in cover letter what is the merging strategy. You can also
mention in patch changelog (---) that one patch must be applied
toogether with another.
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 3/3] ARM: dts: renesas: rcar-gen2: Add TMU nodes
From: Wolfram Sang @ 2024-03-20 7:31 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Magnus Damm, Niklas Söderlund, linux-renesas-soc,
linux-arm-kernel
In-Reply-To: <7efbc8dbac6876f454011563edc1ae8eb50c95db.1710864964.git.geert+renesas@glider.be>
[-- Attachment #1.1: Type: text/plain, Size: 434 bytes --]
On Tue, Mar 19, 2024 at 05:29:07PM +0100, Geert Uytterhoeven wrote:
> Add device nodes for the Timer Units (TMU) on the R-Car H2 (R8A7790),
> M2-W (R8A7791), V2H (R8A7792), M2-N (R8A7793), and E2 (R8A7794) SoCs.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
I don't see anything wrong here, i.e. no obvious reason for TMU3 failing
on M2-W.
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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 v4 5/5] dts: ti: k3-am625-beagleplay: Add mikroBUS
From: Krzysztof Kozlowski @ 2024-03-20 7:31 UTC (permalink / raw)
To: Ayush Singh, open list
Cc: jkridner, robertcnelson, lorforlinux, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Nishanth Menon,
Vignesh Raghavendra, Tero Kristo, Derek Kiernan, Dragan Cvetic,
Arnd Bergmann, Greg Kroah-Hartman, Vaishnav M A, Mark Brown,
Johan Hovold, Alex Elder,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/TEXAS INSTRUMENTS K3 ARCHITECTURE,
open list:SPI SUBSYSTEM, moderated list:GREYBUS SUBSYSTEM,
Vaishnav M A
In-Reply-To: <3ed8c487-544b-4d72-b1e0-edb5baa8119b@gmail.com>
On 19/03/2024 07:34, Ayush Singh wrote:
>
> On 3/19/24 11:29, Krzysztof Kozlowski wrote:
>> On 17/03/2024 20:37, Ayush Singh wrote:
>>> DONOTMERGE
>> Why? Explain then the purpose of this patch.
>
> Well, it was suggested to have DONOTMERGE by Vaishnav in the patches
> until dt bindings have been approved, since this patch touches different
> subsystems. Here is the full context from v3:
>
>> The reasoning behind this is that these patches go in to separate maintainer trees and without the bindings merged first the device tree changes cannot be validated, thus it is a usual practice to get the bindings and driver merged first and the device tree changes to go in the next cycle. Another alternative is you can point to your fork with all the changes together.
This is some odd style of work. Please don't follow such advise.
>
>>> this patch depends on patch 1
>> How? I don't see any dependency.
>
> I think it is not allowed to have code in device tree unless a
> corresponding dt-binding exists for the device. And thus every time the
And you provided the binding.
> dt-binding changes, this patch also needs to change.So I thought it is
> dependent on patch 1.
But it is not a dependency. Dependency means something does not work
without another. Or something must be applied in the same branch as
another. None of the cases are here. Drop the statements.
This is no different than all of our regular works. Do you see any of
such comments ("dont merge", "dependency")? No.
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 v1 2/2] media: i2c: Add GC05A2 image sensor driver
From: Sakari Ailus @ 2024-03-20 7:29 UTC (permalink / raw)
To: Zhi Mao
Cc: mchehab, robh+dt, krzysztof.kozlowski+dt, laurent.pinchart,
shengnan.wang, yaya.chang, Project_Global_Chrome_Upstream_Group,
yunkec, conor+dt, matthias.bgg, angelogioacchino.delregno,
jacopo.mondi, 10572168, hverkuil-cisco, heiko, jernej.skrabec,
macromorgan, linus.walleij, hdegoede, tomi.valkeinen,
gerald.loacker, andy.shevchenko, bingbu.cao, dan.scally,
linux-media, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20240316025253.2300-3-zhi.mao@mediatek.com>
Hi Zhi,
Thanks for the set.
On Sat, Mar 16, 2024 at 10:52:53AM +0800, Zhi Mao wrote:
> +static int gc05a2_set_ctrl(struct v4l2_ctrl *ctrl)
> +{
> + struct gc05a2 *gc05a2 =
> + container_of(ctrl->handler, struct gc05a2, ctrls);
> + int ret = 0;
> + s64 exposure_max;
> + struct v4l2_subdev_state *state;
> + const struct v4l2_mbus_framefmt *format;
> +
> + state = v4l2_subdev_get_locked_active_state(&gc05a2->sd);
> + format = v4l2_subdev_state_get_format(state, 0);
> +
> + if (ctrl->id == V4L2_CID_VBLANK) {
> + /* Update max exposure while meeting expected vblanking */
> + exposure_max = format->height + ctrl->val - GC05A2_EXP_MARGIN;
> + __v4l2_ctrl_modify_range(gc05a2->exposure,
> + gc05a2->exposure->minimum,
> + exposure_max, gc05a2->exposure->step,
> + exposure_max);
> + }
> +
> + /*
> + * Applying V4L2 control value only happens
> + * when power is on for streaming.
> + */
> + if (!pm_runtime_get_if_in_use(gc05a2->dev))
This should be pm_runtime_get_if_active(). Please assume it takes a single
argument (the device)---see commit
c0ef3df8dbaef51ee4cfd58a471adf2eaee6f6b3.
The same comment applies to the GC08A3 if it uses autosuspend, please post
a new patch for that.
--
Kind regards,
Sakari Ailus
_______________________________________________
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 v4 1/3] clk: samsung: Implement manual PLL control for ARM64 SoCs
From: Krzysztof Kozlowski @ 2024-03-20 7:23 UTC (permalink / raw)
To: Sam Protsenko
Cc: Sylwester Nawrocki, Chanwoo Choi, Alim Akhtar, Michael Turquette,
Stephen Boyd, Rob Herring, Conor Dooley, Tomasz Figa,
linux-samsung-soc, linux-clk, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <CAPLW+4=_yD3ShU5DvLWFyEzVrVHNVCsB+4bVkP+x_boRmC-vEw@mail.gmail.com>
On 19/03/2024 19:47, Sam Protsenko wrote:
> On Thu, Feb 29, 2024 at 7:51 PM Sam Protsenko
> <semen.protsenko@linaro.org> wrote:
>>
>> Some ARM64 Exynos chips are capable to control PLL clocks automatically.
>> For those chips, whether the PLL is controlled automatically or manually
>> is chosen in PLL_CON1 register with next bits:
>>
>> [28] ENABLE_AUTOMATIC_CLKGATING
>> [1] MANUAL_PLL_CTRL
>> [0] AUTO_PLL_CTRL
>>
>> The bl2 bootloader sets 0x10000001 value for some PLL_CON1 registers,
>> which means any attempt to control those PLLs manually (e.g.
>> disabling/enabling those PLLs or changing MUX parent clocks) would lead
>> to PLL lock timeout with error message like this:
>>
>> Could not lock PLL ...
>>
>> At the moment, all Samsung clock drivers implement manual clock control.
>> So in order to make it possible to control PLLs, corresponding PLL_CON1
>> registers should be set to 0x2 first.
>>
>> Some older ARM64 chips don't implement the automatic clock control
>> though. It also might be desirable to configure some PLLs for manual
>> control, while keeping the default configuration for the rest. So it'd
>> convenient to choose this PLL mode for each CMU separately. Introduce
>> .manual_plls field to CMU structure to choose the PLL control mode.
>> Because it'll be initialized with "false" in all existing CMU
>> structures by default, it won't affect any existing clock drivers,
>> allowing for this feature to be enabled gradually when it's needed with
>> no change for the rest of users. In case .manual_plls is set, set
>> PLL_CON1 registers to manual control, akin to what's already done for
>> gate clocks in exynos_arm64_init_clocks(). Of course, PLL_CON1 registers
>> should be added to corresponding struct samsung_cmu_info::clk_regs array
>> to make sure they get initialized.
>>
>> No functional change. This patch adds a feature, but doesn't enable it
>> for any users.
>>
>> Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
>> ---
>
> Hi Krzysztof,
>
> If it looks ok to you, can you please apply this series?
>
> [PATCH 1/3] clk: samsung: Implement manual PLL control for ARM64 SoCs
> [PATCH 2/3] clk: samsung: exynos850: Add CMU_CPUCL0 and CMU_CPUCL1
> [PATCH 3/3] arm64: dts: exynos: Add CPU clocks for Exynos850
>
> That concludes my efforts on CPU clock enablement in Exynos850.
Please do not ping during merge window, for anything else than fixes
(and me only for fixes being serious regressions or serious issues, not
for fixing something which never worked thus will not get to fixes
branch). Not only me, but don't ping that way any of the maintainers.
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
* [soc:soc/late] BUILD SUCCESS 72ebb41b88f9d7c10c5e159e0507074af0a22fe2
From: kernel test robot @ 2024-03-20 7:20 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, arm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git soc/late
branch HEAD: 72ebb41b88f9d7c10c5e159e0507074af0a22fe2 soc: fsl: dpio: fix kcalloc() argument order
elapsed time: 865m
configs tested: 195
configs skipped: 4
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc
alpha allyesconfig gcc
alpha defconfig gcc
arc allmodconfig gcc
arc allnoconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc haps_hs_smp_defconfig gcc
arc randconfig-001-20240320 gcc
arc randconfig-002-20240320 gcc
arc vdk_hs38_smp_defconfig gcc
arm allmodconfig gcc
arm allnoconfig clang
arm allyesconfig gcc
arm defconfig clang
arm lpc18xx_defconfig clang
arm mmp2_defconfig gcc
arm mv78xx0_defconfig clang
arm pxa910_defconfig gcc
arm randconfig-001-20240320 gcc
arm randconfig-002-20240320 gcc
arm randconfig-003-20240320 gcc
arm randconfig-004-20240320 gcc
arm rpc_defconfig clang
arm vf610m4_defconfig gcc
arm64 allmodconfig clang
arm64 allnoconfig gcc
arm64 defconfig gcc
arm64 randconfig-001-20240320 clang
arm64 randconfig-002-20240320 gcc
arm64 randconfig-003-20240320 clang
arm64 randconfig-004-20240320 clang
csky allmodconfig gcc
csky allnoconfig gcc
csky allyesconfig gcc
csky defconfig gcc
csky randconfig-001-20240320 gcc
csky randconfig-002-20240320 gcc
hexagon allmodconfig clang
hexagon allnoconfig clang
hexagon allyesconfig clang
hexagon defconfig clang
hexagon randconfig-001-20240320 clang
hexagon randconfig-002-20240320 clang
i386 allmodconfig gcc
i386 allnoconfig gcc
i386 allyesconfig gcc
i386 buildonly-randconfig-001-20240320 clang
i386 buildonly-randconfig-002-20240320 gcc
i386 buildonly-randconfig-003-20240320 gcc
i386 buildonly-randconfig-004-20240320 clang
i386 buildonly-randconfig-005-20240320 gcc
i386 buildonly-randconfig-006-20240320 gcc
i386 defconfig clang
i386 randconfig-001-20240320 clang
i386 randconfig-002-20240320 clang
i386 randconfig-003-20240320 clang
i386 randconfig-004-20240320 clang
i386 randconfig-005-20240320 clang
i386 randconfig-006-20240320 gcc
i386 randconfig-011-20240320 clang
i386 randconfig-012-20240320 clang
i386 randconfig-013-20240320 clang
i386 randconfig-014-20240320 clang
i386 randconfig-015-20240320 gcc
i386 randconfig-016-20240320 clang
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch defconfig gcc
loongarch randconfig-001-20240320 gcc
loongarch randconfig-002-20240320 gcc
m68k allmodconfig gcc
m68k allnoconfig gcc
m68k allyesconfig gcc
m68k defconfig gcc
m68k m5275evb_defconfig gcc
microblaze allmodconfig gcc
microblaze allnoconfig gcc
microblaze allyesconfig gcc
microblaze defconfig gcc
microblaze mmu_defconfig gcc
mips allnoconfig gcc
mips allyesconfig gcc
mips cu1830-neo_defconfig gcc
mips decstation_64_defconfig gcc
mips ip28_defconfig gcc
mips maltaaprp_defconfig clang
mips maltasmvp_defconfig gcc
nios2 3c120_defconfig gcc
nios2 allmodconfig gcc
nios2 allnoconfig gcc
nios2 allyesconfig gcc
nios2 defconfig gcc
nios2 randconfig-001-20240320 gcc
nios2 randconfig-002-20240320 gcc
openrisc allnoconfig gcc
openrisc allyesconfig gcc
openrisc defconfig gcc
parisc allmodconfig gcc
parisc allnoconfig gcc
parisc allyesconfig gcc
parisc defconfig gcc
parisc randconfig-001-20240320 gcc
parisc randconfig-002-20240320 gcc
parisc64 defconfig gcc
powerpc allmodconfig gcc
powerpc allnoconfig gcc
powerpc allyesconfig clang
powerpc chrp32_defconfig clang
powerpc iss476-smp_defconfig gcc
powerpc motionpro_defconfig clang
powerpc randconfig-001-20240320 gcc
powerpc randconfig-002-20240320 clang
powerpc randconfig-003-20240320 gcc
powerpc sam440ep_defconfig gcc
powerpc socrates_defconfig gcc
powerpc tqm8541_defconfig clang
powerpc walnut_defconfig gcc
powerpc wii_defconfig gcc
powerpc xes_mpc85xx_defconfig gcc
powerpc64 randconfig-001-20240320 gcc
powerpc64 randconfig-002-20240320 gcc
powerpc64 randconfig-003-20240320 gcc
riscv allmodconfig clang
riscv allnoconfig gcc
riscv allyesconfig clang
riscv defconfig clang
riscv randconfig-001-20240320 clang
riscv randconfig-002-20240320 gcc
s390 allmodconfig clang
s390 allnoconfig clang
s390 allyesconfig gcc
s390 defconfig clang
s390 randconfig-001-20240320 clang
s390 randconfig-002-20240320 clang
sh allmodconfig gcc
sh allnoconfig gcc
sh allyesconfig gcc
sh defconfig gcc
sh j2_defconfig gcc
sh randconfig-001-20240320 gcc
sh randconfig-002-20240320 gcc
sh rsk7201_defconfig gcc
sh rts7751r2d1_defconfig gcc
sh sh7757lcr_defconfig gcc
sparc allmodconfig gcc
sparc allnoconfig gcc
sparc defconfig gcc
sparc64 allmodconfig gcc
sparc64 allyesconfig gcc
sparc64 defconfig gcc
sparc64 randconfig-001-20240320 gcc
sparc64 randconfig-002-20240320 gcc
um allmodconfig clang
um allnoconfig clang
um allyesconfig gcc
um defconfig clang
um i386_defconfig gcc
um randconfig-001-20240320 gcc
um randconfig-002-20240320 gcc
um x86_64_defconfig clang
x86_64 allnoconfig clang
x86_64 allyesconfig clang
x86_64 buildonly-randconfig-001-20240320 gcc
x86_64 buildonly-randconfig-002-20240320 clang
x86_64 buildonly-randconfig-003-20240320 clang
x86_64 buildonly-randconfig-004-20240320 clang
x86_64 buildonly-randconfig-005-20240320 gcc
x86_64 buildonly-randconfig-006-20240320 clang
x86_64 defconfig gcc
x86_64 randconfig-001-20240320 clang
x86_64 randconfig-002-20240320 clang
x86_64 randconfig-003-20240320 gcc
x86_64 randconfig-004-20240320 clang
x86_64 randconfig-005-20240320 clang
x86_64 randconfig-006-20240320 clang
x86_64 randconfig-011-20240320 gcc
x86_64 randconfig-012-20240320 gcc
x86_64 randconfig-013-20240320 gcc
x86_64 randconfig-014-20240320 gcc
x86_64 randconfig-015-20240320 clang
x86_64 randconfig-016-20240320 gcc
x86_64 randconfig-071-20240320 clang
x86_64 randconfig-072-20240320 gcc
x86_64 randconfig-073-20240320 clang
x86_64 randconfig-074-20240320 gcc
x86_64 randconfig-075-20240320 gcc
x86_64 randconfig-076-20240320 clang
x86_64 rhel-8.3-rust clang
xtensa allnoconfig gcc
xtensa cadence_csp_defconfig gcc
xtensa common_defconfig gcc
xtensa nommu_kc705_defconfig gcc
xtensa randconfig-001-20240320 gcc
xtensa randconfig-002-20240320 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
_______________________________________________
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 3/3] power: reset: add new gs101-poweroff driver
From: Krzysztof Kozlowski @ 2024-03-20 7:20 UTC (permalink / raw)
To: Alexey Klimov, sre, robh, krzysztof.kozlowski+dt, linux-pm,
devicetree, peter.griffin, robh+dt
Cc: conor+dt, linux-samsung-soc, semen.protsenko, linux-kernel,
klimov.linux, kernel-team, tudor.ambarus, andre.draszik,
saravanak, willmcvicker, alim.akhtar, linux-arm-kernel, elder
In-Reply-To: <20240320020549.71810-3-alexey.klimov@linaro.org>
On 20/03/2024 03:05, Alexey Klimov wrote:
> +
> + ret = devm_work_autocancel(dev, &gs101->shutdown_work,
> + gs101_shutdown_work_fn);
> + if (ret) {
> + dev_err(dev, "failed to register gs101 shutdown_work: %i\n", ret);
> + unregister_keyboard_notifier(&gs101->keyboard_nb);
> + return ret;
> + }
> +
> + gs101_poweroff_ctx = gs101;
> + platform_set_drvdata(pdev, gs101);
> +
> + /*
> + * At this point there is a chance that psci_sys_poweroff already
> + * registered as pm_power_off hook but unfortunately it cannot power
> + * off the gs101 SoC hence we are rewriting it here just as is.
> + */
> + pm_power_off = gs101_poweroff;
So that's a duplicated syscon power off driver. Why syscon does not
work? syscon_node_to_regmap() does not return correct regmap? If so,
this should be fixed instead of copying the driver with basically only
one difference.
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 2/3] arm64: dts: exynos: gs101: add poweroff node
From: Krzysztof Kozlowski @ 2024-03-20 7:15 UTC (permalink / raw)
To: Alexey Klimov, sre, robh, krzysztof.kozlowski+dt, linux-pm,
devicetree, peter.griffin, robh+dt
Cc: conor+dt, linux-samsung-soc, semen.protsenko, linux-kernel,
klimov.linux, kernel-team, tudor.ambarus, andre.draszik,
saravanak, willmcvicker, alim.akhtar, linux-arm-kernel, elder
In-Reply-To: <20240320020549.71810-2-alexey.klimov@linaro.org>
On 20/03/2024 03:05, Alexey Klimov wrote:
> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
> ---
> arch/arm64/boot/dts/exynos/google/gs101.dtsi | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> index 55e6bcb3689e..9def28393274 100644
> --- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> @@ -509,6 +509,13 @@ sysreg_apm: syscon@174204e0 {
> pmu_system_controller: system-controller@17460000 {
> compatible = "google,gs101-pmu", "syscon";
> reg = <0x17460000 0x10000>;
> +
> + poweroff {
> + compatible = "google,gs101-poweroff";
> + samsung,syscon-phandle = <&pmu_system_controller>;
This is just senseless... you are the child of pmu, as seen in this DTS.
You do not need to reference yourself (so the PMU)!
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] virtio_ring: Fix the stale index in available ring
From: Michael S. Tsirkin @ 2024-03-20 7:14 UTC (permalink / raw)
To: Gavin Shan
Cc: Will Deacon, virtualization, linux-kernel, jasowang, xuanzhuo,
yihyu, shan.gavin, linux-arm-kernel, Catalin Marinas, mochs
In-Reply-To: <3a6c8b23-af9c-47a7-8c22-8e0a78154bd3@redhat.com>
On Wed, Mar 20, 2024 at 03:24:16PM +1000, Gavin Shan wrote:
> On 3/20/24 10:49, Michael S. Tsirkin wrote:>
> > I think you are wasting the time with these tests. Even if it helps what
> > does this tell us? Try setting a flag as I suggested elsewhere.
> > Then check it in vhost.
> > Or here's another idea - possibly easier. Copy the high bits from index
> > into ring itself. Then vhost can check that head is synchronized with
> > index.
> >
> > Warning: completely untested, not even compiled. But should give you
> > the idea. If this works btw we should consider making this official in
> > the spec.
> >
> >
> > static inline int vhost_get_avail_flags(struct vhost_virtqueue *vq,
> > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> > index 6f7e5010a673..79456706d0bd 100644
> > --- a/drivers/virtio/virtio_ring.c
> > +++ b/drivers/virtio/virtio_ring.c
> > @@ -685,7 +685,8 @@ static inline int virtqueue_add_split(struct virtqueue *_vq,
> > /* Put entry in available array (but don't update avail->idx until they
> > * do sync). */
> > avail = vq->split.avail_idx_shadow & (vq->split.vring.num - 1);
> > - vq->split.vring.avail->ring[avail] = cpu_to_virtio16(_vq->vdev, head);
> > + u16 headwithflag = head | (q->split.avail_idx_shadow & ~(vq->split.vring.num - 1));
> > + vq->split.vring.avail->ring[avail] = cpu_to_virtio16(_vq->vdev, headwithflag);
> > /* Descriptors and available array need to be set before we expose the
> > * new available array entries. */
> >
> > diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> > index 045f666b4f12..bd8f7c763caa 100644
> > --- a/drivers/vhost/vhost.c
> > +++ b/drivers/vhost/vhost.c
> > @@ -1299,8 +1299,15 @@ static inline int vhost_get_avail_idx(struct vhost_virtqueue *vq,
> > static inline int vhost_get_avail_head(struct vhost_virtqueue *vq,
> > __virtio16 *head, int idx)
> > {
> > - return vhost_get_avail(vq, *head,
> > + unsigned i = idx;
> > + unsigned flag = i & ~(vq->num - 1);
> > + unsigned val = vhost_get_avail(vq, *head,
> > &vq->avail->ring[idx & (vq->num - 1)]);
> > + unsigned valflag = val & ~(vq->num - 1);
> > +
> > + WARN_ON(valflag != flag);
> > +
> > + return val & (vq->num - 1);
> > }
>
> Thanks, Michael. The code is already self-explanatory.
Apparently not. See below.
> Since vq->num is 256, I just
> squeezed the last_avail_idx to the high byte. Unfortunately, I'm unable to hit
> the WARN_ON(). Does it mean the low byte is stale (or corrupted) while the high
> byte is still correct and valid?
I would find this very surprising.
> avail = vq->split.avail_idx_shadow & (vq->split.vring.num - 1);
> vq->split.vring.avail->ring[avail] =
> cpu_to_virtio16(_vq->vdev, head | (avail << 8));
>
>
> head = vhost16_to_cpu(vq, ring_head);
> WARN_ON((head >> 8) != (vq->last_avail_idx % vq->num));
> head = head & 0xff;
This code misses the point of the test.
The high value you store now is exactly the same each time you
go around the ring. E.g. at beginning of ring you now always
store 0 as high byte. So a stale value will not be detected/
The high value you store now is exactly the same each time you
go around the ring. E.g. at beginning of ring you now always
store 0 as high byte. So a stale value will not be detected.
The value you are interested in should change
each time you go around the ring a full circle.
Thus you want exactly the *high byte* of avail idx -
this is what my patch did - your patch instead
stored and compared the low byte.
The advantage of this debugging patch is that it will detect the issue immediately
not after guest detected the problem in the used ring.
For example, you can add code to re-read the value, or dump the whole
ring.
> One question: Does QEMU has any chance writing data to the available queue when
> vhost is enabled? My previous understanding is no, the queue is totally owned by
> vhost instead of QEMU.
It shouldn't do it normally.
> Before this patch was posted, I had debugging code to record last 16 transactions
> to the available and used queue from guest and host side. It did reveal the wrong
> head was fetched from the available queue.
Oh nice that's a very good hint. And is this still reproducible?
> [ 11.785745] ================ virtqueue_get_buf_ctx_split ================
> [ 11.786238] virtio_net virtio0: output.0:id 74 is not a head!
> [ 11.786655] head to be released: 036 077
> [ 11.786952]
> [ 11.786952] avail_idx:
> [ 11.787234] 000 63985 <--
> [ 11.787237] 001 63986
> [ 11.787444] 002 63987
> [ 11.787632] 003 63988
> [ 11.787821] 004 63989
> [ 11.788006] 005 63990
> [ 11.788194] 006 63991
> [ 11.788381] 007 63992
> [ 11.788567] 008 63993
> [ 11.788772] 009 63994
> [ 11.788957] 010 63995
> [ 11.789141] 011 63996
> [ 11.789327] 012 63997
> [ 11.789515] 013 63998
> [ 11.789701] 014 63999
> [ 11.789886] 015 64000
> [ 11.790068]
> [ 11.790068] avail_head:
> [ 11.790529] 000 075 <--
> [ 11.790718] 001 036
> [ 11.790890] 002 077
> [ 11.791061] 003 129
> [ 11.791231] 004 072
> [ 11.791400] 005 130
> [ 11.791574] 006 015
> [ 11.791748] 007 074
> [ 11.791918] 008 130
> [ 11.792094] 009 130
> [ 11.792263] 010 074
> [ 11.792437] 011 015
> [ 11.792617] 012 072
> [ 11.792788] 013 129
> [ 11.792961] 014 077 // The last two heads from guest to host: 077, 036
> [ 11.793134] 015 036
Maybe dump the avail ring from guest to make sure
it matches the expected contents?
> [root@nvidia-grace-hopper-05 qemu.main]# cat /proc/vhost
>
> avail_idx
> 000 63998
> 001 64000
> 002 63954 <---
> 003 63955
> 004 63956
> 005 63974
> 006 63981
> 007 63984
> 008 63986
> 009 63987
> 010 63988
> 011 63989
> 012 63992
> 013 63993
> 014 63995
> 015 63997
>
> avail_head
> 000 074
> 001 015
> 002 072
> 003 129
> 004 074 // The last two heads seen by vhost is: 074, 036
> 005 036
> 006 075 <---
And is 074 the previous (stale) value in the ring?
> 007 036
> 008 077
> 009 129
> 010 072
> 011 130
> 012 015
> 013 074
> 014 130
> 015 130
> used_idx
> 000 64000
> 001 63882 <---
> 002 63889
> 003 63891
> 004 63898
> 005 63936
> 006 63942
> 007 63946
> 008 63949
> 009 63953
> 010 63957
> 011 63981
> 012 63990
> 013 63992
> 014 63993
> 015 63999
>
> used_head
> 000 072
> 001 129
> 002 074 // The last two heads published to guest is: 074, 036
> 003 036
> 004 075 <---
> 005 036
> 006 077
> 007 129
> 008 072
> 009 130
> 010 015
> 011 074
> 012 130
> 013 130
> 014 074
> 015 015
>
> Thanks,
> Gavin
I like this debugging patch, it might make sense to
polish it up and include in production. We'll want it in
debugfs naturally not /proc/vhost.
But all in good time.
>
>
_______________________________________________
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/3] dt-bindings: power: reset: add gs101 poweroff bindings
From: Krzysztof Kozlowski @ 2024-03-20 7:14 UTC (permalink / raw)
To: Alexey Klimov, sre, robh, krzysztof.kozlowski+dt, linux-pm,
devicetree, peter.griffin, robh+dt
Cc: conor+dt, linux-samsung-soc, semen.protsenko, linux-kernel,
klimov.linux, kernel-team, tudor.ambarus, andre.draszik,
saravanak, willmcvicker, alim.akhtar, linux-arm-kernel, elder
In-Reply-To: <20240320020549.71810-1-alexey.klimov@linaro.org>
On 20/03/2024 03:05, Alexey Klimov wrote:
> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
Missing commit msg.
A nit, subject: drop second/last, redundant "bindings". The
"dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v6.7-rc8/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
> ---
> .../power/reset/google,gs101-poweroff.yaml | 54 +++++++++++++++++++
> 1 file changed, 54 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/reset/google,gs101-poweroff.yaml
>
> diff --git a/Documentation/devicetree/bindings/power/reset/google,gs101-poweroff.yaml b/Documentation/devicetree/bindings/power/reset/google,gs101-poweroff.yaml
> new file mode 100644
> index 000000000000..d704bf28294a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/reset/google,gs101-poweroff.yaml
> @@ -0,0 +1,54 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/power/reset/google,gs101-poweroff.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Google GS101 poweroff driver
Bindings are not for drivers, but hardware.
> +
> +maintainers:
> + - Alexey Klimov <alexey.klimov@linaro.org>
> +
> +description: |+
> + This is a Google Tensor gs101 poweroff driver using custom regmap
Bindings are not for drivers, but hardware.
> + to map the poweroff register. The poweroff itself is performed with
> + a write to the poweroff register from a privileged mode. Since generic
> + syscon does not support this, the specific one is required.
> + The write to the poweroff register is defined by the register map pointed
> + by syscon reference plus the offset with the value and mask defined
> + in the poweroff node.
> + Default will be little endian mode, 32 bit access only.
> +
> +properties:
> + compatible:
> + const: google,gs101-poweroff
> +
> + mask:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: Update only the register bits defined by the mask (32 bit).
> +
> + offset:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: Offset in the register map for the poweroff register (in bytes).
> +
> + samsung,syscon-phandle:
> + $ref: /schemas/types.yaml#/definitions/phandle
This does not look right. The poweroff handling is within PMU, not
somewhere else. Don't use syscons as a replacement of regular MMIO
addresses.
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] soc: renesas: Enable TMU support on R-Car Gen2
From: Wolfram Sang @ 2024-03-20 7:10 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Magnus Damm, Niklas Söderlund, linux-renesas-soc,
linux-arm-kernel
In-Reply-To: <b7b9fdd6f517a8b29bf5754e7f083d3b71805130.1710865761.git.geert+renesas@glider.be>
[-- Attachment #1.1: Type: text/plain, Size: 348 bytes --]
On Tue, Mar 19, 2024 at 05:29:55PM +0100, Geert Uytterhoeven wrote:
> All Renesas R-Car Gen2 SoCs have Timer Units (TMU). Enable support for
> them by selecting the SYS_SUPPORTS_SH_TMU gatekeeper config symbol.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/3] ARM: dts: renesas: Add more TMU support
From: Wolfram Sang @ 2024-03-20 7:08 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Magnus Damm, Niklas Söderlund, linux-renesas-soc,
linux-arm-kernel
In-Reply-To: <cover.1710864964.git.geert+renesas@glider.be>
[-- Attachment #1.1: Type: text/plain, Size: 405 bytes --]
Hi Geert,
> APE6 (APE6EVM), and on R-Car H2 (Lager) and M2-W (Koelsch), except for
> TMU3 on M2-W, which consistently fails the CLOCK_REALTIME test (why?).
Huh? It works on Lager and fails on Koelsch? Do you have a log file?
> Still to be queued in renesas-devel for v6.10?
I'd say yes, it still describes the HW. Unless it turns out that M2-W
doesn't really have TMU3 ;)
Happy hacking,
Wolfram
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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