* Re: [PATCH v12 06/11] mm/page_table_check: Reinstate address parameter in [__]page_table_check_pte_clear()
From: Pasha Tatashin @ 2024-04-03 23:46 UTC (permalink / raw)
To: Rohan McLure
Cc: linuxppc-dev, mpe, christophe.leroy, linux-mm, linux-riscv,
linux-arm-kernel, x86
In-Reply-To: <20240402051154.476244-7-rmclure@linux.ibm.com>
On Tue, Apr 2, 2024 at 1:11 AM Rohan McLure <rmclure@linux.ibm.com> wrote:
>
> This reverts commit aa232204c468 ("mm/page_table_check: remove unused
> parameter in [__]page_table_check_pte_clear").
>
> Reinstate previously unused parameters for the purpose of supporting
> powerpc platforms, as many do not encode user/kernel ownership of the
> page in the pte, but instead in the address of the access.
>
> Signed-off-by: Rohan McLure <rmclure@linux.ibm.com>
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.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 v12 07/11] mm: Provide address parameter to p{te,md,ud}_user_accessible_page()
From: Pasha Tatashin @ 2024-04-03 23:48 UTC (permalink / raw)
To: Rohan McLure
Cc: linuxppc-dev, mpe, christophe.leroy, linux-mm, linux-riscv,
linux-arm-kernel, x86
In-Reply-To: <20240402051154.476244-8-rmclure@linux.ibm.com>
On Tue, Apr 2, 2024 at 1:13 AM Rohan McLure <rmclure@linux.ibm.com> wrote:
>
> On several powerpc platforms, a page table entry may not imply whether
> the relevant mapping is for userspace or kernelspace. Instead, such
> platforms infer this by the address which is being accessed.
>
> Add an additional address argument to each of these routines in order to
> provide support for page table check on powerpc.
>
> Signed-off-by: Rohan McLure <rmclure@linux.ibm.com>
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.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 v12 08/11] powerpc: mm: Add pud_pfn() stub
From: Pasha Tatashin @ 2024-04-03 23:55 UTC (permalink / raw)
To: Rohan McLure
Cc: linuxppc-dev, mpe, christophe.leroy, linux-mm, linux-riscv,
linux-arm-kernel, x86
In-Reply-To: <20240402051154.476244-9-rmclure@linux.ibm.com>
On Tue, Apr 2, 2024 at 1:11 AM Rohan McLure <rmclure@linux.ibm.com> wrote:
>
> The page table check feature requires that pud_pfn() be defined
> on each consuming architecture. Since only 64-bit, Book3S platforms
> allow for hugepages at this upper level, and since the calling code is
> gated by a call to pud_user_accessible_page(), which will return zero,
> include this stub as a BUILD_BUG().
>
> Signed-off-by: Rohan McLure <rmclure@linux.ibm.com>
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.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 v12 09/11] poweprc: mm: Implement *_user_accessible_page() for ptes
From: Pasha Tatashin @ 2024-04-04 0:00 UTC (permalink / raw)
To: Rohan McLure
Cc: linuxppc-dev, mpe, christophe.leroy, linux-mm, linux-riscv,
linux-arm-kernel, x86
In-Reply-To: <20240402051154.476244-10-rmclure@linux.ibm.com>
On Tue, Apr 2, 2024 at 1:13 AM Rohan McLure <rmclure@linux.ibm.com> wrote:
>
> Page table checking depends on architectures providing an
> implementation of p{te,md,ud}_user_accessible_page. With
> refactorisations made on powerpc/mm, the pte_access_permitted() and
> similar methods verify whether a userland page is accessible with the
> required permissions.
>
> Since page table checking is the only user of
> p{te,md,ud}_user_accessible_page(), implement these for all platforms,
> using some of the same preliminary checks taken by pte_access_permitted()
> on that platform.
>
> Since Commit 8e9bd41e4ce1 ("powerpc/nohash: Replace pte_user() by pte_read()")
> pte_user() is no longer required to be present on all platforms as it
> may be equivalent to or implied by pte_read(). Hence implementations of
> pte_user_accessible_page() are specialised.
>
> Signed-off-by: Rohan McLure <rmclure@linux.ibm.com>
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.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 v12 10/11] powerpc: mm: Use set_pte_at_unchecked() for early-boot / internal usages
From: Pasha Tatashin @ 2024-04-04 0:12 UTC (permalink / raw)
To: Rohan McLure
Cc: linuxppc-dev, mpe, christophe.leroy, linux-mm, linux-riscv,
linux-arm-kernel, x86
In-Reply-To: <20240402051154.476244-11-rmclure@linux.ibm.com>
On Tue, Apr 2, 2024 at 1:13 AM Rohan McLure <rmclure@linux.ibm.com> wrote:
>
> In the new set_ptes() API, set_pte_at() (a special case of set_ptes())
> is intended to be instrumented by the page table check facility. There
> are however several other routines that constitute the API for setting
> page table entries, including set_pmd_at() among others. Such routines
> are themselves implemented in terms of set_ptes_at().
>
> A future patch providing support for page table checking on powerpc
> must take care to avoid duplicate calls to
> page_table_check_p{te,md,ud}_set(). Allow for assignment of pte entries
> without instrumentation through the set_pte_at_unchecked() routine
> introduced in this patch.
>
> Cause API-facing routines that call set_pte_at() to instead call
> set_pte_at_unchecked(), which will remain uninstrumented by page
> table check. set_ptes() is itself implemented by calls to
> __set_pte_at(), so this eliminates redundant code.
>
> Also prefer set_pte_at_unchecked() in early-boot usages which should not be
> instrumented.
Would not the early-boot usage be all kernel mappings that are ignored
by page table check anways? Sounds like it is better to only use the
set_pte_at_unchecked() version where it is really needed, which is to
avoid double counting. This will keep the usage of this function only
for one purpose that is easy to follow.
Pasha
_______________________________________________
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 v12 11/11] powerpc: mm: Support page table check
From: Pasha Tatashin @ 2024-04-04 0:16 UTC (permalink / raw)
To: Rohan McLure
Cc: linuxppc-dev, mpe, christophe.leroy, linux-mm, linux-riscv,
linux-arm-kernel, x86
In-Reply-To: <20240402051154.476244-12-rmclure@linux.ibm.com>
On Tue, Apr 2, 2024 at 1:13 AM Rohan McLure <rmclure@linux.ibm.com> wrote:
>
> On creation and clearing of a page table mapping, instrument such calls
> by invoking page_table_check_pte_set and page_table_check_pte_clear
> respectively. These calls serve as a sanity check against illegal
> mappings.
>
> Enable ARCH_SUPPORTS_PAGE_TABLE_CHECK for all platforms.
>
> See also:
>
> riscv support in commit 3fee229a8eb9 ("riscv/mm: enable
> ARCH_SUPPORTS_PAGE_TABLE_CHECK")
> arm64 in commit 42b2547137f5 ("arm64/mm: enable
> ARCH_SUPPORTS_PAGE_TABLE_CHECK")
> x86_64 in commit d283d422c6c4 ("x86: mm: add x86_64 support for page table
> check")
>
> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> Signed-off-by: Rohan McLure <rmclure@linux.ibm.com>
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Thank you for this work!
Pasha
_______________________________________________
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: dts: debix-a: Disable i2c2 in base .dts
From: Laurent Pinchart @ 2024-04-04 0:20 UTC (permalink / raw)
To: devicetree, imx, linux-arm-kernel
Cc: Jacopo Mondi, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Fabio Estevam, Sascha Hauer, Pengutronix Kernel Team,
Jacopo Mondi, Shawn Guo
From: Jacopo Mondi <jacopo@jmondi.org>
The I2C2 bus is used for the CSI and DSI connectors only, no devices are
connected to it on neither the Debix Model A nor its IO board. Disable
the bus in the board's .dts and remove its clock frequency settings, as
the value depends solely on the devices conncted to the CSI and DSI
connectors. Display panel or camera sensor overlays will configure and
enable the bus when necessary.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
---
Changes since v1:
- Don't drop the bus, just disable it
---
arch/arm64/boot/dts/freescale/imx8mp-debix-model-a.dts | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-debix-model-a.dts b/arch/arm64/boot/dts/freescale/imx8mp-debix-model-a.dts
index 2c19766ebf09..9b8f97a84e61 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-debix-model-a.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-debix-model-a.dts
@@ -197,10 +197,8 @@ ldo5: LDO5 {
};
&i2c2 {
- clock-frequency = <100000>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c2>;
- status = "okay";
};
&i2c3 {
base-commit: 4cece764965020c22cff7665b18a012006359095
--
Regards,
Laurent Pinchart
_______________________________________________
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] dt-bindings: watchdog: aspeed,ast2400-wdt: Convert to DT schema
From: Andrew Jeffery @ 2024-04-04 0:26 UTC (permalink / raw)
To: Rob Herring
Cc: wim, linux, krzysztof.kozlowski+dt, conor+dt, joel, zev,
linux-watchdog, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel
In-Reply-To: <20240403171321.GA3996007-robh@kernel.org>
On Wed, 2024-04-03 at 12:13 -0500, Rob Herring wrote:
> On Wed, Apr 03, 2024 at 12:34:39PM +1030, Andrew Jeffery wrote:
> > Squash warnings such as:
> >
> > ```
> > arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-galaxy100.dtb: /ahb/apb@1e600000/watchdog@1e785000: failed to match any schema with compatible: ['aspeed,ast2400-wdt']
> > ```
> >
> > The schema binding additionally defines the clocks property over the
> > prose binding to align with use of the node in the DTS files.
> >
> > Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
> > ---
> > v2: Address feedback from Rob and Zev
> >
> > - Rob: https://lore.kernel.org/linux-watchdog/20240402180718.GA358505-robh@kernel.org/
> > - Zev: https://lore.kernel.org/linux-watchdog/65722a59-2e94-4616-81e1-835615b0e600@hatter.bewilderbeest.net/
> >
> > v1: https://lore.kernel.org/linux-watchdog/20240402120118.282035-1-andrew@codeconstruct.com.au/
> >
> > .../bindings/watchdog/aspeed,ast2400-wdt.yaml | 142 ++++++++++++++++++
> > .../bindings/watchdog/aspeed-wdt.txt | 73 ---------
> > 2 files changed, 142 insertions(+), 73 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/watchdog/aspeed,ast2400-wdt.yaml
> > delete mode 100644 Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt
> >
> > diff --git a/Documentation/devicetree/bindings/watchdog/aspeed,ast2400-wdt.yaml b/Documentation/devicetree/bindings/watchdog/aspeed,ast2400-wdt.yaml
> > new file mode 100644
> > index 000000000000..be78a9865584
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/watchdog/aspeed,ast2400-wdt.yaml
> > @@ -0,0 +1,142 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/watchdog/aspeed,ast2400-wdt.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Aspeed watchdog timer controllers
> > +
> > +maintainers:
> > + - Andrew Jeffery <andrew@codeconstruct.com.au>
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - aspeed,ast2400-wdt
> > + - aspeed,ast2500-wdt
> > + - aspeed,ast2600-wdt
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + clocks:
> > + maxItems: 1
> > + description: >
>
> You don't need '>' either. I guess it is equivalent here as there are no
> double newlines. Drop these if you respin, otherwise:
>
> Reviewed-by: Rob Herring <robh@kernel.org>
Thanks. I've made a note for the future to avoid `>` if it's not
necessary, but at the time I figured it wasn't incorrect to include it.
Andrew
_______________________________________________
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/4] arm64: patching: always use fixmap
From: Masami Hiramatsu @ 2024-04-03 23:44 UTC (permalink / raw)
To: Catalin Marinas
Cc: Mark Rutland, linux-kernel, Will Deacon, anil.s.keshavamurthy,
aou, davem, jarkko, linux-arm-kernel, mhiramat, naveen.n.rao,
palmer, paul.walmsley
In-Reply-To: <Zg2XXmMb_wWS4fJH@arm.com>
On Wed, 3 Apr 2024 18:52:30 +0100
Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Wed, Apr 03, 2024 at 04:01:51PM +0100, Mark Rutland wrote:
> > For historical reasons, patch_map() won't bother to fixmap non-image
> > addresses when CONFIG_STRICT_MODULE_RWX=n, matching the behaviour prior
> > to the introduction of CONFIG_STRICT_MODULE_RWX. However, as arm64
> > doesn't select CONFIG_ARCH_OPTIONAL_KERNEL_RWX, CONFIG_MODULES implies
> > CONFIG_STRICT_MODULE_RWX, so any kernel built with module support will
> > use the fixmap for any non-image address.
> >
> > Historically we only used patch_map() for the kernel image and modules,
> > but these days its also used by BPF and KPROBES to write to read-only
> > pages of executable text. Currently these both depend on CONFIG_MODULES,
> > but we'd like to change that in subsequent patches, which will require
> > using the fixmap regardless of CONFIG_STRICT_MODULE_RWX.
> >
> > This patch changes patch_map() to always use the fixmap, and simplifies
> > the logic:
> >
> > * Use is_image_text() directly in the if-else, rather than using a
> > temporary boolean variable.
> >
> > * Use offset_in_page() to get the offset within the mapping.
> >
> > * Remove uintaddr and cast the address directly when using
> > is_image_text().
> >
> > For kernels built with CONFIG_MODULES=y, there should be no functional
> > change as a result of this patch.
> >
> > For kernels built with CONFIG_MODULES=n, patch_map() will use the fixmap
> > for non-image addresses, but there are no extant users with non-image
> > addresses when CONFIG_MODULES=n, and hence there should be no functional
> > change as a result of this patch alone.
> >
> > Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Will Deacon <will@kernel.org>
> > ---
> > arch/arm64/kernel/patching.c | 10 +++-------
> > 1 file changed, 3 insertions(+), 7 deletions(-)
> >
> > Catalin, Will, this is a prerequisite for the final two patches in the
> > series. Are you happy for this go via the tracing tree?
>
> Fine by me.
>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Thanks Catalin. I'll pick this series to linux-trace tree.
Thank you!
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
_______________________________________________
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/3] ARM: dts: Modify GPIO table for Asrock X570D4U BMC
From: Andrew Jeffery @ 2024-04-04 1:17 UTC (permalink / raw)
To: Renze Nicolai, linux-arm-kernel, devicetree, linux-kernel,
linux-aspeed, arnd, olof, soc, robh+dt, krzysztof.kozlowski+dt,
joel, andrew
In-Reply-To: <20240403133037.37782-2-renze@rnplus.nl>
Hi Renze,
In the future, the start of the subject should also include 'aspeed: ',
so:
ARM: dts: aspeed: Modify GPIO table for Asrock X570D4U BMC
On Wed, 2024-04-03 at 15:28 +0200, Renze Nicolai wrote:
> Restructure GPIO table to fit maximum line length.
>
> Fix mistakes found while working on OpenBMC
> userland configuration and based on probing
> the board.
>
> Schematic for this board is not available.
> Because of this the choice was made to
> use a descriptive method for naming the
> GPIOs.
>
> - Push-pull outputs start with output-*
> - Open-drain outputs start with control-*
> - LED outputs start with led-*
> - Inputs start with input-*
> - Button inputs start with button-*
> - Active low signals end with *-n
This seems to be a bit of a mix of following conventions in [1] and
not. It might be helpful to weigh in on that document with your ideas.
[1]: https://github.com/openbmc/docs/blob/master/designs/device-tree-gpio-naming.md
I'll put this series in a tree for Joel for now though, with the
subject fix mentioned above.
I've also re-wrapped the commit messages as it seems you stopped a bit
short of the allowable line length.
Andrew
_______________________________________________
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 v3 06/15] net: kunit: Suppress lock warning noise at end of dev_addr_lists tests
From: Jakub Kicinski @ 2024-04-04 1:34 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-kselftest, David Airlie, Arnd Bergmann, Maíra Canal,
Dan Carpenter, Kees Cook, Daniel Diaz, David Gow, Arthur Grillo,
Brendan Higgins, Naresh Kamboju, Maarten Lankhorst, Andrew Morton,
Maxime Ripard, Ville Syrjälä, Daniel Vetter,
Thomas Zimmermann, dri-devel, kunit-dev, linux-arch,
linux-arm-kernel, linux-doc, linux-kernel, linux-parisc,
linuxppc-dev, linux-riscv, linux-s390, linux-sh, loongarch,
netdev, x86, Linux Kernel Functional Testing, Eric Dumazet
In-Reply-To: <20240403131936.787234-7-linux@roeck-us.net>
On Wed, 3 Apr 2024 06:19:27 -0700 Guenter Roeck wrote:
> dev_addr_lists_test generates lock warning noise at the end of tests
> if lock debugging is enabled. There are two sets of warnings.
>
> WARNING: CPU: 0 PID: 689 at kernel/locking/mutex.c:923 __mutex_unlock_slowpath.constprop.0+0x13c/0x368
> DEBUG_LOCKS_WARN_ON(__owner_task(owner) != __get_current())
>
> WARNING: kunit_try_catch/1336 still has locks held!
>
> KUnit test cleanup is not guaranteed to run in the same thread as the test
> itself. For this test, this means that rtnl_lock() and rtnl_unlock() may
> be called from different threads. This triggers the warnings.
> Suppress the warnings because they are irrelevant for the test and just
> confusing and distracting.
>
> The first warning can be suppressed by using START_SUPPRESSED_WARNING()
> and END_SUPPRESSED_WARNING() around the call to rtnl_unlock(). To suppress
> the second warning, it is necessary to set debug_locks_silent while the
> rtnl lock is held.
Is it okay if I move the locking into the tests, instead?
It's only 4 lines more and no magic required, seems to work fine.
_______________________________________________
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/4] ARM: dts: aspeed: greatlakes: correct Mellanox multi-host property
From: Andrew Jeffery @ 2024-04-04 1:41 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Joel Stanley, devicetree, linux-arm-kernel,
linux-aspeed, linux-kernel
In-Reply-To: <171213860535.16780.4635499105199545058.b4-ty@linaro.org>
On Wed, 2024-04-03 at 12:04 +0200, Krzysztof Kozlowski wrote:
> On Sat, 09 Dec 2023 11:44:09 +0100, Krzysztof Kozlowski wrote:
> > "mlx,multi-host" is using incorrect vendor prefix and is not documented.
> >
> >
>
> These wait for ~4 months and they were not picked up. Let me know if anyone
> else wants to take these.
>
> Applied, thanks!
>
> [1/4] ARM: dts: aspeed: greatlakes: correct Mellanox multi-host property
> https://git.kernel.org/krzk/linux-dt/c/7da85354c4fa35b862294dbbb450baeb405b5a92
> [2/4] ARM: dts: aspeed: minerva-cmc: correct Mellanox multi-host property
> https://git.kernel.org/krzk/linux-dt/c/e515719c17beb9625a90039f6c45fa36d58bdda2
> [3/4] ARM: dts: aspeed: yosemite4: correct Mellanox multi-host property
> https://git.kernel.org/krzk/linux-dt/c/af3deaf9bcb4571feb89a4050c7ad75de9aa8e1e
> [4/4] ARM: dts: aspeed: yosemitev2: correct Mellanox multi-host property
> https://git.kernel.org/krzk/linux-dt/c/cac1c1dda6130771e06ace030b1b0ed62096a912
>
> Best regards,
Ah, my apologies. Joel's on leave and I'm accumulating patches in a
tree for him in the mean time. I've had some things going on
professionally (changed jobs) and personally, and these fell into a bit
of a hole.
I'm okay for these patches to be integrated through your tree, given
you've already applied them. Feel free to add acks if your branch
allows:
Acked-by: Andrew Jeffery <andrew@codeconstruct.com.au>
I'm working to stay on top of things a bit more now than I have in the
recent past, so hopefully I won't miss patches again in the future.
Andrew
_______________________________________________
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 v6 3/4] dt-bindings: watchdog: aspeed-wdt: Add aspeed,scu
From: Andrew Jeffery @ 2024-04-04 1:50 UTC (permalink / raw)
To: PeterYin, Rob Herring
Cc: patrick, Wim Van Sebroeck, Guenter Roeck, Krzysztof Kozlowski,
Conor Dooley, Joel Stanley, linux-watchdog, devicetree,
linux-arm-kernel, linux-aspeed, linux-kernel
In-Reply-To: <79b7e2ef-6f53-4642-ad3f-99b8ce780a7f@gmail.com>
On Wed, 2024-04-03 at 17:18 +0800, PeterYin wrote:
> Thanks, I can wait you update it and send a new version for wdt driver.
I've sent v2:
https://lore.kernel.org/linux-watchdog/20240403020439.418788-1-andrew@codeconstruct.com.au/
Rob's okay with it:
https://lore.kernel.org/linux-watchdog/20240403171321.GA3996007-robh@kernel.org/
Feel free to address his comment there if you integrate it into your
series, though make sure to add his tag, keep my authorship, and append
your own S-o-b if you do.
Andrew
_______________________________________________
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: mailbox: arm,mhuv3: Add bindings
From: kernel test robot @ 2024-04-04 2:01 UTC (permalink / raw)
To: Cristian Marussi, linux-kernel, linux-arm-kernel, devicetree
Cc: oe-kbuild-all, sudeep.holla, cristian.marussi, jassisinghbrar,
robh+dt, krzysztof.kozlowski+dt, conor+dt
In-Reply-To: <20240403171346.3173843-2-cristian.marussi@arm.com>
Hi Cristian,
kernel test robot noticed the following build warnings:
[auto build test WARNING on soc/for-next]
[also build test WARNING on robh/for-next linus/master v6.9-rc2 next-20240403]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Cristian-Marussi/dt-bindings-mailbox-arm-mhuv3-Add-bindings/20240404-012010
base: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git for-next
patch link: https://lore.kernel.org/r/20240403171346.3173843-2-cristian.marussi%40arm.com
patch subject: [PATCH v2 1/2] dt-bindings: mailbox: arm,mhuv3: Add bindings
compiler: loongarch64-linux-gcc (GCC) 13.2.0
reproduce: (https://download.01.org/0day-ci/archive/20240404/202404040918.E8nkWuIn-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202404040918.E8nkWuIn-lkp@intel.com/
dtcheck warnings: (new ones prefixed by >>)
>> Documentation/devicetree/bindings/mailbox/arm,mhuv3.yaml:86:1: [error] syntax error: found character '\t' that cannot start any token (syntax)
--
>> Documentation/devicetree/bindings/mailbox/arm,mhuv3.yaml:86:1: found a tab character where an indentation space is expected
--
>> Documentation/devicetree/bindings/mailbox/arm,mhuv3.yaml: ignoring, error parsing file
vim +86 Documentation/devicetree/bindings/mailbox/arm,mhuv3.yaml
8
9 maintainers:
10 - Sudeep Holla <sudeep.holla@arm.com>
11 - Cristian Marussi <cristian.marussi@arm.com>
12
13 description: |
14 The Arm Message Handling Unit (MHU) Version 3 is a mailbox controller that
15 enables unidirectional communications with remote processors through various
16 possible transport protocols.
17 The controller can optionally support a varying number of extensions that, in
18 turn, enable different kinds of transport to be used for communication.
19 Number, type and characteristics of each supported extension can be discovered
20 dynamically at runtime.
21
22 Given the unidirectional nature of the controller, an MHUv3 mailbox controller
23 is composed of a MHU Sender (MHUS) containing a PostBox (PBX) block and a MHU
24 Receiver (MHUR) containing a MailBox (MBX) block, where
25
26 PBX is used to
27 - Configure the MHU
28 - Send Transfers to the Receiver
29 - Optionally receive acknowledgment of a Transfer from the Receiver
30
31 MBX is used to
32 - Configure the MHU
33 - Receive Transfers from the Sender
34 - Optionally acknowledge Transfers sent by the Sender
35
36 Both PBX and MBX need to be present and defined in the DT description if you
37 need to establish a bidirectional communication, since you will have to
38 acquire two distinct unidirectional channels, one for each block.
39
40 As a consequence both blocks needs to be represented separately and specified
41 as distinct DT nodes in order to properly describe their resources.
42
43 Note that, though, thanks to the runtime discoverability, there is no need to
44 identify the type of blocks with distinct compatibles.
45
46 Following are the MHUv3 possible extensions.
47
48 - Doorbell Extension (DBE): DBE defines a type of channel called a Doorbell
49 Channel (DBCH). DBCH enables a single bit Transfer to be sent from the
50 Sender to Receiver. The Transfer indicates that an event has occurred.
51 When DBE is implemented, the number of DBCHs that an implementation of the
52 MHU can support is between 1 and 128, numbered starting from 0 in ascending
53 order and discoverable at run-time.
54 Each DBCH contains 32 individual fields, referred to as flags, each of which
55 can be used independently. It is possible for the Sender to send multiple
56 Transfers at once using a single DBCH, so long as each Transfer uses
57 a different flag in the DBCH.
58 Optionally, data may be transmitted through an out-of-band shared memory
59 region, wherein the MHU Doorbell is used strictly as an interrupt generation
60 mechanism, but this is out of the scope of these bindings.
61
62 - FastChannel Extension (FCE): FCE defines a type of channel called a Fast
63 Channel (FCH). FCH is intended for lower overhead communication between
64 Sender and Receiver at the expense of determinism. An FCH allows the Sender
65 to update the channel value at any time, regardless of whether the previous
66 value has been seen by the Receiver. When the Receiver reads the channel's
67 content it gets the last value written to the channel.
68 FCH is considered lossy in nature, and means that the Sender has no way of
69 knowing if, or when, the Receiver will act on the Transfer.
70 FCHs are expected to behave as RAM which generates interrupts when writes
71 occur to the locations within the RAM.
72 When FCE is implemented, the number of FCHs that an implementation of the
73 MHU can support is between 1-1024, if the FastChannel word-size is 32-bits,
74 or between 1-512, when the FastChannel word-size is 64-bits.
75 FCHs are numbered from 0 in ascending order.
76 Note that the number of FCHs and the word-size are implementation defined,
77 not configurable but discoverable at run-time.
78 Optionally, data may be transmitted through an out-of-band shared memory
79 region, wherein the MHU FastChannel is used as an interrupt generation
80 mechanism which carries also a pointer to such out-of-band data, but this
81 is out of the scope of these bindings.
82
83 - FIFO Extension (FE): FE defines a Channel type called a FIFO Channel (FFCH).
84 FFCH allows a Sender to send
85 - Multiple Transfers to the Receiver without having to wait for the
> 86 previous Transfer to be acknowledged by the Receiver, as long as the
87 FIFO has room for the Transfer.
88 - Transfers which require the Receiver to provide acknowledgment.
89 - Transfers which have in-band payload.
90 In all cases, the data is guaranteed to be observed by the Receiver in the
91 same order which the Sender sent it.
92 When FE is implemented, the number of FFCHs that an implementation of the
93 MHU can support is between 1 and 64, numbered starting from 0 in ascending
94 order. The number of FFCHs, their depth (same for all implemented FFCHs) and
95 the access-granularity are implementation defined, not configurable but
96 discoverable at run-time.
97 Optionally, additional data may be transmitted through an out-of-band shared
98 memory region, wherein the MHU FIFO is used to transmit, in order, a small
99 part of the payload (like a header) and a reference to the shared memory
100 area holding the remaining, bigger, chunk of the payload, but this is out of
101 the scope of these bindings.
102
103 properties:
104 compatible:
105 const: arm,mhuv3
106
107 reg:
108 maxItems: 1
109
110 interrupts:
111 minItems: 1
112 maxItems: 74
113
114 interrupt-names:
115 description: |
116 The MHUv3 controller generates a number of events some of which are used
117 to generate interrupts; as a consequence it can expose a varying number of
118 optional PBX/MBX interrupts, representing the events generated during the
119 operation of the various transport protocols associated with different
120 extensions. All interrupts of the MHU are level-sensitive.
121 Some of these optional interrupts are defined per-channel, where the
122 number of channels effectively available is implementation defined and
123 run-time discoverable.
124 In the following names are enumerated using patterns, with per-channel
125 interrupts implicitly capped at the maximum channels allowed by the
126 specification for each extension type.
127 For the sake of simplicity maxItems is anyway capped to a most plausible
128 number, assuming way less channels would be implemented than actually
129 possible.
130
131 The only mandatory interrupts on the MHU are:
132 - combined
133 - mbx-fch-xfer-<N> but only if mbx-fcgrp-xfer-<N> is not implemented.
134
135 minItems: 1
136 maxItems: 74
137 items:
138 oneOf:
139 - const: combined
140 description: PBX/MBX Combined interrupt
141 - const: combined-ffch
142 description: PBX/MBX FIFO Combined interrupt
143 - pattern: '^ffch-low-tide-[0-9]+$'
144 description: PBX/MBX FIFO Channel <N> Low Tide interrupt
145 - pattern: '^ffch-high-tide-[0-9]+$'
146 description: PBX/MBX FIFO Channel <N> High Tide interrupt
147 - pattern: '^ffch-flush-[0-9]+$'
148 description: PBX/MBX FIFO Channel <N> Flush interrupt
149 - pattern: '^mbx-dbch-xfer-[0-9]+$'
150 description: MBX Doorbell Channel <N> Transfer interrupt
151 - pattern: '^mbx-fch-xfer-[0-9]+$'
152 description: MBX FastChannel <N> Transfer interrupt
153 - pattern: '^mbx-fchgrp-xfer-[0-9]+$'
154 description: MBX FastChannel <N> Group Transfer interrupt
155 - pattern: '^mbx-ffch-xfer-[0-9]+$'
156 description: MBX FIFO Channel <N> Transfer interrupt
157 - pattern: '^pbx-dbch-xfer-ack-[0-9]+$'
158 description: PBX Doorbell Channel <N> Transfer Ack interrupt
159 - pattern: '^pbx-ffch-xfer-ack-[0-9]+$'
160 description: PBX FIFO Channel <N> Transfer Ack interrupt
161
162 '#mbox-cells':
163 description: |
164 The first argument in the consumers 'mboxes' property represents the
165 extension type, the second is for the channel number while the third
166 depends on extension type.
167
168 Extension type for DBE is 0 and the third parameter represents the
169 doorbell flag number to use.
170 Extension type for FCE is 1, third parameter unused.
171 Extension type for FE is 2, third parameter unused.
172
173 mboxes = <&mhu 0 0 5>; // DBE, Doorbell Channel Window 0, doorbell flag 5.
174 mboxes = <&mhu 0 1 7>; // DBE, Doorbell Channel Window 1, doorbell flag 7.
175 mboxes = <&mhu 1 0 0>; // FCE, FastChannel Window 0.
176 mboxes = <&mhu 1 3 0>; // FCE, FastChannel Window 3.
177 mboxes = <&mhu 2 1 0>; // FE, FIFO Channel Window 1.
178 mboxes = <&mhu 2 7 0>; // FE, FIFO Channel Window 7.
179 const: 3
180
181 clocks:
182 maxItems: 1
183
184 required:
185 - compatible
186 - reg
187 - interrupts
188 - interrupt-names
189 - '#mbox-cells'
190
--
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
* [PATCH] arm64: dts: imx8mp-debix-som-a-bmb-08: Remove 'phy-supply' from eqos
From: Fabio Estevam @ 2024-04-04 2:08 UTC (permalink / raw)
To: shawnguo; +Cc: linux-arm-kernel, laurent.pinchart, Fabio Estevam
From: Fabio Estevam <festevam@denx.de>
Per nxp,dwmac-imx.yaml, it is not valid to pass 'phy-supply'.
Remove it to fix the following dt-schema warning:
ethernet@30bf0000: Unevaluated properties are not allowed ('phy-supply' was unexpected)
from schema $id: http://devicetree.org/schemas/net/nxp,dwmac-imx.yaml#
Signed-off-by: Fabio Estevam <festevam@denx.de>
---
arch/arm64/boot/dts/freescale/imx8mp-debix-som-a-bmb-08.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-debix-som-a-bmb-08.dts b/arch/arm64/boot/dts/freescale/imx8mp-debix-som-a-bmb-08.dts
index b11d694b98e1..d241db3743a9 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-debix-som-a-bmb-08.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-debix-som-a-bmb-08.dts
@@ -144,7 +144,6 @@ &eqos {
pinctrl-0 = <&pinctrl_eqos>;
nvmem-cells = <ðmac1>;
nvmem-cell-names = "mac-address";
- phy-supply = <®_baseboard_vdd3v3>;
phy-handle = <ðphy0>;
phy-mode = "rgmii-id";
status = "okay";
--
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 v3 15/15] powerpc: Add support for suppressing warning backtraces
From: Michael Ellerman @ 2024-04-04 2:14 UTC (permalink / raw)
To: Guenter Roeck, linux-kselftest
Cc: David Airlie, Arnd Bergmann, Maíra Canal, Dan Carpenter,
Kees Cook, Daniel Diaz, David Gow, Arthur Grillo, Brendan Higgins,
Naresh Kamboju, Maarten Lankhorst, Andrew Morton, Maxime Ripard,
Ville Syrjälä, Daniel Vetter, Thomas Zimmermann,
dri-devel, kunit-dev, linux-arch, linux-arm-kernel, linux-doc,
linux-kernel, linux-parisc, linuxppc-dev, linux-riscv, linux-s390,
linux-sh, loongarch, netdev, x86, Guenter Roeck,
Linux Kernel Functional Testing
In-Reply-To: <20240403131936.787234-16-linux@roeck-us.net>
Guenter Roeck <linux@roeck-us.net> writes:
> Add name of functions triggering warning backtraces to the __bug_table
> object section to enable support for suppressing WARNING backtraces.
>
> To limit image size impact, the pointer to the function name is only added
> to the __bug_table section if both CONFIG_KUNIT_SUPPRESS_BACKTRACE and
> CONFIG_DEBUG_BUGVERBOSE are enabled. Otherwise, the __func__ assembly
> parameter is replaced with a (dummy) NULL parameter to avoid an image size
> increase due to unused __func__ entries (this is necessary because __func__
> is not a define but a virtual variable).
>
> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
> Acked-by: Dan Carpenter <dan.carpenter@linaro.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> ---
> v2:
> - Rebased to v6.9-rc1
> - Added Tested-by:, Acked-by:, and Reviewed-by: tags
> - Introduced KUNIT_SUPPRESS_BACKTRACE configuration option
> v3:
> - Rebased to v6.9-rc2
>
> arch/powerpc/include/asm/bug.h | 37 +++++++++++++++++++++++++---------
> 1 file changed, 28 insertions(+), 9 deletions(-)
I ran it through some build and boot tests, LGTM.
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
cheers
_______________________________________________
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] net: stmmac: fix rx queue priority assignment
From: patchwork-bot+netdevbpf @ 2024-04-04 2:30 UTC (permalink / raw)
To: Piotr Wejman
Cc: alexandre.torgue, joabreu, davem, edumazet, kuba, pabeni,
mcoquelin.stm32, Joao.Pinto, netdev, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <20240401192239.33942-1-piotrwejman90@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 1 Apr 2024 21:22:39 +0200 you wrote:
> The driver should ensure that same priority is not mapped to multiple
> rx queues. From DesignWare Cores Ethernet Quality-of-Service
> Databook, section 17.1.29 MAC_RxQ_Ctrl2:
> "[...]The software must ensure that the content of this field is
> mutually exclusive to the PSRQ fields for other queues, that is,
> the same priority is not mapped to multiple Rx queues[...]"
>
> [...]
Here is the summary with links:
- [v4] net: stmmac: fix rx queue priority assignment
https://git.kernel.org/netdev/net/c/b3da86d432b7
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
_______________________________________________
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 02/18] PCI: endpoint: Introduce pci_epc_map_align()
From: Damien Le Moal @ 2024-04-04 2:43 UTC (permalink / raw)
To: Kishon Vijay Abraham I, Manivannan Sadhasivam, Lorenzo Pieralisi,
Kishon Vijay Abraham I, Shawn Lin, Krzysztof Wilczyński,
Bjorn Helgaas, Heiko Stuebner, linux-pci, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree
Cc: linux-rockchip, linux-arm-kernel, Rick Wertenbroek,
Wilfred Mallawa, Niklas Cassel
In-Reply-To: <dccb87db-d826-43fa-a499-cf36ea9b10d5@amd.com>
On 4/3/24 21:33, Kishon Vijay Abraham I wrote:
> Hi Damien,
>
> On 3/30/2024 9:49 AM, Damien Le Moal wrote:
>> Some endpoint controllers have requirements on the alignment of the
>> controller physical memory address that must be used to map a RC PCI
>> address region. For instance, the rockchip endpoint controller uses
>> at most the lower 20 bits of a physical memory address region as the
>> lower bits of an RC PCI address. For mapping a PCI address region of
>> size bytes starting from pci_addr, the exact number of address bits
>> used is the number of address bits changing in the address range
>> [pci_addr..pci_addr + size - 1].
>>
>> For this example, this creates the following constraints:
>> 1) The offset into the controller physical memory allocated for a
>> mapping depends on the mapping size *and* the starting PCI address
>> for the mapping.
>> 2) A mapping size cannot exceed the controller windows size (1MB) minus
>> the offset needed into the allocated physical memory, which can end
>> up being a smaller size than the desired mapping size.
>>
>> Handling these constraints independently of the controller being used in
>> a PCI EP function driver is not possible with the current EPC API as
>> it only provides the ->align field in struct pci_epc_features.
>> Furthermore, this alignment is static and does not depend on a mapping
>> pci address and size.
>>
>> Solve this by introducing the function pci_epc_map_align() and the
>> endpoint controller operation ->map_align to allow endpoint function
>> drivers to obtain the size and the offset into a controller address
>> region that must be used to map an RC PCI address region. The size
>> of the physical address region provided by pci_epc_map_align() can then
>> be used as the size argument for the function pci_epc_mem_alloc_addr().
>> The offset into the allocated controller memory can be used to
>> correctly handle data transfers. Of note is that pci_epc_map_align() may
>> indicate upon return a mapping size that is smaller (but not 0) than the
>> requested PCI address region size. For such case, an endpoint function
>> driver must handle data transfers in fragments.
>>
>> The controller operation ->map_align is optional: controllers that do
>> not have any address alignment constraints for mapping a RC PCI address
>> region do not need to implement this operation. For such controllers,
>> pci_epc_map_align() always returns the mapping size as equal
>> to the requested size and an offset equal to 0.
>>
>> The structure pci_epc_map is introduced to represent a mapping start PCI
>> address, size and the size and offset into the controller memory needed
>> for mapping the PCI address region.
>>
>> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
>> ---
>> drivers/pci/endpoint/pci-epc-core.c | 66 +++++++++++++++++++++++++++++
>> include/linux/pci-epc.h | 33 +++++++++++++++
>> 2 files changed, 99 insertions(+)
>>
>> diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c
>> index 754afd115bbd..37758ca91d7f 100644
>> --- a/drivers/pci/endpoint/pci-epc-core.c
>> +++ b/drivers/pci/endpoint/pci-epc-core.c
>> @@ -433,6 +433,72 @@ void pci_epc_unmap_addr(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
>> }
>> EXPORT_SYMBOL_GPL(pci_epc_unmap_addr);
>>
>> +/**
>> + * pci_epc_map_align() - Get the offset into and the size of a controller memory
>> + * address region needed to map a RC PCI address region
>> + * @epc: the EPC device on which address is allocated
>> + * @func_no: the physical endpoint function number in the EPC device
>> + * @vfunc_no: the virtual endpoint function number in the physical function
>> + * @pci_addr: PCI address to which the physical address should be mapped
>> + * @size: the size of the mapping starting from @pci_addr
>> + * @map: populate here the actual size and offset into the controller memory
>> + * that must be allocated for the mapping
>> + *
>> + * Invoke the controller map_align operation to obtain the size and the offset
>> + * into a controller address region that must be allocated to map @size
>> + * bytes of the RC PCI address space starting from @pci_addr.
>> + *
>> + * The size of the mapping that can be handled by the controller is indicated
>> + * using the pci_size field of @map. This size may be smaller than the requested
>> + * @size. In such case, the function driver must handle the mapping using
>> + * several fragments. The offset into the controller memory for the effective
>> + * mapping of the @pci_addr..@pci_addr+@map->pci_size address range is indicated
>> + * using the map_ofst field of @map.
>> + */
>> +int pci_epc_map_align(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
>> + u64 pci_addr, size_t size, struct pci_epc_map *map)
>> +{
>> + const struct pci_epc_features *features;
>> + size_t mask;
>> + int ret;
>> +
>> + if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
>> + return -EINVAL;
>> +
>> + if (!size || !map)
>> + return -EINVAL;
>> +
>> + memset(map, 0, sizeof(*map));
>> + map->pci_addr = pci_addr;
>> + map->pci_size = size;
>> +
>> + if (epc->ops->map_align) {
>> + mutex_lock(&epc->lock);
>> + ret = epc->ops->map_align(epc, func_no, vfunc_no, map);
>> + mutex_unlock(&epc->lock);
>> + return ret;
>> + }
>> +
>> + /*
>> + * Assume a fixed alignment constraint as specified by the controller
>> + * features.
>> + */
>> + features = pci_epc_get_features(epc, func_no, vfunc_no);
>> + if (!features || !features->align) {
>> + map->map_pci_addr = pci_addr;
>> + map->map_size = size;
>> + map->map_ofst = 0;
>> + }
>
> The 'align' of pci_epc_features was initially added only to address the
> inbound ATU constraints. This is also added as comment in [1]. The PCI
> address restrictions (only fixed alignment constraint) were handled by
> the host side driver and depends on the connected endpoint device
> (atleast it was like that for pci_endpoint_test.c [2]).
> So pci-epf-test.c used the 'align' in pci_epc_features only as part of
> pci_epf_alloc_space().
>
> Though I have abused 'align' of pci_epc_features in pci-epf-ntb.c using
> it out of pci_epf_alloc_space(), I think we should keep the 'align' of
> pci_epc_features only within pci_epf_alloc_space() and controllers with
> any PCI address restrictions to implement ->map_align(). This could as
> well be done in a phased manner to let controllers implement
> ->map_align() and then remove using pci_epc_features in
> pci_epc_map_align(). Let me know what you think?
Yep, good idea. I will remove the use of "align" as a default alignment
constraint. For controllers that have a fixed alignment constraint (not
necessarilly epc->features->align), it is trivial to provide a generic helper
function that implements the ->map_align method.
--
Damien Le Moal
Western Digital Research
_______________________________________________
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] arm64: dts: imx8mp-debix-som-a-bmb-08: Remove 'phy-supply' from eqos
From: Laurent Pinchart @ 2024-04-04 3:21 UTC (permalink / raw)
To: Fabio Estevam
Cc: shawnguo, linux-arm-kernel, Fabio Estevam, Paul Elder, Umang Jain,
Kieran Bingham
In-Reply-To: <20240404020831.520120-1-festevam@gmail.com>
I don't have a SoM so I can't test this. Paul, Umang, Kieran, could one
of you review this patch ?
On Wed, Apr 03, 2024 at 11:08:31PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam@denx.de>
>
> Per nxp,dwmac-imx.yaml, it is not valid to pass 'phy-supply'.
>
> Remove it to fix the following dt-schema warning:
>
> ethernet@30bf0000: Unevaluated properties are not allowed ('phy-supply' was unexpected)
> from schema $id: http://devicetree.org/schemas/net/nxp,dwmac-imx.yaml#
>
> Signed-off-by: Fabio Estevam <festevam@denx.de>
> ---
> arch/arm64/boot/dts/freescale/imx8mp-debix-som-a-bmb-08.dts | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-debix-som-a-bmb-08.dts b/arch/arm64/boot/dts/freescale/imx8mp-debix-som-a-bmb-08.dts
> index b11d694b98e1..d241db3743a9 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp-debix-som-a-bmb-08.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-debix-som-a-bmb-08.dts
> @@ -144,7 +144,6 @@ &eqos {
> pinctrl-0 = <&pinctrl_eqos>;
> nvmem-cells = <ðmac1>;
> nvmem-cell-names = "mac-address";
> - phy-supply = <®_baseboard_vdd3v3>;
> phy-handle = <ðphy0>;
> phy-mode = "rgmii-id";
> status = "okay";
--
Regards,
Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/1] dt-bindings: media: imx-jpeg: add clocks,clock-names,slot to fix warning
From: Frank Li @ 2024-04-04 3:52 UTC (permalink / raw)
To: Mirela Rabulea, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
open list:NXP i.MX 8QXP/8QM JPEG V4L2 DRIVER,
open list:NXP i.MX 8QXP/8QM JPEG V4L2 DRIVER,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list
Cc: imx
Fix below DTB_CHECK warning.
make CHECK_DTBS=y freescale/imx8qxp-mek.dtb
DTC_CHK arch/arm64/boot/dts/freescale/imx8qxp-mek.dtb
arch/arm64/boot/dts/freescale/imx8qxp-mek.dtb: jpegdec@58400000: 'assigned-clock-rates', 'assigned-clocks', 'clock-names', 'clocks', 'slot' do not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/media/nxp,imx8-jpeg.yaml#
Add 'clocks' and 'clock-names' property.
Add 'slot' to choose which physical jpeg slot.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Notes:
Pass dtb_binding check
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j8 dt_binding_check DT_SCHEMA_FILES=nxp,imx8-jpeg.yaml
LINT Documentation/devicetree/bindings
DTEX Documentation/devicetree/bindings/media/nxp,imx8-jpeg.example.dts
CHKDT Documentation/devicetree/bindings/processed-schema.json
SCHEMA Documentation/devicetree/bindings/processed-schema.json
DTC_CHK Documentation/devicetree/bindings/media/nxp,imx8-jpeg.example.dtb
.../devicetree/bindings/media/nxp,imx8-jpeg.yaml | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml b/Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml
index 3d9d1db37040d..32820ec42de9d 100644
--- a/Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml
+++ b/Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml
@@ -31,6 +31,15 @@ properties:
reg:
maxItems: 1
+ clocks:
+ minItems: 2
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: per
+ - const: ipg
+
interrupts:
description: |
There are 4 slots available in the IP, which the driver may use
@@ -46,6 +55,12 @@ properties:
minItems: 2 # Wrapper and 1 slot
maxItems: 5 # Wrapper and 4 slots
+ slot:
+ description: Certain slot number is used.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 3
+
required:
- compatible
- reg
--
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 v5 02/10] dt-bindings: mailbox: Add mboxes property for CMDQ secure driver
From: Jason-JH Lin (林睿祥) @ 2024-04-04 4:31 UTC (permalink / raw)
To: Shawn Sung (宋孝謙), conor@kernel.org
Cc: linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
Houlong Wei (魏厚龙),
devicetree@vger.kernel.org, CK Hu (胡俊光),
conor+dt@kernel.org, robh@kernel.org,
linux-arm-kernel@lists.infradead.org,
krzysztof.kozlowski+dt@linaro.org, matthias.bgg@gmail.com,
jassisinghbrar@gmail.com, angelogioacchino.delregno@collabora.com
In-Reply-To: <20240403-conflict-detest-717b4175a00c@spud>
Hi Conor,
Thanks for the reviews.
On Wed, 2024-04-03 at 16:46 +0100, Conor Dooley wrote:
> On Wed, Apr 03, 2024 at 06:25:54PM +0800, Shawn Sung wrote:
> > From: "Jason-JH.Lin" <jason-jh.lin@mediatek.com>
> >
> > Add mboxes to define a GCE loopping thread as a secure irq handler.
> > This property is only required if CMDQ secure driver is supported.
> >
> > Signed-off-by: Jason-JH.Lin <jason-jh.lin@mediatek.com>
> > Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.com>
> > ---
> > .../bindings/mailbox/mediatek,gce-mailbox.yaml | 10
> > ++++++++++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/mailbox/mediatek,gce-
> > mailbox.yaml
> > b/Documentation/devicetree/bindings/mailbox/mediatek,gce-
> > mailbox.yaml
> > index cef9d76013985..c0d80cc770899 100644
> > --- a/Documentation/devicetree/bindings/mailbox/mediatek,gce-
> > mailbox.yaml
> > +++ b/Documentation/devicetree/bindings/mailbox/mediatek,gce-
> > mailbox.yaml
> > @@ -49,6 +49,16 @@ properties:
> > items:
> > - const: gce
> >
> > + mediatek,gce-events:
> > + description:
> > + The event id which is mapping to the specific hardware event
> > signal
> > + to gce. The event id is defined in the gce header
> > + include/dt-bindings/gce/<chip>-gce.h of each chips.
>
> Missing any info here about when this should be used, hint - you have
> it
> in the commit message.
>
> > + $ref: /schemas/types.yaml#/definitions/uint32-arrayi
>
> Why is the ID used by the CMDQ service not fixed for each SoC?
>
I forgot to sync with Shawn about this:
https://lore.kernel.org/all/20240124011459.12204-1-jason-
jh.lin@mediatek.com
I'll fix it at the next version.
Regards,
Jason-JH.Lin
> Cheers,
> Conor
_______________________________________________
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] arm64: tlb: Fix TLBI RANGE operand
From: Gavin Shan @ 2024-04-04 4:35 UTC (permalink / raw)
To: Marc Zyngier
Cc: linux-arm-kernel, linux-kernel, catalin.marinas, will, akpm,
apopple, mark.rutland, ryan.roberts, rananta, yangyicong,
v-songbaohua, yezhenyu2, yihyu, shan.gavin
In-Reply-To: <87jzlesgqy.wl-maz@kernel.org>
On 4/3/24 23:44, Marc Zyngier wrote:
> On Wed, 03 Apr 2024 12:37:30 +0100,
> Gavin Shan <gshan@redhat.com> wrote:
>>
>> On 4/3/24 18:58, Marc Zyngier wrote:
>>> On Wed, 03 Apr 2024 07:49:29 +0100,
>>> Gavin Shan <gshan@redhat.com> wrote:
>>>>
>>>> KVM/arm64 relies on TLBI RANGE feature to flush TLBs when the dirty
>>>> bitmap is collected by VMM and the corresponding PTEs need to be
>>>> write-protected again. Unfortunately, the operand passed to the TLBI
>>>> RANGE instruction isn't correctly sorted out by commit d1d3aa98b1d4
>>>> ("arm64: tlb: Use the TLBI RANGE feature in arm64"). It leads to
>>>> crash on the destination VM after live migration because some of the
>>>> dirty pages are missed.
>>>>
>>>> For example, I have a VM where 8GB memory is assigned, starting from
>>>> 0x40000000 (1GB). Note that the host has 4KB as the base page size.
>>>> All TLBs for VM can be covered by one TLBI RANGE operation. However,
>>>> I receives 0xffff708000040000 as the operand, which is wrong and the
>>>> correct one should be 0x00007f8000040000. From the wrong operand, we
>>>> have 3 and 1 for SCALE (bits[45:44) and NUM (bits943:39], only 1GB
>>>> instead of 8GB memory is covered.
>>>>
>>>> Fix the macro __TLBI_RANGE_NUM() so that the correct NUM and TLBI
>>>> RANGE operand are provided.
>>>>
>>>> Fixes: d1d3aa98b1d4 ("arm64: tlb: Use the TLBI RANGE feature in arm64")
>>>> Cc: stable@kernel.org # v5.10+
>>>> Reported-by: Yihuang Yu <yihyu@redhat.com>
>>>> Signed-off-by: Gavin Shan <gshan@redhat.com>
>>>> ---
>>>> arch/arm64/include/asm/tlbflush.h | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
>>>> index 3b0e8248e1a4..07c4fb4b82b4 100644
>>>> --- a/arch/arm64/include/asm/tlbflush.h
>>>> +++ b/arch/arm64/include/asm/tlbflush.h
>>>> @@ -166,7 +166,7 @@ static inline unsigned long get_trans_granule(void)
>>>> */
>>>> #define TLBI_RANGE_MASK GENMASK_ULL(4, 0)
>>>> #define __TLBI_RANGE_NUM(pages, scale) \
>>>> - ((((pages) >> (5 * (scale) + 1)) & TLBI_RANGE_MASK) - 1)
>>>> + ((((pages) >> (5 * (scale) + 1)) - 1) & TLBI_RANGE_MASK)
>>>> /*
>>>> * TLB Invalidation
>>>
>>> This looks pretty wrong, by the very definition of the comment that's
>>> just above:
>>>
>>> <quote>
>>> /*
>>> * Generate 'num' values from -1 to 30 with -1 rejected by the
>>> * __flush_tlb_range() loop below.
>>> */
>>> </quote>
>>>
>>> With your change, num can't ever be negative, and that breaks
>>> __flush_tlb_range_op():
>>>
>>> <quote>
>>> num = __TLBI_RANGE_NUM(pages, scale); \
>>> if (num >= 0) { \
>>> addr = __TLBI_VADDR_RANGE(start >> shift, asid, \
>>> scale, num, tlb_level); \
>>> __tlbi(r##op, addr); \
>>> if (tlbi_user) \
>>> __tlbi_user(r##op, addr); \
>>> start += __TLBI_RANGE_PAGES(num, scale) << PAGE_SHIFT; \
>>> pages -= __TLBI_RANGE_PAGES(num, scale); \
>>> } \
>>> scale--; \
>>> </quote>
>>>
>>> We'll then shove whatever value we've found in the TLBI operation,
>>> leading to unknown results instead of properly adjusting the scale to
>>> issue a smaller invalidation.
>>>
>>
>> Marc, thanks for your review and comments.
>>
>> Indeed, this patch is incomplete at least. I think we need __TLBI_RANGE_NUM()
>> to return [-1 31] instead of [-1 30], to be consistent with MAX_TLBI_RANGE_PAGES.
>> -1 will be rejected in the following loop. I'm not 100% sure if I did the correct
>> calculation though.
>>
>> /*
>> * Generate 'num' values in range [-1 31], but -1 will be rejected
>> * by the __flush_tlb_range() loop below.
>> */
>> #define __TLBI_RANGE_NUM(pages, scale) \
>> ({ \
>> int __next = (pages) & (1ULL << (5 * (scale) + 6)); \
>> int __mask = ((pages) >> (5 * (scale) + 1)) & TLBI_RANGE_MASK; \
>> int __num = (((pages) >> (5 * (scale) + 1)) - 1) & \
>> TLBI_RANGE_MASK; \
>> (__next || __mask) ? __num : -1; \
>> })
>
> I'm afraid I don't follow the logic here, and it looks awfully
> complex. I came up with something simpler with this:
>
> diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
> index 3b0e8248e1a4..b3f1a9c61189 100644
> --- a/arch/arm64/include/asm/tlbflush.h
> +++ b/arch/arm64/include/asm/tlbflush.h
> @@ -161,12 +161,18 @@ static inline unsigned long get_trans_granule(void)
> #define MAX_TLBI_RANGE_PAGES __TLBI_RANGE_PAGES(31, 3)
>
> /*
> - * Generate 'num' values from -1 to 30 with -1 rejected by the
> + * Generate 'num' values from -1 to 31 with -1 rejected by the
> * __flush_tlb_range() loop below.
> */
> #define TLBI_RANGE_MASK GENMASK_ULL(4, 0)
> -#define __TLBI_RANGE_NUM(pages, scale) \
> - ((((pages) >> (5 * (scale) + 1)) & TLBI_RANGE_MASK) - 1)
> +#define __TLBI_RANGE_NUM(pages, scale) \
> + ({ \
> + int __pages = min((pages), \
> + __TLBI_RANGE_PAGES(31, (scale))); \
> + int __numplus1 = __pages >> (5 * (scale) + 1); \
> + \
> + (__numplus1 - 1); \
> + })
>
Thanks, Marc. Both your changes and mine worked, my issue can be fixed at least.
Your version is certainly simpler and clearer. I will integrate your changes to
v2 with TLB_RANGE_MASK dropped since no one will uses it any more.
> /*
> * TLB Invalidation
> @@ -379,10 +385,6 @@ static inline void arch_tlbbatch_flush(struct arch_tlbflush_unmap_batch *batch)
> * 3. If there is 1 page remaining, flush it through non-range operations. Range
> * operations can only span an even number of pages. We save this for last to
> * ensure 64KB start alignment is maintained for the LPA2 case.
> - *
> - * Note that certain ranges can be represented by either num = 31 and
> - * scale or num = 0 and scale + 1. The loop below favours the latter
> - * since num is limited to 30 by the __TLBI_RANGE_NUM() macro.
> */
> #define __flush_tlb_range_op(op, start, pages, stride, \
> asid, tlb_level, tlbi_user, lpa2) \
>
>>
>> Alternatively, we can also limit the number of pages to be invalidated from
>> arch/arm64/kvm/hyp/pgtable.c::kvm_tlb_flush_vmid_range() because the maximal
>> capacity is (MAX_TLBI_RANGE_PAGES - 1) instead of MAX_TLBI_RANGE_PAGES, as
>> the comments for __flush_tlb_range_nosync() say.
>>
>> - inval_pages = min(pages, MAX_TLBI_RANGE_PAGES);
>> + inval_pages = min(pages, MAX_TLBI_RANGE_PAGES - 1);
>>
>>
>> static inline void __flush_tlb_range_nosync(...)
>> {
>> :
>> /*
>> * When not uses TLB range ops, we can handle up to
>> * (MAX_DVM_OPS - 1) pages;
>> * When uses TLB range ops, we can handle up to
>> * (MAX_TLBI_RANGE_PAGES - 1) pages.
>> */
>> if ((!system_supports_tlb_range() &&
>> (end - start) >= (MAX_DVM_OPS * stride)) ||
>> pages >= MAX_TLBI_RANGE_PAGES) {
>> flush_tlb_mm(vma->vm_mm);
>> return;
>> }
>> }
>>
>> Please let me know which way is better.
>
> I would really prefer to fix the range stuff itself instead of
> papering over the problem by reducing the reach of the range
> invalidation.
>
Yes, Agreed.
>>
>>> I think the problem is that you are triggering NUM=31 and SCALE=3,
>>> which the current code cannot handle as per the comment above
>>> __flush_tlb_range_op() (we can't do NUM=30 and SCALE=4, obviously).
>>>
>>
>> Yes, exactly.
>>
>>> Can you try the untested patch below?
>>>
>>>
>>> diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
>>> index 3b0e8248e1a4..b71a1cece802 100644
>>> --- a/arch/arm64/include/asm/tlbflush.h
>>> +++ b/arch/arm64/include/asm/tlbflush.h
>>> @@ -379,10 +379,6 @@ static inline void arch_tlbbatch_flush(struct arch_tlbflush_unmap_batch *batch)
>>> * 3. If there is 1 page remaining, flush it through non-range operations. Range
>>> * operations can only span an even number of pages. We save this for last to
>>> * ensure 64KB start alignment is maintained for the LPA2 case.
>>> - *
>>> - * Note that certain ranges can be represented by either num = 31 and
>>> - * scale or num = 0 and scale + 1. The loop below favours the latter
>>> - * since num is limited to 30 by the __TLBI_RANGE_NUM() macro.
>>> */
>>> #define __flush_tlb_range_op(op, start, pages, stride, \
>>> asid, tlb_level, tlbi_user, lpa2) \
>>> @@ -407,6 +403,7 @@ do { \
>>> \
>>> num = __TLBI_RANGE_NUM(pages, scale); \
>>> if (num >= 0) { \
>>> + num += 1; \
>>> addr = __TLBI_VADDR_RANGE(start >> shift, asid, \
>>> scale, num, tlb_level); \
>>> __tlbi(r##op, addr); \
>>>
>>
>> Thanks, but I don't think it's going to work. The loop will be running infinitely
>> because the condition 'if (num >= 0)' can't be met when @pages is 0x200000 when
>> @scale is 3/2/1/0 until @scale becomes negative and positive again, but @scale
>> isn't in range [0 3]. I ported the chunk of code to user-space and I can see this
>> with added printf() messages.
>
> Yeah, we lose num==0, which is silly. Hopefully the hack above helps a
> bit.
>
Yes, the hack works. Thank you again.
Thanks,
Gavin
_______________________________________________
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] KVM: arm64: Limit stage2_apply_range() batch size to smallest block
From: Krister Johansen @ 2024-04-04 4:40 UTC (permalink / raw)
To: Marc Zyngier
Cc: Oliver Upton, James Morse, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Ali Saidi, David Reaver,
linux-arm-kernel, kvmarm, linux-kernel
In-Reply-To: <20240402170052.GA1988@templeofstupid.com>
On Tue, Apr 02, 2024 at 10:00:53AM -0700, Krister Johansen wrote:
> On Sat, Mar 30, 2024 at 10:17:43AM +0000, Marc Zyngier wrote:
> > On Fri, 29 Mar 2024 19:15:37 +0000,
> > Krister Johansen <kjlx@templeofstupid.com> wrote:
> > > On Fri, Mar 29, 2024 at 06:48:38AM -0700, Oliver Upton wrote:
> > > > On Thu, Mar 28, 2024 at 12:05:08PM -0700, Krister Johansen wrote:
> > > > > Further reducing the stage2_apply_range() batch size has substantial
> > > > > performance improvements for IO that share a CPU performing an unmap
> > > > > operation. By switching to a 2mb chunk, IO performance regressions were
> > > > > no longer observed in this author's tests. E.g. it was possible to
> > > > > obtain the advertised device throughput despite an unmap operation
> > > > > occurring on the CPU where the interrupt was running. There is a
> > > > > tradeoff, however. No changes were observed in per-operation timings
> > > > > when running the kvm_pagetable_test without an interrupt load. However,
> > > > > with a 64gb VM, 1 vcpu, and 4k pages and a IO load, map times increased
> > > > > by about 15% and unmap times increased by about 58%. In essence, this
> > > > > trades slower map/unmap times for improved IO throughput.
> > > >
> > > > There are other users of the range-based operations, like
> > > > write-protection. Live migration is especially sensitive to the latency
> > > > of page table updates as it can affect the VMM's ability to converge
> > > > with the guest.
> > >
> > > To be clear, the reduction in performance was observed when I
> > > concurrently executed both the kvm_pagetable_test and a networking
> > > benchmark where the NIC's interrupts were assigned to the same CPU where
> > > the pagetable test was executing. I didn't see a slowdown just running
> > > the pagetable test.
> >
> > Any chance you could share more details about your HW configuration
> > (what CPU is that?) and the type of traffic? This is the sort of
> > things I'd like to be able to reproduce in order to experiment various
> > strategies.
>
> Sure, I only have access to documentation that is publicly available.
>
> The hardware where we ran into this inititally was Graviton 3, which is
> a Neoverse-V1 based core. It does not support FEAT_TLBIRANGE. I've
> also tested on Graviton 4, which is Neoverse-V2 based. It _does_
> support FEAT_TLBIRANGE. The deferred range based invalidation
> support, was enough to allow us to teardown a large VM based on 4k pages
> and not incur a visible performance penalty. I haven't had a chance to
> test to see if and how Will's patches change this, though.
Just a quick followup that I did test Will's patches and didn't find
that it changed the performance of the workload that I'd been testing.
IOW, I wasn't able to discern a network performance difference between
the baseline and those changes.
Thanks,
-K
_______________________________________________
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: tlb: Fix TLBI RANGE operand
From: Gavin Shan @ 2024-04-04 5:36 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, catalin.marinas, will, akpm, maz, oliver.upton,
mark.rutland, ryan.roberts, apopple, rananta, yangyicong,
v-songbaohua, yezhenyu2, yihyu, shan.gavin
KVM/arm64 relies on TLBI RANGE feature to flush TLBs when the dirty
bitmap is collected by VMM and the corresponding PTEs need to be
write-protected during live migration. Unfortunately, the operand
passed to the TLBI RANGE instruction isn't correctly sorted out by
commit d1d3aa98b1d4 ("arm64: tlb: Use the TLBI RANGE feature in arm64").
It leads to crash on the destination VM after live migration because
TLBs aren't flushed completely and some of the dirty pages are missed.
For example, I have a VM where 8GB memory is assigned, starting from
0x40000000 (1GB). Note that the host has 4KB as the base page size.
All TLBs for VM can be covered by one TLBI RANGE operation. However,
the operand 0xffff708000040000 is set for scale -9, and -1 is returned
from __TLBI_RANGE_NUM() for scale 3/2/1/0 and rejected by the loop in
__flush_tlb_range_op(). __TLBI_RANGE_NUM() isn't expected to work
like this because all the pages should be covered by scale 3/2/1/0,
plus an additional page if needed.
Fix the macro __TLBI_RANGE_NUM() so that the correct NUM and TLBI RANGE
operand are provided for each scale level. With the changes, [-1 31]
instead of [-1 30] can be returned from the macro, meaning the TLBs for
0x200000 pages (8GB memory) can be flushed in one shoot at scale 3. The
macro TLBI_RANGE_MASK is dropped since no one uses it any more.
Fixes: d1d3aa98b1d4 ("arm64: tlb: Use the TLBI RANGE feature in arm64")
Cc: stable@kernel.org # v5.10+
Reported-by: Yihuang Yu <yihyu@redhat.com>
Suggested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Gavin Shan <gshan@redhat.com>
---
v2: Improve __TLBI_RANGE_NUM() as Marc suggested
---
arch/arm64/include/asm/tlbflush.h | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
index 3b0e8248e1a4..cd9b71c30366 100644
--- a/arch/arm64/include/asm/tlbflush.h
+++ b/arch/arm64/include/asm/tlbflush.h
@@ -161,12 +161,17 @@ static inline unsigned long get_trans_granule(void)
#define MAX_TLBI_RANGE_PAGES __TLBI_RANGE_PAGES(31, 3)
/*
- * Generate 'num' values from -1 to 30 with -1 rejected by the
+ * Generate 'num' values from -1 to 31 with -1 rejected by the
* __flush_tlb_range() loop below.
*/
-#define TLBI_RANGE_MASK GENMASK_ULL(4, 0)
-#define __TLBI_RANGE_NUM(pages, scale) \
- ((((pages) >> (5 * (scale) + 1)) & TLBI_RANGE_MASK) - 1)
+#define __TLBI_RANGE_NUM(pages, scale) \
+ ({ \
+ int __pages = min((pages), \
+ __TLBI_RANGE_PAGES(31, (scale))); \
+ int __numplus1 = __pages >> (5 * (scale) + 1); \
+ \
+ (__numplus1 - 1); \
+ })
/*
* TLB Invalidation
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 2/2] arm64: dts: ti: k3-am642-phyboard-electra-rdk: Increase CAN max bitrate
From: Wadim Egorov @ 2024-04-04 5:44 UTC (permalink / raw)
To: Nathan Morrisson, nm, vigneshr, kristo, robh,
krzysztof.kozlowski+dt, conor+dt
Cc: linux-arm-kernel, devicetree, linux-kernel, upstream
In-Reply-To: <20240402160825.1516036-3-nmorrisson@phytec.com>
Am 02.04.24 um 18:08 schrieb Nathan Morrisson:
> The phyBOARD-Electra has two TCAN1044VDD CAN transceivers which
> support CAN FD at 8 Mbps.
>
> Increase the maximum bitrate to 8 Mbps.
>
> Signed-off-by: Nathan Morrisson <nmorrisson@phytec.com>
For both patches
Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
> ---
> arch/arm64/boot/dts/ti/k3-am642-phyboard-electra-rdk.dts | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am642-phyboard-electra-rdk.dts b/arch/arm64/boot/dts/ti/k3-am642-phyboard-electra-rdk.dts
> index 8237b8c815b8..522699ec65e8 100644
> --- a/arch/arm64/boot/dts/ti/k3-am642-phyboard-electra-rdk.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am642-phyboard-electra-rdk.dts
> @@ -42,7 +42,7 @@ can_tc1: can-phy0 {
> pinctrl-names = "default";
> pinctrl-0 = <&can_tc1_pins_default>;
> #phy-cells = <0>;
> - max-bitrate = <5000000>;
> + max-bitrate = <8000000>;
> standby-gpios = <&main_gpio0 32 GPIO_ACTIVE_HIGH>;
> };
>
> @@ -51,7 +51,7 @@ can_tc2: can-phy1 {
> pinctrl-names = "default";
> pinctrl-0 = <&can_tc2_pins_default>;
> #phy-cells = <0>;
> - max-bitrate = <5000000>;
> + max-bitrate = <8000000>;
> standby-gpios = <&main_gpio0 35 GPIO_ACTIVE_HIGH>;
> };
>
_______________________________________________
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