* Re: [PATCH V2 2/5] arm64: dts: ti: k3-am65*: Drop bootargs
From: Jan Kiszka @ 2023-04-19 14:47 UTC (permalink / raw)
To: Nishanth Menon, Krzysztof Kozlowski, Rob Herring,
Vignesh Raghavendra
Cc: linux-kernel, devicetree, linux-arm-kernel, Tero Kristo,
Krzysztof Kozlowski, Roger Quadros
In-Reply-To: <20230419141222.383567-3-nm@ti.com>
On 19.04.23 16:12, Nishanth Menon wrote:
> Drop bootargs from the dts. earlycon is a debug property that should be
> enabled only when debug is desired and not as default - see referenced
> link on discussion on this topic.
>
> Cc: Jan Kiszka <jan.kiszka@siemens.com>
> Link: https://lore.kernel.org/linux-arm-kernel/81134eb9-2b7d-05bc-3035-a47f020861a8@linaro.org/
> Suggested-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Reviewed-by: Roger Quadros <rogerq@kernel.org>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> Similar discussions can be seen in https://lore.kernel.org/linux-devicetree/?q=Krzysztof+bootargs
>
> Changes since v1:
> - improved commit message
> - picked up acks and reviews from Roger and Krzysztof
>
> V1: https://lore.kernel.org/r/20230418165212.1456415-3-nm@ti.com
>
> arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi | 1 -
> arch/arm64/boot/dts/ti/k3-am654-base-board.dts | 1 -
> 2 files changed, 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
> index 96ac2b476b11..7d256a1638ff 100644
> --- a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
> @@ -21,7 +21,6 @@ aliases {
>
> chosen {
> stdout-path = "serial3:115200n8";
> - bootargs = "earlycon=ns16550a,mmio32,0x02810000";
> };
>
> reserved-memory {
> diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
> index 592ab2b54cb3..0d6fc89eba7a 100644
> --- a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
> @@ -15,7 +15,6 @@ / {
>
> chosen {
> stdout-path = "serial2:115200n8";
> - bootargs = "earlycon=ns16550a,mmio32,0x02800000";
> };
>
> memory@80000000 {
For the IOT2050:
Acked-by: Jan Kiszka <jan.kiszka@siemens.com>
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [net-next PATCH v7 13/16] ARM: dts: qcom: ipq8064-rb3011: Add Switch LED for each port
From: Christian Marangi @ 2023-04-19 14:38 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Andrew Lunn, Florian Fainelli, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Heiner Kallweit, Russell King,
Jonathan Corbet, Gregory Clement, Sebastian Hesselbarth,
Andy Gross, Bjorn Andersson, Konrad Dybcio, Pavel Machek,
Lee Jones, John Crispin, netdev, devicetree, linux-kernel,
linux-doc, linux-arm-kernel, linux-arm-msm, linux-leds,
Jonathan McDowell
In-Reply-To: <289b7604-d32d-49d9-8f06-87147d6fd473@linaro.org>
On Wed, Apr 19, 2023 at 02:53:45PM +0200, Krzysztof Kozlowski wrote:
> On 17/04/2023 17:17, Christian Marangi wrote:
> > Add Switch LED for each port for MikroTik RB3011UiAS-RM.
> >
> > MikroTik RB3011UiAS-RM is a 10 port device with 2 qca8337 switch chips
> > connected.
> >
> > It was discovered that in the hardware design all 3 Switch LED trace of
> > the related port is connected to the same LED. This was discovered by
> > setting to 'always on' the related led in the switch regs and noticing
> > that all 3 LED for the specific port (for example for port 1) cause the
> > connected LED for port 1 to turn on. As an extra test we tried enabling
> > 2 different LED for the port resulting in the LED turned off only if
> > every led in the reg was off.
> >
> > Aside from this funny and strange hardware implementation, the device
> > itself have one green LED for each port, resulting in 10 green LED one
> > for each of the 10 supported port.
> >
> > Cc: Jonathan McDowell <noodles@earth.li>
> > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> > ---
> > arch/arm/boot/dts/qcom-ipq8064-rb3011.dts | 120 ++++++++++++++++++++++
>
> Please do not send the DTS patches to the net-next, but to the Qualcomm
> SoC maintainers. The DTS must not be mixed with driver code.
>
Hi,
sorry for the mess, it was asked to give an user of the LED feature for
qca8k so I was a bit confused on where to include it and at the end I
decided to put it in this series.
What was the correct way? 2 different series and reference the DT one in
the net-next? (or not targetting net-next at all?)
--
Ansuel
_______________________________________________
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] crypto: ixp4xx - silence uninitialized variable warning
From: Arnd Bergmann @ 2023-04-19 14:36 UTC (permalink / raw)
To: Dan Carpenter
Cc: Linus Walleij, Imre Kaloz, Krzysztof Halasa, Herbert Xu,
David S . Miller, linux-crypto, linux-arm-kernel, kernel-janitors
In-Reply-To: <7de7d932-d01b-4ada-ae07-827c32438e00@kili.mountain>
On Wed, Apr 19, 2023, at 16:26, Dan Carpenter wrote:
> Smatch complains that "dma" is uninitialized if dma_pool_alloc() fails.
> This is true, but also harmless. Anyway, move the assignment after the
> error checking to silence this warning.
>
> Fixes: 586d492f2856 ("crypto: ixp4xx - fix building wiht 64-bit dma_addr_t")
> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Nice catch, thanks for the fix,
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
_______________________________________________
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: delete dead code in this_cpu_set_vectors()
From: Ard Biesheuvel @ 2023-04-19 14:29 UTC (permalink / raw)
To: Dan Carpenter
Cc: James Morse, Will Deacon, Kristina Martsenko, Mark Rutland,
Mark Brown, Liu Song, D Scott Phillips, linux-arm-kernel,
linux-kernel, kernel-janitors
In-Reply-To: <73859c9e-dea0-4764-bf01-7ae694fa2e37@kili.mountain>
On Wed, 19 Apr 2023 at 09:58, Dan Carpenter <dan.carpenter@linaro.org> wrote:
>
> The "slot" variable is an enum, and in this context it is an unsigned
> int. So the type means it can never be negative and also we never pass
> invalid data to this function. If something did pass invalid data then
> this check would be insufficient protection.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
> ---
> arch/arm64/kernel/proton-pack.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/arch/arm64/kernel/proton-pack.c b/arch/arm64/kernel/proton-pack.c
> index fca9cc6f5581..05f40c4e18fd 100644
> --- a/arch/arm64/kernel/proton-pack.c
> +++ b/arch/arm64/kernel/proton-pack.c
> @@ -966,9 +966,6 @@ static void this_cpu_set_vectors(enum arm64_bp_harden_el1_vectors slot)
> {
> const char *v = arm64_get_bp_hardening_vector(slot);
>
> - if (slot < 0)
> - return;
> -
> __this_cpu_write(this_cpu_vector, v);
>
> /*
> --
> 2.39.2
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] crypto: ixp4xx - silence uninitialized variable warning
From: Dan Carpenter @ 2023-04-19 14:26 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linus Walleij, Imre Kaloz, Krzysztof Halasa, Herbert Xu,
David S. Miller, linux-crypto, linux-arm-kernel, kernel-janitors
Smatch complains that "dma" is uninitialized if dma_pool_alloc() fails.
This is true, but also harmless. Anyway, move the assignment after the
error checking to silence this warning.
Fixes: 586d492f2856 ("crypto: ixp4xx - fix building wiht 64-bit dma_addr_t")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
---
drivers/crypto/intel/ixp4xx/ixp4xx_crypto.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/intel/ixp4xx/ixp4xx_crypto.c b/drivers/crypto/intel/ixp4xx/ixp4xx_crypto.c
index ed15379a9818..4a18095ae5d8 100644
--- a/drivers/crypto/intel/ixp4xx/ixp4xx_crypto.c
+++ b/drivers/crypto/intel/ixp4xx/ixp4xx_crypto.c
@@ -1175,9 +1175,9 @@ static int aead_perform(struct aead_request *req, int encrypt,
/* The 12 hmac bytes are scattered,
* we need to copy them into a safe buffer */
req_ctx->hmac_virt = dma_pool_alloc(buffer_pool, flags, &dma);
- crypt->icv_rev_aes = dma;
if (unlikely(!req_ctx->hmac_virt))
goto free_buf_dst;
+ crypt->icv_rev_aes = dma;
if (!encrypt) {
scatterwalk_map_and_copy(req_ctx->hmac_virt,
req->src, cryptlen, authsize, 0);
--
2.39.2
_______________________________________________
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 2/3] PCI: brcmstb: CLKREQ# accomodations of downstream device
From: Jim Quinlan @ 2023-04-19 14:23 UTC (permalink / raw)
To: Cyril Brulebois
Cc: Florian Fainelli, linux-pci, Nicolas Saenz Julienne,
Bjorn Helgaas, Lorenzo Pieralisi, Phil Elwell,
bcm-kernel-feedback-list, james.quinlan, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list
In-Reply-To: <20230414161907.zfd2ibshfx4rz56j@mraw.org>
On Fri, Apr 14, 2023 at 12:19 PM Cyril Brulebois <kibi@debian.org> wrote:
>
> Florian Fainelli <f.fainelli@gmail.com> (2023-04-14):
> > Cyril, based upon the table and logs you provided whereby you have used the
> > following:
> >
> > - Raspberry Pi Compute Module 4 (Rev 1.0, 8G RAM, 32G storage)
> > - Raspberry Pi Compute Module 4 IO Board
> > - SupaHub PCIe-to-multiple-USB adapter, reference PCE6U1C-R02, VER 006S
> >
> > in the before/unpatched case we have a PCIe link down and in the
> > after/patched we have a PCIe link up but a kernel panic. Neither are great
> > nor resulting in a fully functional PCIe device.
>
> Based on Jim's feedback, I'm attaching a new dmesg for the aforementioned
> setup, with an unpatched kernel (dmesg-unpatched-pcie-link-up.txt).
Hello Cyril,
I'm still seeing things in the logs that do not make sense to me.
First, the "unpatched" version logs -- including the Raspian case --
all have the following lines:
[ 0.000000] Movable zone start for each node
/* ... */
[ 0.000000] pcpu-alloc: s88232 r8192 d30552 u126976 alloc=31*4096
[ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
The above lines are also in my logs. But they are missing from your
"after patch" logs -- what did you change to have these lines
disappear on the patched logs?
Second, you say that you used a different "CM4" from the one used in
the Bugzilla report -- what do you mean by that? Are you referring
to the CM4 module proper, whose only change was going from 4GB to 8GB,
or the IO board being used? My testing is done with a standard RPi
CM4 and standard RPi IO board. Before this patch series, the only way
this standard configuration can work for most hobbyist PCI cards (i.e.
floating CLKREQ# pin) is by using Raspian AND adding
"brcm,enable-l1ss" to the DT node.
I'm guessing that you are using the configuration that you described
to me in a personal email: "[the] chip is embedded directly on the
modified PCB, as opposed to plugged into the PCIe slot on the official
CM4 IO Board". If true, you are testing on a configuration that (a)
is unique to you and your group and (b) must be doing something with
the CLKREQ# signal so that your "before" case does not panic. Is this
the case?
Finally, and this is a big one, is the fact that in both of the
"before" and "after" cases the value written to the internal Brcm
CLKREQ# register is the same.
This is evident by this line in the "after" patch: "brcm-pcie
fd500000.pcie: uni-dir CLKREQ# for ASPM". This mode is the only mode
supported by the "before"
case. Now there are some other things going on in the patch series
-- reading two registers and extending the timeout value of a
completion abort, but I'm having
a hard time imagining how they could cause a panic.
Regards,
Jim
PS Can you please include in your logs the output of "sudo lspci
-vvv" for those cases that boot to prompt?
>
> I fear that initially I might have not waited enough before power off and
> power on when replugging the SupaHub adapter, and I've only seen the PCIe
> link down a few times (now that I'm actively paying attention to that
> part). I'm indeed seeing PCIe link up consistently (100%) when using the
> following method:
>
> for i in $(seq 1 20); do
> # power on, let the system boot up and settle:
> sispmctl -t 4; sleep 2m
> ssh cm4 sh -c "dmesg > dmesg-$i.txt; poweroff"
> # let the system power down, and power off:
> sleep 30; sispmctl -t 4
> # wait before power cycling:
> sleep 10
> done
>
> > Looking at:
> > https://www.amazon.co.uk/SupaHub-Express-BandWidth-Capable-Expanding/dp/B092ZQWG5B
> >
> > it would appear that it can accept an external power supply, do you have one
> > connected to that USB expansion card by any chance?
>
> With the patched kernel, I have tried several things (leaving the regular
> 12V adapter plugged in all the time):
> - No external power supply (that's what I've been using in all previous
> attempts).
> - Using a 5V PSU with 2 pins (ground and 5V) plugged on the Ext PSU
> 4-pin header on the IO Board.
> - Using a 5V PSU with a SATA connector plugged directly onto the SupaHub
> adapter.
>
> I'm getting the same trace in all cases.
>
> > Are you able to boot the kernel before/after if you disconnect any USB
> > peripheral?
>
> The trace is obtained without any USB peripheral (on the extension card or
> on the onboard USB slots). Besides the SupaHub adapter on the PCIe slot, I
> only have Ethernet and HDMI plugged in (I'm getting traces via serial
> console, and operating the system over SSH when it boots fine).
>
> As soon as I unplug the SupaHub board itself, the system boots fine.
>
> > Does that SupaHub board plugged to the CM4 1.0 system work fine in the
> > Raspberry Pi kernel tree?
>
> With the Raspberry Pi OS (64-bit) > Raspberry Pi OS Lite image
> (2023-02-21-raspios-bullseye-arm64-lite.img.xz), the system at least
> boots fine; I haven't tried adding devices to the mix just yet, trying
> to stick with that particular setup.
>
> A full dmesg is attached (dmesg-raspios.txt).
>
>
> Cheers,
> --
> Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
> D-I release manager -- Release team member -- Freelance Consultant
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] clk: imx: scu: use _safe list iterator to avoid a use after free
From: Dan Carpenter @ 2023-04-19 14:23 UTC (permalink / raw)
To: Dong Aisheng
Cc: Abel Vesa, Peng Fan, Michael Turquette, Stephen Boyd, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, linux-clk, linux-arm-kernel, kernel-janitors
This loop is freeing "clk" so it needs to use list_for_each_entry_safe().
Otherwise it dereferences a freed variable to get the next item on the
loop.
Fixes: 77d8f3068c63 ("clk: imx: scu: add two cells binding support")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
---
drivers/clk/imx/clk-scu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/imx/clk-scu.c b/drivers/clk/imx/clk-scu.c
index 1e6870f3671f..db307890e4c1 100644
--- a/drivers/clk/imx/clk-scu.c
+++ b/drivers/clk/imx/clk-scu.c
@@ -707,11 +707,11 @@ struct clk_hw *imx_clk_scu_alloc_dev(const char *name,
void imx_clk_scu_unregister(void)
{
- struct imx_scu_clk_node *clk;
+ struct imx_scu_clk_node *clk, *n;
int i;
for (i = 0; i < IMX_SC_R_LAST; i++) {
- list_for_each_entry(clk, &imx_scu_clks[i], node) {
+ list_for_each_entry_safe(clk, n, &imx_scu_clks[i], node) {
clk_hw_unregister(clk->hw);
kfree(clk);
}
--
2.39.2
_______________________________________________
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 09/21] riscv: dma-mapping: skip invalidation before bidirectional DMA
From: Palmer Dabbelt @ 2023-04-19 14:22 UTC (permalink / raw)
To: arnd
Cc: linux-kernel, Arnd Bergmann, vgupta, linux, neil.armstrong,
linus.walleij, Catalin Marinas, Will Deacon, guoren, bcain, geert,
monstr, tsbogend, dinguyen, shorne, deller, mpe, christophe.leroy,
Paul Walmsley, dalias, glaubitz, davem, jcmvbkbc,
Christoph Hellwig, robin.murphy, prabhakar.mahadev-lad.rj,
Conor Dooley, linux-snps-arc, linux-arm-kernel, linux-oxnas,
linux-csky, linux-hexagon, linux-m68k, linux-mips, linux-openrisc,
linux-parisc, linuxppc-dev, linux-riscv, linux-sh, sparclinux,
linux-xtensa
In-Reply-To: <20230327121317.4081816-10-arnd@kernel.org>
On Mon, 27 Mar 2023 05:13:05 PDT (-0700), arnd@kernel.org wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> For a DMA_BIDIRECTIONAL transfer, the caches have to be cleaned
> first to let the device see data written by the CPU, and invalidated
> after the transfer to let the CPU see data written by the device.
>
> riscv also invalidates the caches before the transfer, which does
> not appear to serve any purpose.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/riscv/mm/dma-noncoherent.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/riscv/mm/dma-noncoherent.c b/arch/riscv/mm/dma-noncoherent.c
> index 640f4c496d26..69c80b2155a1 100644
> --- a/arch/riscv/mm/dma-noncoherent.c
> +++ b/arch/riscv/mm/dma-noncoherent.c
> @@ -25,7 +25,7 @@ void arch_sync_dma_for_device(phys_addr_t paddr, size_t size,
> ALT_CMO_OP(clean, vaddr, size, riscv_cbom_block_size);
> break;
> case DMA_BIDIRECTIONAL:
> - ALT_CMO_OP(flush, vaddr, size, riscv_cbom_block_size);
> + ALT_CMO_OP(clean, vaddr, size, riscv_cbom_block_size);
> break;
> default:
> break;
Acked-by: Palmer Dabbelt <palmer@rivosinc.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 08/21] riscv: dma-mapping: only invalidate after DMA, not flush
From: Palmer Dabbelt @ 2023-04-19 14:22 UTC (permalink / raw)
To: arnd
Cc: linux-kernel, Arnd Bergmann, vgupta, linux, neil.armstrong,
linus.walleij, Catalin Marinas, Will Deacon, guoren, bcain, geert,
monstr, tsbogend, dinguyen, shorne, deller, mpe, christophe.leroy,
Paul Walmsley, dalias, glaubitz, davem, jcmvbkbc,
Christoph Hellwig, robin.murphy, prabhakar.mahadev-lad.rj,
Conor Dooley, linux-snps-arc, linux-arm-kernel, linux-oxnas,
linux-csky, linux-hexagon, linux-m68k, linux-mips, linux-openrisc,
linux-parisc, linuxppc-dev, linux-riscv, linux-sh, sparclinux,
linux-xtensa
In-Reply-To: <20230327121317.4081816-9-arnd@kernel.org>
On Mon, 27 Mar 2023 05:13:04 PDT (-0700), arnd@kernel.org wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> No other architecture intentionally writes back dirty cache lines into
> a buffer that a device has just finished writing into. If the cache is
> clean, this has no effect at all, but if a cacheline in the buffer has
> actually been written by the CPU, there is a drive bug that is likely
> made worse by overwriting that buffer.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/riscv/mm/dma-noncoherent.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/riscv/mm/dma-noncoherent.c b/arch/riscv/mm/dma-noncoherent.c
> index d919efab6eba..640f4c496d26 100644
> --- a/arch/riscv/mm/dma-noncoherent.c
> +++ b/arch/riscv/mm/dma-noncoherent.c
> @@ -42,7 +42,7 @@ void arch_sync_dma_for_cpu(phys_addr_t paddr, size_t size,
> break;
> case DMA_FROM_DEVICE:
> case DMA_BIDIRECTIONAL:
> - ALT_CMO_OP(flush, vaddr, size, riscv_cbom_block_size);
> + ALT_CMO_OP(inval, vaddr, size, riscv_cbom_block_size);
> break;
> default:
> break;
Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH net-next v6] net: stmmac:fix system hang when setting up tag_8021q VLAN for DSA ports
From: Yan Wang @ 2023-04-19 14:13 UTC (permalink / raw)
To: davem, edumazet, pabeni, kuba, mcoquelin.stm32
Cc: Yan Wang, Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
Joakim Zhang, open list:STMMAC ETHERNET DRIVER,
moderated list:ARM/STM32 ARCHITECTURE,
moderated list:ARM/STM32 ARCHITECTURE, open list
In-Reply-To: <KL1PR01MB5448020DE191340AE64530B0E6989@KL1PR01MB5448.apcprd01.prod.exchangelabs.com>
The system hang because of dsa_tag_8021q_port_setup()->
stmmac_vlan_rx_add_vid().
I found in stmmac_drv_probe() that cailing pm_runtime_put()
disabled the clock.
First, when the kernel is compiled with CONFIG_PM=y,The stmmac's
resume/suspend is active.
Secondly,stmmac as DSA master,the dsa_tag_8021q_port_setup() function
will callback stmmac_vlan_rx_add_vid when DSA dirver starts. However,
The system is hanged for the stmmac_vlan_rx_add_vid() accesses its
registers after stmmac's clock is closed.
I would suggest adding the pm_runtime_resume_and_get() to the
stmmac_vlan_rx_add_vid().This guarantees that resuming clock output
while in use.
Fixes: b3dcb3127786 ("net: stmmac: correct clocks enabled in stmmac_vlan_rx_kill_vid()")
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Yan Wang <rk.code@outlook.com>
---
v6:
- Add Reviewed Signature
v5: https://lore.kernel.org/netdev/KL1PR01MB544863D839654F0EC9485894E69C9@KL1PR01MB5448.apcprd01.prod.exchangelabs.com/
- Add version tags.
v4: https://lore.kernel.org/netdev/KL1PR01MB5448C7BF5A7AAC1CBCD5C36AE6989@KL1PR01MB5448.apcprd01.prod.exchangelabs.com/
- Fixed email address,but The Version number is wrong.
v3: https://lore.kernel.org/netdev/KL1PR01MB544872920F00149E3BDDC7ECE6999@KL1PR01MB5448.apcprd01.prod.exchangelabs.com/
- Fixed the Fixes tag,but Missing version change log.
v2: https://lore.kernel.org/netdev/KL1PR01MB54482D50B5C8713A2CA697DFE6999@KL1PR01MB5448.apcprd01.prod.exchangelabs.com/
- Add a error fixed tag.
v1: https://lore.kernel.org/netdev/KL1PR01MB5448020DE191340AE64530B0E6989@KL1PR01MB5448.apcprd01.prod.exchangelabs.com/
- the Subject is set incorrectly
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index d7fcab057032..f9cd063f1fe3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -6350,6 +6350,10 @@ static int stmmac_vlan_rx_add_vid(struct net_device *ndev, __be16 proto, u16 vid
bool is_double = false;
int ret;
+ ret = pm_runtime_resume_and_get(priv->device);
+ if (ret < 0)
+ return ret;
+
if (be16_to_cpu(proto) == ETH_P_8021AD)
is_double = true;
@@ -6357,16 +6361,18 @@ static int stmmac_vlan_rx_add_vid(struct net_device *ndev, __be16 proto, u16 vid
ret = stmmac_vlan_update(priv, is_double);
if (ret) {
clear_bit(vid, priv->active_vlans);
- return ret;
+ goto err_pm_put;
}
if (priv->hw->num_vlan) {
ret = stmmac_add_hw_vlan_rx_fltr(priv, ndev, priv->hw, proto, vid);
if (ret)
- return ret;
+ goto err_pm_put;
}
+err_pm_put:
+ pm_runtime_put(priv->device);
- return 0;
+ return ret;
}
static int stmmac_vlan_rx_kill_vid(struct net_device *ndev, __be16 proto, u16 vid)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2] stm: class: Add MIPI OST protocol support
From: Mao Jinlong @ 2023-04-19 14:13 UTC (permalink / raw)
To: Steven Rostedt, Masami Hiramatsu, Jonathan Corbet,
Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Tingwei Zhang
Cc: Mao Jinlong, linux-kernel, linux-trace-kernel, linux-doc,
linux-stm32, linux-arm-kernel, linux-arm-msm, Yuanfang Zhang,
Tao Zhang, Hao Zhang
Add MIPI OST(Open System Trace) protocol support for stm to format
the traces. OST over STP packet consists of Header/Payload/End. In
header, there will be STARTSIMPLE/VERSION/ENTITY/PROTOCOL. STARTSIMPLE
is used to signal the beginning of a simplified OST base protocol
packet.The Entity ID field is a one byte unsigned number that identifies
the source. FLAG packet is used for END token.
Signed-off-by: Tingwei Zhang <quic_tingweiz@quicinc.com>
Signed-off-by: Yuanfang Zhang <quic_yuanfang@quicinc.com>
Signed-off-by: Mao Jinlong <quic_jinlmao@quicinc.com>
---
.../ABI/testing/configfs-stp-policy-p_ost | 13 ++
Documentation/trace/p_ost.rst | 40 ++++
drivers/hwtracing/stm/Kconfig | 14 ++
drivers/hwtracing/stm/Makefile | 2 +
drivers/hwtracing/stm/p_ost.c | 213 ++++++++++++++++++
5 files changed, 282 insertions(+)
create mode 100644 Documentation/ABI/testing/configfs-stp-policy-p_ost
create mode 100644 Documentation/trace/p_ost.rst
create mode 100644 drivers/hwtracing/stm/p_ost.c
diff --git a/Documentation/ABI/testing/configfs-stp-policy-p_ost b/Documentation/ABI/testing/configfs-stp-policy-p_ost
new file mode 100644
index 000000000000..7ad11ae21760
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-stp-policy-p_ost
@@ -0,0 +1,13 @@
+What: /config/stp-policy/<device>:p_ost.<policy>/<node>/entity_available
+Date: April 2023
+KernelVersion: 6.3
+Description:
+ Show entity that p_ost supports, RO.
+
+What: /config/stp-policy/<device>:p_ost.<policy>/<node>/entity
+Date: April 2023
+KernelVersion: 6.3
+Description:
+ Set the entity which is to identify the source, RW.
+ The available entity can be gotten by reading entity_available.
+
diff --git a/Documentation/trace/p_ost.rst b/Documentation/trace/p_ost.rst
new file mode 100644
index 000000000000..8d7afa341b9e
--- /dev/null
+++ b/Documentation/trace/p_ost.rst
@@ -0,0 +1,40 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===================
+MIPI OST over STP
+===================
+
+The OST(Open System Trace) driver is used with STM class devices to
+generate standardized trace stream. Trace sources can be identified
+by different entity ids.
+
+CONFIG_STM_PROTO_OST is for p_ost driver enablement. Once this config
+is enabled, you can select the p_ost protocol by command below:
+
+# mkdir /sys/kernel/config/stp-policy/stm0:p_ost.policy
+
+The policy name format is extended like this:
+ <device_name>:<protocol_name>.<policy_name>
+
+With coresight-stm device, it will be look like "stm0:p_ost.policy".
+
+You can check if the protocol is set successfully by:
+# cat /sys/kernel/config/stp-policy/stm0:p_ost.policy/protocol
+p_ost
+
+With MIPI OST protocol driver, the attributes for each protocol node is:
+# mkdir /sys/kernel/config/stp-policy/stm0:p_ost.policy/default
+# ls /sys/kernel/config/stp-policy/stm0:p_ost.policy/default
+channels entity masters
+
+The entity here is the set the entity that p_ost supports. Currently
+p_ost supports ftrace and console entity.
+
+Get current available entity that p_ost supports:
+# cat /sys/kernel/config/stp-policy/stm0:p_ost.policy/default/entity_available
+ftrace console
+
+Set entity:
+# echo 'ftrace' > /sys/kernel/config/stp-policy/stm0:p_ost.policy/default/entity
+
+See Documentation/ABI/testing/configfs-stp-policy-p_ost for more details.
diff --git a/drivers/hwtracing/stm/Kconfig b/drivers/hwtracing/stm/Kconfig
index eda6b11d40a1..daa4aa09f64d 100644
--- a/drivers/hwtracing/stm/Kconfig
+++ b/drivers/hwtracing/stm/Kconfig
@@ -40,6 +40,20 @@ config STM_PROTO_SYS_T
If you don't know what this is, say N.
+config STM_PROTO_OST
+ tristate "MIPI OST STM framing protocol driver"
+ default CONFIG_STM
+ help
+ This is an implementation of MIPI OST protocol to be used
+ over the STP transport. In addition to the data payload, it
+ also carries additional metadata for entity, better
+ means of trace source identification, etc.
+
+ The receiving side must be able to decode this protocol in
+ addition to the MIPI STP, in order to extract the data.
+
+ If you don't know what this is, say N.
+
config STM_DUMMY
tristate "Dummy STM driver"
help
diff --git a/drivers/hwtracing/stm/Makefile b/drivers/hwtracing/stm/Makefile
index 1692fcd29277..715fc721891e 100644
--- a/drivers/hwtracing/stm/Makefile
+++ b/drivers/hwtracing/stm/Makefile
@@ -5,9 +5,11 @@ stm_core-y := core.o policy.o
obj-$(CONFIG_STM_PROTO_BASIC) += stm_p_basic.o
obj-$(CONFIG_STM_PROTO_SYS_T) += stm_p_sys-t.o
+obj-$(CONFIG_STM_PROTO_OST) += stm_p_ost.o
stm_p_basic-y := p_basic.o
stm_p_sys-t-y := p_sys-t.o
+stm_p_ost-y := p_ost.o
obj-$(CONFIG_STM_DUMMY) += dummy_stm.o
diff --git a/drivers/hwtracing/stm/p_ost.c b/drivers/hwtracing/stm/p_ost.c
new file mode 100644
index 000000000000..fe99b68569d3
--- /dev/null
+++ b/drivers/hwtracing/stm/p_ost.c
@@ -0,0 +1,213 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
+ *
+ * MIPI OST framing protocol for STM devices.
+ */
+
+#include <linux/configfs.h>
+#include <linux/module.h>
+#include <linux/device.h>
+#include <linux/slab.h>
+#include <linux/stm.h>
+#include "stm.h"
+
+
+#define OST_TOKEN_STARTSIMPLE (0x10)
+#define OST_VERSION_MIPI1 (0x10 << 8)
+
+/* entity id to identify the source*/
+#define OST_ENTITY_FTRACE (0x01 << 16)
+#define OST_ENTITY_CONSOLE (0x02 << 16)
+
+#define OST_CONTROL_PROTOCOL (0x0 << 24)
+
+/*
+ * OST Base Protocol Header
+ *
+ * Position Bits Field Name
+ * 0 8 STARTSIMPLE
+ * 1 8 Version
+ * 2 8 Entity ID
+ * 3 8 protocol ID
+ */
+#define DATA_HEADER (OST_TOKEN_STARTSIMPLE | OST_VERSION_MIPI1 | \
+ OST_CONTROL_PROTOCOL)
+
+#define STM_MAKE_VERSION(ma, mi) ((ma << 8) | mi)
+#define STM_HEADER_MAGIC (0x5953)
+
+enum ost_entity_type {
+ OST_ENTITY_TYPE_NONE,
+ OST_ENTITY_TYPE_FTRACE,
+ OST_ENTITY_TYPE_CONSOLE,
+};
+
+static const char * const str_ost_entity_type[] = {
+ [OST_ENTITY_TYPE_NONE] = "none",
+ [OST_ENTITY_TYPE_FTRACE] = "ftrace",
+ [OST_ENTITY_TYPE_CONSOLE] = "console",
+};
+
+struct ost_policy_node {
+ enum ost_entity_type entity_type;
+};
+
+struct ost_output {
+ struct ost_policy_node node;
+};
+
+/* Set default entity type as none */
+static void ost_policy_node_init(void *priv)
+{
+ struct ost_policy_node *pn = priv;
+
+ pn->entity_type = OST_ENTITY_TYPE_NONE;
+}
+
+static int ost_output_open(void *priv, struct stm_output *output)
+{
+ struct ost_policy_node *pn = priv;
+ struct ost_output *opriv;
+
+ opriv = kzalloc(sizeof(*opriv), GFP_ATOMIC);
+ if (!opriv)
+ return -ENOMEM;
+
+ memcpy(&opriv->node, pn, sizeof(opriv->node));
+ output->pdrv_private = opriv;
+ return 0;
+}
+
+static void ost_output_close(struct stm_output *output)
+{
+ kfree(output->pdrv_private);
+}
+
+static ssize_t ost_t_policy_entity_show(struct config_item *item,
+ char *page)
+{
+ struct ost_policy_node *pn = to_pdrv_policy_node(item);
+
+ return scnprintf(page, PAGE_SIZE, "%s\n",
+ str_ost_entity_type[pn->entity_type]);
+}
+
+static ssize_t
+ost_t_policy_entity_store(struct config_item *item, const char *page,
+ size_t count)
+{
+ struct mutex *mutexp = &item->ci_group->cg_subsys->su_mutex;
+ struct ost_policy_node *pn = to_pdrv_policy_node(item);
+ char str[10] = "";
+
+ mutex_lock(mutexp);
+ if (sscanf(page, "%s", str) != 1)
+ return -EINVAL;
+ mutex_unlock(mutexp);
+
+ if (!strcmp(str, str_ost_entity_type[OST_ENTITY_TYPE_FTRACE]))
+ pn->entity_type = OST_ENTITY_TYPE_FTRACE;
+ else if (!strcmp(str, str_ost_entity_type[OST_ENTITY_TYPE_CONSOLE]))
+ pn->entity_type = OST_ENTITY_TYPE_CONSOLE;
+ else
+ return -EINVAL;
+ return count;
+}
+CONFIGFS_ATTR(ost_t_policy_, entity);
+
+static ssize_t ost_t_policy_entity_available_show(struct config_item *item,
+ char *page)
+{
+ return scnprintf(page, PAGE_SIZE, "%s\n", "ftrace console");
+}
+CONFIGFS_ATTR_RO(ost_t_policy_, entity_available);
+
+static struct configfs_attribute *ost_t_policy_attrs[] = {
+ &ost_t_policy_attr_entity,
+ &ost_t_policy_attr_entity_available,
+ NULL,
+};
+
+static ssize_t notrace ost_write(struct stm_data *data,
+ struct stm_output *output, unsigned int chan,
+ const char *buf, size_t count)
+{
+ unsigned int c = output->channel + chan;
+ unsigned int m = output->master;
+ const unsigned char nil = 0;
+ u32 header = DATA_HEADER;
+ u8 trc_hdr[16];
+ ssize_t sz;
+
+ struct ost_output *op = output->pdrv_private;
+
+ /*
+ * Identify the source by entity type.
+ * If entity type is not set, return error value.
+ */
+ if (op->node.entity_type == OST_ENTITY_TYPE_FTRACE) {
+ header |= OST_ENTITY_FTRACE;
+ } else if (op->node.entity_type == OST_ENTITY_TYPE_CONSOLE) {
+ header |= OST_ENTITY_CONSOLE;
+ } else {
+ pr_debug("p_ost: Entity must be set for trace data.");
+ return -EINVAL;
+ }
+
+ /*
+ * STP framing rules for OST frames:
+ * * the first packet of the OST frame is marked;
+ * * the last packet is a FLAG with timestamped tag.
+ */
+ /* Message layout: HEADER / DATA / TAIL */
+ /* HEADER */
+ sz = data->packet(data, m, c, STP_PACKET_DATA, STP_PACKET_MARKED,
+ 4, (u8 *)&header);
+ if (sz <= 0)
+ return sz;
+
+ /* DATA */
+ *(u16 *)(trc_hdr) = STM_MAKE_VERSION(0, 4);
+ *(u16 *)(trc_hdr + 2) = STM_HEADER_MAGIC;
+ *(u32 *)(trc_hdr + 4) = raw_smp_processor_id();
+ *(u64 *)(trc_hdr + 8) = task_tgid_nr(get_current());
+ sz = stm_data_write(data, m, c, false, trc_hdr, sizeof(trc_hdr));
+ if (sz <= 0)
+ return sz;
+
+ sz = stm_data_write(data, m, c, false, buf, count);
+
+ /* TAIL */
+ if (sz > 0)
+ data->packet(data, m, c, STP_PACKET_FLAG,
+ STP_PACKET_TIMESTAMPED, 0, &nil);
+
+ return sz;
+}
+
+static const struct stm_protocol_driver ost_pdrv = {
+ .owner = THIS_MODULE,
+ .name = "p_ost",
+ .write = ost_write,
+ .policy_attr = ost_t_policy_attrs,
+ .output_open = ost_output_open,
+ .output_close = ost_output_close,
+ .policy_node_init = ost_policy_node_init,
+};
+
+static int ost_stm_init(void)
+{
+ return stm_register_protocol(&ost_pdrv);
+}
+
+static void ost_stm_exit(void)
+{
+ stm_unregister_protocol(&ost_pdrv);
+}
+
+module_init(ost_stm_init);
+module_exit(ost_stm_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("MIPI Open System Trace STM framing protocol driver");
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V2 5/5] arm64: dts: ti: k3-j721s2-common-proc-board: Drop bootargs
From: Nishanth Menon @ 2023-04-19 14:12 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rob Herring, Vignesh Raghavendra
Cc: linux-kernel, devicetree, linux-arm-kernel, Tero Kristo,
Nishanth Menon, Krzysztof Kozlowski, Roger Quadros
In-Reply-To: <20230419141222.383567-1-nm@ti.com>
Drop bootargs from the dts. The console arguments are already covered in
stdout-path property and earlycon is a debug property that should be
enabled only when debug is desired and not as default.
Link: https://lore.kernel.org/linux-arm-kernel/81134eb9-2b7d-05bc-3035-a47f020861a8@linaro.org/
Suggested-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Similar discussions can be seen in https://lore.kernel.org/linux-devicetree/?q=Krzysztof+bootargs
Changes since v1:
- improved commit message
- picked up acks and reviews from Roger and Krzysztof
V1: https://lore.kernel.org/r/20230418165212.1456415-6-nm@ti.com
arch/arm64/boot/dts/ti/k3-j721s2-common-proc-board.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-common-proc-board.dts b/arch/arm64/boot/dts/ti/k3-j721s2-common-proc-board.dts
index b4b9edfe2d12..1299c715f34c 100644
--- a/arch/arm64/boot/dts/ti/k3-j721s2-common-proc-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-j721s2-common-proc-board.dts
@@ -16,7 +16,6 @@ / {
chosen {
stdout-path = "serial2:115200n8";
- bootargs = "console=ttyS2,115200n8 earlycon=ns16550a,mmio32,2880000";
};
aliases {
--
2.40.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
* [PATCH V2 3/5] arm64: dts: ti: k3-j721e-*: Drop bootargs
From: Nishanth Menon @ 2023-04-19 14:12 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rob Herring, Vignesh Raghavendra
Cc: linux-kernel, devicetree, linux-arm-kernel, Tero Kristo,
Nishanth Menon, Krzysztof Kozlowski, Roger Quadros
In-Reply-To: <20230419141222.383567-1-nm@ti.com>
Drop bootargs from the dts. The console arguments are already covered in
stdout-path property and earlycon is a debug property that should be
enabled only when debug is desired and not as default.
Link: https://lore.kernel.org/linux-arm-kernel/81134eb9-2b7d-05bc-3035-a47f020861a8@linaro.org/
Suggested-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Similar discussions can be seen in https://lore.kernel.org/linux-devicetree/?q=Krzysztof+bootargs
Changes since v1:
- improved commit message
- picked up acks and reviews from Roger and Krzysztof
V1: https://lore.kernel.org/r/20230418165212.1456415-4-nm@ti.com
arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts | 1 -
arch/arm64/boot/dts/ti/k3-j721e-sk.dts | 1 -
2 files changed, 2 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts b/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
index 7db0603125aa..c11c092c1ce0 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
@@ -17,7 +17,6 @@ / {
chosen {
stdout-path = "serial2:115200n8";
- bootargs = "console=ttyS2,115200n8 earlycon=ns16550a,mmio32,0x02800000";
};
gpio_keys: gpio-keys {
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-sk.dts b/arch/arm64/boot/dts/ti/k3-j721e-sk.dts
index f650a7fd66b4..ad7b45aeed0a 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-j721e-sk.dts
@@ -18,7 +18,6 @@ / {
chosen {
stdout-path = "serial2:115200n8";
- bootargs = "console=ttyS2,115200n8 earlycon=ns16550a,mmio32,0x02800000";
};
memory@80000000 {
--
2.40.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
* [PATCH V2 2/5] arm64: dts: ti: k3-am65*: Drop bootargs
From: Nishanth Menon @ 2023-04-19 14:12 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rob Herring, Vignesh Raghavendra
Cc: linux-kernel, devicetree, linux-arm-kernel, Tero Kristo,
Nishanth Menon, Jan Kiszka, Krzysztof Kozlowski, Roger Quadros
In-Reply-To: <20230419141222.383567-1-nm@ti.com>
Drop bootargs from the dts. earlycon is a debug property that should be
enabled only when debug is desired and not as default - see referenced
link on discussion on this topic.
Cc: Jan Kiszka <jan.kiszka@siemens.com>
Link: https://lore.kernel.org/linux-arm-kernel/81134eb9-2b7d-05bc-3035-a47f020861a8@linaro.org/
Suggested-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Similar discussions can be seen in https://lore.kernel.org/linux-devicetree/?q=Krzysztof+bootargs
Changes since v1:
- improved commit message
- picked up acks and reviews from Roger and Krzysztof
V1: https://lore.kernel.org/r/20230418165212.1456415-3-nm@ti.com
arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi | 1 -
arch/arm64/boot/dts/ti/k3-am654-base-board.dts | 1 -
2 files changed, 2 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
index 96ac2b476b11..7d256a1638ff 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
@@ -21,7 +21,6 @@ aliases {
chosen {
stdout-path = "serial3:115200n8";
- bootargs = "earlycon=ns16550a,mmio32,0x02810000";
};
reserved-memory {
diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
index 592ab2b54cb3..0d6fc89eba7a 100644
--- a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
@@ -15,7 +15,6 @@ / {
chosen {
stdout-path = "serial2:115200n8";
- bootargs = "earlycon=ns16550a,mmio32,0x02800000";
};
memory@80000000 {
--
2.40.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
* [PATCH V2 1/5] arm64: dts: ti: k3-am62x-sk-common: Drop bootargs
From: Nishanth Menon @ 2023-04-19 14:12 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rob Herring, Vignesh Raghavendra
Cc: linux-kernel, devicetree, linux-arm-kernel, Tero Kristo,
Nishanth Menon, Krzysztof Kozlowski, Roger Quadros
In-Reply-To: <20230419141222.383567-1-nm@ti.com>
Drop bootargs from the dts. The console arguments are already covered in
stdout-path property and earlycon is a debug property that should be
enabled only when debug is desired and not as default.
Link: https://lore.kernel.org/linux-arm-kernel/81134eb9-2b7d-05bc-3035-a47f020861a8@linaro.org/
Suggested-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Similar discussions can be seen in https://lore.kernel.org/linux-devicetree/?q=Krzysztof+bootargs
Changes since v1:
- improved commit message
- picked up acks and reviews from Roger and Krzysztof
V1: https://lore.kernel.org/r/20230418165212.1456415-2-nm@ti.com
arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi b/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
index 976f8303c84f..a61e8648f189 100644
--- a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
@@ -25,7 +25,6 @@ aliases {
chosen {
stdout-path = "serial2:115200n8";
- bootargs = "console=ttyS2,115200n8 earlycon=ns16550a,mmio32,0x02800000";
};
memory@80000000 {
--
2.40.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
* [PATCH V2 4/5] arm64: dts: ti: k3-j7200-common-proc-board: Drop bootargs
From: Nishanth Menon @ 2023-04-19 14:12 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rob Herring, Vignesh Raghavendra
Cc: linux-kernel, devicetree, linux-arm-kernel, Tero Kristo,
Nishanth Menon, Krzysztof Kozlowski, Roger Quadros
In-Reply-To: <20230419141222.383567-1-nm@ti.com>
Drop bootargs from the dts. The console arguments are already covered in
stdout-path property and earlycon is a debug property that should be
enabled only when debug is desired and not as default.
Link: https://lore.kernel.org/linux-arm-kernel/81134eb9-2b7d-05bc-3035-a47f020861a8@linaro.org/
Suggested-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Similar discussions can be seen in https://lore.kernel.org/linux-devicetree/?q=Krzysztof+bootargs
Changes since v1:
- improved commit message
- picked up acks and reviews from Roger and Krzysztof
V1: https://lore.kernel.org/r/20230418165212.1456415-5-nm@ti.com
arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
index 0d39d6b8cc0c..5506341aae21 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
@@ -17,7 +17,6 @@ / {
chosen {
stdout-path = "serial2:115200n8";
- bootargs = "console=ttyS2,115200n8 earlycon=ns16550a,mmio32,0x02800000";
};
evm_12v0: fixedregulator-evm12v0 {
--
2.40.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
* [PATCH V2 0/5] arm64: dts: ti: Drop bootargs
From: Nishanth Menon @ 2023-04-19 14:12 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rob Herring, Vignesh Raghavendra
Cc: linux-kernel, devicetree, linux-arm-kernel, Tero Kristo,
Nishanth Menon
The bootargs atm contains (generally) two information: console and
earlycon - console is already covered by stdout-path and earlycon is
really meant to be used when debug is needed and not something of a
default to spin out to all users.
This has come up multiple times, so cleaning it all up.
See [1] for context. AM64 is covered in [2]. There are quite a few other
instances of the same in mailing list[3].
Changes since V1:
* No functional changes
* Commit message update to be verbose as to the rationale.
* Picked up Roger's and Krzysztof's acks.
V1: https://lore.kernel.org/all/20230418165212.1456415-1-nm@ti.com/
[1] https://lore.kernel.org/linux-arm-kernel/81134eb9-2b7d-05bc-3035-a47f020861a8@linaro.org/
[2] https://lore.kernel.org/all/20230414073328.381336-1-nm@ti.com/
[3] https://lore.kernel.org/linux-devicetree/?q=Krzysztof+bootargs
Nishanth Menon (5):
arm64: dts: ti: k3-am62x-sk-common: Drop bootargs
arm64: dts: ti: k3-am65*: Drop bootargs
arm64: dts: ti: k3-j721e-*: Drop bootargs
arm64: dts: ti: k3-j7200-common-proc-board: Drop bootargs
arm64: dts: ti: k3-j721s2-common-proc-board: Drop bootargs
arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 1 -
arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi | 1 -
arch/arm64/boot/dts/ti/k3-am654-base-board.dts | 1 -
arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts | 1 -
arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts | 1 -
arch/arm64/boot/dts/ti/k3-j721e-sk.dts | 1 -
arch/arm64/boot/dts/ti/k3-j721s2-common-proc-board.dts | 1 -
7 files changed, 7 deletions(-)
--
2.40.0
_______________________________________________
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] phy: mediatek: Avoid floating point constants
From: Guillaume Ranquet @ 2023-04-19 13:52 UTC (permalink / raw)
To: Thierry Reding, Vinod Koul, Kishon Vijay Abraham I
Cc: Chun-Kuang Hu, Philipp Zabel, Matthias Brugger,
AngeloGioacchino Del Regno, Guillaume Ranquet, linux-mediatek,
linux-phy, linux-arm-kernel, Jonathan Hunter
In-Reply-To: <20230419122131.2167122-1-thierry.reding@gmail.com>
On Wed, 19 Apr 2023 14:21, Thierry Reding <thierry.reding@gmail.com> wrote:
>From: Thierry Reding <treding@nvidia.com>
>
>When building with old versions of GCC (6.3 in this case), the compiler
>stumbles over the floating point constants in this driver:
>
> drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c: In function ‘mtk_hdmi_pll_prepare’:
> drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:331:23: error: ‘-mgeneral-regs-only’ is incompatible with floating-point code
> } else if (pixel_clk >= 74.175 * MEGA && pixel_clk <= 300 * MEGA) {
>
> drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:361:12: error: ‘-mgeneral-regs-only’ is incompatible with floating-point code
> static int mtk_hdmi_pll_prepare(struct clk_hw *hw)
> ^~~~~~~~~~~~~~~~~~~~
> drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:361:12: error: ‘-mgeneral-regs-only’ is incompatible with floating-point code
>
>Fix this by switching to the KILO macro instead and multiplying the
>constants by 1000 to get rid of the floating point.
>
>Fixes: 45810d486bb4 ("phy: mediatek: add support for phy-mtk-hdmi-mt8195")
>Reported-by: Jonathan Hunter <jonathanh@nvidia.com>
>Signed-off-by: Thierry Reding <treding@nvidia.com>
>---
> drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
>diff --git a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
>index abfc077fb0a8..b10af26cad2f 100644
>--- a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
>+++ b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
>@@ -239,9 +239,9 @@ static int mtk_hdmi_pll_calc(struct mtk_hdmi_phy *hdmi_phy, struct clk_hw *hw,
> txposdiv = 8;
> else if (tmds_clk >= 54 * MEGA && tmds_clk < 148.35 * MEGA)
> txposdiv = 4;
>- else if (tmds_clk >= 148.35 * MEGA && tmds_clk < 296.7 * MEGA)
>+ else if (tmds_clk >= 148350 * KILO && tmds_clk < 296700 * KILO)
> txposdiv = 2;
>- else if (tmds_clk >= 296.7 * MEGA && tmds_clk <= 594 * MEGA)
>+ else if (tmds_clk >= 296700 * KILO && tmds_clk <= 594 * MEGA)
> txposdiv = 1;
> else
> return -EINVAL;
>@@ -328,12 +328,12 @@ static int mtk_hdmi_pll_drv_setting(struct clk_hw *hw)
> clk_channel_bias = 0x34; /* 20mA */
> impedance_en = 0xf;
> impedance = 0x36; /* 100ohm */
>- } else if (pixel_clk >= 74.175 * MEGA && pixel_clk <= 300 * MEGA) {
>+ } else if (pixel_clk >= 74175 * KILO && pixel_clk <= 300 * MEGA) {
> data_channel_bias = 0x34; /* 20mA */
> clk_channel_bias = 0x2c; /* 16mA */
> impedance_en = 0xf;
> impedance = 0x36; /* 100ohm */
>- } else if (pixel_clk >= 27 * MEGA && pixel_clk < 74.175 * MEGA) {
>+ } else if (pixel_clk >= 27 * MEGA && pixel_clk < 74175 * KILO) {
> data_channel_bias = 0x14; /* 10mA */
> clk_channel_bias = 0x14; /* 10mA */
> impedance_en = 0x0;
>--
>2.40.0
>
Thx for the fix!
Reviewed-by: Guillaume Ranquet <granquet@baylibre.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] spi: spi-rockchip: Fix missing unwind goto in rockchip_sfc_probe()
From: Mark Brown @ 2023-04-19 13:51 UTC (permalink / raw)
To: Heiko Stuebner, Chris Morgan, Jon Lin, Li Lanzhe
Cc: Dongliang Mu, linux-spi, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20230419115030.6029-1-u202212060@hust.edu.cn>
On Wed, 19 Apr 2023 07:50:29 -0400, Li Lanzhe wrote:
> If devm_request_irq() fails, then we are directly return 'ret' without
> clk_disable_unprepare(sfc->clk) and clk_disable_unprepare(sfc->hclk).
>
> Fix this by changing direct return to a goto 'err_irq'.
>
>
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/1] spi: spi-rockchip: Fix missing unwind goto in rockchip_sfc_probe()
commit: 359f5b0d4e26b7a7bcc574d6148b31a17cefe47d
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [patch 00/37] cpu/hotplug, x86: Reworked parallel CPU bringup
From: Andrew Cooper @ 2023-04-19 13:50 UTC (permalink / raw)
To: Thomas Gleixner, Paul Menzel
Cc: linux-kernel, x86, David Woodhouse, Brian Gerst,
Arjan van de Veen, Paolo Bonzini, Paul McKenney, Tom Lendacky,
Sean Christopherson, Oleksandr Natalenko, Guilherme G. Piccoli,
Piotr Gorski, David Woodhouse, Usama Arif, Jürgen Groß,
Boris Ostrovsky, xen-devel, Russell King, Arnd Bergmann,
linux-arm-kernel, Catalin Marinas, Will Deacon, Guo Ren,
linux-csky, Thomas Bogendoerfer, linux-mips,
James E. J. Bottomley, Helge Deller, linux-parisc, Paul Walmsley,
Palmer Dabbelt, linux-riscv, Mark Rutland, Sabin Rapan
In-Reply-To: <874jpc3s3r.ffs@tglx>
On 19/04/2023 2:43 pm, Thomas Gleixner wrote:
> On Wed, Apr 19 2023 at 14:38, Thomas Gleixner wrote:
>> On Wed, Apr 19 2023 at 11:38, Thomas Gleixner wrote:
>> IOW, the BIOS assignes random numbers to the AP APICs for whatever
>> raisins, which leaves the parallel startup low level code up a creek
>> without a paddle, except for actually reading the APICID back from the
>> APIC. *SHUDDER*
> So Andrew just pointed out on IRC that this might be related to the
> ancient issue of the 3-wire APIC bus where IO/APIC and APIC shared the
> ID space, but that system is definitely post 3-wire APIC :)
Doesn't mean the BIOS code was updated adequately following that.
What I'm confused by is why this system boots in the first place. I can
only think that's is a system which only has 4-bit APIC IDs, and happens
to function when bit 4 gets truncated off the top of the SIPI destination...
~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: [RFC PATCH 1/2] arm64: amlogic: add new ARCH_AMLIPC for IPC SoC
From: Neil Armstrong @ 2023-04-19 13:43 UTC (permalink / raw)
To: Dmitry Rokosov, =Xianwei Zhao
Cc: linux-arm-kernel, linux-kernel, linux-amlogic, devicetree,
Catalin Marinas, Will Deacon, Kevin Hilman, Rob Herring,
Krzysztof Kozlowski
In-Reply-To: <20230419131416.cns3xvkbzjeyrnux@CAB-WSD-L081021>
On 19/04/2023 15:14, Dmitry Rokosov wrote:
> On Wed, Apr 19, 2023 at 03:38:33PM +0800, =Xianwei Zhao wrote:
>> From: Xianwei Zhao <xianwei.zhao@amlogic.com>
>>
>> The C series SoCs are designed for smart IP camera
>> applications, which does not belong to Meson series.
>> So, Add ARCH_AMLIPC for the new series.
>>
>> There are now multiple amlogic SoC seies supported, so group them under
>> their own menu. we can easily add new platforms there in the future.
>> Introduce ARCH_AMLOGIC to cover all Amlogic SoC series.
>>
>> No functional changes introduced.
>>
>> Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
>> ---
>> arch/arm64/Kconfig.platforms | 12 ++++++++++++
>> arch/arm64/configs/defconfig | 2 ++
>> 2 files changed, 14 insertions(+)
>>
>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
>> index 89a0b13b058d..bfbc817eef8f 100644
>> --- a/arch/arm64/Kconfig.platforms
>> +++ b/arch/arm64/Kconfig.platforms
>> @@ -162,12 +162,24 @@ config ARCH_MEDIATEK
>> This enables support for MediaTek MT27xx, MT65xx, MT76xx
>> & MT81xx ARMv8 SoCs
>>
>> +menuconfig ARCH_AMLOGIC
>> + bool "NXP SoC support"
>
> NXP? Did you mean "Amlogic"?
>
>> +
>> +if ARCH_AMLOGIC
>> +
>> config ARCH_MESON
>> bool "Amlogic Platforms"
>> help
>> This enables support for the arm64 based Amlogic SoCs
>> such as the s905, S905X/D, S912, A113X/D or S905X/D2
>>
>> +config ARCH_AMLIPC
>
> Do we really need a different ARCH for Amlogic IPC?
> I can imagine that it's not the Meson architecture at all.
> But maybe a better solution is just to rename ARCH_MESON to ARCH_AMLOGIC?
It should be changed treewide, and is it worth it ?
Neil
>
>> + bool "Amlogic IPC Platforms"
>> + help
>> + This enables support for the arm64 based Amlogic IPC SoCs
>> + such as the C302X, C308L
>> +endif
>> +
>> config ARCH_MVEBU
>> bool "Marvell EBU SoC Family"
>> select ARMADA_AP806_SYSCON
>> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
>> index 7790ee42c68a..f231bd1723fd 100644
>> --- a/arch/arm64/configs/defconfig
>> +++ b/arch/arm64/configs/defconfig
>> @@ -46,7 +46,9 @@ CONFIG_ARCH_LG1K=y
>> CONFIG_ARCH_HISI=y
>> CONFIG_ARCH_KEEMBAY=y
>> CONFIG_ARCH_MEDIATEK=y
>> +CONFIG_ARCH_AMLOGIC=y
>> CONFIG_ARCH_MESON=y
>> +CONFIG_ARCH_AMLIPC=y
>> CONFIG_ARCH_MVEBU=y
>> CONFIG_ARCH_NXP=y
>> CONFIG_ARCH_LAYERSCAPE=y
>> --
>> 2.37.1
>>
>>
>> _______________________________________________
>> linux-amlogic mailing list
>> linux-amlogic@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-amlogic
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [patch 00/37] cpu/hotplug, x86: Reworked parallel CPU bringup
From: Thomas Gleixner @ 2023-04-19 13:43 UTC (permalink / raw)
To: Paul Menzel
Cc: linux-kernel, x86, David Woodhouse, Andrew Cooper, Brian Gerst,
Arjan van de Veen, Paolo Bonzini, Paul McKenney, Tom Lendacky,
Sean Christopherson, Oleksandr Natalenko, Guilherme G. Piccoli,
Piotr Gorski, David Woodhouse, Usama Arif, Jürgen Groß,
Boris Ostrovsky, xen-devel, Russell King, Arnd Bergmann,
linux-arm-kernel, Catalin Marinas, Will Deacon, Guo Ren,
linux-csky, Thomas Bogendoerfer, linux-mips,
James E. J. Bottomley, Helge Deller, linux-parisc, Paul Walmsley,
Palmer Dabbelt, linux-riscv, Mark Rutland, Sabin Rapan
In-Reply-To: <877cu83v45.ffs@tglx>
On Wed, Apr 19 2023 at 14:38, Thomas Gleixner wrote:
> On Wed, Apr 19 2023 at 11:38, Thomas Gleixner wrote:
> IOW, the BIOS assignes random numbers to the AP APICs for whatever
> raisins, which leaves the parallel startup low level code up a creek
> without a paddle, except for actually reading the APICID back from the
> APIC. *SHUDDER*
So Andrew just pointed out on IRC that this might be related to the
ancient issue of the 3-wire APIC bus where IO/APIC and APIC shared the
ID space, but that system is definitely post 3-wire APIC :)
Thanks,
tglx
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/33] mm: add utility functions for ptdesc
From: Vernon Yang @ 2023-04-19 13:33 UTC (permalink / raw)
To: Vishal Moola
Cc: Andrew Morton, Matthew Wilcox, linux-mm, linux-arch,
linux-arm-kernel, linux-csky, linux-hexagon, loongarch,
linux-m68k, linux-mips, linux-openrisc, linuxppc-dev, linux-riscv,
linux-s390, linux-sh, sparclinux, linux-um, xen-devel, kvm
In-Reply-To: <20230417205048.15870-5-vishal.moola@gmail.com>
On Mon, Apr 17, 2023 at 01:50:19PM -0700, Vishal Moola wrote:
> Introduce utility functions setting the foundation for ptdescs. These
> will also assist in the splitting out of ptdesc from struct page.
>
> ptdesc_alloc() is defined to allocate new ptdesc pages as compound
> pages. This is to standardize ptdescs by allowing for one allocation
> and one free function, in contrast to 2 allocation and 2 free functions.
>
> Signed-off-by: Vishal Moola (Oracle) <vishal.moola@gmail.com>
> ---
> include/asm-generic/tlb.h | 11 ++++++++++
> include/linux/mm.h | 44 +++++++++++++++++++++++++++++++++++++++
> include/linux/pgtable.h | 13 ++++++++++++
> 3 files changed, 68 insertions(+)
>
> diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
> index b46617207c93..6bade9e0e799 100644
> --- a/include/asm-generic/tlb.h
> +++ b/include/asm-generic/tlb.h
> @@ -481,6 +481,17 @@ static inline void tlb_remove_page(struct mmu_gather *tlb, struct page *page)
> return tlb_remove_page_size(tlb, page, PAGE_SIZE);
> }
>
> +static inline void tlb_remove_ptdesc(struct mmu_gather *tlb, void *pt)
> +{
> + tlb_remove_table(tlb, pt);
> +}
> +
> +/* Like tlb_remove_ptdesc, but for page-like page directories. */
> +static inline void tlb_remove_page_ptdesc(struct mmu_gather *tlb, struct ptdesc *pt)
> +{
> + tlb_remove_page(tlb, ptdesc_page(pt));
> +}
> +
> static inline void tlb_change_page_size(struct mmu_gather *tlb,
> unsigned int page_size)
> {
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index b18848ae7e22..ec3cbe2fa665 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2744,6 +2744,45 @@ static inline pmd_t *pmd_alloc(struct mm_struct *mm, pud_t *pud, unsigned long a
> }
> #endif /* CONFIG_MMU */
>
> +static inline struct ptdesc *virt_to_ptdesc(const void *x)
> +{
> + return page_ptdesc(virt_to_head_page(x));
> +}
> +
> +static inline void *ptdesc_to_virt(struct ptdesc *pt)
> +{
> + return page_to_virt(ptdesc_page(pt));
> +}
> +
> +static inline void *ptdesc_address(struct ptdesc *pt)
> +{
> + return folio_address(ptdesc_folio(pt));
> +}
> +
> +static inline bool ptdesc_is_reserved(struct ptdesc *pt)
> +{
> + return folio_test_reserved(ptdesc_folio(pt));
> +}
> +
> +static inline struct ptdesc *ptdesc_alloc(gfp_t gfp, unsigned int order)
> +{
> + struct page *page = alloc_pages(gfp | __GFP_COMP, order);
> +
> + return page_ptdesc(page);
> +}
> +
> +static inline void ptdesc_free(struct ptdesc *pt)
> +{
> + struct page *page = ptdesc_page(pt);
> +
> + __free_pages(page, compound_order(page));
> +}
> +
> +static inline void ptdesc_clear(void *x)
> +{
> + clear_page(x);
> +}
> +
> #if USE_SPLIT_PTE_PTLOCKS
> #if ALLOC_SPLIT_PTLOCKS
> void __init ptlock_cache_init(void);
> @@ -2970,6 +3009,11 @@ static inline void mark_page_reserved(struct page *page)
> adjust_managed_page_count(page, -1);
> }
>
> +static inline void free_reserved_ptdesc(struct ptdesc *pt)
> +{
> + free_reserved_page(ptdesc_page(pt));
> +}
> +
> /*
> * Default method to free all the __init memory into the buddy system.
> * The freed pages will be poisoned with pattern "poison" if it's within
> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> index 7cc6ea057ee9..7cd803aa38eb 100644
> --- a/include/linux/pgtable.h
> +++ b/include/linux/pgtable.h
> @@ -97,6 +97,19 @@ TABLE_MATCH(ptl, ptl);
> #undef TABLE_MATCH
> static_assert(sizeof(struct ptdesc) <= sizeof(struct page));
>
> +#define ptdesc_page(pt) (_Generic((pt), \
> + const struct ptdesc *: (const struct page *)(pt), \
> + struct ptdesc *: (struct page *)(pt)))
> +
> +#define ptdesc_folio(pt) (_Generic((pt), \
> + const struct ptdesc *: (const struct folio *)(pt), \
> + struct ptdesc *: (struct folio *)(pt)))
> +
> +static inline struct ptdesc *page_ptdesc(struct page *page)
> +{
> + return (struct ptdesc *)page;
> +}
Hi Vishal,
I'm a little curious, why is the page_ptdesc() using inline functions instead of macro?
If this is any magic, please tell me, thank you very much.
> +
> /*
> * A page table page can be thought of an array like this: pXd_t[PTRS_PER_PxD]
> *
>
> --
> 2.39.2
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [patch 00/37] cpu/hotplug, x86: Reworked parallel CPU bringup
From: David Woodhouse @ 2023-04-19 13:32 UTC (permalink / raw)
To: Thomas Gleixner, Paul Menzel
Cc: linux-kernel, x86, Andrew Cooper, Brian Gerst, Arjan van de Veen,
Paolo Bonzini, Paul McKenney, Tom Lendacky, Sean Christopherson,
Oleksandr Natalenko, Guilherme G. Piccoli, Piotr Gorski,
Usama Arif, Jürgen Groß, Boris Ostrovsky, xen-devel,
Russell King, Arnd Bergmann, linux-arm-kernel, Catalin Marinas,
Will Deacon, Guo Ren, linux-csky, Thomas Bogendoerfer, linux-mips,
James E. J. Bottomley, Helge Deller, linux-parisc, Paul Walmsley,
Palmer Dabbelt, linux-riscv, Mark Rutland, Sabin Rapan
In-Reply-To: <877cu83v45.ffs@tglx>
[-- Attachment #1.1: Type: text/plain, Size: 286 bytes --]
On Wed, 2023-04-19 at 14:38 +0200, Thomas Gleixner wrote:
>
> I'm leaning towards disabling the CPUID lead 0x01 based discovery and be
> done with it.
Makes sense. The large machines where users really want the parallel
startup all ought to have X2APIC and hence CPUID 0x0b.
[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5965 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: [RFC PATCH 1/2] arm64: amlogic: add new ARCH_AMLIPC for IPC SoC
From: Dmitry Rokosov @ 2023-04-19 13:14 UTC (permalink / raw)
To: =Xianwei Zhao
Cc: linux-arm-kernel, linux-kernel, linux-amlogic, devicetree,
Catalin Marinas, Will Deacon, Neil Armstrong, Kevin Hilman,
Rob Herring, Krzysztof Kozlowski
In-Reply-To: <20230419073834.972273-2-xianwei.zhao@amlogic.com>
On Wed, Apr 19, 2023 at 03:38:33PM +0800, =Xianwei Zhao wrote:
> From: Xianwei Zhao <xianwei.zhao@amlogic.com>
>
> The C series SoCs are designed for smart IP camera
> applications, which does not belong to Meson series.
> So, Add ARCH_AMLIPC for the new series.
>
> There are now multiple amlogic SoC seies supported, so group them under
> their own menu. we can easily add new platforms there in the future.
> Introduce ARCH_AMLOGIC to cover all Amlogic SoC series.
>
> No functional changes introduced.
>
> Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
> ---
> arch/arm64/Kconfig.platforms | 12 ++++++++++++
> arch/arm64/configs/defconfig | 2 ++
> 2 files changed, 14 insertions(+)
>
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 89a0b13b058d..bfbc817eef8f 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -162,12 +162,24 @@ config ARCH_MEDIATEK
> This enables support for MediaTek MT27xx, MT65xx, MT76xx
> & MT81xx ARMv8 SoCs
>
> +menuconfig ARCH_AMLOGIC
> + bool "NXP SoC support"
NXP? Did you mean "Amlogic"?
> +
> +if ARCH_AMLOGIC
> +
> config ARCH_MESON
> bool "Amlogic Platforms"
> help
> This enables support for the arm64 based Amlogic SoCs
> such as the s905, S905X/D, S912, A113X/D or S905X/D2
>
> +config ARCH_AMLIPC
Do we really need a different ARCH for Amlogic IPC?
I can imagine that it's not the Meson architecture at all.
But maybe a better solution is just to rename ARCH_MESON to ARCH_AMLOGIC?
> + bool "Amlogic IPC Platforms"
> + help
> + This enables support for the arm64 based Amlogic IPC SoCs
> + such as the C302X, C308L
> +endif
> +
> config ARCH_MVEBU
> bool "Marvell EBU SoC Family"
> select ARMADA_AP806_SYSCON
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 7790ee42c68a..f231bd1723fd 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -46,7 +46,9 @@ CONFIG_ARCH_LG1K=y
> CONFIG_ARCH_HISI=y
> CONFIG_ARCH_KEEMBAY=y
> CONFIG_ARCH_MEDIATEK=y
> +CONFIG_ARCH_AMLOGIC=y
> CONFIG_ARCH_MESON=y
> +CONFIG_ARCH_AMLIPC=y
> CONFIG_ARCH_MVEBU=y
> CONFIG_ARCH_NXP=y
> CONFIG_ARCH_LAYERSCAPE=y
> --
> 2.37.1
>
>
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic
--
Thank you,
Dmitry
_______________________________________________
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