* Re: [PATCH net-next 1/2] dt-bindings: net: mediatek: add WED RX binding for MT7981 eth driver
From: AngeloGioacchino Del Regno @ 2023-04-20 7:40 UTC (permalink / raw)
To: Daniel Golle, devicetree, netdev, linux-mediatek,
linux-arm-kernel, linux-kernel, Rob Herring, Krzysztof Kozlowski,
Felix Fietkau, John Crispin, Sean Wang, Mark Lee,
Lorenzo Bianconi, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Matthias Brugger
In-Reply-To: <e970078a937c39067d5733ddafb64d0eb56ac474.1681930898.git.daniel@makrotopia.org>
Il 19/04/23 21:04, Daniel Golle ha scritto:
> Add compatible string for mediatek,mt7981-wed as MT7981 also supports
> RX WED just like MT7986, but needs a different firmware file.
>
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> ---
> .../devicetree/bindings/arm/mediatek/mediatek,mt7622-wed.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-wed.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-wed.yaml
> index 5c223cb063d48..2c5e04c9adcc8 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-wed.yaml
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-wed.yaml
> @@ -21,6 +21,7 @@ properties:
> - enum:
> - mediatek,mt7622-wed
> - mediatek,mt7986-wed
> + - mediatek,mt7981-wed
Please, keep entries ordered. 7891 goes before 7986.
Cheers,
Angelo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V22 2/3] misc: dcc: Add driver support for Data Capture and Compare unit(DCC)
From: Greg Kroah-Hartman @ 2023-04-20 6:58 UTC (permalink / raw)
To: Trilok Soni
Cc: Souradeep Chowdhury, Arnd Bergmann, Andy Gross, Konrad Dybcio,
Krzysztof Kozlowski, Bjorn Andersson, Rob Herring, Alex Elder,
linux-arm-kernel, linux-kernel, linux-arm-msm, devicetree,
Sibi Sankar, Rajendra Nayak
In-Reply-To: <2024b144-42cf-1044-258c-2dc6c6af0d88@quicinc.com>
On Wed, Apr 19, 2023 at 09:10:14AM -0700, Trilok Soni wrote:
> On 4/19/2023 9:08 AM, Trilok Soni wrote:
> > On 4/19/2023 3:20 AM, Souradeep Chowdhury wrote:
> > >
> > >
> > > On 4/19/2023 1:00 PM, Arnd Bergmann wrote:
> > > > On Wed, Apr 19, 2023, at 09:00, Souradeep Chowdhury wrote:
> > > > > On 4/18/2023 9:15 PM, Greg Kroah-Hartman wrote:
> > > > > >
> > > > > > > The following is the justification of using debugfs
> > > > > > > interface over the
> > > > > > > other alternatives like sysfs/ioctls
> > > > > > >
> > > > > > > i) As can be seen from the debugfs attribute
> > > > > > > descriptions, some of the
> > > > > > > debugfs attribute files here contains multiple
> > > > > > > arguments which needs to
> > > > > > > be accepted from the user. This goes against the
> > > > > > > design style of sysfs.
> > > > > > >
> > > > > > > ii) The user input patterns have been made simple
> > > > > > > and convenient in this
> > > > > > > case with the use of debugfs interface as user
> > > > > > > doesn't need to shuffle
> > > > > > > between different files to execute one instruction as was the case on
> > > > > > > using other alternatives.
> > > > > >
> > > > > > Why do you have debugfs and also a misc device? How are they related?
> > > > > > Why both? Why not just one? What userspace tools are going to use
> > > > > > either of these interfaces and where are they published
> > > > > > to show how this
> > > > > > all was tested?
> > > > >
> > > > > DCC has two fundamental steps of usage:-
> > > > >
> > > > > 1.Configuring the register addresses on the dcc_sram which is done by
> > > > > user through the debugfs interface. For example:-
> > > > >
> > > > > echo R 0x10c004 > /sys/kernel/debug/dcc/../3/config
> > > > >
> > > > > Here we are configuring the register addresses for list 3, the 'R'
> > > > > indicates a read operation, so this register value will be read
> > > > > in case of a software trigger or kernel panic/watchdog bite and
> > > > > dumped into the dcc_sram.
> > > >
> > > > Can you describe why the register location needs to be
> > > > runtime configurable? I would have expected this type of setting
> > > > to be part of the devicetree, which already describes other
> > > > parts that interact with sram devices.
> > >
> > > Register addresses are made runtime configurable to give the user the
> > > option of going for a software trigger. So the user can debug issues
> > > during run-time as well. These register locations are arbitrary
> > > and is configured by the user for debugging purposes and is not
> > > related to the DCC hardware itself.
> >
> > Please note that we don't want to recompile the devicetree for new
> > settings since these registers can be set by team of engineers who are
> > debugging system level issues with various IPs across the SOCs. You
> > don't want to recompile the images while reproducing the system hangs/IP
> > watchdogs etc;
>
> ...and also these registers list is not fixed, it will vary based on the
> problem you are seeing and debugging on the SOC across the IPs.
Then all of this should be documented in the driver, and in the
changelog please.
thanks,
greg k-h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 6/7] ASoC: mediatek: mt8188: add bus protection
From: Trevor Wu (吳文良) @ 2023-04-20 6:44 UTC (permalink / raw)
To: robh+dt@kernel.org, broonie@kernel.org, tiwai@suse.com,
lgirdwood@gmail.com, krzysztof.kozlowski+dt@linaro.org,
matthias.bgg@gmail.com, perex@perex.cz,
angelogioacchino.delregno@collabora.com
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
alsa-devel@alsa-project.org, devicetree@vger.kernel.org
In-Reply-To: <23dea66b-27cd-dbeb-37f5-ad9566e50962@collabora.com>
On Thu, 2023-04-13 at 15:19 +0200, AngeloGioacchino Del Regno wrote:
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>
>
> Il 13/04/23 12:47, Trevor Wu ha scritto:
> > Add bus protection for reset controller.
> >
> > Signed-off-by: Trevor Wu <trevor.wu@mediatek.com>
>
> Is MT8188 the only SoC that will ever use bus protection for reset,
> now and
> in the future?
>
> ...otherwise, I think that the best solution here would be to
> implement that
> into the reset controller itself.
>
> Regards,
> Angelo
Hi Angelo,
MT8188 is not the only SoC that will use bus protection for reset.
I checked with the owner of reset controller.
There are some reasons that they prefer to control bus protection by
each module which needs reset function individually. First, reset
function is only used by few modules. Second, bus protection register
for the same module is possibly different in each of SoCs. Finally, bus
protect bits are diverse, so it's not easy to implement in reset
controller driver.
Thanks,
Trevor
_______________________________________________
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 7/7] ASoC: dt-bindings: mediatek,mt8188-afe: add audio properties
From: Trevor Wu (吳文良) @ 2023-04-20 6:25 UTC (permalink / raw)
To: robh+dt@kernel.org, krzysztof.kozlowski@linaro.org,
broonie@kernel.org, tiwai@suse.com, lgirdwood@gmail.com,
krzysztof.kozlowski+dt@linaro.org, matthias.bgg@gmail.com,
perex@perex.cz, angelogioacchino.delregno@collabora.com
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
alsa-devel@alsa-project.org, devicetree@vger.kernel.org
In-Reply-To: <47f27da1-8ed1-327e-74d7-ad4e3f12e3d6@linaro.org>
On Tue, 2023-04-18 at 14:25 +0200, Krzysztof Kozlowski wrote:
> On 18/04/2023 12:23, Trevor Wu (吳文良) wrote:
> > > Actually, doing that is borderline-ok... there's no devicetree
> > > for
> > > MT8188
> > > upstream, so that's not breaking anything at all.
> > > In any case, I agree that you should generally avoid doing that
> > > but I
> > > think
> > > that in this specific case it's fine; I'm not a devicetree
> > > maintainer
> > > though.
> > >
> > > P.S.: Trevor, next time please make reviewers aware of the fact
> > > that
> > > no 8188
> > > devicetree is present upstream!
> > >
> >
> > Got it. Thanks.
> >
> >
> > Hi krzysztof,
> >
> > Because there is no upstream mt8188 DTS, should I move the new
> > clock to
> > the end of clock list?
>
> What is the reason to add them in the middle? So far there was no
> argument, so always add at the end. If you have an argument, let's
> discuss it.
>
No special reason. Just hope to sort the clock by the clock type.
But it's possible to extend the clock list after we upstream MT8188
DTS, so it won't follow the order finally.
I think it is fine to put the clock at the end. I will move it to the
end in V2.
> >
> > If I move "apll1_d4" to the end of the list at binding file, when I
> > upstream the devicetree node existing clocks and clock-names
> > properties
> > , should I follow the sequence defined in dt-bindings
>
> If you do not follow the sequence of bindings, you upstream incorrect
> DTS which does not follow ABI and fails the tests. Therefore yes, use
> the same order as your bindings define.
>
> > or can I have a
> > new sequence based on the clock type or alphabet?
>
> Sorry, I don't know what is the order of clock type and alphabet. If
> you
> mean anything else than bindings, then no, because how is it supposed
> to
> work then?
>
>
Got it. Thanks for the detailed explanation.
I will follow the order as bindings when I update the DTS node.
Thanks,
Trevor
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] soc: ti: pruss: Avoid cast to incompatible function type
From: Md Danish Anwar @ 2023-04-20 5:49 UTC (permalink / raw)
To: Simon Horman, Nishanth Menon, Santosh Shilimkar
Cc: Nathan Chancellor, Nick Desaulniers, Tom Rix, linux-kernel,
linux-arm-kernel, llvm
In-Reply-To: <20230418-pruss-clk-cb-v1-1-549a7e7febe4@kernel.org>
On 18/04/23 17:11, Simon Horman wrote:
> Rather than casting clk_unregister_mux to an incompatible function
> type provide a trivial wrapper with the correct signature for the
> use-case.
>
> Reported by clang-16 with W=1:
>
> drivers/soc/ti/pruss.c:158:38: error: cast from 'void (*)(struct clk *)' to 'void (*)(void *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict]
> ret = devm_add_action_or_reset(dev, (void(*)(void *))clk_unregister_mux,
>
> No functional change intended.
> Compile tested only.
>
> Signed-off-by: Simon Horman <horms@kernel.org>
> ---
> drivers/soc/ti/pruss.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/soc/ti/pruss.c b/drivers/soc/ti/pruss.c
> index 6882c86b3ce5..e68441bd7b30 100644
> --- a/drivers/soc/ti/pruss.c
> +++ b/drivers/soc/ti/pruss.c
> @@ -38,6 +38,11 @@ static void pruss_of_free_clk_provider(void *data)
> of_node_put(clk_mux_np);
> }
>
> +static void pruss_clk_unregister_mux(void *data)
> +{
> + clk_unregister_mux(data);
> +}
> +
> static int pruss_clk_mux_setup(struct pruss *pruss, struct clk *clk_mux,
> char *mux_name, struct device_node *clks_np)
> {
> @@ -93,8 +98,7 @@ static int pruss_clk_mux_setup(struct pruss *pruss, struct clk *clk_mux,
> goto put_clk_mux_np;
> }
>
> - ret = devm_add_action_or_reset(dev, (void(*)(void *))clk_unregister_mux,
> - clk_mux);
> + ret = devm_add_action_or_reset(dev, pruss_clk_unregister_mux, clk_mux);
> if (ret) {
> dev_err(dev, "failed to add clkmux unregister action %d", ret);
> goto put_clk_mux_np;
>
>
> From mboxrd@z Thu Jan 1 00:00:00 1970
> Return-Path: <linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org>
> X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
> aws-us-west-2-korg-lkml-1.web.codeaurora.org
> Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133])
> (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
> (No client certificate requested)
> by smtp.lore.kernel.org (Postfix) with ESMTPS id 91400C77B78
> for <linux-arm-kernel@archiver.kernel.org>; Tue, 18 Apr 2023 11:42:44 +0000 (UTC)
> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
> d=lists.infradead.org; s=bombadil.20210309; h=Sender:
> Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post:
> List-Archive:List-Unsubscribe:List-Id:Cc:To:Message-Id:MIME-Version:Subject:
> Date:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:
> Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:
> List-Owner; bh=+CAO6uf34Wr1geK3ZRBtb0JAI43xTLZvVoAx3bYFR8o=; b=cuIUNZeFjlNWar
> n1qXrpSC2BWjTp1I6lb3nOHEvktz/aw4F5DEvvoNHxGvFGjKOkNVCOZ8kbNaPmbgN+kTATZka4FkF
> qQ/sW/CVCX/kWrwG1Wp/Q0rQfY1gO9+SaQEKNFvIM/RKK/G/9IP0kk2vQDjozKlCG52ka8uzTU5/Y
> mv5rKIYXf6KAsCH8KNxykQvIo5vCnaRzOIh/DGnFsuCdD0ShIuf1ymQBmFmg6rpXtTNBaiEU9asnR
> JbTngu0Ike23z2CkRSjpjDU7yULHoaUcp0FELF8NnkX5bbbKsPpjww949637SS7v9pEs11L7pNeDi
> lW4G7+LEEpL2z2yRkAPQ==;
> Received: from localhost ([::1] helo=bombadil.infradead.org)
> by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux))
> id 1pojif-001zZA-2v;
> Tue, 18 Apr 2023 11:41:57 +0000
> Received: from dfw.source.kernel.org ([139.178.84.217])
> by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux))
> id 1pojid-001zYi-0s
> for linux-arm-kernel@lists.infradead.org;
> Tue, 18 Apr 2023 11:41:56 +0000
> Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140])
> (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
> (No client certificate requested)
> by dfw.source.kernel.org (Postfix) with ESMTPS id B371562AB8;
> Tue, 18 Apr 2023 11:41:54 +0000 (UTC)
> Received: by smtp.kernel.org (Postfix) with ESMTPSA id 82D70C433EF;
> Tue, 18 Apr 2023 11:41:52 +0000 (UTC)
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
> s=k20201202; t=1681818114;
> bh=HDO76kSQTCd/EdXhW03QxEZMNUJlfvxdzP1GEo8IYVg=;
> h=From:Date:Subject:To:Cc:From;
> b=JZMzw7vBy3kF7tUHrf3heWahdw/+GlTfSbSfX4l8BXBY+xlpkYbzXBZF6yUtnZ6ei
> X9heGXlXJ7Qjq+ln6+s1947UlK8OkkZ8GO5SvG5L6ek9ceYzedjuzvPZfxymikoQY+
> e3xN7D2jgVVu7zVcX2rgraJ86iVq7G62fX9TnTnZ3cy6CQpj1mkPaQSTd0FJ09djlq
> Ott8fvgXVB18h1Z2jWGiQOs3a4y7x0d+smz5RcKCOs2Qm6EWCicR19vJHHrpjqh3Yd
> Wycn9PVVKILWspPmYdQLWAj2UTH539mJEdC3MrBHQG5XKAoYZ45uelHZwLuE+fL9gI
> hj7mkdKhM7mmg==
> From: Simon Horman <horms@kernel.org>
> Date: Tue, 18 Apr 2023 13:41:48 +0200
> Subject: [PATCH] soc: ti: pruss: Avoid cast to incompatible function type
> MIME-Version: 1.0
> Message-Id: <20230418-pruss-clk-cb-v1-1-549a7e7febe4@kernel.org>
> X-B4-Tracking: v=1; b=H4sIAPuBPmQC/x2N0QqDMAwAf0XyvICtE8d+ZeyhjekMlk4SHAPx3
> xf2eAfHHWCswgb37gDlj5i8m0O4dEBLai9GmZ0h9nHor+GGm+5mSHVFyljGkOfINA1jAU9yMsa
> sqdHiUdtrdbkpF/n+H4/nef4A+lxSD3MAAAA=
> To: Nishanth Menon <nm@ti.com>, Santosh Shilimkar <ssantosh@kernel.org>
> Cc: Nathan Chancellor <nathan@kernel.org>,
> Nick Desaulniers <ndesaulniers@google.com>, Tom Rix <trix@redhat.com>,
> linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
> llvm@lists.linux.dev, Simon Horman <horms@kernel.org>
> X-Mailer: b4 0.12.2
> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3
> X-CRM114-CacheID: sfid-20230418_044155_365668_53307A20
> X-CRM114-Status: GOOD ( 11.38 )
> X-BeenThere: linux-arm-kernel@lists.infradead.org
> X-Mailman-Version: 2.1.34
> Precedence: list
> List-Id: <linux-arm-kernel.lists.infradead.org>
> List-Unsubscribe: <http://lists.infradead.org/mailman/options/linux-arm-kernel>,
> <mailto:linux-arm-kernel-request@lists.infradead.org?subject=unsubscribe>
> List-Archive: <http://lists.infradead.org/pipermail/linux-arm-kernel/>
> List-Post: <mailto:linux-arm-kernel@lists.infradead.org>
> List-Help: <mailto:linux-arm-kernel-request@lists.infradead.org?subject=help>
> List-Subscribe: <http://lists.infradead.org/mailman/listinfo/linux-arm-kernel>,
> <mailto:linux-arm-kernel-request@lists.infradead.org?subject=subscribe>
> Content-Type: text/plain; charset="us-ascii"
> Content-Transfer-Encoding: 7bit
> Sender: "linux-arm-kernel" <linux-arm-kernel-bounces@lists.infradead.org>
> Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org
>
> Rather than casting clk_unregister_mux to an incompatible function
> type provide a trivial wrapper with the correct signature for the
> use-case.
>
> Reported by clang-16 with W=1:
>
> drivers/soc/ti/pruss.c:158:38: error: cast from 'void (*)(struct clk *)' to 'void (*)(void *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict]
> ret = devm_add_action_or_reset(dev, (void(*)(void *))clk_unregister_mux,
>
> No functional change intended.
> Compile tested only.
>
> Signed-off-by: Simon Horman <horms@kernel.org>
Reviewed-by: MD Danish Anwar <danishanwar@ti.com>
> ---
> drivers/soc/ti/pruss.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/soc/ti/pruss.c b/drivers/soc/ti/pruss.c
> index 6882c86b3ce5..e68441bd7b30 100644
> --- a/drivers/soc/ti/pruss.c
> +++ b/drivers/soc/ti/pruss.c
> @@ -38,6 +38,11 @@ static void pruss_of_free_clk_provider(void *data)
> of_node_put(clk_mux_np);
> }
>
> +static void pruss_clk_unregister_mux(void *data)
> +{
> + clk_unregister_mux(data);
> +}
> +
> static int pruss_clk_mux_setup(struct pruss *pruss, struct clk *clk_mux,
> char *mux_name, struct device_node *clks_np)
> {
> @@ -93,8 +98,7 @@ static int pruss_clk_mux_setup(struct pruss *pruss, struct clk *clk_mux,
> goto put_clk_mux_np;
> }
>
> - ret = devm_add_action_or_reset(dev, (void(*)(void *))clk_unregister_mux,
> - clk_mux);
> + ret = devm_add_action_or_reset(dev, pruss_clk_unregister_mux, clk_mux);
> if (ret) {
> dev_err(dev, "failed to add clkmux unregister action %d", ret);
> goto put_clk_mux_np;
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Thanks and Regards,
Danish.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V3] spi: cadence-quadspi: use macro DEFINE_SIMPLE_DEV_PM_OPS
From: Dhruva Gole @ 2023-04-20 5:42 UTC (permalink / raw)
To: Mark Brown
Cc: Dhruva Gole, Vaishnav Achath, Vignesh, Apurva Nandan,
linux-arm-kernel, linux-spi, linux-kernel, kernel test robot
Using this macro makes the code more readable.
It also inits the members of dev_pm_ops in the following manner
without us explicitly needing to:
.suspend = cqspi_suspend, \
.resume = cqspi_resume, \
.freeze = cqspi_suspend, \
.thaw = cqspi_resume, \
.poweroff = cqspi_suspend, \
.restore = cqspi_resume
Also get rid of conditional compilation based on CONFIG_PM_SLEEP because
it introduces build issues with certain configs when CQSPI_DEV_PM_OPS is
just NULL.
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/oe-kbuild-all/202304191900.2fARFQW9-lkp@intel.com/
Fixes: 140623410536 ("mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller")
Signed-off-by: Dhruva Gole <d-gole@ti.com>
---
Previously sent here:
https://lore.kernel.org/all/20230419084817.481136-1-d-gole@ti.com/
Base: next-20230419
Changelog:
* Fix build errors reported by kernel test bot.
drivers/spi/spi-cadence-quadspi.c | 13 ++-----------
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c
index 53829eb5eca0..6ddb2dfc0f00 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -1820,7 +1820,6 @@ static void cqspi_remove(struct platform_device *pdev)
pm_runtime_disable(&pdev->dev);
}
-#ifdef CONFIG_PM_SLEEP
static int cqspi_suspend(struct device *dev)
{
struct cqspi_st *cqspi = dev_get_drvdata(dev);
@@ -1850,15 +1849,7 @@ static int cqspi_resume(struct device *dev)
return spi_master_resume(master);
}
-static const struct dev_pm_ops cqspi__dev_pm_ops = {
- .suspend = cqspi_suspend,
- .resume = cqspi_resume,
-};
-
-#define CQSPI_DEV_PM_OPS (&cqspi__dev_pm_ops)
-#else
-#define CQSPI_DEV_PM_OPS NULL
-#endif
+static DEFINE_SIMPLE_DEV_PM_OPS(cqspi_dev_pm_ops, cqspi_suspend, cqspi_resume);
static const struct cqspi_driver_platdata cdns_qspi = {
.quirks = CQSPI_DISABLE_DAC_MODE,
@@ -1933,7 +1924,7 @@ static struct platform_driver cqspi_platform_driver = {
.remove_new = cqspi_remove,
.driver = {
.name = CQSPI_NAME,
- .pm = CQSPI_DEV_PM_OPS,
+ .pm = &cqspi_dev_pm_ops,
.of_match_table = cqspi_dt_ids,
},
};
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 5/6] drm: bridge: samsung-dsim: Support non-burst mode
From: Adam Ford @ 2023-04-20 2:24 UTC (permalink / raw)
To: Marek Vasut
Cc: dri-devel, m.szyprowski, aford, Rob Herring, Krzysztof Kozlowski,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, Inki Dae, Jagan Teki, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, David Airlie, Daniel Vetter, Frieder Schrempf,
devicetree, linux-arm-kernel, linux-kernel, Lucas Stach
In-Reply-To: <ac7ce475-23dd-4d9d-afd1-ad139496a510@denx.de>
On Mon, Apr 17, 2023 at 6:23 PM Marek Vasut <marex@denx.de> wrote:
>
> On 4/18/23 00:24, Adam Ford wrote:
> > On Mon, Apr 17, 2023 at 3:08 PM Marek Vasut <marex@denx.de> wrote:
> >>
> >> On 4/17/23 13:57, Adam Ford wrote:
> >>> On Sun, Apr 16, 2023 at 5:13 PM Marek Vasut <marex@denx.de> wrote:
> >>>>
> >>>> On 4/15/23 12:41, Adam Ford wrote:
> >>>>> The high-speed clock is hard-coded to the burst-clock
> >>>>> frequency specified in the device tree. However, when
> >>>>> using devices like certain bridge chips without burst mode
> >>>>> and varying resolutions and refresh rates, it may be
> >>>>> necessary to set the high-speed clock dynamically based
> >>>>> on the desired pixel clock for the connected device.
> >>>>
> >>>> The link rate negotiation should happen internally between the nearest
> >>>> bridge and DSIM, so please add that to DRM core instead of hacking
> >>>> around it by tweaking the HS clock again.
> >>>
> >>> I thought you tried to add something like this before and had some resistance.
> >>
> >> Yes, all my attempts were rejected by a single reviewer. I suspended my
> >> efforts in that area for now.
> >>
> >>> The Pixel clock is set by the bridge already without any new code
> >>> added to the DRM core.. I am just reading that value that's there,
> >>> and setting the clock accordingly. I don't see how this is a hack.
> >>
> >> Assume you have a DSI-to-HDMI bridge attached to your DSIM bridge, it
> >> operates in non-burst mode, like ADV7533 . How would you configure the
> >
> > I have an ADV7535
> >
> >> HS clock rate for such a bridge in DT ? (hint: you cannot, because the
> >> required clock comes from the EDID, which may not be available just yet)
> >
> > The whole idea is that you wouldn't want to or need to configure the
> > clock speed in the device tree because it comes from the
> > EDID->bridge->DSI.
> >
> > I've tested this configuration on imx8mm, imx8mn, and imx8mp and I can
> > change the resolution and refresh rate on the fly and the DSI will
> > automatically readjust accordingly. If you fixed the clock in the
> > device tree, you wouldn't be able to do that, and that was the point
> > of this patch.
>
> Uh, I retract my comment, I was clearly confused here and we're talking
> about the same thing.
I'm working on a V2 for this series. Are you OK with this if I update
the commit message a bit to make it more clear?
adam
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 1/2] KVM: arm64: Acquire mp_state_lock in kvm_arch_vcpu_ioctl_vcpu_init()
From: Reiji Watanabe @ 2023-04-20 2:13 UTC (permalink / raw)
To: Marc Zyngier
Cc: Oliver Upton, kvmarm, kvm, linux-arm-kernel, James Morse,
Alexandru Elisei, Zenghui Yu, Suzuki K Poulose, Paolo Bonzini,
Ricardo Koller, Jing Zhang, Raghavendra Rao Anata, Will Deacon
In-Reply-To: <87cz405or6.wl-maz@kernel.org>
Hi Marc,
On Wed, Apr 19, 2023 at 08:12:45AM +0100, Marc Zyngier wrote:
> On Wed, 19 Apr 2023 03:18:51 +0100,
> Reiji Watanabe <reijiw@google.com> wrote:
> > kvm_arch_vcpu_ioctl_vcpu_init() doesn't acquire mp_state_lock
> > when setting the mp_state to KVM_MP_STATE_RUNNABLE. Fix the
> > code to acquire the lock.
> >
> > Signed-off-by: Reiji Watanabe <reijiw@google.com>
> > ---
> > arch/arm64/kvm/arm.c | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > index fbafcbbcc463..388aa4f18f21 100644
> > --- a/arch/arm64/kvm/arm.c
> > +++ b/arch/arm64/kvm/arm.c
> > @@ -1244,8 +1244,11 @@ static int kvm_arch_vcpu_ioctl_vcpu_init(struct kvm_vcpu *vcpu,
> > */
> > if (test_bit(KVM_ARM_VCPU_POWER_OFF, vcpu->arch.features))
> > kvm_arm_vcpu_power_off(vcpu);
> > - else
> > + else {
> > + spin_lock(&vcpu->arch.mp_state_lock);
> > WRITE_ONCE(vcpu->arch.mp_state.mp_state, KVM_MP_STATE_RUNNABLE);
> > + spin_unlock(&vcpu->arch.mp_state_lock);
> > + }
> >
> > return 0;
> > }
>
> I'm not entirely convinced that this fixes anything. What does the
> lock hazard against given that the write is atomic? But maybe a
It appears that kvm_psci_vcpu_on() expects the vCPU's mp_state
to not be changed by holding the lock. Although I don't think this
code practically causes any real issues now, I am a little concerned
about leaving one instance that updates mpstate without acquiring the
lock, in terms of future maintenance, as holding the lock won't prevent
mp_state from being updated.
What do you think ?
> slightly more readable of this would be to expand the critical section
> this way:
>
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index 4ec888fdd4f7..bb21d0c25de7 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -1246,11 +1246,15 @@ static int kvm_arch_vcpu_ioctl_vcpu_init(struct kvm_vcpu *vcpu,
> /*
> * Handle the "start in power-off" case.
> */
> + spin_lock(&vcpu->arch.mp_state_lock);
> +
> if (test_bit(KVM_ARM_VCPU_POWER_OFF, vcpu->arch.features))
> - kvm_arm_vcpu_power_off(vcpu);
> + __kvm_arm_vcpu_power_off(vcpu);
> else
> WRITE_ONCE(vcpu->arch.mp_state.mp_state, KVM_MP_STATE_RUNNABLE);
>
> + spin_unlock(&vcpu->arch.mp_state_lock);
> +
> return 0;
> }
>
> Thoughts?
Yes, it looks better!
Thank you,
Reiji
_______________________________________________
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 linux-next v3 4/4] clocksource/drivers/timer-mediatek: Make timer-mediatek become loadable module
From: Walter Chang (張維哲) @ 2023-04-20 1:46 UTC (permalink / raw)
To: tglx@linutronix.de, daniel.lezcano@linaro.org,
matthias.bgg@gmail.com, jstultz@google.com,
angelogioacchino.delregno@collabora.com, macro@orcam.me.uk
Cc: linux-arm-kernel@lists.infradead.org, wsd_upstream,
linux-kernel@vger.kernel.org,
Stanley Chu (朱原陞),
Freddy Hsin (辛恒豐),
linux-mediatek@lists.infradead.org,
Chun-Hung Wu (巫駿宏)
In-Reply-To: <3dac0be8-6a49-43db-da65-e99d2e9719e6@collabora.com>
On Wed, 2023-04-19 at 10:10 +0200, AngeloGioacchino Del Regno wrote:
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>
>
> Il 19/04/23 09:49, walter.chang@mediatek.com ha scritto:
> > From: Chun-Hung Wu <chun-hung.wu@mediatek.com>
> >
> > Make the timer-mediatek driver which can register
> > an always-on timer as tick_broadcast_device on
> > MediaTek SoCs become loadable module in GKI.
> >
> > Tested-by: Walter Chang <walter.chang@mediatek.com>
> > Signed-off-by: Chun-Hung Wu <chun-hung.wu@mediatek.com>
>
> I think I typoed your email when sending the example patch for the
> conversion to platform_device. Check [1], it may be better to just
> iterate through that? (please ignore the pure_initcall() part, that's
> a mistake, it's never gonna happen as it automatically becomes a
> module_init() call).
>
> It depends on what maintainers think about that clocksource.h
> addition,
> the patch got zero comments, so if you're interested in that perhaps
> we
> can explicitly ask what would be the best option between yours and
> mine;
> that addition is done only to avoid the big ifdef party that this
> patch
> proposes and makes things a bit shorter if this timer modularization
> goes on with more drivers, but I don't have strong opinions anyway.
>
> In the meanwhile, just to eventually speed up integrating this, or
> the
> other patch - I'll still give you a review of this one.
>
> [1]:
>
https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/20230309132119.175650-1-angelogioacchino.delregno@collabora.com/__;!!CTRNKA9wMg0ARbw!kellIP9qWQwZCUsbK9-s9WForDbz_5-CAGdMIzYbGSXgvXjVGnyGmlmGHeKEbXr_URQeKVHnb6eFAh-fBshGD1KTERh-mzSAlQ$
Thank you for providing an alternative implementation to make the timer
driver loadable. We will study whether this solution is feasible.
>
> > ---
> > drivers/clocksource/Kconfig | 2 +-
> > drivers/clocksource/timer-mediatek.c | 39
> > ++++++++++++++++++++++++++++
> > 2 files changed, 40 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/clocksource/Kconfig
> > b/drivers/clocksource/Kconfig
> > index 526382dc7482..a7413ad7b6ad 100644
> > --- a/drivers/clocksource/Kconfig
> > +++ b/drivers/clocksource/Kconfig
> > @@ -472,7 +472,7 @@ config SYS_SUPPORTS_SH_CMT
> > bool
> >
> > config MTK_TIMER
> > - bool "Mediatek timer driver" if COMPILE_TEST
> > + tristate "Mediatek timer driver"
>
> While at it, you could also fix the text, Mediatek -> MediaTek
>
> > depends on HAS_IOMEM
> > select TIMER_OF
> > select CLKSRC_MMIO
> > diff --git a/drivers/clocksource/timer-mediatek.c
> > b/drivers/clocksource/timer-mediatek.c
> > index 7bcb4a3f26fb..3448848682c0 100644
> > --- a/drivers/clocksource/timer-mediatek.c
> > +++ b/drivers/clocksource/timer-mediatek.c
> > @@ -13,6 +13,9 @@
> > #include <linux/clocksource.h>
> > #include <linux/interrupt.h>
> > #include <linux/irqreturn.h>
> > +#include <linux/module.h>
> > +#include <linux/of_device.h>
> > +#include <linux/platform_device.h>
> > #include <linux/sched_clock.h>
> > #include <linux/slab.h>
> > #include "timer-of.h"
> > @@ -337,5 +340,41 @@ static int __init mtk_gpt_init(struct
> > device_node *node)
> >
> > return 0;
> > }
> > +
> > +#ifdef MODULE
>
> #ifndef MODULE
> ... two lines...
> #else
> ... a bunch of lines ...
> #endif
>
> looks more readable. I'd go with that.
>
> > +static int mtk_timer_probe(struct platform_device *pdev)
> > +{
> > + int (*timer_init)(struct device_node *node);
> > + struct device_node *np = pdev->dev.of_node;
> > +
> > + timer_init = of_device_get_match_data(&pdev->dev);
> > + return timer_init(np);
> > +}
> > +
> > +static const struct of_device_id mtk_timer_match_table[] = {
> > + {
> > + .compatible = "mediatek,mt6577-timer",
> > + .data = mtk_gpt_init,
>
> Fits in one line!
>
> > + },
> > + {
> > + .compatible = "mediatek,mt6765-timer",
> > + .data = mtk_syst_init,
>
> ditto.
>
> > + },
> > + {}
>
> Always end with { /* sentinel */ }
>
> > +};
> > +
> > +static struct platform_driver mtk_timer_driver = {
> > + .probe = mtk_timer_probe,
> > + .driver = {
> > + .name = "mtk-timer",
>
> "mediatek-timer" looks nicer :-)
>
> > + .of_match_table = mtk_timer_match_table,
> > + },
> > +};
> > +module_platform_driver(mtk_timer_driver);
> > +
> > +MODULE_DESCRIPTION("MediaTek Module Timer driver");
>
> "MediaTek Timer driver" is enough, "Module" gets misleading if this
> gets compiled
> as built in platform driver (instead of built in timer_of).
>
Thanks for your review, I will fix these in next patch.
Best regards,
Walter Chang
_______________________________________________
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 net-next] net: stmmac: dwmac-meson8b: Avoid cast to incompatible function type
From: patchwork-bot+netdevbpf @ 2023-04-20 1:50 UTC (permalink / raw)
To: Simon Horman
Cc: kuba, davem, edumazet, pabeni, peppe.cavallaro, alexandre.torgue,
joabreu, neil.armstrong, khilman, jbrunet, martin.blumenstingl,
mcoquelin.stm32, nathan, ndesaulniers, trix, netdev,
linux-arm-kernel, linux-amlogic, linux-stm32, llvm
In-Reply-To: <20230418-dwmac-meson8b-clk-cb-cast-v1-1-e892b670cbbb@kernel.org>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 18 Apr 2023 13:07:33 +0200 you wrote:
> Rather than casting clk_disable_unprepare to an incompatible function
> type provide a trivial wrapper with the correct signature for the
> use-case.
>
> Reported by clang-16 with W=1:
>
> drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c:276:6: error: cast from 'void (*)(struct clk *)' to 'void (*)(void *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict]
> (void(*)(void *))clk_disable_unprepare,
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> No functional change intended.
> Compile tested only.
>
> [...]
Here is the summary with links:
- [net-next] net: stmmac: dwmac-meson8b: Avoid cast to incompatible function type
https://git.kernel.org/netdev/net-next/c/43bb6100d8d5
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 net-next v2] net: dsa: mt7530: fix support for MT7531BE
From: Jakub Kicinski @ 2023-04-20 0:41 UTC (permalink / raw)
To: Daniel Golle
Cc: netdev, linux-mediatek, linux-arm-kernel, linux-kernel, Sean Wang,
Landen Chao, DENG Qingfang, Andrew Lunn, Florian Fainelli,
Vladimir Oltean, David S. Miller, Eric Dumazet, Paolo Abeni,
Russell King, AngeloGioacchino Del Regno, Matthias Brugger,
Arınç ÜNAL, Jesse Brandeburg
In-Reply-To: <ZECFvFnhW1D3IRxO@makrotopia.org>
On Thu, 20 Apr 2023 01:22:20 +0100 Daniel Golle wrote:
> This v2 submission addresses the comments made by Jesse Brandeburg
> regarding zero-initializing regmap_config as we are now not necessarily
> using both of them. Comments by Arınç ÜNAL have also been discussed
> and resulting in receiving Ack.
>
> However, I can see in patchwork that the patch has been set to
> "Changes Requested".
>
> Can someone please tell me which further changes are needed?
> I don't see any other comments on the mailing list or patchwork.
Someone mis-categorized :( I was keeping an eye, tho, so it wouldn't
have gotten lost.
Applied now, thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH net-next v2] net: dsa: mt7530: fix support for MT7531BE
From: patchwork-bot+netdevbpf @ 2023-04-20 0:40 UTC (permalink / raw)
To: Daniel Golle
Cc: netdev, linux-mediatek, linux-arm-kernel, linux-kernel, sean.wang,
Landen.Chao, dqfext, andrew, f.fainelli, olteanv, davem, edumazet,
kuba, pabeni, linux, angelogioacchino.delregno, matthias.bgg,
arinc.unal, jesse.brandeburg
In-Reply-To: <ZDvlLhhqheobUvOK@makrotopia.org>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sun, 16 Apr 2023 13:08:14 +0100 you wrote:
> There are two variants of the MT7531 switch IC which got different
> features (and pins) regarding port 5:
> * MT7531AE: SGMII/1000Base-X/2500Base-X SerDes PCS
> * MT7531BE: RGMII
>
> Moving the creation of the SerDes PCS from mt753x_setup to mt7530_probe
> with commit 6de285229773 ("net: dsa: mt7530: move SGMII PCS creation
> to mt7530_probe function") works fine for MT7531AE which got two
> instances of mtk-pcs-lynxi, however, MT7531BE requires mt7531_pll_setup
> to setup clocks before the single PCS on port 6 (usually used as CPU
> port) starts to work and hence the PCS creation failed on MT7531BE.
>
> [...]
Here is the summary with links:
- [net-next,v2] net: dsa: mt7530: fix support for MT7531BE
https://git.kernel.org/netdev/net-next/c/91daa4f62ce8
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 0/4] riscv: Allow userspace to directly access perf counters
From: Ian Rogers @ 2023-04-20 0:31 UTC (permalink / raw)
To: Atish Patra
Cc: Alexandre Ghiti, paranlee, David Laight, Jonathan Corbet,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Mark Rutland, Alexander Shishkin, Jiri Olsa, Namhyung Kim,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Anup Patel, Will Deacon,
Rob Herring, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
linux-riscv@lists.infradead.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAOnJCU+5EQp-AqrwJpBo6ZPWfybwaGyD3zcC0YrCAsSY4=fqdw@mail.gmail.com>
On Wed, Apr 19, 2023 at 4:22 PM Atish Patra <atishp@atishpatra.org> wrote:
>
> On Wed, Apr 19, 2023 at 11:13 PM Ian Rogers <irogers@google.com> wrote:
> >
> > On Wed, Apr 19, 2023 at 2:21 AM Alexandre Ghiti <alexghiti@rivosinc.com> wrote:
> > >
> > > Hi Ian,
> > >
> > > On Tue, Apr 18, 2023 at 10:30 PM Atish Patra <atishp@atishpatra.org> wrote:
> > > >
> > > > On Tue, Apr 18, 2023 at 11:46 PM Ian Rogers <irogers@google.com> wrote:
> > > > >
> > > > > On Tue, Apr 18, 2023 at 9:43 AM Atish Patra <atishp@atishpatra.org> wrote:
> > > > > >
> > > > > > On Fri, Apr 14, 2023 at 2:40 AM David Laight <David.Laight@aculab.com> wrote:
> > > > > > >
> > > > > > > From: Atish Patra
> > > > > > > > Sent: 13 April 2023 20:18
> > > > > > > >
> > > > > > > > On Thu, Apr 13, 2023 at 9:47 PM Alexandre Ghiti <alexghiti@rivosinc.com> wrote:
> > > > > > > > >
> > > > > > > > > riscv used to allow direct access to cycle/time/instret counters,
> > > > > > > > > bypassing the perf framework, this patchset intends to allow the user to
> > > > > > > > > mmap any counter when accessed through perf. But we can't break the
> > > > > > > > > existing behaviour so we introduce a sysctl perf_user_access like arm64
> > > > > > > > > does, which defaults to the legacy mode described above.
> > > > > > > > >
> > > > > > > >
> > > > > > > > It would be good provide additional direction for user space packages:
> > > > > > > >
> > > > > > > > The legacy behavior is supported for now in order to avoid breaking
> > > > > > > > existing software.
> > > > > > > > However, reading counters directly without perf interaction may
> > > > > > > > provide incorrect values which
> > > > > > > > the userspace software must avoid. We are hoping that the user space
> > > > > > > > packages which
> > > > > > > > read the cycle/instret directly, will move to the proper interface
> > > > > > > > eventually if they actually need it.
> > > > > > > > Most of the users are supposed to read "time" instead of "cycle" if
> > > > > > > > they intend to read timestamps.
> > > > > > >
> > > > > > > If you are trying to measure the performance of short code
> > > > > > > fragments then you need pretty much raw access directly to
> > > > > > > the cycle/clock count register.
> > > > > > >
> > > > > > > I've done this on x86 to compare the actual cycle times
> > > > > > > of different implementations of the IP checksum loop
> > > > > > > (and compare them to the theoretical limit).
> > > > > > > The perf framework just added far too much latency,
> > > > > > > only directly reading the cpu registers gave anything
> > > > > > > like reliable (and consistent) answers.
> > > > > > >
> > > > > >
> > > > > > This series allows direct access to the counters once configured
> > > > > > through the perf.
> > > > > > Earlier the cycle/instret counters are directly exposed to the
> > > > > > userspace without kernel/perf frameworking knowing
> > > > > > when/which user space application is reading it. That has security implications.
> > > > > >
> > > > > > With this series applied, the user space application just needs to
> > > > > > configure the event (cycle/instret) through perf syscall.
> > > > > > Once configured, the userspace application can find out the counter
> > > > > > information from the mmap & directly
> > > > > > read the counter. There is no latency while reading the counters.
> > > > > >
> > > > > > This mechanism allows stop/clear the counters when the requesting task
> > > > > > is not running. It also takes care of context switching
> > > > > > which may result in invalid values as you mentioned below. This is
> > > > > > nothing new and all other arch (x86, ARM64) allow user space
> > > > > > counter read through the same mechanism.
> > > > > >
> > > > > > Here is the relevant upstream discussion:
> > > > > > https://lore.kernel.org/lkml/Y7wLa7I2hlz3rKw%2F@hirez.programming.kicks-ass.net/T/
> > > > > >
> > > > > > ARM64:
> > > > > > https://docs.kernel.org/arm64/perf.html?highlight=perf_user_access#perf-userspace-pmu-hardware-counter-access
> > > > > >
> > > > > > example usage in x86:
> > > > > > https://github.com/andikleen/pmu-tools/blob/master/jevents/rdpmc.c
> > > > >
> > > > > The canonical implementation of this should be:
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/lib/perf/mmap.c#n400
> > > >
> > > > Thanks for sharing the libperf implementation.
> > > >
> > > > > which is updated in these patches but the tests are not:
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/perf/tests/mmap-basic.c#n287
> > > > > Which appears to be an oversight. The tests display some differences
> > > >
> > > > Yes. It's an oversight. We should make sure that perf mmap tests pass
> > > > for RISC-V as well.
> > >
> > > Yes, that's an oversight, I had a local test adapted from this one but
> > > forgot to update it afterwards, I'll do that in the next version.
> > >
> > > Thanks for your quick feedbacks and sorry for being late,
> > >
> > > Alex
> >
> > Thanks Alex, there was an equally likely chance that I wasn't
> > understanding things :-) Is there any information on RISC-V PMU
> > testing? I know ParanLee is interested. It'd be awesome to have
>
> Are you looking for something specific to RISC-V general or perf on RISC-V?
> All the RISC-V PMU patches have been upstream for a while (both in the
> Qemu & Linux kernel).
> Perf should work out-of-the box when you boot the latest kernel in the
> latest version of the Qemu.
>
> Initial KVM[1] patches support got merged during the last merge
> window. It doesn't support
> event sampling yet. We are working on that.
>
> [1] https://lore.kernel.org/lkml/20230207095529.1787260-1-atishp@rivosinc.com/
Cool, it'd be nice to have a recipe for this from x86 Linux :-)
> > something say on:
> > https://perf.wiki.kernel.org/index.php/Main_Page
> > on how to run tests, perhaps on QEMU or known to work boards. We can
> > also just drop a link on there if there is information. We can also
> > add the RISC-V PMU information to the links here:
> > https://perf.wiki.kernel.org/index.php/Useful_Links
> >
>
> I did not see any arch specific information there. Let us know what
> would be good to
> add there and we would be happy to add.
I was specifically thinking under Manuals where the Intel, AMD and ARM
manuals are, links to the RISC-V documentation could be added.
Thanks,
Ian
> > Thanks,
> > Ian
> >
> > >
> > > >
> > > >
> > > > > between x86 and aarch64 that have assumed userspace hardware counter
> > > > > access, and everything else that it is assumed don't.
> > > > >
> > > > > Thanks,
> > > > > Ian
> > > > >
> > > > > > > Clearly process switches (especially cpu migrations) cause
> > > > > > > problems, but they are obviously invalid values and can
> > > > > > > be ignored.
> > > > > > >
> > > > > > > So while a lot of uses may be 'happy' with the values the
> > > > > > > perf framework gives, sometimes you do need to directly
> > > > > > > read the relevant registers.
> > > > > > >
> > > > > > > David
> > > > > > >
> > > > > > > -
> > > > > > > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> > > > > > > Registration No: 1397386 (Wales)
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Regards,
> > > > > > Atish
> > > >
> > > >
> > > >
> > > > --
> > > > Regards,
> > > > Atish
>
>
>
> --
> Regards,
> Atish
_______________________________________________
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] perf: arm_cspmu: Separate Arm and vendor module
From: Besar Wicaksono @ 2023-04-20 0:22 UTC (permalink / raw)
To: Suzuki K Poulose, catalin.marinas@arm.com, will@kernel.org,
mark.rutland@arm.com
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org,
Thierry Reding, Jonathan Hunter, Vikram Sethi, Richard Wiley,
Eric Funsten
In-Reply-To: <926a8f15-504e-c7a6-2686-c901f877a4dd@arm.com>
Hi Suzuki,
> -----Original Message-----
> From: Suzuki K Poulose <suzuki.poulose@arm.com>
> Sent: Wednesday, April 19, 2023 4:32 PM
> To: Besar Wicaksono <bwicaksono@nvidia.com>; catalin.marinas@arm.com;
> will@kernel.org; mark.rutland@arm.com
> Cc: linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> tegra@vger.kernel.org; Thierry Reding <treding@nvidia.com>; Jonathan
> Hunter <jonathanh@nvidia.com>; Vikram Sethi <vsethi@nvidia.com>; Richard
> Wiley <rwiley@nvidia.com>; Eric Funsten <efunsten@nvidia.com>
> Subject: Re: [PATCH v2] perf: arm_cspmu: Separate Arm and vendor module
>
> External email: Use caution opening links or attachments
>
>
> On 18/04/2023 20:33, Besar Wicaksono wrote:
> > Hi Suzuki,
> >
> >> -----Original Message-----
> >> From: Suzuki K Poulose <suzuki.poulose@arm.com>
> >> Sent: Tuesday, April 18, 2023 6:07 AM
> >> To: Besar Wicaksono <bwicaksono@nvidia.com>;
> catalin.marinas@arm.com;
> >> will@kernel.org; mark.rutland@arm.com
> >> Cc: linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> linux-
> >> tegra@vger.kernel.org; Thierry Reding <treding@nvidia.com>; Jonathan
> >> Hunter <jonathanh@nvidia.com>; Vikram Sethi <vsethi@nvidia.com>;
> Richard
> >> Wiley <rwiley@nvidia.com>; Eric Funsten <efunsten@nvidia.com>
> >> Subject: Re: [PATCH v2] perf: arm_cspmu: Separate Arm and vendor
> module
> >>
> >> External email: Use caution opening links or attachments
> >>
> >>
> >> On 18/04/2023 07:20, Besar Wicaksono wrote:
> >>> Arm Coresight PMU driver consists of main standard code and vendor
> >>> backend code. Both are currently built as a single module.
> >>> This patch adds vendor registration API to separate the two to
> >>> keep things modular. Vendor module shall register to the main
> >>> module on loading and trigger device reprobe.
> >>>
> >>> Signed-off-by: Besar Wicaksono <bwicaksono@nvidia.com>
> >>> ---
> >>>
> >>> Changes from v1:
> >>> * Added separate Kconfig entry for nvidia backend
> >>> * Added lock to protect accesses to the lists
> >>> * Added support for matching subset devices from a vendor
> >>> * Added state tracking to avoid reprobe when a device is in use
> >>> v1: ttps://lore.kernel.org/linux-arm-kernel/20230403163905.20354-1-
> >> bwicaksono@nvidia.com/T/#u
> >>>
> >>> ---
> >>> drivers/perf/arm_cspmu/Kconfig | 9 +-
> >>> drivers/perf/arm_cspmu/Makefile | 6 +-
> >>> drivers/perf/arm_cspmu/arm_cspmu.c | 280
> >> +++++++++++++++++++++++---
> >>> drivers/perf/arm_cspmu/arm_cspmu.h | 32 ++-
> >>> drivers/perf/arm_cspmu/nvidia_cspmu.c | 39 +++-
> >>> drivers/perf/arm_cspmu/nvidia_cspmu.h | 17 --
> >>> 6 files changed, 325 insertions(+), 58 deletions(-)
> >>> delete mode 100644 drivers/perf/arm_cspmu/nvidia_cspmu.h
> >>>
> >>> diff --git a/drivers/perf/arm_cspmu/Kconfig
> >> b/drivers/perf/arm_cspmu/Kconfig
> >>> index 0b316fe69a45..8ce7b45a0075 100644
> >>> --- a/drivers/perf/arm_cspmu/Kconfig
> >>> +++ b/drivers/perf/arm_cspmu/Kconfig
> >>> @@ -1,6 +1,6 @@
> >>> # SPDX-License-Identifier: GPL-2.0
> >>> #
> >>> -# Copyright (c) 2022, NVIDIA CORPORATION & AFFILIATES. All rights
> >> reserved.
> >>> +# Copyright (c) 2022-2023, NVIDIA CORPORATION & AFFILIATES. All
> rights
> >> reserved.
> >>>
> >>> config ARM_CORESIGHT_PMU_ARCH_SYSTEM_PMU
> >>> tristate "ARM Coresight Architecture PMU"
> >>> @@ -11,3 +11,10 @@ config
> ARM_CORESIGHT_PMU_ARCH_SYSTEM_PMU
> >>> based on ARM CoreSight PMU architecture. Note that this PMU
> >>> architecture does not have relationship with the ARM CoreSight
> >>> Self-Hosted Tracing.
> >>> +
> >>> +config NVIDIA_CORESIGHT_PMU_ARCH_SYSTEM_PMU
> >>> + tristate "NVIDIA Coresight Architecture PMU"
> >>> + depends on ARM_CORESIGHT_PMU_ARCH_SYSTEM_PMU
> >>> + help
> >>> + Provides NVIDIA specific attributes for performance monitoring unit
> >>> + (PMU) devices based on ARM CoreSight PMU architecture.
> >>> diff --git a/drivers/perf/arm_cspmu/Makefile
> >> b/drivers/perf/arm_cspmu/Makefile
> >>> index fedb17df982d..f8ae22411d59 100644
> >>> --- a/drivers/perf/arm_cspmu/Makefile
> >>> +++ b/drivers/perf/arm_cspmu/Makefile
> >>> @@ -1,6 +1,6 @@
> >>> -# Copyright (c) 2022, NVIDIA CORPORATION & AFFILIATES. All rights
> >> reserved.
> >>> +# Copyright (c) 2022-2023, NVIDIA CORPORATION & AFFILIATES. All
> rights
> >> reserved.
> >>> #
> >>> # SPDX-License-Identifier: GPL-2.0
> >>>
> >>> -obj-$(CONFIG_ARM_CORESIGHT_PMU_ARCH_SYSTEM_PMU) +=
> >> arm_cspmu_module.o
> >>> -arm_cspmu_module-y := arm_cspmu.o nvidia_cspmu.o
> >>> +obj-$(CONFIG_ARM_CORESIGHT_PMU_ARCH_SYSTEM_PMU) +=
> >> arm_cspmu.o
> >>> +obj-$(CONFIG_NVIDIA_CORESIGHT_PMU_ARCH_SYSTEM_PMU) +=
> >> nvidia_cspmu.o
> >>> diff --git a/drivers/perf/arm_cspmu/arm_cspmu.c
> >> b/drivers/perf/arm_cspmu/arm_cspmu.c
> >>> index e31302ab7e37..c55ea2b74454 100644
> >>> --- a/drivers/perf/arm_cspmu/arm_cspmu.c
> >>> +++ b/drivers/perf/arm_cspmu/arm_cspmu.c
> >>> @@ -16,7 +16,7 @@
> >>> * The user should refer to the vendor technical documentation to get
> >> details
> >>> * about the supported events.
> >>> *
> >>> - * Copyright (c) 2022, NVIDIA CORPORATION & AFFILIATES. All rights
> >> reserved.
> >>> + * Copyright (c) 2022-2023, NVIDIA CORPORATION & AFFILIATES. All
> rights
> >> reserved.
> >>> *
> >>> */
> >>>
> >>> @@ -25,13 +25,14 @@
> >>> #include <linux/ctype.h>
> >>> #include <linux/interrupt.h>
> >>> #include <linux/io-64-nonatomic-lo-hi.h>
> >>> +#include <linux/list.h>
> >>> #include <linux/module.h>
> >>> +#include <linux/mutex.h>
> >>> #include <linux/perf_event.h>
> >>> #include <linux/platform_device.h>
> >>> #include <acpi/processor.h>
> >>>
> >>> #include "arm_cspmu.h"
> >>> -#include "nvidia_cspmu.h"
> >>>
> >>> #define PMUNAME "arm_cspmu"
> >>> #define DRVNAME "arm-cs-arch-pmu"
> >>> @@ -117,11 +118,52 @@
> >>> */
> >>> #define HILOHI_MAX_POLL 1000
> >>>
> >>> -/* JEDEC-assigned JEP106 identification code */
> >>> -#define ARM_CSPMU_IMPL_ID_NVIDIA 0x36B
> >>> -
> >>> static unsigned long arm_cspmu_cpuhp_state;
> >>>
> >>> +/* List of Coresight PMU instances in the system. */
> >>> +static LIST_HEAD(arm_cspmus);
> >>> +
> >>> +/* List of registered vendor backends. */
> >>> +static LIST_HEAD(arm_cspmu_impls);
> >>> +
> >>> +static DEFINE_MUTEX(arm_cspmu_lock);
> >>> +
> >>> +/*
> >>> + * State of the generic driver.
> >>> + * 0 => registering backend.
> >>> + * 1 => ready to use.
> >>> + * 2 or more => in use.
> >>> + */
> >>> +#define ARM_CSPMU_STATE_REG 0
> >>> +#define ARM_CSPMU_STATE_READY 1
> >>> +static atomic_t arm_cspmu_state;
> >>> +
> >>> +static void arm_cspmu_state_ready(void)
> >>> +{
> >>> + atomic_set(&arm_cspmu_state, ARM_CSPMU_STATE_READY);
> >>> +}
> >>> +
> >>> +static bool try_arm_cspmu_state_reg(void)
> >>> +{
> >>> + const int old = ARM_CSPMU_STATE_READY;
> >>> + const int new = ARM_CSPMU_STATE_REG;
> >>> +
> >>> + return atomic_cmpxchg(&arm_cspmu_state, old, new) == old;
> >>> +}
> >>> +
> >>> +static bool try_arm_cspmu_state_get(void)
> >>> +{
> >>> + return atomic_inc_not_zero(&arm_cspmu_state);
> >>> +}
> >>> +
> >>> +static void arm_cspmu_state_put(void)
> >>> +{
> >>> + int ret;
> >>> +
> >>> + ret = atomic_dec_if_positive(&arm_cspmu_state);
> >>> + WARN_ON(ret < 0);
> >>> +}
> >>> +
> >>
> >> As long as the vendor module is set for the PMU instance, it won't be
> >> unloaded as long as there are any perf events and thus the specific
> >> driver cannot be unloaded. So, you don't need explicit refcount
> >> maintenance for each pmu callbacks.
> >>
> >
> > The arm_cspmu_state mainly protects during new backend registration
> when
> > the device is attached to standard implementation. All devices are attached
> to
> > standard implementation initially when arm_cspmu module is loaded, since
> there
> > is no backend yet. On backend registration, the standard impl is replaced by
> > backend impl. However, the module unloading mechanism doesn't provide
> > protection because standard impl is owned by arm_cspmu module, which
> > is not unloaded during registration.
> >
> > The refcount may not be required if the devices are not attached to standard
> > Implementation by default, and the unreg doesn't fallback to it. But that
> makes
> > the devices usable only when there is a vendor backend available.
>
> Ok, thanks for the explanation. But I still think we :
>
> - Don't need a single global refcount for all the PMUs. Instead this
> could be per PMU instance (arm_cspmu), only when it is backed by
Ok, we can add refcount per PMU.
> "generic" backend, others get module refcount. If the refcount of
> "generic" PMU is positive, during the registration of a matching
> backend driver, we could simply mark that as pending reprobe.
>
> - And only do the refcount for the following call backs:
>
> pmu:: event_init -> hold the refcount
> pmu:: destroy -> drop the refcount and trigger a reprobe if one was
> pending (see above)
Is it safe to reprobe on destroy ? The reprobe will free and reallocate
the memory managed by the device.
Thanks,
Besar
_______________________________________________
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 net-next v2] net: dsa: mt7530: fix support for MT7531BE
From: Daniel Golle @ 2023-04-20 0:22 UTC (permalink / raw)
To: netdev, linux-mediatek, linux-arm-kernel, linux-kernel, Sean Wang,
Landen Chao, DENG Qingfang, Andrew Lunn, Florian Fainelli,
Vladimir Oltean, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Russell King, AngeloGioacchino Del Regno,
Matthias Brugger, Arınç ÜNAL, Jesse Brandeburg
In-Reply-To: <ZDvlLhhqheobUvOK@makrotopia.org>
On Sun, Apr 16, 2023 at 01:08:14PM +0100, Daniel Golle wrote:
> There are two variants of the MT7531 switch IC which got different
> features (and pins) regarding port 5:
> * MT7531AE: SGMII/1000Base-X/2500Base-X SerDes PCS
> * MT7531BE: RGMII
>
> Moving the creation of the SerDes PCS from mt753x_setup to mt7530_probe
> with commit 6de285229773 ("net: dsa: mt7530: move SGMII PCS creation
> to mt7530_probe function") works fine for MT7531AE which got two
> instances of mtk-pcs-lynxi, however, MT7531BE requires mt7531_pll_setup
> to setup clocks before the single PCS on port 6 (usually used as CPU
> port) starts to work and hence the PCS creation failed on MT7531BE.
>
> Fix this by introducing a pointer to mt7531_create_sgmii function in
> struct mt7530_priv and call it again at the end of mt753x_setup like it
> was before commit 6de285229773 ("net: dsa: mt7530: move SGMII PCS
> creation to mt7530_probe function").
>
> Fixes: 6de285229773 ("net: dsa: mt7530: move SGMII PCS creation to mt7530_probe function")
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> ---
This v2 submission addresses the comments made by Jesse Brandeburg
regarding zero-initializing regmap_config as we are now not necessarily
using both of them. Comments by Arınç ÜNAL have also been discussed
and resulting in receiving Ack.
However, I can see in patchwork that the patch has been set to
"Changes Requested".
Can someone please tell me which further changes are needed?
I don't see any other comments on the mailing list or patchwork.
Thank you!
Daniel
_______________________________________________
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] Revert "ASoC: fsl: remove unnecessary dai_link->platform"
From: Kuninori Morimoto @ 2023-04-20 0:11 UTC (permalink / raw)
To: Shengjiu Wang
Cc: shengjiu.wang, Xiubo.Lee, festevam, nicoleotsuka, lgirdwood,
broonie, perex, tiwai, shawnguo, s.hauer, kernel, linux-imx,
alsa-devel, linuxppc-dev, linux-arm-kernel, linux-kernel
In-Reply-To: <1681900158-17428-1-git-send-email-shengjiu.wang@nxp.com>
Hi Shengjiu
Cc Mark
Thank you for the patch
> This reverts commit 33683cbf49b5412061cb1e4c876063fdef86def4.
>
> dai_link->platform is needed. The platform component is
> "snd_dmaengine_pcm", which is registered from cpu driver,
>
> If dai_link->platform is not assigned, then platform
> component will not be probed, then there will be issue:
>
> aplay: main:831: audio open error: Invalid argument
>
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> ---
And sorry to my noise patch. I understood the issue.
Can I ask 2 things ?
My original patch removed 3 platforms.
Then, I understood that 2 of them are used as
soc-generic-dmaengine-pcm (= 1st, 3rd platform).
I think we want to have comment here that
why dummy component is needed. Can you agree ?
I wonder how about 2nd platform ? Is it same ?
I'm asking because it doesn't have of_node which other 2 platforms have.
Thank you for your help !!
Best regards
---
Kuninori Morimoto
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v8 07/10] kgdb: Expose default CPUs roundup fallback mechanism
From: Douglas Anderson @ 2023-04-19 22:56 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Sumit Garg, Daniel Thompson,
Marc Zyngier, Mark Rutland
Cc: ito-yuichi, kgdb-bugreport, Chen-Yu Tsai, Masayoshi Mizuma,
Peter Zijlstra, Ard Biesheuvel, Rafael J . Wysocki,
linux-arm-kernel, Stephen Boyd, Lecopzer Chen, Thomas Gleixner,
linux-perf-users, Douglas Anderson, Jason Wessel, linux-kernel
In-Reply-To: <20230419225604.21204-1-dianders@chromium.org>
From: Sumit Garg <sumit.garg@linaro.org>
Add a new API kgdb_smp_call_nmi_hook() to expose default CPUs roundup
mechanism to a particular archichecture as a runtime fallback if it
detects to not support NMI roundup.
Currently such an architecture example is arm64 supporting pseudo NMIs
feature which is only available on platforms which have support for GICv3
or later version.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Tested-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
(no changes since v1)
include/linux/kgdb.h | 12 ++++++++++++
kernel/debug/debug_core.c | 8 +++++++-
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h
index 258cdde8d356..87713bd390f3 100644
--- a/include/linux/kgdb.h
+++ b/include/linux/kgdb.h
@@ -199,6 +199,18 @@ kgdb_arch_handle_qxfer_pkt(char *remcom_in_buffer,
extern void kgdb_call_nmi_hook(void *ignored);
+/**
+ * kgdb_smp_call_nmi_hook - Provide default fallback mechanism to
+ * round-up CPUs
+ *
+ * If you're using the default implementation of kgdb_roundup_cpus()
+ * this function will be called. And if an arch detects at runtime to
+ * not support NMI based roundup then it can fallback to default
+ * mechanism using this API.
+ */
+
+extern void kgdb_smp_call_nmi_hook(void);
+
/**
* kgdb_roundup_cpus - Get other CPUs into a holding pattern
*
diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
index d5e9ccde3ab8..14d40a7d6a4b 100644
--- a/kernel/debug/debug_core.c
+++ b/kernel/debug/debug_core.c
@@ -238,7 +238,7 @@ NOKPROBE_SYMBOL(kgdb_call_nmi_hook);
static DEFINE_PER_CPU(call_single_data_t, kgdb_roundup_csd) =
CSD_INIT(kgdb_call_nmi_hook, NULL);
-void __weak kgdb_roundup_cpus(void)
+void kgdb_smp_call_nmi_hook(void)
{
call_single_data_t *csd;
int this_cpu = raw_smp_processor_id();
@@ -269,6 +269,12 @@ void __weak kgdb_roundup_cpus(void)
kgdb_info[cpu].rounding_up = false;
}
}
+NOKPROBE_SYMBOL(kgdb_smp_call_nmi_hook);
+
+void __weak kgdb_roundup_cpus(void)
+{
+ kgdb_smp_call_nmi_hook();
+}
NOKPROBE_SYMBOL(kgdb_roundup_cpus);
#endif
--
2.40.0.634.g4ca3ef3211-goog
_______________________________________________
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 v8 06/10] arm64: idle: Tag the arm64 idle functions as __cpuidle
From: Douglas Anderson @ 2023-04-19 22:56 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Sumit Garg, Daniel Thompson,
Marc Zyngier, Mark Rutland
Cc: ito-yuichi, kgdb-bugreport, Chen-Yu Tsai, Masayoshi Mizuma,
Peter Zijlstra, Ard Biesheuvel, Rafael J . Wysocki,
linux-arm-kernel, Stephen Boyd, Lecopzer Chen, Thomas Gleixner,
linux-perf-users, Douglas Anderson, Frederic Weisbecker,
Gautham R. Shenoy, Ingo Molnar, linux-kernel
In-Reply-To: <20230419225604.21204-1-dianders@chromium.org>
As per the (somewhat recent) comment before the definition of
`__cpuidle`, the tag is like `noinstr` but also marks a function so it
can be identified by cpu_in_idle(). Let'a add this.
After doing this then when we dump stack traces of all processors
using nmi_cpu_backtrace() then instead of getting useless backtraces
we get things like:
NMI backtrace for cpu N skipped: idling at cpu_do_idle+0x94/0x98
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
Changes in v8:
- "Tag the arm64 idle functions as __cpuidle" new for v8
arch/arm64/kernel/idle.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/idle.c b/arch/arm64/kernel/idle.c
index c1125753fe9b..05cfb347ec26 100644
--- a/arch/arm64/kernel/idle.c
+++ b/arch/arm64/kernel/idle.c
@@ -20,7 +20,7 @@
* ensure that interrupts are not masked at the PMR (because the core will
* not wake up if we block the wake up signal in the interrupt controller).
*/
-void noinstr cpu_do_idle(void)
+void __cpuidle cpu_do_idle(void)
{
struct arm_cpuidle_irq_context context;
@@ -35,7 +35,7 @@ void noinstr cpu_do_idle(void)
/*
* This is our default idle handler.
*/
-void noinstr arch_cpu_idle(void)
+void __cpuidle arch_cpu_idle(void)
{
/*
* This should do all the clock switching and wait for interrupt
--
2.40.0.634.g4ca3ef3211-goog
_______________________________________________
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 v8 05/10] arm64: ipi_nmi: Add support for NMI backtrace
From: Douglas Anderson @ 2023-04-19 22:55 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Sumit Garg, Daniel Thompson,
Marc Zyngier, Mark Rutland
Cc: ito-yuichi, kgdb-bugreport, Chen-Yu Tsai, Masayoshi Mizuma,
Peter Zijlstra, Ard Biesheuvel, Rafael J . Wysocki,
linux-arm-kernel, Stephen Boyd, Lecopzer Chen, Thomas Gleixner,
linux-perf-users, Masayoshi Mizuma, Douglas Anderson,
linux-kernel
In-Reply-To: <20230419225604.21204-1-dianders@chromium.org>
From: Sumit Garg <sumit.garg@linaro.org>
Enable NMI backtrace support on arm64 using IPI turned as an NMI
leveraging pseudo NMIs support. It is now possible for users to get a
backtrace of a CPU stuck in hard-lockup using magic SYSRQ.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Tested-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
Tested-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
Changes in v8:
- Removed "#ifdef CONFIG_SMP" since arm64 is always SMP
arch/arm64/include/asm/irq.h | 4 ++++
arch/arm64/kernel/ipi_nmi.c | 18 ++++++++++++++++--
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/irq.h b/arch/arm64/include/asm/irq.h
index fac08e18bcd5..dc35b9d23a81 100644
--- a/arch/arm64/include/asm/irq.h
+++ b/arch/arm64/include/asm/irq.h
@@ -6,6 +6,10 @@
#include <asm-generic/irq.h>
+extern bool arch_trigger_cpumask_backtrace(const cpumask_t *mask,
+ bool exclude_self);
+#define arch_trigger_cpumask_backtrace arch_trigger_cpumask_backtrace
+
struct pt_regs;
int set_handle_irq(void (*handle_irq)(struct pt_regs *));
diff --git a/arch/arm64/kernel/ipi_nmi.c b/arch/arm64/kernel/ipi_nmi.c
index 712411eed949..c592e92b8cbf 100644
--- a/arch/arm64/kernel/ipi_nmi.c
+++ b/arch/arm64/kernel/ipi_nmi.c
@@ -8,6 +8,7 @@
#include <linux/interrupt.h>
#include <linux/irq.h>
+#include <linux/nmi.h>
#include <linux/smp.h>
#include <asm/nmi.h>
@@ -31,11 +32,24 @@ void arm64_send_nmi(cpumask_t *mask)
__ipi_send_mask(ipi_nmi_desc, mask);
}
+bool arch_trigger_cpumask_backtrace(const cpumask_t *mask, bool exclude_self)
+{
+ if (!ipi_nmi_desc)
+ return false;
+
+ nmi_trigger_cpumask_backtrace(mask, exclude_self, arm64_send_nmi);
+
+ return true;
+}
+
static irqreturn_t ipi_nmi_handler(int irq, void *data)
{
- /* nop, NMI handlers for special features can be added here. */
+ irqreturn_t ret = IRQ_NONE;
+
+ if (nmi_cpu_backtrace(get_irq_regs()))
+ ret = IRQ_HANDLED;
- return IRQ_NONE;
+ return ret;
}
void dynamic_ipi_setup(void)
--
2.40.0.634.g4ca3ef3211-goog
_______________________________________________
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 v8 08/10] kgdb: Provide a stub kgdb_nmicallback() if !CONFIG_KGDB
From: Douglas Anderson @ 2023-04-19 22:56 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Sumit Garg, Daniel Thompson,
Marc Zyngier, Mark Rutland
Cc: ito-yuichi, kgdb-bugreport, Chen-Yu Tsai, Masayoshi Mizuma,
Peter Zijlstra, Ard Biesheuvel, Rafael J . Wysocki,
linux-arm-kernel, Stephen Boyd, Lecopzer Chen, Thomas Gleixner,
linux-perf-users, Douglas Anderson, Jason Wessel, linux-kernel
In-Reply-To: <20230419225604.21204-1-dianders@chromium.org>
To save architectures from needing to wrap the call in #ifdefs, add a
stub no-op version of kgdb_nmicallback(), which returns 1 if it didn't
handle anything.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
Changes in v8:
- "Provide a stub kgdb_nmicallback() if !CONFIG_KGDB" new for v8
include/linux/kgdb.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h
index 87713bd390f3..9ce628ee47cc 100644
--- a/include/linux/kgdb.h
+++ b/include/linux/kgdb.h
@@ -377,5 +377,6 @@ extern void kgdb_free_init_mem(void);
#define dbg_late_init()
static inline void kgdb_panic(const char *msg) {}
static inline void kgdb_free_init_mem(void) { }
+static int kgdb_nmicallback(int cpu, void *regs) { return 1; }
#endif /* ! CONFIG_KGDB */
#endif /* _KGDB_H_ */
--
2.40.0.634.g4ca3ef3211-goog
_______________________________________________
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 0/4] riscv: Allow userspace to directly access perf counters
From: Atish Patra @ 2023-04-19 23:21 UTC (permalink / raw)
To: Ian Rogers
Cc: Alexandre Ghiti, paranlee, David Laight, Jonathan Corbet,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Mark Rutland, Alexander Shishkin, Jiri Olsa, Namhyung Kim,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Anup Patel, Will Deacon,
Rob Herring, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
linux-riscv@lists.infradead.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAP-5=fX6kaZt68UbMMZzW-zs0RyRWoOS-Tq5NwekWj8k9Shx6g@mail.gmail.com>
On Wed, Apr 19, 2023 at 11:13 PM Ian Rogers <irogers@google.com> wrote:
>
> On Wed, Apr 19, 2023 at 2:21 AM Alexandre Ghiti <alexghiti@rivosinc.com> wrote:
> >
> > Hi Ian,
> >
> > On Tue, Apr 18, 2023 at 10:30 PM Atish Patra <atishp@atishpatra.org> wrote:
> > >
> > > On Tue, Apr 18, 2023 at 11:46 PM Ian Rogers <irogers@google.com> wrote:
> > > >
> > > > On Tue, Apr 18, 2023 at 9:43 AM Atish Patra <atishp@atishpatra.org> wrote:
> > > > >
> > > > > On Fri, Apr 14, 2023 at 2:40 AM David Laight <David.Laight@aculab.com> wrote:
> > > > > >
> > > > > > From: Atish Patra
> > > > > > > Sent: 13 April 2023 20:18
> > > > > > >
> > > > > > > On Thu, Apr 13, 2023 at 9:47 PM Alexandre Ghiti <alexghiti@rivosinc.com> wrote:
> > > > > > > >
> > > > > > > > riscv used to allow direct access to cycle/time/instret counters,
> > > > > > > > bypassing the perf framework, this patchset intends to allow the user to
> > > > > > > > mmap any counter when accessed through perf. But we can't break the
> > > > > > > > existing behaviour so we introduce a sysctl perf_user_access like arm64
> > > > > > > > does, which defaults to the legacy mode described above.
> > > > > > > >
> > > > > > >
> > > > > > > It would be good provide additional direction for user space packages:
> > > > > > >
> > > > > > > The legacy behavior is supported for now in order to avoid breaking
> > > > > > > existing software.
> > > > > > > However, reading counters directly without perf interaction may
> > > > > > > provide incorrect values which
> > > > > > > the userspace software must avoid. We are hoping that the user space
> > > > > > > packages which
> > > > > > > read the cycle/instret directly, will move to the proper interface
> > > > > > > eventually if they actually need it.
> > > > > > > Most of the users are supposed to read "time" instead of "cycle" if
> > > > > > > they intend to read timestamps.
> > > > > >
> > > > > > If you are trying to measure the performance of short code
> > > > > > fragments then you need pretty much raw access directly to
> > > > > > the cycle/clock count register.
> > > > > >
> > > > > > I've done this on x86 to compare the actual cycle times
> > > > > > of different implementations of the IP checksum loop
> > > > > > (and compare them to the theoretical limit).
> > > > > > The perf framework just added far too much latency,
> > > > > > only directly reading the cpu registers gave anything
> > > > > > like reliable (and consistent) answers.
> > > > > >
> > > > >
> > > > > This series allows direct access to the counters once configured
> > > > > through the perf.
> > > > > Earlier the cycle/instret counters are directly exposed to the
> > > > > userspace without kernel/perf frameworking knowing
> > > > > when/which user space application is reading it. That has security implications.
> > > > >
> > > > > With this series applied, the user space application just needs to
> > > > > configure the event (cycle/instret) through perf syscall.
> > > > > Once configured, the userspace application can find out the counter
> > > > > information from the mmap & directly
> > > > > read the counter. There is no latency while reading the counters.
> > > > >
> > > > > This mechanism allows stop/clear the counters when the requesting task
> > > > > is not running. It also takes care of context switching
> > > > > which may result in invalid values as you mentioned below. This is
> > > > > nothing new and all other arch (x86, ARM64) allow user space
> > > > > counter read through the same mechanism.
> > > > >
> > > > > Here is the relevant upstream discussion:
> > > > > https://lore.kernel.org/lkml/Y7wLa7I2hlz3rKw%2F@hirez.programming.kicks-ass.net/T/
> > > > >
> > > > > ARM64:
> > > > > https://docs.kernel.org/arm64/perf.html?highlight=perf_user_access#perf-userspace-pmu-hardware-counter-access
> > > > >
> > > > > example usage in x86:
> > > > > https://github.com/andikleen/pmu-tools/blob/master/jevents/rdpmc.c
> > > >
> > > > The canonical implementation of this should be:
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/lib/perf/mmap.c#n400
> > >
> > > Thanks for sharing the libperf implementation.
> > >
> > > > which is updated in these patches but the tests are not:
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/perf/tests/mmap-basic.c#n287
> > > > Which appears to be an oversight. The tests display some differences
> > >
> > > Yes. It's an oversight. We should make sure that perf mmap tests pass
> > > for RISC-V as well.
> >
> > Yes, that's an oversight, I had a local test adapted from this one but
> > forgot to update it afterwards, I'll do that in the next version.
> >
> > Thanks for your quick feedbacks and sorry for being late,
> >
> > Alex
>
> Thanks Alex, there was an equally likely chance that I wasn't
> understanding things :-) Is there any information on RISC-V PMU
> testing? I know ParanLee is interested. It'd be awesome to have
Are you looking for something specific to RISC-V general or perf on RISC-V?
All the RISC-V PMU patches have been upstream for a while (both in the
Qemu & Linux kernel).
Perf should work out-of-the box when you boot the latest kernel in the
latest version of the Qemu.
Initial KVM[1] patches support got merged during the last merge
window. It doesn't support
event sampling yet. We are working on that.
[1] https://lore.kernel.org/lkml/20230207095529.1787260-1-atishp@rivosinc.com/
> something say on:
> https://perf.wiki.kernel.org/index.php/Main_Page
> on how to run tests, perhaps on QEMU or known to work boards. We can
> also just drop a link on there if there is information. We can also
> add the RISC-V PMU information to the links here:
> https://perf.wiki.kernel.org/index.php/Useful_Links
>
I did not see any arch specific information there. Let us know what
would be good to
add there and we would be happy to add.
> Thanks,
> Ian
>
> >
> > >
> > >
> > > > between x86 and aarch64 that have assumed userspace hardware counter
> > > > access, and everything else that it is assumed don't.
> > > >
> > > > Thanks,
> > > > Ian
> > > >
> > > > > > Clearly process switches (especially cpu migrations) cause
> > > > > > problems, but they are obviously invalid values and can
> > > > > > be ignored.
> > > > > >
> > > > > > So while a lot of uses may be 'happy' with the values the
> > > > > > perf framework gives, sometimes you do need to directly
> > > > > > read the relevant registers.
> > > > > >
> > > > > > David
> > > > > >
> > > > > > -
> > > > > > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> > > > > > Registration No: 1397386 (Wales)
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Regards,
> > > > > Atish
> > >
> > >
> > >
> > > --
> > > Regards,
> > > Atish
--
Regards,
Atish
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v8 10/10] arm64: ipi_nmi: Fallback to a regular IPI if NMI isn't enabled
From: Douglas Anderson @ 2023-04-19 22:56 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Sumit Garg, Daniel Thompson,
Marc Zyngier, Mark Rutland
Cc: ito-yuichi, kgdb-bugreport, Chen-Yu Tsai, Masayoshi Mizuma,
Peter Zijlstra, Ard Biesheuvel, Rafael J . Wysocki,
linux-arm-kernel, Stephen Boyd, Lecopzer Chen, Thomas Gleixner,
linux-perf-users, Douglas Anderson, Masayoshi Mizuma,
linux-kernel
In-Reply-To: <20230419225604.21204-1-dianders@chromium.org>
The current ipi_nmi implementation relies on the arm64 pseudo-NMI
support. This needs to be enabled in both the kernel config with
CONFIG_ARM64_PSEUDO_NMI and on the kernel command line with
"irqchip.gicv3_pseudo_nmi=1".
Let's add a fallback of using a regular IPI if the NMI isn't
enabled. The fallback mechanism of using a regular IPI matches what
arm32 does all the time since there is no NMI there.
The reason for doing this is to make the trigger_all_cpu_backtrace()
class of functions work. While those functions all return a bool
indicating that the caller should try a fallback upon failure, an
inspection of the callers shows that nearly nobody implements a
fallback. It's better to at least provide something here.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
I dunno what people think of this patch. If it's great, we could
actually drop some of the patches out of this series since some of
them are to account for the fact that we might not be able to register
an "ipi_nmi". If it's awful, it could simply be dropped.
Changes in v8:
- "Fallback to a regular IPI if NMI isn't enabled" new for v8
arch/arm64/kernel/ipi_nmi.c | 31 +++++++++++++++++++++++++------
1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kernel/ipi_nmi.c b/arch/arm64/kernel/ipi_nmi.c
index 2adaaf1519e5..02868752845c 100644
--- a/arch/arm64/kernel/ipi_nmi.c
+++ b/arch/arm64/kernel/ipi_nmi.c
@@ -16,6 +16,7 @@
static struct irq_desc *ipi_nmi_desc __read_mostly;
static int ipi_nmi_id __read_mostly;
+static bool is_nmi;
bool arm64_supports_nmi(void)
{
@@ -62,8 +63,12 @@ void dynamic_ipi_setup(void)
if (!ipi_nmi_desc)
return;
- if (!prepare_percpu_nmi(ipi_nmi_id))
- enable_percpu_nmi(ipi_nmi_id, IRQ_TYPE_NONE);
+ if (is_nmi) {
+ if (!prepare_percpu_nmi(ipi_nmi_id))
+ enable_percpu_nmi(ipi_nmi_id, IRQ_TYPE_NONE);
+ } else {
+ enable_percpu_irq(ipi_nmi_id, IRQ_TYPE_NONE);
+ }
}
void dynamic_ipi_teardown(void)
@@ -71,14 +76,28 @@ void dynamic_ipi_teardown(void)
if (!ipi_nmi_desc)
return;
- disable_percpu_nmi(ipi_nmi_id);
- teardown_percpu_nmi(ipi_nmi_id);
+ if (is_nmi) {
+ disable_percpu_nmi(ipi_nmi_id);
+ teardown_percpu_nmi(ipi_nmi_id);
+ } else {
+ disable_percpu_irq(ipi_nmi_id);
+ }
}
void __init set_smp_dynamic_ipi(int ipi)
{
+ int err;
+
if (!request_percpu_nmi(ipi, ipi_nmi_handler, "IPI", &cpu_number)) {
- ipi_nmi_desc = irq_to_desc(ipi);
- ipi_nmi_id = ipi;
+ is_nmi = true;
+ } else {
+ err = request_percpu_irq(ipi, ipi_nmi_handler, "IPI", &cpu_number);
+ if (WARN_ON(err))
+ return;
+
+ irq_set_status_flags(ipi, IRQ_HIDDEN);
}
+
+ ipi_nmi_desc = irq_to_desc(ipi);
+ ipi_nmi_id = ipi;
}
--
2.40.0.634.g4ca3ef3211-goog
_______________________________________________
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 v8 09/10] arm64: kgdb: Roundup cpus using IPI as NMI
From: Douglas Anderson @ 2023-04-19 22:56 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Sumit Garg, Daniel Thompson,
Marc Zyngier, Mark Rutland
Cc: ito-yuichi, kgdb-bugreport, Chen-Yu Tsai, Masayoshi Mizuma,
Peter Zijlstra, Ard Biesheuvel, Rafael J . Wysocki,
linux-arm-kernel, Stephen Boyd, Lecopzer Chen, Thomas Gleixner,
linux-perf-users, Douglas Anderson, Alexandru Elisei,
Masayoshi Mizuma, linux-kernel
In-Reply-To: <20230419225604.21204-1-dianders@chromium.org>
From: Sumit Garg <sumit.garg@linaro.org>
arm64 platforms with GICv3 or later supports pseudo NMIs which can be
leveraged to roundup CPUs which are stuck in hard lockup state with
interrupts disabled that wouldn't be possible with a normal IPI.
So instead switch to roundup CPUs using IPI turned as NMI. And in
case a particular arm64 platform doesn't supports pseudo NMIs,
it will switch back to default kgdb CPUs roundup mechanism.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Tested-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
(no changes since v1)
arch/arm64/kernel/ipi_nmi.c | 5 +++++
arch/arm64/kernel/kgdb.c | 18 ++++++++++++++++++
2 files changed, 23 insertions(+)
diff --git a/arch/arm64/kernel/ipi_nmi.c b/arch/arm64/kernel/ipi_nmi.c
index c592e92b8cbf..2adaaf1519e5 100644
--- a/arch/arm64/kernel/ipi_nmi.c
+++ b/arch/arm64/kernel/ipi_nmi.c
@@ -8,6 +8,7 @@
#include <linux/interrupt.h>
#include <linux/irq.h>
+#include <linux/kgdb.h>
#include <linux/nmi.h>
#include <linux/smp.h>
@@ -45,10 +46,14 @@ bool arch_trigger_cpumask_backtrace(const cpumask_t *mask, bool exclude_self)
static irqreturn_t ipi_nmi_handler(int irq, void *data)
{
irqreturn_t ret = IRQ_NONE;
+ unsigned int cpu = smp_processor_id();
if (nmi_cpu_backtrace(get_irq_regs()))
ret = IRQ_HANDLED;
+ if (!kgdb_nmicallback(cpu, get_irq_regs()))
+ ret = IRQ_HANDLED;
+
return ret;
}
diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
index cda9c1e9864f..2c85bc1df013 100644
--- a/arch/arm64/kernel/kgdb.c
+++ b/arch/arm64/kernel/kgdb.c
@@ -17,6 +17,7 @@
#include <asm/debug-monitors.h>
#include <asm/insn.h>
+#include <asm/nmi.h>
#include <asm/patching.h>
#include <asm/traps.h>
@@ -354,3 +355,20 @@ int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
return aarch64_insn_write((void *)bpt->bpt_addr,
*(u32 *)bpt->saved_instr);
}
+
+void kgdb_roundup_cpus(void)
+{
+ struct cpumask mask;
+
+ if (!arm64_supports_nmi()) {
+ kgdb_smp_call_nmi_hook();
+ return;
+ }
+
+ cpumask_copy(&mask, cpu_online_mask);
+ cpumask_clear_cpu(raw_smp_processor_id(), &mask);
+ if (cpumask_empty(&mask))
+ return;
+
+ arm64_send_nmi(&mask);
+}
--
2.40.0.634.g4ca3ef3211-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/7] arm64: dts: ti: k3-am654-base-board: Rename regulator node name
From: Nishanth Menon @ 2023-04-19 22:59 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rob Herring, Vignesh Raghavendra
Cc: linux-kernel, devicetree, linux-arm-kernel, Tero Kristo,
Nishanth Menon, Jan Kiszka
In-Reply-To: <20230419225913.663448-1-nm@ti.com>
Rename the regulator node names to the standard regulator-0.. numbers.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm64/boot/dts/ti/k3-am654-base-board.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
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 7a79ef51bcc8..d3dd6899ef03 100644
--- a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
@@ -86,7 +86,7 @@ switch-6 {
};
};
- evm_12v0: fixedregulator-evm12v0 {
+ evm_12v0: regulator-0 {
/* main supply */
compatible = "regulator-fixed";
regulator-name = "evm_12v0";
@@ -96,7 +96,7 @@ evm_12v0: fixedregulator-evm12v0 {
regulator-boot-on;
};
- vcc3v3_io: fixedregulator-vcc3v3io {
+ vcc3v3_io: regulator-1 {
/* Output of TPS54334 */
compatible = "regulator-fixed";
regulator-name = "vcc3v3_io";
@@ -107,7 +107,7 @@ vcc3v3_io: fixedregulator-vcc3v3io {
vin-supply = <&evm_12v0>;
};
- vdd_mmc1_sd: fixedregulator-sd {
+ vdd_mmc1_sd: regulator-2 {
compatible = "regulator-fixed";
regulator-name = "vdd_mmc1_sd";
regulator-min-microvolt = <3300000>;
--
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 1/7] arm64: dts: ti: k3-am654-base-board: Add missing pinmux wkup_uart, mcu_uart and mcu_i2c
From: Nishanth Menon @ 2023-04-19 22:59 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rob Herring, Vignesh Raghavendra
Cc: linux-kernel, devicetree, linux-arm-kernel, Tero Kristo,
Nishanth Menon, Jan Kiszka
In-Reply-To: <20230419225913.663448-1-nm@ti.com>
Many of the definitions depend on pinmux done by the bootloader. Be
explicit about the pinmux for functionality and completeness.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
.../arm64/boot/dts/ti/k3-am654-base-board.dts | 34 +++++++++++++++++--
1 file changed, 32 insertions(+), 2 deletions(-)
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..7a79ef51bcc8 100644
--- a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
@@ -120,6 +120,15 @@ vdd_mmc1_sd: fixedregulator-sd {
};
&wkup_pmx0 {
+ wkup_uart0_pins_default: wkup-uart0-pins-default {
+ pinctrl-single,pins = <
+ AM65X_WKUP_IOPAD(0x00a0, PIN_INPUT, 0) /* (AB1) WKUP_UART0_RXD */
+ AM65X_WKUP_IOPAD(0x00a4, PIN_OUTPUT, 0) /* (AB5) WKUP_UART0_TXD */
+ AM65X_WKUP_IOPAD(0x00c8, PIN_INPUT, 1) /* (AC2) WKUP_GPIO0_6.WKUP_UART0_CTSn */
+ AM65X_WKUP_IOPAD(0x00cc, PIN_OUTPUT, 1) /* (AC1) WKUP_GPIO0_7.WKUP_UART0_RTSn */
+ >;
+ };
+
wkup_i2c0_pins_default: wkup-i2c0-pins-default {
pinctrl-single,pins = <
AM65X_WKUP_IOPAD(0x00e0, PIN_INPUT, 0) /* (AC7) WKUP_I2C0_SCL */
@@ -156,6 +165,15 @@ AM65X_WKUP_IOPAD(0x0034, PIN_INPUT, 7) /* (T1) MCU_OSPI1_CLK.WKUP_GPIO0_25 */
>;
};
+ mcu_uart0_pins_default: mcu-uart0-pins-default {
+ pinctrl-single,pins = <
+ AM65X_WKUP_IOPAD(0x0044, PIN_INPUT, 4) /* (P4) MCU_OSPI1_D1.MCU_UART0_RXD */
+ AM65X_WKUP_IOPAD(0x0048, PIN_OUTPUT, 4) /* (P5) MCU_OSPI1_D2.MCU_UART0_TXD */
+ AM65X_WKUP_IOPAD(0x004C, PIN_INPUT, 4) /* (P1) MCU_OSPI1_D3.MCU_UART0_CTSn */
+ AM65X_WKUP_IOPAD(0x0054, PIN_OUTPUT, 4) /* (N3) MCU_OSPI1_CSn1.MCU_UART0_RTSn */
+ >;
+ };
+
mcu_cpsw_pins_default: mcu-cpsw-pins-default {
pinctrl-single,pins = <
AM65X_WKUP_IOPAD(0x0058, PIN_OUTPUT, 0) /* (N4) MCU_RGMII1_TX_CTL */
@@ -179,6 +197,13 @@ AM65X_WKUP_IOPAD(0x008c, PIN_OUTPUT, 0) /* (L1) MCU_MDIO0_MDC */
AM65X_WKUP_IOPAD(0x0088, PIN_INPUT, 0) /* (L4) MCU_MDIO0_MDIO */
>;
};
+
+ mcu_i2c0_pins_default: mcu-i2c0-pins-default {
+ pinctrl-single,pins = <
+ AM65X_WKUP_IOPAD(0x00e8, PIN_INPUT, 0) /* (AD8) MCU_I2C0_SCL */
+ AM65X_WKUP_IOPAD(0x00ec, PIN_INPUT, 0) /* (AD7) MCU_I2C0_SDA */
+ >;
+ };
};
&main_pmx0 {
@@ -269,11 +294,14 @@ AM65X_IOPAD(0x0010, PIN_INPUT, 0) /* (D21) ECAP0_IN_APWM_OUT */
&wkup_uart0 {
/* Wakeup UART is used by System firmware */
status = "reserved";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wkup_uart0_pins_default>;
};
&mcu_uart0 {
status = "okay";
- /* Default pinmux */
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcu_uart0_pins_default>;
};
&main_uart0 {
@@ -305,7 +333,9 @@ pca9554: gpio@39 {
&mcu_i2c0 {
status = "okay";
- /* Default pinmux */
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcu_i2c0_pins_default>;
+ clock-frequency = <400000>;
};
&main_i2c0 {
--
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
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