* Re: [PATCH v4 0/7] firmware: smccc: Add basic SMCCC v1.2 + ARCH_SOC_ID support
From: Sudeep Holla @ 2020-05-21 10:24 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Lorenzo Pieralisi, Arnd Bergmann, Catalin Marinas,
linux-kernel@vger.kernel.org, Steven Price, harb, Sudeep Holla,
Linux ARM
In-Reply-To: <20200521101437.GB5360@willie-the-truck>
On Thu, May 21, 2020 at 11:14:38AM +0100, Will Deacon wrote:
> On Thu, May 21, 2020 at 10:26:27AM +0100, Sudeep Holla wrote:
> > On Thu, May 21, 2020 at 10:17:39AM +0100, Will Deacon wrote:
> > > On Thu, May 21, 2020 at 11:06:23AM +0200, Arnd Bergmann wrote:
> > > > On Thu, May 21, 2020 at 10:11 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
> > > > > /me confused. Do you need the fix for this warning or you are happy to ignore?
> > > >
> > > > I want a fix for that, as I hope we can eventually turn this warning on by
> > > > default and stop playing whack-a-mole when they come up. Most of these
> > > > warnings are harmless, but occasionally the prototypes don't match exactly
> > > > and cause real bugs depending on the configuration, and ensuring both
> > > > sides include a common header file is an easy way to make it work
> > > > more reliably.
> > > >
> > > > Note that the warning should come up for either W=1 or C=1, and I also
> > > > think that
> > > > new code should generally be written sparse-clean and have no warnings with
> > > > 'make C=1' as a rule.
> > >
> > > Fair enough. Is anybody working on a tree-wide sweep for this, like we've
> > > done for other things such as zero-length arrays? If so, I can start
> > > enforcing this in the arch code as well (I haven't been so far, even though
> > > I do run sparse on every commit).
> > >
> > > Anyway, I've dropped the last patch from the branch, and we can put a fix
> > > for the missing prototype on top.
> > >
> >
> > Thanks Will, sorry for the trouble. Though I can send the fix for the
> > missing prototype right away, I would like to get my clang setup working
> > as an opportunity. clang-8 that I have is failing vanilla v5.7-rc6
> > when expanding arm_smccc_1_1_*
>
> No trouble at all, really. I also saw this from Nathan the other day, which
> may help you get up and running with clang:
>
> https://lore.kernel.org/r/20200520024736.GA854786@ubuntu-s3-xlarge-x86
>
Thanks for the link, I will try some other time(may be next time I run
into clang issue 😄). Anyway upgrading to clang-11 fixed the build issue.
I will soon post the patch for missing prototype.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] media: fimc-capture: Fix runtime PM imbalance on error
From: Dinghao Liu @ 2020-05-21 10:22 UTC (permalink / raw)
To: dinghao.liu, kjlu
Cc: linux-samsung-soc, linux-kernel, Krzysztof Kozlowski,
Kyungmin Park, Kukjin Kim, Sylwester Nawrocki,
Mauro Carvalho Chehab, linux-arm-kernel, linux-media
pm_runtime_get_sync() increments the runtime PM usage counter even
when it returns an error code. Thus a pairing decrement is needed on
the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
---
drivers/media/platform/exynos4-is/fimc-capture.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c b/drivers/media/platform/exynos4-is/fimc-capture.c
index 705f182330ca..dd33b888971f 100644
--- a/drivers/media/platform/exynos4-is/fimc-capture.c
+++ b/drivers/media/platform/exynos4-is/fimc-capture.c
@@ -478,8 +478,10 @@ static int fimc_capture_open(struct file *file)
set_bit(ST_CAPT_BUSY, &fimc->state);
ret = pm_runtime_get_sync(&fimc->pdev->dev);
- if (ret < 0)
+ if (ret < 0) {
+ pm_runtime_put_sync(&fimc->pdev->dev);
goto unlock;
+ }
ret = v4l2_fh_open(file);
if (ret) {
--
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
* Re: [RESEND PATCH v14 04/11] pwm: clps711x: Cast period to u32 before use as divisor
From: Daniel Thompson @ 2020-05-21 10:19 UTC (permalink / raw)
To: Guru Das Srinagesh
Cc: linux-arm-kernel, linux-pwm, Arnd Bergmann, David Collins,
Stephen Boyd, linux-kernel, Thierry Reding, Geert Uytterhoeven,
Dan Carpenter, Uwe Kleine-König, Joe Perches,
Subbaraman Narayanamurthy, Lee Jones, Guenter Roeck
In-Reply-To: <1d6918c3fc2976bdbdb687bf54a2ef09fc1558db.1589330178.git.gurus@codeaurora.org>
On Wed, May 20, 2020 at 03:55:57PM -0700, Guru Das Srinagesh wrote:
> Since the PWM framework is switching struct pwm_args.period's datatype
> to u64, prepare for this transition by typecasting it to u32.
>
> Also, since the dividend is still a 32-bit number, any divisor greater
> than the numerator will cause the quotient to be zero, so return 0 in
> that case to efficiently skip the division.
>
> Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
> ---
> drivers/pwm/pwm-clps711x.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pwm/pwm-clps711x.c b/drivers/pwm/pwm-clps711x.c
> index 924d39a..da771b1 100644
> --- a/drivers/pwm/pwm-clps711x.c
> +++ b/drivers/pwm/pwm-clps711x.c
> @@ -43,7 +43,10 @@ static void clps711x_pwm_update_val(struct clps711x_chip *priv, u32 n, u32 v)
> static unsigned int clps711x_get_duty(struct pwm_device *pwm, unsigned int v)
> {
> /* Duty cycle 0..15 max */
> - return DIV_ROUND_CLOSEST(v * 0xf, pwm->args.period);
> + if (pwm->args.period > (v * 0xf))
> + return 0;
This doesn't look right to me.
DIV_ROUND_CLOSEST() does rounded division and the short circuit doesn't
implement that.
Daniel.
> +
> + return DIV_ROUND_CLOSEST(v * 0xf, (u32)pwm->args.period);
> }
>
> static int clps711x_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
_______________________________________________
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] dt-bindings: mfd: mediatek: Add MT6397 Pin Controller
From: Matthias Brugger @ 2020-05-21 10:16 UTC (permalink / raw)
To: matthias.bgg, Lee Jones
Cc: Mark Rutland, Rob Herring, devicetree, linux-kernel,
linux-mediatek, linux-arm-kernel
In-Reply-To: <20200115151938.GA8182@bogus>
Hi Lee,
On 15/01/2020 16:19, Rob Herring wrote:
> On Fri, 10 Jan 2020 15:59:51 +0100, matthias.bgg@kernel.org wrote:
>> From: Matthias Brugger <matthias.bgg@gmail.com>
>>
>> The MT6397 mfd includes a pin controller. Add binding
>> a description for it.
>>
>> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
>>
>> ---
>>
>> Documentation/devicetree/bindings/mfd/mt6397.txt | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>
> Acked-by: Rob Herring <robh@kernel.org>
>
It looks like this fall through the cracks.
Would you consider to queue it or do you have further comments?
Regards,
Matthias
_______________________________________________
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/14] Adding support for Microchip Sparx5 SoC
From: Arnd Bergmann @ 2020-05-21 10:16 UTC (permalink / raw)
To: Lars Povlsen
Cc: DTML, open list:GPIO SUBSYSTEM, Stephen Boyd, Steen Hegelund,
linux-clk, linux-kernel@vger.kernel.org,
Microchip Linux Driver Support, Michael Turquette, SoC Team,
Olof Johansson, Linus Walleij, Linux ARM
In-Reply-To: <20200513125532.24585-1-lars.povlsen@microchip.com>
On Wed, May 13, 2020 at 2:55 PM Lars Povlsen <lars.povlsen@microchip.com> wrote:
>
> This patch series adds support for Microchip Sparx5 SoC, the CPU
> system of a advanced, TSN capable gigabit switch. The CPU is an armv8
> x 2 CPU core (A53).
>
> Although this is an ARM core, it shares some peripherals with the
> Microsemi Ocelot SoC.
>
> This is the first official revision of the series.
I see you sent multiple series to soc@kernel.org for review. This is the
correct address for getting the initial soc support merged, but as the patches
are still being reviewed by subsystem maintainers, please leave it off
for now, until you are confident that they are ready to get merged for the
following merge window and have received the appropriate Acks.
For each subsystem, there is generally the choice between merging
code through the subsystem maintainer tree, or through the soc tree
on an initial submission, as going through multiple trees is particularly
hard to do for the devicetree files.
For the moment, I have marked all sparx5 patches as "Not Applicable"
in patchwork at https://patchwork.kernel.org/project/linux-soc/list/
as it is still unclear who is merging which parts, and they are under
active review, but please do send them again after the review is
complete.
If you have a lot of patches, sending pull requests is sometimes easier,
but it also takes a bit of practice to know how exactly to structure
those. Let me know if you have questions about them. You an also
contact me and most of the other maintainers on IRC using the
#armlinux channel on irc.freenode.net.
Sorry for not having been able to review the patches myself yet, I
hope to get to that soon.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 0/7] firmware: smccc: Add basic SMCCC v1.2 + ARCH_SOC_ID support
From: Russell King - ARM Linux admin @ 2020-05-21 10:14 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Rutland, Lorenzo Pieralisi, Catalin Marinas,
linux-kernel@vger.kernel.org, Steven Price, harb, Sudeep Holla,
Will Deacon, Linux ARM
In-Reply-To: <CAK8P3a3dV0B26XE3oFQGTFf8EWV0AHoLudNtpSSB_t+pCfkOkQ@mail.gmail.com>
On Thu, May 21, 2020 at 11:06:23AM +0200, Arnd Bergmann wrote:
> Note that the warning should come up for either W=1 or C=1, and I also
> think that
> new code should generally be written sparse-clean and have no warnings with
> 'make C=1' as a rule.
No, absolutely not, that's a stupid idea, there are corner cases
where hiding a sparse warning is the wrong thing to do. Look at
many of the cases in fs/ for example.
See https://lkml.org/lkml/2004/9/12/249 which should make anyone
who sees a use of __force in some random code stop and question
why it is there, and whether it is actually correct, or just there
to hide a sparse warning.
Remember, sparse is there to warn that something isn't quite right,
and the view taken is, if it isn't right, then we don't "cast the
warning away" with __force, even if we intend not to fix the code
immediately.
So, going for "sparse-clean" is actually not correct. Going for
"no unnecessary warnings" is.
And don't think what I've said above doesn't happen; I've rejected
patches from people who've gone around trying to fix every sparse
warning that they see by throwing __force incorrectly at it.
The thing is, if you hide all the warnings, even for incorrect code,
then sparse becomes completely useless to identify where things in
the code are not quite correct.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 0/7] firmware: smccc: Add basic SMCCC v1.2 + ARCH_SOC_ID support
From: Will Deacon @ 2020-05-21 10:14 UTC (permalink / raw)
To: Sudeep Holla
Cc: Mark Rutland, Lorenzo Pieralisi, Arnd Bergmann, Catalin Marinas,
linux-kernel@vger.kernel.org, Steven Price, harb, Linux ARM
In-Reply-To: <20200521092627.GB6425@bogus>
On Thu, May 21, 2020 at 10:26:27AM +0100, Sudeep Holla wrote:
> On Thu, May 21, 2020 at 10:17:39AM +0100, Will Deacon wrote:
> > On Thu, May 21, 2020 at 11:06:23AM +0200, Arnd Bergmann wrote:
> > > On Thu, May 21, 2020 at 10:11 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
> > > > /me confused. Do you need the fix for this warning or you are happy to ignore?
> > >
> > > I want a fix for that, as I hope we can eventually turn this warning on by
> > > default and stop playing whack-a-mole when they come up. Most of these
> > > warnings are harmless, but occasionally the prototypes don't match exactly
> > > and cause real bugs depending on the configuration, and ensuring both
> > > sides include a common header file is an easy way to make it work
> > > more reliably.
> > >
> > > Note that the warning should come up for either W=1 or C=1, and I also
> > > think that
> > > new code should generally be written sparse-clean and have no warnings with
> > > 'make C=1' as a rule.
> >
> > Fair enough. Is anybody working on a tree-wide sweep for this, like we've
> > done for other things such as zero-length arrays? If so, I can start
> > enforcing this in the arch code as well (I haven't been so far, even though
> > I do run sparse on every commit).
> >
> > Anyway, I've dropped the last patch from the branch, and we can put a fix
> > for the missing prototype on top.
> >
>
> Thanks Will, sorry for the trouble. Though I can send the fix for the
> missing prototype right away, I would like to get my clang setup working
> as an opportunity. clang-8 that I have is failing vanilla v5.7-rc6
> when expanding arm_smccc_1_1_*
No trouble at all, really. I also saw this from Nathan the other day, which
may help you get up and running with clang:
https://lore.kernel.org/r/20200520024736.GA854786@ubuntu-s3-xlarge-x86
(but I haven't tried it myself, as I'm just using the Android binary)
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] arm64: dts: mt8183: Add gce setting in display node
From: Matthias Brugger @ 2020-05-21 10:10 UTC (permalink / raw)
To: Bibby Hsieh, David Airlie, Daniel Vetter, dri-devel,
linux-mediatek
Cc: drinkcat, Yongqiang Niu, srv_heupstream, linux-kernel, tfiga,
CK Hu, Thierry Reding, Philipp Zabel, YT Shen, linux-arm-kernel
In-Reply-To: <2369225e-2a92-c493-d089-e03f792df8cf@gmail.com>
On 14/02/2020 11:06, Matthias Brugger wrote:
>
>
> On 14/02/2020 05:49, Bibby Hsieh wrote:
>> In order to use GCE function, we need add some information
>> into display node (mboxes, mediatek,gce-client-reg, mediatek,gce-events).
>>
>> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
>> Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
>> ---
>
> For the next time please provide some context on which patches this are based
> on. Bet below the '---' with a link.
>
> For this time, on which patch/series is this based? :)
Bibby can you please help and rebase the patch against my for-next branch [1].
I'm then happy to queue it. Not sure if we can make it for v5.8 as we are really
late, but we could try :)
Thanks!
Matthias
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/log/?h=for-next
>
> Thanks,
> Matthias
>
>> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 16 ++++++++++++++++
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>> index be4428c92f35..8b522b039a37 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>> @@ -9,6 +9,7 @@
>> #include <dt-bindings/interrupt-controller/arm-gic.h>
>> #include <dt-bindings/interrupt-controller/irq.h>
>> #include <dt-bindings/power/mt8183-power.h>
>> +#include <dt-bindings/gce/mt8183-gce.h>
>> #include "mt8183-pinfunc.h"
>>
>> / {
>> @@ -664,6 +665,9 @@
>> reg = <0 0x14000000 0 0x1000>;
>> power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
>> #clock-cells = <1>;
>> + mboxes = <&gce 0 CMDQ_THR_PRIO_HIGHEST>,
>> + <&gce 1 CMDQ_THR_PRIO_HIGHEST>;
>> + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0 0x1000>;
>> };
>>
>> ovl0: ovl@14008000 {
>> @@ -672,6 +676,7 @@
>> interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_LOW>;
>> power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
>> clocks = <&mmsys CLK_MM_DISP_OVL0>;
>> + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x8000 0x1000>;
>> };
>>
>> ovl_2l0: ovl@14009000 {
>> @@ -680,6 +685,7 @@
>> interrupts = <GIC_SPI 226 IRQ_TYPE_LEVEL_LOW>;
>> power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
>> clocks = <&mmsys CLK_MM_DISP_OVL0_2L>;
>> + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x9000 0x1000>;
>> };
>>
>> ovl_2l1: ovl@1400a000 {
>> @@ -688,6 +694,7 @@
>> interrupts = <GIC_SPI 227 IRQ_TYPE_LEVEL_LOW>;
>> power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
>> clocks = <&mmsys CLK_MM_DISP_OVL1_2L>;
>> + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xa000 0x1000>;
>> };
>>
>> rdma0: rdma@1400b000 {
>> @@ -697,6 +704,7 @@
>> power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
>> clocks = <&mmsys CLK_MM_DISP_RDMA0>;
>> mediatek,rdma_fifo_size = <5120>;
>> + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xb000 0x1000>;
>> };
>>
>> rdma1: rdma@1400c000 {
>> @@ -706,6 +714,7 @@
>> power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
>> clocks = <&mmsys CLK_MM_DISP_RDMA1>;
>> mediatek,rdma_fifo_size = <2048>;
>> + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xc000 0x1000>;
>> };
>>
>> color0: color@1400e000 {
>> @@ -715,6 +724,7 @@
>> interrupts = <GIC_SPI 231 IRQ_TYPE_LEVEL_LOW>;
>> power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
>> clocks = <&mmsys CLK_MM_DISP_COLOR0>;
>> + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xe000 0x1000>;
>> };
>>
>> ccorr0: ccorr@1400f000 {
>> @@ -723,6 +733,7 @@
>> interrupts = <GIC_SPI 232 IRQ_TYPE_LEVEL_LOW>;
>> power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
>> clocks = <&mmsys CLK_MM_DISP_CCORR0>;
>> + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xf000 0x1000>;
>> };
>>
>> aal0: aal@14010000 {
>> @@ -732,6 +743,7 @@
>> interrupts = <GIC_SPI 233 IRQ_TYPE_LEVEL_LOW>;
>> power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
>> clocks = <&mmsys CLK_MM_DISP_AAL0>;
>> + mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0 0x1000>;
>> };
>>
>> gamma0: gamma@14011000 {
>> @@ -741,6 +753,7 @@
>> interrupts = <GIC_SPI 234 IRQ_TYPE_LEVEL_LOW>;
>> power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
>> clocks = <&mmsys CLK_MM_DISP_GAMMA0>;
>> + mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x1000 0x1000>;
>> };
>>
>> dither0: dither@14012000 {
>> @@ -749,6 +762,7 @@
>> interrupts = <GIC_SPI 235 IRQ_TYPE_LEVEL_LOW>;
>> power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
>> clocks = <&mmsys CLK_MM_DISP_DITHER0>;
>> + mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x2000 0x1000>;
>> };
>>
>> mutex: mutex@14016000 {
>> @@ -756,6 +770,8 @@
>> reg = <0 0x14016000 0 0x1000>;
>> interrupts = <GIC_SPI 217 IRQ_TYPE_LEVEL_LOW>;
>> power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
>> + mediatek,gce-events = <CMDQ_EVENT_MUTEX_STREAM_DONE0>,
>> + <CMDQ_EVENT_MUTEX_STREAM_DONE1>;
>> };
>>
>> smi_common: smi@14019000 {
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* arm64/acpi: NULL dereference reports from UBSAN at boot
From: Will Deacon @ 2020-05-21 10:09 UTC (permalink / raw)
To: lorenzo.pieralisi, guohanjun
Cc: mark.rutland, rjw, linux-kernel, linux-arm-kernel
Hi folks,
I just tried booting the arm64 for-kernelci branch under QEMU (version
4.2.50 (v4.2.0-779-g4354edb6dcc7)) with UBSAN enabled, and I see a couple
of NULL pointer dereferences reported at boot. I think they're both GIC
related (log below). I don't see a panic with UBSAN disabled, so something's
fishy here.
Please can you take a look when you get a chance? I haven't had time to see
if this is a regression or not, but I don't think it's particularly serious
as I have all sorts of horrible stuff enabled in my .config, since I'm
trying to chase down another bug:
https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/plain/arch/arm64/configs/fuzzing.config?h=fuzzing/arm64-kernelci-20200519&id=c149cf6a51aa4f72d53fc681c6661094e93ef660
(on top of defconfig)
CONFIG_FAIL_PAGE_ALLOC may be to blame.
Cheers,
Will
--->8
[ 0.000000][ T0] ================================================================================
[ 0.000000][ T0] UBSAN: null-ptr-deref in drivers/acpi/acpica/tbfadt.c:459:37
[ 0.000000][ T0] member access within null pointer of type 'struct acpi_table_fadt'
[ 0.000000][ T0] CPU: 0 PID: 0 Comm: swapper Not tainted 5.7.0-rc6-00124-g96bc42ff0a82 #1
[ 0.000000][ T0] Call trace:
[ 0.000000][ T0] dump_backtrace+0x0/0x384
[ 0.000000][ T0] show_stack+0x28/0x38
[ 0.000000][ T0] dump_stack+0xec/0x174
[ 0.000000][ T0] handle_null_ptr_deref+0x134/0x174
[ 0.000000][ T0] __ubsan_handle_type_mismatch_v1+0x84/0xa4
[ 0.000000][ T0] acpi_tb_create_local_fadt+0x1d4/0x1418
[ 0.000000][ T0] acpi_tb_parse_fadt+0x108/0x4b8
[ 0.000000][ T0] acpi_tb_parse_root_table+0x380/0x578
[ 0.000000][ T0] acpi_initialize_tables+0x140/0x194
[ 0.000000][ T0] acpi_table_init+0x90/0xcc
[ 0.000000][ T0] acpi_boot_table_init+0xfc/0x1c8
[ 0.000000][ T0] setup_arch+0x2b4/0x3ec
[ 0.000000][ T0] start_kernel+0x98/0x6f4
[ 0.000000][ T0] ================================================================================
[ 0.000000][ T0] ================================================================================
[ 0.000000][ T0] UBSAN: null-ptr-deref in arch/arm64/kernel/smp.c:596:6
[ 0.000000][ T0] member access within null pointer of type 'struct acpi_madt_generic_interrupt'
[ 0.000000][ T0] CPU: 0 PID: 0 Comm: swapper Not tainted 5.7.0-rc6-00124-g96bc42ff0a82 #1
[ 0.000000][ T0] Call trace:
[ 0.000000][ T0] dump_backtrace+0x0/0x384
[ 0.000000][ T0] show_stack+0x28/0x38
[ 0.000000][ T0] dump_stack+0xec/0x174
[ 0.000000][ T0] handle_null_ptr_deref+0x134/0x174
[ 0.000000][ T0] __ubsan_handle_type_mismatch_v1+0x84/0xa4
[ 0.000000][ T0] acpi_parse_gic_cpu_interface+0x60/0xe8
[ 0.000000][ T0] acpi_parse_entries_array+0x288/0x498
[ 0.000000][ T0] acpi_table_parse_entries_array+0x178/0x1b4
[ 0.000000][ T0] acpi_table_parse_madt+0xa4/0x110
[ 0.000000][ T0] acpi_parse_and_init_cpus+0x38/0x100
[ 0.000000][ T0] smp_init_cpus+0x74/0x258
[ 0.000000][ T0] setup_arch+0x350/0x3ec
[ 0.000000][ T0] start_kernel+0x98/0x6f4
[ 0.000000][ T0] ================================================================================
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/2] arm64 sigreturn unwinding fixes
From: Daniel Kiss @ 2020-05-21 9:53 UTC (permalink / raw)
To: Will Deacon
Cc: Tamas Zsoldos, Mark Brown, kernel-team@android.com, Dave P Martin,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20200520175539.28464-1-will@kernel.org>
Hi Will,
Works okay, LGTM.
Thanks for the patch.
Cheers,
Daniel
> On 20 May 2020, at 19:55, Will Deacon <will@kernel.org> wrote:
>
> Hi folks,
>
> Here is v3 of my attempt at fixing the vdso sigreturn code for unwinders.
> Previous versions are available here:
>
> v1: https://lore.kernel.org/r/20200519121818.14511-1-will@kernel.org
> v2: https://lore.kernel.org/r/20200519162821.16857-1-will@kernel.org
>
> Changes since v2 include:
>
> * Fix the .cfi directives to identify the link register correctly
> * Even more comments
>
> Daniel, please can you give this a spin with the LLVM unwinder? It should work
> this time.
>
> Cheers,
>
> Will
>
> Cc: Dave Martin <dave.martin@arm.com>
> Cc: Tamas Zsoldos <tamas.zsoldos@arm.com>
> Cc: Daniel Kiss <daniel.kiss@arm.com>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: <kernel-team@android.com>
>
> --->8
>
> Will Deacon (2):
> arm64: vdso: Don't prefix sigreturn trampoline with a BTI C
> instruction
> arm64: vdso: Fix CFI directives in sigreturn trampoline
>
> arch/arm64/include/asm/linkage.h | 6 ++--
> arch/arm64/kernel/vdso/sigreturn.S | 51 ++++++++++++++++++++++++----
> arch/arm64/kernel/vdso32/sigreturn.S | 19 ++++++-----
> 3 files changed, 58 insertions(+), 18 deletions(-)
>
> --
> 2.26.2.761.g0e0b3e54be-goog
>
_______________________________________________
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 v13 5/6] rtc: mt6397: Add support for the MediaTek MT6358 RTC
From: Matthias Brugger @ 2020-05-21 9:38 UTC (permalink / raw)
To: Lee Jones
Cc: linux-rtc, Alessandro Zummo, Alexandre Belloni, drinkcat,
srv_heupstream, Frank Wunderlich, Josef Friedl, Ran Bi, Sean Wang,
Sebastian Reichel, linux-kernel, Richard Fontana, devicetree,
Rob Herring, linux-mediatek, linux-arm-kernel, linux-pm,
Thomas Gleixner, Eddie Huang, Hsin-Hsiung Wang
In-Reply-To: <20200521074718.GN271301@dell>
On 21/05/2020 09:47, Lee Jones wrote:
> On Sat, 16 May 2020, Matthias Brugger wrote:
>
>> Hi Lee,
>>
>> On 21/04/2020 05:00, Hsin-Hsiung Wang wrote:
>>> From: Ran Bi <ran.bi@mediatek.com>
>>>
>>> This add support for the MediaTek MT6358 RTC. Driver using
>>> compatible data to store different RTC_WRTGR address offset.
>>> This replace RTC_WRTGR to RTC_WRTGR_MT6323 in mt6323-poweroff
>>> driver which only needed by armv7 CPU without ATF.
>>>
>>> Signed-off-by: Ran Bi <ran.bi@mediatek.com>
>>> Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com>
>>> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
>>> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
>>> Acked-by: Sebastian Reichel <sre@kernel.org>
>>> Reviewed-by: Yingjoe Chen <yingjoe.chen@mediatek.com>
>>
>> We have Acked-by from rtc and reset drivers maintainers. Are you OK to take them
>> through your mfd branch?
>>
>> Are you planning to queue them for v5.8?
>>
>> Just asking because if so I'd queue patch 6 through my tree.
>
> Yes, please take patch 6.
>
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 v13 6/6] arm64: dts: mt6358: add PMIC MT6358 related nodes
From: Matthias Brugger @ 2020-05-21 9:38 UTC (permalink / raw)
To: Hsin-Hsiung Wang, Lee Jones, Rob Herring, Alexandre Belloni
Cc: linux-rtc, Alessandro Zummo, Josef Friedl, drinkcat,
srv_heupstream, Frank Wunderlich, Ran Bi, Sean Wang,
Sebastian Reichel, linux-kernel, Richard Fontana, devicetree,
linux-mediatek, linux-pm, Thomas Gleixner, Eddie Huang,
linux-arm-kernel
In-Reply-To: <1587438012-24832-7-git-send-email-hsin-hsiung.wang@mediatek.com>
On 21/04/2020 05:00, Hsin-Hsiung Wang wrote:
> add PMIC MT6358 related nodes which is for MT8183 platform
>
> Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com>
> ---
Now queued for v5.7-next/dts64
Thanks!
> arch/arm64/boot/dts/mediatek/mt6358.dtsi | 358 ++++++++++++++++++++++++++++
> arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 1 +
> 2 files changed, 359 insertions(+)
> create mode 100644 arch/arm64/boot/dts/mediatek/mt6358.dtsi
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt6358.dtsi b/arch/arm64/boot/dts/mediatek/mt6358.dtsi
> new file mode 100644
> index 0000000..9361ada
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt6358.dtsi
> @@ -0,0 +1,358 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright (c) 2020 MediaTek Inc.
> + */
> +
> +&pwrap {
> + pmic: mt6358 {
> + compatible = "mediatek,mt6358";
> + interrupt-controller;
> + interrupt-parent = <&pio>;
> + interrupts = <182 IRQ_TYPE_LEVEL_HIGH>;
> + #interrupt-cells = <2>;
> +
> + mt6358codec: mt6358codec {
> + compatible = "mediatek,mt6358-sound";
> + };
> +
> + mt6358regulator: mt6358regulator {
> + mt6358_vdram1_reg: buck_vdram1 {
> + regulator-name = "vdram1";
> + regulator-min-microvolt = <500000>;
> + regulator-max-microvolt = <2087500>;
> + regulator-ramp-delay = <12500>;
> + regulator-enable-ramp-delay = <0>;
> + regulator-always-on;
> + regulator-allowed-modes = <0 1>;
> + };
> +
> + mt6358_vcore_reg: buck_vcore {
> + regulator-name = "vcore";
> + regulator-min-microvolt = <500000>;
> + regulator-max-microvolt = <1293750>;
> + regulator-ramp-delay = <6250>;
> + regulator-enable-ramp-delay = <200>;
> + regulator-always-on;
> + regulator-allowed-modes = <0 1>;
> + };
> +
> + mt6358_vpa_reg: buck_vpa {
> + regulator-name = "vpa";
> + regulator-min-microvolt = <500000>;
> + regulator-max-microvolt = <3650000>;
> + regulator-ramp-delay = <50000>;
> + regulator-enable-ramp-delay = <250>;
> + regulator-allowed-modes = <0 1>;
> + };
> +
> + mt6358_vproc11_reg: buck_vproc11 {
> + regulator-name = "vproc11";
> + regulator-min-microvolt = <500000>;
> + regulator-max-microvolt = <1293750>;
> + regulator-ramp-delay = <6250>;
> + regulator-enable-ramp-delay = <200>;
> + regulator-always-on;
> + regulator-allowed-modes = <0 1>;
> + };
> +
> + mt6358_vproc12_reg: buck_vproc12 {
> + regulator-name = "vproc12";
> + regulator-min-microvolt = <500000>;
> + regulator-max-microvolt = <1293750>;
> + regulator-ramp-delay = <6250>;
> + regulator-enable-ramp-delay = <200>;
> + regulator-always-on;
> + regulator-allowed-modes = <0 1>;
> + };
> +
> + mt6358_vgpu_reg: buck_vgpu {
> + regulator-name = "vgpu";
> + regulator-min-microvolt = <500000>;
> + regulator-max-microvolt = <1293750>;
> + regulator-ramp-delay = <6250>;
> + regulator-enable-ramp-delay = <200>;
> + regulator-allowed-modes = <0 1>;
> + };
> +
> + mt6358_vs2_reg: buck_vs2 {
> + regulator-name = "vs2";
> + regulator-min-microvolt = <500000>;
> + regulator-max-microvolt = <2087500>;
> + regulator-ramp-delay = <12500>;
> + regulator-enable-ramp-delay = <0>;
> + regulator-always-on;
> + };
> +
> + mt6358_vmodem_reg: buck_vmodem {
> + regulator-name = "vmodem";
> + regulator-min-microvolt = <500000>;
> + regulator-max-microvolt = <1293750>;
> + regulator-ramp-delay = <6250>;
> + regulator-enable-ramp-delay = <900>;
> + regulator-always-on;
> + regulator-allowed-modes = <0 1>;
> + };
> +
> + mt6358_vs1_reg: buck_vs1 {
> + regulator-name = "vs1";
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <2587500>;
> + regulator-ramp-delay = <12500>;
> + regulator-enable-ramp-delay = <0>;
> + regulator-always-on;
> + };
> +
> + mt6358_vdram2_reg: ldo_vdram2 {
> + regulator-name = "vdram2";
> + regulator-min-microvolt = <600000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-enable-ramp-delay = <3300>;
> + };
> +
> + mt6358_vsim1_reg: ldo_vsim1 {
> + regulator-name = "vsim1";
> + regulator-min-microvolt = <1700000>;
> + regulator-max-microvolt = <3100000>;
> + regulator-enable-ramp-delay = <540>;
> + };
> +
> + mt6358_vibr_reg: ldo_vibr {
> + regulator-name = "vibr";
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <60>;
> + };
> +
> + mt6358_vrf12_reg: ldo_vrf12 {
> + compatible = "regulator-fixed";
> + regulator-name = "vrf12";
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <1200000>;
> + regulator-enable-ramp-delay = <120>;
> + };
> +
> + mt6358_vio18_reg: ldo_vio18 {
> + compatible = "regulator-fixed";
> + regulator-name = "vio18";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-enable-ramp-delay = <2700>;
> + regulator-always-on;
> + };
> +
> + mt6358_vusb_reg: ldo_vusb {
> + regulator-name = "vusb";
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3100000>;
> + regulator-enable-ramp-delay = <270>;
> + regulator-always-on;
> + };
> +
> + mt6358_vcamio_reg: ldo_vcamio {
> + compatible = "regulator-fixed";
> + regulator-name = "vcamio";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-enable-ramp-delay = <325>;
> + };
> +
> + mt6358_vcamd_reg: ldo_vcamd {
> + regulator-name = "vcamd";
> + regulator-min-microvolt = <900000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-enable-ramp-delay = <325>;
> + };
> +
> + mt6358_vcn18_reg: ldo_vcn18 {
> + compatible = "regulator-fixed";
> + regulator-name = "vcn18";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-enable-ramp-delay = <270>;
> + };
> +
> + mt6358_vfe28_reg: ldo_vfe28 {
> + compatible = "regulator-fixed";
> + regulator-name = "vfe28";
> + regulator-min-microvolt = <2800000>;
> + regulator-max-microvolt = <2800000>;
> + regulator-enable-ramp-delay = <270>;
> + };
> +
> + mt6358_vsram_proc11_reg: ldo_vsram_proc11 {
> + regulator-name = "vsram_proc11";
> + regulator-min-microvolt = <500000>;
> + regulator-max-microvolt = <1293750>;
> + regulator-ramp-delay = <6250>;
> + regulator-enable-ramp-delay = <240>;
> + regulator-always-on;
> + };
> +
> + mt6358_vcn28_reg: ldo_vcn28 {
> + compatible = "regulator-fixed";
> + regulator-name = "vcn28";
> + regulator-min-microvolt = <2800000>;
> + regulator-max-microvolt = <2800000>;
> + regulator-enable-ramp-delay = <270>;
> + };
> +
> + mt6358_vsram_others_reg: ldo_vsram_others {
> + regulator-name = "vsram_others";
> + regulator-min-microvolt = <500000>;
> + regulator-max-microvolt = <1293750>;
> + regulator-ramp-delay = <6250>;
> + regulator-enable-ramp-delay = <240>;
> + regulator-always-on;
> + };
> +
> + mt6358_vsram_gpu_reg: ldo_vsram_gpu {
> + regulator-name = "vsram_gpu";
> + regulator-min-microvolt = <500000>;
> + regulator-max-microvolt = <1293750>;
> + regulator-ramp-delay = <6250>;
> + regulator-enable-ramp-delay = <240>;
> + };
> +
> + mt6358_vxo22_reg: ldo_vxo22 {
> + compatible = "regulator-fixed";
> + regulator-name = "vxo22";
> + regulator-min-microvolt = <2200000>;
> + regulator-max-microvolt = <2200000>;
> + regulator-enable-ramp-delay = <120>;
> + regulator-always-on;
> + };
> +
> + mt6358_vefuse_reg: ldo_vefuse {
> + regulator-name = "vefuse";
> + regulator-min-microvolt = <1700000>;
> + regulator-max-microvolt = <1900000>;
> + regulator-enable-ramp-delay = <270>;
> + };
> +
> + mt6358_vaux18_reg: ldo_vaux18 {
> + compatible = "regulator-fixed";
> + regulator-name = "vaux18";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-enable-ramp-delay = <270>;
> + };
> +
> + mt6358_vmch_reg: ldo_vmch {
> + regulator-name = "vmch";
> + regulator-min-microvolt = <2900000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <60>;
> + };
> +
> + mt6358_vbif28_reg: ldo_vbif28 {
> + compatible = "regulator-fixed";
> + regulator-name = "vbif28";
> + regulator-min-microvolt = <2800000>;
> + regulator-max-microvolt = <2800000>;
> + regulator-enable-ramp-delay = <270>;
> + };
> +
> + mt6358_vsram_proc12_reg: ldo_vsram_proc12 {
> + regulator-name = "vsram_proc12";
> + regulator-min-microvolt = <500000>;
> + regulator-max-microvolt = <1293750>;
> + regulator-ramp-delay = <6250>;
> + regulator-enable-ramp-delay = <240>;
> + regulator-always-on;
> + };
> +
> + mt6358_vcama1_reg: ldo_vcama1 {
> + regulator-name = "vcama1";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3000000>;
> + regulator-enable-ramp-delay = <325>;
> + };
> +
> + mt6358_vemc_reg: ldo_vemc {
> + regulator-name = "vemc";
> + regulator-min-microvolt = <2900000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <60>;
> + };
> +
> + mt6358_vio28_reg: ldo_vio28 {
> + compatible = "regulator-fixed";
> + regulator-name = "vio28";
> + regulator-min-microvolt = <2800000>;
> + regulator-max-microvolt = <2800000>;
> + regulator-enable-ramp-delay = <270>;
> + };
> +
> + mt6358_va12_reg: ldo_va12 {
> + compatible = "regulator-fixed";
> + regulator-name = "va12";
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <1200000>;
> + regulator-enable-ramp-delay = <270>;
> + regulator-always-on;
> + };
> +
> + mt6358_vrf18_reg: ldo_vrf18 {
> + compatible = "regulator-fixed";
> + regulator-name = "vrf18";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-enable-ramp-delay = <120>;
> + };
> +
> + mt6358_vcn33_bt_reg: ldo_vcn33_bt {
> + regulator-name = "vcn33_bt";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3500000>;
> + regulator-enable-ramp-delay = <270>;
> + };
> +
> + mt6358_vcn33_wifi_reg: ldo_vcn33_wifi {
> + regulator-name = "vcn33_wifi";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3500000>;
> + regulator-enable-ramp-delay = <270>;
> + };
> +
> + mt6358_vcama2_reg: ldo_vcama2 {
> + regulator-name = "vcama2";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3000000>;
> + regulator-enable-ramp-delay = <325>;
> + };
> +
> + mt6358_vmc_reg: ldo_vmc {
> + regulator-name = "vmc";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <60>;
> + };
> +
> + mt6358_vldo28_reg: ldo_vldo28 {
> + regulator-name = "vldo28";
> + regulator-min-microvolt = <2800000>;
> + regulator-max-microvolt = <3000000>;
> + regulator-enable-ramp-delay = <270>;
> + };
> +
> + mt6358_vaud28_reg: ldo_vaud28 {
> + compatible = "regulator-fixed";
> + regulator-name = "vaud28";
> + regulator-min-microvolt = <2800000>;
> + regulator-max-microvolt = <2800000>;
> + regulator-enable-ramp-delay = <270>;
> + };
> +
> + mt6358_vsim2_reg: ldo_vsim2 {
> + regulator-name = "vsim2";
> + regulator-min-microvolt = <1700000>;
> + regulator-max-microvolt = <3100000>;
> + regulator-enable-ramp-delay = <540>;
> + };
> + };
> +
> + mt6358rtc: mt6358rtc {
> + compatible = "mediatek,mt6358-rtc";
> + };
> + };
> +};
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> index 1fb195c..9eb84d7 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> @@ -7,6 +7,7 @@
>
> /dts-v1/;
> #include "mt8183.dtsi"
> +#include "mt6358.dtsi"
>
> / {
> model = "MediaTek MT8183 evaluation board";
>
_______________________________________________
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 4/5] kdump: update Documentation about crashkernel on arm64
From: Chen Zhou @ 2020-05-21 9:38 UTC (permalink / raw)
To: tglx, mingo, catalin.marinas, will, dyoung, bhe, robh+dt
Cc: John.p.donnelly, arnd, devicetree, chenzhou10, linux-doc, kexec,
linux-kernel, horms, guohanjun, pkushwaha, linux-arm-kernel
In-Reply-To: <20200521093805.64398-1-chenzhou10@huawei.com>
Now we support crashkernel=X,[low] on arm64, update the Documentation.
Signed-off-by: Chen Zhou <chenzhou10@huawei.com>
Tested-by: John Donnelly <John.p.donnelly@oracle.com>
Tested-by: Prabhakar Kushwaha <pkushwaha@marvell.com>
---
Documentation/admin-guide/kdump/kdump.rst | 13 +++++++++++--
Documentation/admin-guide/kernel-parameters.txt | 12 +++++++++++-
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/Documentation/admin-guide/kdump/kdump.rst b/Documentation/admin-guide/kdump/kdump.rst
index ac7e131d2935..e55173ec1666 100644
--- a/Documentation/admin-guide/kdump/kdump.rst
+++ b/Documentation/admin-guide/kdump/kdump.rst
@@ -299,7 +299,13 @@ Boot into System Kernel
"crashkernel=64M@16M" tells the system kernel to reserve 64 MB of memory
starting at physical address 0x01000000 (16MB) for the dump-capture kernel.
- On x86 and x86_64, use "crashkernel=64M@16M".
+ On x86 use "crashkernel=64M@16M".
+
+ On x86_64, use "crashkernel=Y[@X]" to select a region under 4G first, and
+ fall back to reserve region above 4G when '@offset' hasn't been specified.
+ We can also use "crashkernel=X,high" to select a region above 4G, which
+ also tries to allocate at least 256M below 4G automatically and
+ "crashkernel=Y,low" can be used to allocate specified size low memory.
On ppc64, use "crashkernel=128M@32M".
@@ -316,8 +322,11 @@ Boot into System Kernel
kernel will automatically locate the crash kernel image within the
first 512MB of RAM if X is not given.
- On arm64, use "crashkernel=Y[@X]". Note that the start address of
+ On arm64, use "crashkernel=Y[@X]". Note that the start address of
the kernel, X if explicitly specified, must be aligned to 2MiB (0x200000).
+ If crashkernel=Z,low is specified simultaneously, reserve spcified size
+ low memory for crash kdump kernel devices firstly and then reserve memory
+ above 4G.
Load the Dump-capture Kernel
============================
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 7bc83f3d9bdf..97695783b817 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -722,6 +722,9 @@
[KNL, x86_64] select a region under 4G first, and
fall back to reserve region above 4G when '@offset'
hasn't been specified.
+ [KNL, arm64] If crashkernel=X,low is specified, reserve
+ spcified size low memory for crash kdump kernel devices
+ firstly, and then reserve memory above 4G.
See Documentation/admin-guide/kdump/kdump.rst for further details.
crashkernel=range1:size1[,range2:size2,...][@offset]
@@ -746,12 +749,19 @@
requires at least 64M+32K low memory, also enough extra
low memory is needed to make sure DMA buffers for 32-bit
devices won't run out. Kernel would try to allocate at
- at least 256M below 4G automatically.
+ least 256M below 4G automatically.
This one let user to specify own low range under 4G
for second kernel instead.
0: to disable low allocation.
It will be ignored when crashkernel=X,high is not used
or memory reserved is below 4G.
+ [KNL, arm64] range under 4G.
+ This one let user to specify own low range under 4G
+ for crash dump kernel instead.
+ Different with x86_64, kernel allocates specified size
+ physical memory region only when this parameter is specified
+ instead of trying to allocate at least 256M below 4G
+ automatically.
cryptomgr.notests
[KNL] Disable crypto self-tests
--
2.20.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 v8 3/5] arm64: kdump: add memory for devices by DT property, low-memory-range
From: Chen Zhou @ 2020-05-21 9:38 UTC (permalink / raw)
To: tglx, mingo, catalin.marinas, will, dyoung, bhe, robh+dt
Cc: John.p.donnelly, arnd, devicetree, chenzhou10, linux-doc, kexec,
linux-kernel, horms, guohanjun, pkushwaha, linux-arm-kernel
In-Reply-To: <20200521093805.64398-1-chenzhou10@huawei.com>
If we want to reserve crashkernel above 4G, we could use parameters
"crashkernel=X crashkernel=Y,low", in this case, specified size low
memory is reserved for crash dump kernel devices and never mapped by
the first kernel. This memory range is advertised to crash dump kernel
via DT property under /chosen,
linux,low-memory-range=<BASE SIZE>
Crash dump kernel reads this property at boot time and call
memblock_add() after memblock_cap_memory_range() has been called.
Signed-off-by: Chen Zhou <chenzhou10@huawei.com>
Tested-by: John Donnelly <John.p.donnelly@oracle.com>
Tested-by: Prabhakar Kushwaha <pkushwaha@marvell.com>
---
arch/arm64/mm/init.c | 30 +++++++++++++++++++++++++++++-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 71498acf0cd8..fcc3abee7003 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -323,6 +323,26 @@ static int __init early_mem(char *p)
}
early_param("mem", early_mem);
+static int __init early_init_dt_scan_lowmem(unsigned long node,
+ const char *uname, int depth, void *data)
+{
+ struct memblock_region *lowmem = data;
+ const __be32 *reg;
+ int len;
+
+ if (depth != 1 || strcmp(uname, "chosen") != 0)
+ return 0;
+
+ reg = of_get_flat_dt_prop(node, "linux,low-memory-range", &len);
+ if (!reg || (len < (dt_root_addr_cells + dt_root_size_cells)))
+ return 1;
+
+ lowmem->base = dt_mem_next_cell(dt_root_addr_cells, ®);
+ lowmem->size = dt_mem_next_cell(dt_root_size_cells, ®);
+
+ return 1;
+}
+
static int __init early_init_dt_scan_usablemem(unsigned long node,
const char *uname, int depth, void *data)
{
@@ -353,13 +373,21 @@ static void __init fdt_enforce_memory_region(void)
if (reg.size)
memblock_cap_memory_range(reg.base, reg.size);
+
+ of_scan_flat_dt(early_init_dt_scan_lowmem, ®);
+
+ if (reg.size)
+ memblock_add(reg.base, reg.size);
}
void __init arm64_memblock_init(void)
{
const s64 linear_region_size = BIT(vabits_actual - 1);
- /* Handle linux,usable-memory-range property */
+ /*
+ * Handle linux,usable-memory-range and linux,low-memory-range
+ * properties.
+ */
fdt_enforce_memory_region();
/* Remove memory above our supported physical address size */
--
2.20.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 v8 5/5] dt-bindings: chosen: Document linux, low-memory-range for arm64 kdump
From: Chen Zhou @ 2020-05-21 9:38 UTC (permalink / raw)
To: tglx, mingo, catalin.marinas, will, dyoung, bhe, robh+dt
Cc: John.p.donnelly, arnd, devicetree, chenzhou10, linux-doc, kexec,
linux-kernel, horms, guohanjun, pkushwaha, linux-arm-kernel
In-Reply-To: <20200521093805.64398-1-chenzhou10@huawei.com>
Add documentation for DT property used by arm64 kdump:
linux,low-memory-range.
"linux,low-memory-range" is an another memory region used for crash
dump kernel devices.
Signed-off-by: Chen Zhou <chenzhou10@huawei.com>
---
Documentation/devicetree/bindings/chosen.txt | 25 ++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
index 45e79172a646..bfe6fb6976e6 100644
--- a/Documentation/devicetree/bindings/chosen.txt
+++ b/Documentation/devicetree/bindings/chosen.txt
@@ -103,6 +103,31 @@ While this property does not represent a real hardware, the address
and the size are expressed in #address-cells and #size-cells,
respectively, of the root node.
+linux,low-memory-range
+----------------------
+This property (arm64 only) holds a base address and size, describing a
+limited region below 4G. Similar to "linux,usable-memory-range", it is
+an another memory range which may be considered available for use by the
+kernel.
+
+e.g.
+
+/ {
+ chosen {
+ linux,low-memory-range = <0x0 0x70000000 0x0 0x10000000>;
+ linux,usable-memory-range = <0x202f 0xc0000000 0x0 0x40000000>;
+ };
+};
+
+The main usage is for crash dump kernel devices when reserving crashkernel
+above 4G. When reserving crashkernel above 4G, there may be two crash kernel
+regions, one is below 4G, the other is above 4G. In order to distinct from
+the high region, use this property to pass the low region.
+
+While this property does not represent a real hardware, the address
+and the size are expressed in #address-cells and #size-cells,
+respectively, of the root node.
+
linux,elfcorehdr
----------------
--
2.20.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 v8 1/5] x86: kdump: move reserve_crashkernel_low() into crash_core.c
From: Chen Zhou @ 2020-05-21 9:38 UTC (permalink / raw)
To: tglx, mingo, catalin.marinas, will, dyoung, bhe, robh+dt
Cc: John.p.donnelly, arnd, devicetree, chenzhou10, linux-doc, kexec,
linux-kernel, horms, guohanjun, pkushwaha, linux-arm-kernel
In-Reply-To: <20200521093805.64398-1-chenzhou10@huawei.com>
In preparation for supporting reserve_crashkernel_low in arm64 as
x86_64 does, move reserve_crashkernel_low() into kernel/crash_core.c.
BTW, move x86 CRASH_ALIGN to 2M.
Note, in arm64, we reserve low memory if and only if crashkernel=X,low
is specified. Different with x86_64, don't set low memory automatically.
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Chen Zhou <chenzhou10@huawei.com>
Tested-by: John Donnelly <John.p.donnelly@oracle.com>
Tested-by: Prabhakar Kushwaha <pkushwaha@marvell.com>
---
arch/x86/kernel/setup.c | 66 ++++-------------------------
include/linux/crash_core.h | 3 ++
include/linux/kexec.h | 2 -
kernel/crash_core.c | 85 ++++++++++++++++++++++++++++++++++++++
kernel/kexec_core.c | 17 --------
5 files changed, 96 insertions(+), 77 deletions(-)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 4b3fa6cd3106..de75fec73d47 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -395,8 +395,8 @@ static void __init memblock_x86_reserve_range_setup_data(void)
#ifdef CONFIG_KEXEC_CORE
-/* 16M alignment for crash kernel regions */
-#define CRASH_ALIGN SZ_16M
+/* 2M alignment for crash kernel regions */
+#define CRASH_ALIGN SZ_2M
/*
* Keep the crash kernel below this limit.
@@ -419,59 +419,6 @@ static void __init memblock_x86_reserve_range_setup_data(void)
# define CRASH_ADDR_HIGH_MAX SZ_64T
#endif
-static int __init reserve_crashkernel_low(void)
-{
-#ifdef CONFIG_X86_64
- unsigned long long base, low_base = 0, low_size = 0;
- unsigned long total_low_mem;
- int ret;
-
- total_low_mem = memblock_mem_size(1UL << (32 - PAGE_SHIFT));
-
- /* crashkernel=Y,low */
- ret = parse_crashkernel_low(boot_command_line, total_low_mem, &low_size, &base);
- if (ret) {
- /*
- * two parts from kernel/dma/swiotlb.c:
- * -swiotlb size: user-specified with swiotlb= or default.
- *
- * -swiotlb overflow buffer: now hardcoded to 32k. We round it
- * to 8M for other buffers that may need to stay low too. Also
- * make sure we allocate enough extra low memory so that we
- * don't run out of DMA buffers for 32-bit devices.
- */
- low_size = max(swiotlb_size_or_default() + (8UL << 20), 256UL << 20);
- } else {
- /* passed with crashkernel=0,low ? */
- if (!low_size)
- return 0;
- }
-
- low_base = memblock_find_in_range(0, 1ULL << 32, low_size, CRASH_ALIGN);
- if (!low_base) {
- pr_err("Cannot reserve %ldMB crashkernel low memory, please try smaller size.\n",
- (unsigned long)(low_size >> 20));
- return -ENOMEM;
- }
-
- ret = memblock_reserve(low_base, low_size);
- if (ret) {
- pr_err("%s: Error reserving crashkernel low memblock.\n", __func__);
- return ret;
- }
-
- pr_info("Reserving %ldMB of low memory at %ldMB for crashkernel (System low RAM: %ldMB)\n",
- (unsigned long)(low_size >> 20),
- (unsigned long)(low_base >> 20),
- (unsigned long)(total_low_mem >> 20));
-
- crashk_low_res.start = low_base;
- crashk_low_res.end = low_base + low_size - 1;
- insert_resource(&iomem_resource, &crashk_low_res);
-#endif
- return 0;
-}
-
static void __init reserve_crashkernel(void)
{
unsigned long long crash_size, crash_base, total_mem;
@@ -535,9 +482,12 @@ static void __init reserve_crashkernel(void)
return;
}
- if (crash_base >= (1ULL << 32) && reserve_crashkernel_low()) {
- memblock_free(crash_base, crash_size);
- return;
+ if (crash_base >= (1ULL << 32)) {
+ if (reserve_crashkernel_low()) {
+ memblock_free(crash_base, crash_size);
+ return;
+ }
+ insert_resource(&iomem_resource, &crashk_low_res);
}
pr_info("Reserving %ldMB of memory at %ldMB for crashkernel (System RAM: %ldMB)\n",
diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
index 525510a9f965..4df8c0bff03e 100644
--- a/include/linux/crash_core.h
+++ b/include/linux/crash_core.h
@@ -63,6 +63,8 @@ phys_addr_t paddr_vmcoreinfo_note(void);
extern unsigned char *vmcoreinfo_data;
extern size_t vmcoreinfo_size;
extern u32 *vmcoreinfo_note;
+extern struct resource crashk_res;
+extern struct resource crashk_low_res;
Elf_Word *append_elf_note(Elf_Word *buf, char *name, unsigned int type,
void *data, size_t data_len);
@@ -74,5 +76,6 @@ int parse_crashkernel_high(char *cmdline, unsigned long long system_ram,
unsigned long long *crash_size, unsigned long long *crash_base);
int parse_crashkernel_low(char *cmdline, unsigned long long system_ram,
unsigned long long *crash_size, unsigned long long *crash_base);
+int __init reserve_crashkernel_low(void);
#endif /* LINUX_CRASH_CORE_H */
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 1776eb2e43a4..5d5d9635b18d 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -330,8 +330,6 @@ extern int kexec_load_disabled;
/* Location of a reserved region to hold the crash kernel.
*/
-extern struct resource crashk_res;
-extern struct resource crashk_low_res;
extern note_buf_t __percpu *crash_notes;
/* flag to track if kexec reboot is in progress */
diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index 9f1557b98468..a7580d291c37 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -7,6 +7,8 @@
#include <linux/crash_core.h>
#include <linux/utsname.h>
#include <linux/vmalloc.h>
+#include <linux/memblock.h>
+#include <linux/swiotlb.h>
#include <asm/page.h>
#include <asm/sections.h>
@@ -19,6 +21,22 @@ u32 *vmcoreinfo_note;
/* trusted vmcoreinfo, e.g. we can make a copy in the crash memory */
static unsigned char *vmcoreinfo_data_safecopy;
+/* Location of the reserved area for the crash kernel */
+struct resource crashk_res = {
+ .name = "Crash kernel",
+ .start = 0,
+ .end = 0,
+ .flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
+ .desc = IORES_DESC_CRASH_KERNEL
+};
+struct resource crashk_low_res = {
+ .name = "Crash kernel",
+ .start = 0,
+ .end = 0,
+ .flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
+ .desc = IORES_DESC_CRASH_KERNEL
+};
+
/*
* parsing the "crashkernel" commandline
*
@@ -292,6 +310,73 @@ int __init parse_crashkernel_low(char *cmdline,
"crashkernel=", suffix_tbl[SUFFIX_LOW]);
}
+#if defined(CONFIG_X86_64) || defined(CONFIG_ARM64)
+#define CRASH_ALIGN SZ_2M
+#endif
+
+int __init reserve_crashkernel_low(void)
+{
+#if defined(CONFIG_X86_64) || defined(CONFIG_ARM64)
+ unsigned long long base, low_base = 0, low_size = 0;
+ unsigned long total_low_mem;
+ int ret;
+
+ total_low_mem = memblock_mem_size(1UL << (32 - PAGE_SHIFT));
+
+ /* crashkernel=Y,low */
+ ret = parse_crashkernel_low(boot_command_line, total_low_mem, &low_size,
+ &base);
+ if (ret) {
+#ifdef CONFIG_X86_64
+ /*
+ * two parts from lib/swiotlb.c:
+ * -swiotlb size: user-specified with swiotlb= or default.
+ *
+ * -swiotlb overflow buffer: now hardcoded to 32k. We round it
+ * to 8M for other buffers that may need to stay low too. Also
+ * make sure we allocate enough extra low memory so that we
+ * don't run out of DMA buffers for 32-bit devices.
+ */
+ low_size = max(swiotlb_size_or_default() + (8UL << 20),
+ 256UL << 20);
+#else
+ /*
+ * in arm64, reserve low memory if and only if crashkernel=X,low
+ * specified.
+ */
+ return -EINVAL;
+#endif
+ } else {
+ /* passed with crashkernel=0,low ? */
+ if (!low_size)
+ return 0;
+ }
+
+ low_base = memblock_find_in_range(0, 1ULL << 32, low_size, CRASH_ALIGN);
+ if (!low_base) {
+ pr_err("Cannot reserve %ldMB crashkernel low memory, please try smaller size.\n",
+ (unsigned long)(low_size >> 20));
+ return -ENOMEM;
+ }
+
+ ret = memblock_reserve(low_base, low_size);
+ if (ret) {
+ pr_err("%s: Error reserving crashkernel low memblock.\n",
+ __func__);
+ return ret;
+ }
+
+ pr_info("Reserving %ldMB of low memory at %ldMB for crashkernel (System low RAM: %ldMB)\n",
+ (unsigned long)(low_size >> 20),
+ (unsigned long)(low_base >> 20),
+ (unsigned long)(total_low_mem >> 20));
+
+ crashk_low_res.start = low_base;
+ crashk_low_res.end = low_base + low_size - 1;
+#endif
+ return 0;
+}
+
Elf_Word *append_elf_note(Elf_Word *buf, char *name, unsigned int type,
void *data, size_t data_len)
{
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index c19c0dad1ebe..db66bbabfff3 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -53,23 +53,6 @@ note_buf_t __percpu *crash_notes;
/* Flag to indicate we are going to kexec a new kernel */
bool kexec_in_progress = false;
-
-/* Location of the reserved area for the crash kernel */
-struct resource crashk_res = {
- .name = "Crash kernel",
- .start = 0,
- .end = 0,
- .flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
- .desc = IORES_DESC_CRASH_KERNEL
-};
-struct resource crashk_low_res = {
- .name = "Crash kernel",
- .start = 0,
- .end = 0,
- .flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
- .desc = IORES_DESC_CRASH_KERNEL
-};
-
int kexec_should_crash(struct task_struct *p)
{
/*
--
2.20.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 v8 2/5] arm64: kdump: reserve crashkenel above 4G for crash dump kernel
From: Chen Zhou @ 2020-05-21 9:38 UTC (permalink / raw)
To: tglx, mingo, catalin.marinas, will, dyoung, bhe, robh+dt
Cc: John.p.donnelly, arnd, devicetree, chenzhou10, linux-doc, kexec,
linux-kernel, horms, guohanjun, pkushwaha, linux-arm-kernel
In-Reply-To: <20200521093805.64398-1-chenzhou10@huawei.com>
Crashkernel=X tries to reserve memory for the crash dump kernel under
4G. If crashkernel=X,low is specified simultaneously, reserve spcified
size low memory for crash kdump kernel devices firstly and then reserve
memory above 4G.
Signed-off-by: Chen Zhou <chenzhou10@huawei.com>
Tested-by: John Donnelly <John.p.donnelly@oracle.com>
Tested-by: Prabhakar Kushwaha <pkushwaha@marvell.com>
---
arch/arm64/kernel/setup.c | 8 +++++++-
arch/arm64/mm/init.c | 31 +++++++++++++++++++++++++++++--
2 files changed, 36 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 3fd2c11c09fc..a8487e4d3e5a 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -238,7 +238,13 @@ static void __init request_standard_resources(void)
kernel_data.end <= res->end)
request_resource(res, &kernel_data);
#ifdef CONFIG_KEXEC_CORE
- /* Userspace will find "Crash kernel" region in /proc/iomem. */
+ /*
+ * Userspace will find "Crash kernel" region in /proc/iomem.
+ * Note: the low region is renamed as Crash kernel (low).
+ */
+ if (crashk_low_res.end && crashk_low_res.start >= res->start &&
+ crashk_low_res.end <= res->end)
+ request_resource(res, &crashk_low_res);
if (crashk_res.end && crashk_res.start >= res->start &&
crashk_res.end <= res->end)
request_resource(res, &crashk_res);
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index e42727e3568e..71498acf0cd8 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -81,6 +81,7 @@ static void __init reserve_crashkernel(void)
{
unsigned long long crash_base, crash_size;
int ret;
+ phys_addr_t crash_max = arm64_dma32_phys_limit;
ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
&crash_size, &crash_base);
@@ -88,12 +89,38 @@ static void __init reserve_crashkernel(void)
if (ret || !crash_size)
return;
+ ret = reserve_crashkernel_low();
+ if (!ret && crashk_low_res.end) {
+ /*
+ * If crashkernel=X,low specified, there may be two regions,
+ * we need to make some changes as follows:
+ *
+ * 1. rename the low region as "Crash kernel (low)"
+ * In order to distinct from the high region and make no effect
+ * to the use of existing kexec-tools, rename the low region as
+ * "Crash kernel (low)".
+ *
+ * 2. change the upper bound for crash memory
+ * Set MEMBLOCK_ALLOC_ACCESSIBLE upper bound for crash memory.
+ *
+ * 3. mark the low region as "nomap"
+ * The low region is intended to be used for crash dump kernel
+ * devices, just mark the low region as "nomap" simply.
+ */
+ const char *rename = "Crash kernel (low)";
+
+ crashk_low_res.name = rename;
+ crash_max = MEMBLOCK_ALLOC_ACCESSIBLE;
+ memblock_mark_nomap(crashk_low_res.start,
+ resource_size(&crashk_low_res));
+ }
+
crash_size = PAGE_ALIGN(crash_size);
if (crash_base == 0) {
/* Current arm64 boot protocol requires 2MB alignment */
- crash_base = memblock_find_in_range(0, arm64_dma32_phys_limit,
- crash_size, SZ_2M);
+ crash_base = memblock_find_in_range(0, crash_max, crash_size,
+ SZ_2M);
if (crash_base == 0) {
pr_warn("cannot allocate crashkernel (size:0x%llx)\n",
crash_size);
--
2.20.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 v8 0/5] support reserving crashkernel above 4G on arm64 kdump
From: Chen Zhou @ 2020-05-21 9:38 UTC (permalink / raw)
To: tglx, mingo, catalin.marinas, will, dyoung, bhe, robh+dt
Cc: John.p.donnelly, arnd, devicetree, chenzhou10, linux-doc, kexec,
linux-kernel, horms, guohanjun, pkushwaha, linux-arm-kernel
This patch series enable reserving crashkernel above 4G in arm64.
There are following issues in arm64 kdump:
1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
when there is no enough low memory.
2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
in this case, if swiotlb or DMA buffers are required, crash dump kernel
will boot failure because there is no low memory available for allocation.
To solve these issues, introduce crashkernel=X,low to reserve specified
size low memory.
Crashkernel=X tries to reserve memory for the crash dump kernel under
4G. If crashkernel=Y,low is specified simultaneously, reserve spcified
size low memory for crash kdump kernel devices firstly and then reserve
memory above 4G.
When crashkernel is reserved above 4G in memory, that is, crashkernel=X,low
is specified simultaneously, kernel should reserve specified size low memory
for crash dump kernel devices. So there may be two crash kernel regions, one
is below 4G, the other is above 4G.
In order to distinct from the high region and make no effect to the use of
kexec-tools, rename the low region as "Crash kernel (low)", and add DT property
"linux,low-memory-range" to crash dump kernel's dtb to pass the low region.
Besides, we need to modify kexec-tools:
arm64: kdump: add another DT property to crash dump kernel's dtb(see [1])
The previous changes and discussions can be retrieved from:
Changes since [v7]
- Move x86 CRASH_ALIGN to 2M
Suggested by Dave and do some test, move x86 CRASH_ALIGN to 2M.
- Update Documentation/devicetree/bindings/chosen.txt
Add corresponding documentation to Documentation/devicetree/bindings/chosen.txt suggested by Arnd.
- Add Tested-by from Jhon and pk
Changes since [v6]
- Fix build errors reported by kbuild test robot.
Changes since [v5]
- Move reserve_crashkernel_low() into kernel/crash_core.c.
- Delete crashkernel=X,high.
- Modify crashkernel=X,low.
If crashkernel=X,low is specified simultaneously, reserve spcified size low
memory for crash kdump kernel devices firstly and then reserve memory above 4G.
In addition, rename crashk_low_res as "Crash kernel (low)" for arm64, and then
pass to crash dump kernel by DT property "linux,low-memory-range".
- Update Documentation/admin-guide/kdump/kdump.rst.
Changes since [v4]
- Reimplement memblock_cap_memory_ranges for multiple ranges by Mike.
Changes since [v3]
- Add memblock_cap_memory_ranges back for multiple ranges.
- Fix some compiling warnings.
Changes since [v2]
- Split patch "arm64: kdump: support reserving crashkernel above 4G" as
two. Put "move reserve_crashkernel_low() into kexec_core.c" in a separate
patch.
Changes since [v1]:
- Move common reserve_crashkernel_low() code into kernel/kexec_core.c.
- Remove memblock_cap_memory_ranges() i added in v1 and implement that
in fdt_enforce_memory_region().
There are at most two crash kernel regions, for two crash kernel regions
case, we cap the memory range [min(regs[*].start), max(regs[*].end)]
and then remove the memory range in the middle.
[1]: http://lists.infradead.org/pipermail/kexec/2020-May/025128.html
[v1]: https://lkml.org/lkml/2019/4/2/1174
[v2]: https://lkml.org/lkml/2019/4/9/86
[v3]: https://lkml.org/lkml/2019/4/9/306
[v4]: https://lkml.org/lkml/2019/4/15/273
[v5]: https://lkml.org/lkml/2019/5/6/1360
[v6]: https://lkml.org/lkml/2019/8/30/142
[v7]: https://lkml.org/lkml/2019/12/23/411
Chen Zhou (5):
x86: kdump: move reserve_crashkernel_low() into crash_core.c
arm64: kdump: reserve crashkenel above 4G for crash dump kernel
arm64: kdump: add memory for devices by DT property, low-memory-range
kdump: update Documentation about crashkernel on arm64
dt-bindings: chosen: Document linux,low-memory-range for arm64 kdump
Documentation/admin-guide/kdump/kdump.rst | 13 ++-
.../admin-guide/kernel-parameters.txt | 12 ++-
Documentation/devicetree/bindings/chosen.txt | 25 ++++++
arch/arm64/kernel/setup.c | 8 +-
arch/arm64/mm/init.c | 61 ++++++++++++-
arch/x86/kernel/setup.c | 66 ++------------
include/linux/crash_core.h | 3 +
include/linux/kexec.h | 2 -
kernel/crash_core.c | 85 +++++++++++++++++++
kernel/kexec_core.c | 17 ----
10 files changed, 208 insertions(+), 84 deletions(-)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 0/7] firmware: smccc: Add basic SMCCC v1.2 + ARCH_SOC_ID support
From: Arnd Bergmann @ 2020-05-21 9:30 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Lorenzo Pieralisi, Catalin Marinas,
linux-kernel@vger.kernel.org, Steven Price, harb, Sudeep Holla,
Linux ARM
In-Reply-To: <20200521091736.GA5091@willie-the-truck>
On Thu, May 21, 2020 at 11:17 AM Will Deacon <will@kernel.org> wrote:
> On Thu, May 21, 2020 at 11:06:23AM +0200, Arnd Bergmann wrote:
> > On Thu, May 21, 2020 at 10:11 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
> > Note that the warning should come up for either W=1 or C=1, and I also
> > think that
> > new code should generally be written sparse-clean and have no warnings with
> > 'make C=1' as a rule.
>
> Fair enough. Is anybody working on a tree-wide sweep for this, like we've
> done for other things such as zero-length arrays? If so, I can start
> enforcing this in the arch code as well (I haven't been so far, even though
> I do run sparse on every commit).
I've done some work on that a few years ago, and there are always
some cleanup patches for C=1 and W=1 warnings, most recently
with an increase from Huawei's automated build testing + manual
patching.
I have not looked in a while, but it always seemed to be somewhere
between "too much to do by myself" and "small enough that it should
really be done" as build warnings go.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 0/7] firmware: smccc: Add basic SMCCC v1.2 + ARCH_SOC_ID support
From: Sudeep Holla @ 2020-05-21 9:26 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Lorenzo Pieralisi, Arnd Bergmann, Catalin Marinas,
linux-kernel@vger.kernel.org, Steven Price, harb, Linux ARM
In-Reply-To: <20200521091736.GA5091@willie-the-truck>
On Thu, May 21, 2020 at 10:17:39AM +0100, Will Deacon wrote:
> On Thu, May 21, 2020 at 11:06:23AM +0200, Arnd Bergmann wrote:
> > On Thu, May 21, 2020 at 10:11 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
> > > Indeed, it is also last patch in the series. However if Arnd is happy
> > > with the sysfs names, we can move to generic code later without breaking
> > > anything.
> > >
> > > We need not revert or drop it now. I will leave that to you or Arnd to
> > > decide. Just that it may be too late to get acks for all the soc sysfs
> > > drivers in time for v5.8
> > >
> > > I am fine if you want to drop the last patch.
> >
> > Ok, let's drop that patch then and make sure we do something that
> > everyone is happy with later on. I'm already in favor of adding
> > a more reliable soc_device instance based on this, but we need to
> > be sure we don't screw up the contents of the attributes when we
> > can't change them later.
> >
> > > > > >> drivers/firmware/smccc/smccc.c:14:13: warning: no previous prototype for function 'arm_smccc_version_init' [-Wmissing-prototypes]
> > > > > void __init arm_smccc_version_init(u32 version, enum arm_smccc_conduit conduit)
> > > > > ^
> > > > > drivers/firmware/smccc/smccc.c:14:1: note: declare 'static' if the
> > > > > function is not intended to be used outside of this translation unit
> > > > > void __init arm_smccc_version_init(u32 version, enum arm_smccc_conduit conduit)
> > > >
> > > > I saw that when I applied the patches, but since the function is called from
> > > > another compilation unit (psci/psci.o), I just ignored it as we have loads
> > > > of these already and it only screams if you build with W=1.
> > > >
> > >
> > > /me confused. Do you need the fix for this warning or you are happy to ignore?
> >
> > I want a fix for that, as I hope we can eventually turn this warning on by
> > default and stop playing whack-a-mole when they come up. Most of these
> > warnings are harmless, but occasionally the prototypes don't match exactly
> > and cause real bugs depending on the configuration, and ensuring both
> > sides include a common header file is an easy way to make it work
> > more reliably.
> >
> > Note that the warning should come up for either W=1 or C=1, and I also
> > think that
> > new code should generally be written sparse-clean and have no warnings with
> > 'make C=1' as a rule.
>
> Fair enough. Is anybody working on a tree-wide sweep for this, like we've
> done for other things such as zero-length arrays? If so, I can start
> enforcing this in the arch code as well (I haven't been so far, even though
> I do run sparse on every commit).
>
> Anyway, I've dropped the last patch from the branch, and we can put a fix
> for the missing prototype on top.
>
Thanks Will, sorry for the trouble. Though I can send the fix for the
missing prototype right away, I would like to get my clang setup working
as an opportunity. clang-8 that I have is failing vanilla v5.7-rc6
when expanding arm_smccc_1_1_*
--
Regards,
Sudeep
_______________________________________________
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 v5 05/19] mtd: spi-nor: add support for DTR protocol
From: masonccyang @ 2020-05-21 9:24 UTC (permalink / raw)
To: Pratyush Yadav
Cc: Alexandre Belloni, Vignesh Raghavendra, Tudor Ambarus,
Richard Weinberger, Mark Brown, Sekhar Nori, linux-kernel,
linux-spi, Ludovic Desroches, Boris Brezillon, linux-mediatek,
Miquel Raynal, Matthias Brugger, linux-mtd, Pratyush Yadav,
linux-arm-kernel
In-Reply-To: <20200519142642.24131-6-p.yadav@ti.com>
Hi Pratyush,
> @@ -311,6 +313,7 @@ struct flash_info {
> * BP3 is bit 6 of status register.
> * Must be used with SPI_NOR_4BIT_BP.
> */
> +#define SPI_NOR_OCTAL_DTR_READ BIT(19) /* Flash supports octal DTR
Read. */
#define SPI_NOR_OCTAL_DTR_RDWR BIT(19) /* Support Octal DTR Read & Write
*/
more precisely and clearly ?
thanks,
Mason
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information
and/or personal data, which is protected by applicable laws. Please be
reminded that duplication, disclosure, distribution, or use of this e-mail
(and/or its attachments) or any part thereof is prohibited. If you receive
this e-mail in error, please notify us immediately and delete this mail as
well as its attachment(s) from your system. In addition, please be
informed that collection, processing, and/or use of personal data is
prohibited unless expressly permitted by personal data protection laws.
Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=====================================================================
============================================================================
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=====================================================================
_______________________________________________
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] iommu: arm-smmu-v3: Copy SMMU table for kdump kernel
From: Will Deacon @ 2020-05-21 9:23 UTC (permalink / raw)
To: Prabhakar Kushwaha
Cc: Ganapatrao Prabhakerrao Kulkarni, Marc Zyngier, Bhupesh Sharma,
kexec mailing list, Bjorn Helgaas, Prabhakar Kushwaha,
Robin Murphy, linux-arm-kernel
In-Reply-To: <CAJ2QiJLMKckbuAqJutAi_zUQqqaK5Mg_u5Q=gg-POSvmk8cT9g@mail.gmail.com>
On Tue, May 19, 2020 at 08:24:21AM +0530, Prabhakar Kushwaha wrote:
> On Mon, May 18, 2020 at 9:25 PM Will Deacon <will@kernel.org> wrote:
> > On Mon, May 11, 2020 at 07:46:06PM -0700, Prabhakar Kushwaha wrote:
> > > @@ -3272,6 +3281,23 @@ static int arm_smmu_init_l1_strtab(struct arm_smmu_device *smmu)
> > > return 0;
> > > }
> > >
> > > +static void arm_smmu_copy_table(struct arm_smmu_device *smmu,
> > > + struct arm_smmu_strtab_cfg *cfg, u32 size)
> > > +{
> > > + struct arm_smmu_strtab_cfg rdcfg;
> > > +
> > > + rdcfg.strtab_dma = readq_relaxed(smmu->base + ARM_SMMU_STRTAB_BASE);
> > > + rdcfg.strtab_base_cfg = readq_relaxed(smmu->base
> > > + + ARM_SMMU_STRTAB_BASE_CFG);
> > > +
> > > + rdcfg.strtab_dma &= STRTAB_BASE_ADDR_MASK;
> > > + rdcfg.strtab = memremap(rdcfg.strtab_dma, size, MEMREMAP_WB);
> > > +
> > > + memcpy_fromio(cfg->strtab, rdcfg.strtab, size);
> > > +
>
> this need a fix. It should be memcpy.
>
> > > + cfg->strtab_base_cfg = rdcfg.strtab_base_cfg;
> >
> > Sorry, but this is unacceptable. These things were allocated by the DMA API
> > so you can't just memcpy them around and hope for the best.
> >
>
> I was referring copy_context_table() in drivers/iommu/intel-iommu.c.
> here i see usage of memremap and memcpy to copy older iommu table.
> did I take wrong reference?
>
> What kind of issue you are foreseeing in using memcpy(). May be we can
> try to find a solution.
Well the thing might not be cache-coherent to start with...
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 0/7] firmware: smccc: Add basic SMCCC v1.2 + ARCH_SOC_ID support
From: Will Deacon @ 2020-05-21 9:17 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Rutland, Lorenzo Pieralisi, Catalin Marinas,
linux-kernel@vger.kernel.org, Steven Price, harb, Sudeep Holla,
Linux ARM
In-Reply-To: <CAK8P3a3dV0B26XE3oFQGTFf8EWV0AHoLudNtpSSB_t+pCfkOkQ@mail.gmail.com>
On Thu, May 21, 2020 at 11:06:23AM +0200, Arnd Bergmann wrote:
> On Thu, May 21, 2020 at 10:11 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
> > Indeed, it is also last patch in the series. However if Arnd is happy
> > with the sysfs names, we can move to generic code later without breaking
> > anything.
> >
> > We need not revert or drop it now. I will leave that to you or Arnd to
> > decide. Just that it may be too late to get acks for all the soc sysfs
> > drivers in time for v5.8
> >
> > I am fine if you want to drop the last patch.
>
> Ok, let's drop that patch then and make sure we do something that
> everyone is happy with later on. I'm already in favor of adding
> a more reliable soc_device instance based on this, but we need to
> be sure we don't screw up the contents of the attributes when we
> can't change them later.
>
> > > > >> drivers/firmware/smccc/smccc.c:14:13: warning: no previous prototype for function 'arm_smccc_version_init' [-Wmissing-prototypes]
> > > > void __init arm_smccc_version_init(u32 version, enum arm_smccc_conduit conduit)
> > > > ^
> > > > drivers/firmware/smccc/smccc.c:14:1: note: declare 'static' if the
> > > > function is not intended to be used outside of this translation unit
> > > > void __init arm_smccc_version_init(u32 version, enum arm_smccc_conduit conduit)
> > >
> > > I saw that when I applied the patches, but since the function is called from
> > > another compilation unit (psci/psci.o), I just ignored it as we have loads
> > > of these already and it only screams if you build with W=1.
> > >
> >
> > /me confused. Do you need the fix for this warning or you are happy to ignore?
>
> I want a fix for that, as I hope we can eventually turn this warning on by
> default and stop playing whack-a-mole when they come up. Most of these
> warnings are harmless, but occasionally the prototypes don't match exactly
> and cause real bugs depending on the configuration, and ensuring both
> sides include a common header file is an easy way to make it work
> more reliably.
>
> Note that the warning should come up for either W=1 or C=1, and I also
> think that
> new code should generally be written sparse-clean and have no warnings with
> 'make C=1' as a rule.
Fair enough. Is anybody working on a tree-wide sweep for this, like we've
done for other things such as zero-length arrays? If so, I can start
enforcing this in the arch code as well (I haven't been so far, even though
I do run sparse on every commit).
Anyway, I've dropped the last patch from the branch, and we can put a fix
for the missing prototype on top.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v15 02/11] dt-bindings: soc: Add MT8183 power dt-bindings
From: Weiyi Lu @ 2020-05-21 9:06 UTC (permalink / raw)
To: Enric Balletbo Serra, Matthias Brugger, Nicolas Boichat,
Rob Herring, Sascha Hauer
Cc: James Liao, Weiyi Lu, srv_heupstream, devicetree, linux-kernel,
Fan Chen, linux-mediatek, linux-arm-kernel
In-Reply-To: <1590051985-29149-1-git-send-email-weiyi.lu@mediatek.com>
Add power dt-bindings of MT8183 and introduces "BASIC" and
"SUBSYS" clock types in binding document.
The "BASIC" type is compatible to the original power control with
clock name [a-z]+[0-9]*, e.g. mm, vpu1.
The "SUBSYS" type is used for bus protection control with clock
name [a-z]+-[0-9]+, e.g. isp-0, cam-1.
And add an optional "mediatek,smi" property for phandle to smi-common
node.
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
---
.../devicetree/bindings/soc/mediatek/scpsys.txt | 21 ++++++++++++++---
include/dt-bindings/power/mt8183-power.h | 26 ++++++++++++++++++++++
2 files changed, 44 insertions(+), 3 deletions(-)
create mode 100644 include/dt-bindings/power/mt8183-power.h
diff --git a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
index 2bc3677..8e0b9f2 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
+++ b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
@@ -15,6 +15,7 @@ power/power-domain.yaml. It provides the power domains defined in
- include/dt-bindings/power/mt2701-power.h
- include/dt-bindings/power/mt2712-power.h
- include/dt-bindings/power/mt7622-power.h
+- include/dt-bindings/power/mt8183-power.h
Required properties:
- compatible: Should be one of:
@@ -27,12 +28,16 @@ Required properties:
- "mediatek,mt7623a-scpsys": For MT7623A SoC
- "mediatek,mt7629-scpsys", "mediatek,mt7622-scpsys": For MT7629 SoC
- "mediatek,mt8173-scpsys"
+ - "mediatek,mt8183-scpsys"
- #power-domain-cells: Must be 1
- reg: Address range of the SCPSYS unit
- infracfg: must contain a phandle to the infracfg controller
-- clock, clock-names: clocks according to the common clock binding.
- These are clocks which hardware needs to be
- enabled before enabling certain power domains.
+- clock, clock-names: Clocks according to the common clock binding.
+ Some SoCs have to groups of clocks.
+ BASIC clocks need to be enabled before enabling the
+ corresponding power domain.
+ SUBSYS clocks need to be enabled before releasing the
+ bus protection.
Required clocks for MT2701 or MT7623: "mm", "mfg", "ethif"
Required clocks for MT2712: "mm", "mfg", "venc", "jpgdec", "audio", "vdec"
Required clocks for MT6765: MUX: "mm", "mfg"
@@ -43,6 +48,15 @@ Required properties:
Required clocks for MT7622 or MT7629: "hif_sel"
Required clocks for MT7623A: "ethif"
Required clocks for MT8173: "mm", "mfg", "venc", "venc_lt"
+ Required clocks for MT8183: BASIC: "audio", "mfg", "mm", "cam", "isp",
+ "vpu", "vpu1", "vpu2", "vpu3"
+ SUBSYS: "mm-0", "mm-1", "mm-2", "mm-3",
+ "mm-4", "mm-5", "mm-6", "mm-7",
+ "mm-8", "mm-9", "isp-0", "isp-1",
+ "cam-0", "cam-1", "cam-2", "cam-3",
+ "cam-4", "cam-5", "cam-6", "vpu-0",
+ "vpu-1", "vpu-2", "vpu-3", "vpu-4",
+ "vpu-5"
Optional properties:
- vdec-supply: Power supply for the vdec power domain
@@ -55,6 +69,7 @@ Optional properties:
- mfg_async-supply: Power supply for the mfg_async power domain
- mfg_2d-supply: Power supply for the mfg_2d power domain
- mfg-supply: Power supply for the mfg power domain
+- mediatek,smi : A phandle to the smi_common node
Example:
diff --git a/include/dt-bindings/power/mt8183-power.h b/include/dt-bindings/power/mt8183-power.h
new file mode 100644
index 0000000..d1ab387
--- /dev/null
+++ b/include/dt-bindings/power/mt8183-power.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2020 MediaTek Inc.
+ * Author: Weiyi Lu <weiyi.lu@mediatek.com>
+ */
+
+#ifndef _DT_BINDINGS_POWER_MT8183_POWER_H
+#define _DT_BINDINGS_POWER_MT8183_POWER_H
+
+#define MT8183_POWER_DOMAIN_AUDIO 0
+#define MT8183_POWER_DOMAIN_CONN 1
+#define MT8183_POWER_DOMAIN_MFG_ASYNC 2
+#define MT8183_POWER_DOMAIN_MFG 3
+#define MT8183_POWER_DOMAIN_MFG_CORE0 4
+#define MT8183_POWER_DOMAIN_MFG_CORE1 5
+#define MT8183_POWER_DOMAIN_MFG_2D 6
+#define MT8183_POWER_DOMAIN_DISP 7
+#define MT8183_POWER_DOMAIN_CAM 8
+#define MT8183_POWER_DOMAIN_ISP 9
+#define MT8183_POWER_DOMAIN_VDEC 10
+#define MT8183_POWER_DOMAIN_VENC 11
+#define MT8183_POWER_DOMAIN_VPU_TOP 12
+#define MT8183_POWER_DOMAIN_VPU_CORE0 13
+#define MT8183_POWER_DOMAIN_VPU_CORE1 14
+
+#endif /* _DT_BINDINGS_POWER_MT8183_POWER_H */
--
1.8.1.1.dirty
_______________________________________________
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 v15 04/11] soc: mediatek: Remove infracfg misc driver support
From: Weiyi Lu @ 2020-05-21 9:06 UTC (permalink / raw)
To: Enric Balletbo Serra, Matthias Brugger, Nicolas Boichat,
Rob Herring, Sascha Hauer
Cc: James Liao, Weiyi Lu, srv_heupstream, devicetree, linux-kernel,
Fan Chen, linux-mediatek, linux-arm-kernel
In-Reply-To: <1590051985-29149-1-git-send-email-weiyi.lu@mediatek.com>
The functions provided by infracfg misc driver have no other user except
the scpsys driver so move those into scpsys driver directly.
And then, remove infracfg misc driver which is no longer being used.
BTW, in next patch, we're going to extend the bus protection functions
with more customized arguments.
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
drivers/soc/mediatek/Kconfig | 10 -----
drivers/soc/mediatek/Makefile | 1 -
drivers/soc/mediatek/mtk-infracfg.c | 79 -----------------------------------
drivers/soc/mediatek/mtk-scpsys.c | 66 +++++++++++++++++++++++++----
include/linux/soc/mediatek/infracfg.h | 39 -----------------
5 files changed, 57 insertions(+), 138 deletions(-)
delete mode 100644 drivers/soc/mediatek/mtk-infracfg.c
delete mode 100644 include/linux/soc/mediatek/infracfg.h
diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index 2114b56..f837b3c 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -10,21 +10,12 @@ config MTK_CMDQ
depends on ARCH_MEDIATEK || COMPILE_TEST
select MAILBOX
select MTK_CMDQ_MBOX
- select MTK_INFRACFG
help
Say yes here to add support for the MediaTek Command Queue (CMDQ)
driver. The CMDQ is used to help read/write registers with critical
time limitation, such as updating display configuration during the
vblank.
-config MTK_INFRACFG
- bool "MediaTek INFRACFG Support"
- select REGMAP
- help
- Say yes here to add support for the MediaTek INFRACFG controller. The
- INFRACFG controller contains various infrastructure registers not
- directly associated to any device.
-
config MTK_PMIC_WRAP
tristate "MediaTek PMIC Wrapper Support"
depends on RESET_CONTROLLER
@@ -38,7 +29,6 @@ config MTK_SCPSYS
bool "MediaTek SCPSYS Support"
default ARCH_MEDIATEK
select REGMAP
- select MTK_INFRACFG
select PM_GENERIC_DOMAINS if PM
help
Say yes here to add support for the MediaTek SCPSYS power domain
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index b017330..2b2c2537 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -1,5 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o
-obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
diff --git a/drivers/soc/mediatek/mtk-infracfg.c b/drivers/soc/mediatek/mtk-infracfg.c
deleted file mode 100644
index 341c7ac..0000000
--- a/drivers/soc/mediatek/mtk-infracfg.c
+++ /dev/null
@@ -1,79 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright (c) 2015 Pengutronix, Sascha Hauer <kernel@pengutronix.de>
- */
-
-#include <linux/export.h>
-#include <linux/jiffies.h>
-#include <linux/regmap.h>
-#include <linux/soc/mediatek/infracfg.h>
-#include <asm/processor.h>
-
-#define MTK_POLL_DELAY_US 10
-#define MTK_POLL_TIMEOUT (jiffies_to_usecs(HZ))
-
-#define INFRA_TOPAXI_PROTECTEN 0x0220
-#define INFRA_TOPAXI_PROTECTSTA1 0x0228
-#define INFRA_TOPAXI_PROTECTEN_SET 0x0260
-#define INFRA_TOPAXI_PROTECTEN_CLR 0x0264
-
-/**
- * mtk_infracfg_set_bus_protection - enable bus protection
- * @regmap: The infracfg regmap
- * @mask: The mask containing the protection bits to be enabled.
- * @reg_update: The boolean flag determines to set the protection bits
- * by regmap_update_bits with enable register(PROTECTEN) or
- * by regmap_write with set register(PROTECTEN_SET).
- *
- * This function enables the bus protection bits for disabled power
- * domains so that the system does not hang when some unit accesses the
- * bus while in power down.
- */
-int mtk_infracfg_set_bus_protection(struct regmap *infracfg, u32 mask,
- bool reg_update)
-{
- u32 val;
- int ret;
-
- if (reg_update)
- regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask,
- mask);
- else
- regmap_write(infracfg, INFRA_TOPAXI_PROTECTEN_SET, mask);
-
- ret = regmap_read_poll_timeout(infracfg, INFRA_TOPAXI_PROTECTSTA1,
- val, (val & mask) == mask,
- MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
-
- return ret;
-}
-
-/**
- * mtk_infracfg_clear_bus_protection - disable bus protection
- * @regmap: The infracfg regmap
- * @mask: The mask containing the protection bits to be disabled.
- * @reg_update: The boolean flag determines to clear the protection bits
- * by regmap_update_bits with enable register(PROTECTEN) or
- * by regmap_write with clear register(PROTECTEN_CLR).
- *
- * This function disables the bus protection bits previously enabled with
- * mtk_infracfg_set_bus_protection.
- */
-
-int mtk_infracfg_clear_bus_protection(struct regmap *infracfg, u32 mask,
- bool reg_update)
-{
- int ret;
- u32 val;
-
- if (reg_update)
- regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, 0);
- else
- regmap_write(infracfg, INFRA_TOPAXI_PROTECTEN_CLR, mask);
-
- ret = regmap_read_poll_timeout(infracfg, INFRA_TOPAXI_PROTECTSTA1,
- val, !(val & mask),
- MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
-
- return ret;
-}
diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
index c9c3cf7..b603af7 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -10,8 +10,8 @@
#include <linux/of_device.h>
#include <linux/platform_device.h>
#include <linux/pm_domain.h>
+#include <linux/regmap.h>
#include <linux/regulator/consumer.h>
-#include <linux/soc/mediatek/infracfg.h>
#include <dt-bindings/power/mt2701-power.h>
#include <dt-bindings/power/mt2712-power.h>
@@ -78,6 +78,29 @@
#define PWR_STATUS_HIF1 BIT(26) /* MT7622 */
#define PWR_STATUS_WB BIT(27) /* MT7622 */
+#define INFRA_TOPAXI_PROTECTEN 0x0220
+#define INFRA_TOPAXI_PROTECTSTA1 0x0228
+#define INFRA_TOPAXI_PROTECTEN_SET 0x0260
+#define INFRA_TOPAXI_PROTECTEN_CLR 0x0264
+
+#define MT2701_TOP_AXI_PROT_EN_MM_M0 BIT(1)
+#define MT2701_TOP_AXI_PROT_EN_CONN_M BIT(2)
+#define MT2701_TOP_AXI_PROT_EN_CONN_S BIT(8)
+
+#define MT7622_TOP_AXI_PROT_EN_ETHSYS (BIT(3) | BIT(17))
+#define MT7622_TOP_AXI_PROT_EN_HIF0 (BIT(24) | BIT(25))
+#define MT7622_TOP_AXI_PROT_EN_HIF1 (BIT(26) | BIT(27) | \
+ BIT(28))
+#define MT7622_TOP_AXI_PROT_EN_WB (BIT(2) | BIT(6) | \
+ BIT(7) | BIT(8))
+
+#define MT8173_TOP_AXI_PROT_EN_MM_M0 BIT(1)
+#define MT8173_TOP_AXI_PROT_EN_MM_M1 BIT(2)
+#define MT8173_TOP_AXI_PROT_EN_MFG_S BIT(14)
+#define MT8173_TOP_AXI_PROT_EN_MFG_M0 BIT(21)
+#define MT8173_TOP_AXI_PROT_EN_MFG_M1 BIT(22)
+#define MT8173_TOP_AXI_PROT_EN_MFG_SNOOP_OUT BIT(23)
+
#define MAX_CLKS 3
/**
@@ -251,25 +274,50 @@ static int scpsys_sram_disable(struct scp_domain *scpd, void __iomem *ctl_addr)
static int scpsys_bus_protect_enable(struct scp_domain *scpd)
{
struct scp *scp = scpd->scp;
+ struct regmap *infracfg = scp->infracfg;
+ u32 mask = scpd->data->bus_prot_mask;
+ bool reg_update = scp->bus_prot_reg_update;
+ u32 val;
+ int ret;
- if (!scpd->data->bus_prot_mask)
+ if (!mask)
return 0;
- return mtk_infracfg_set_bus_protection(scp->infracfg,
- scpd->data->bus_prot_mask,
- scp->bus_prot_reg_update);
+ if (reg_update)
+ regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask,
+ mask);
+ else
+ regmap_write(infracfg, INFRA_TOPAXI_PROTECTEN_SET, mask);
+
+ ret = regmap_read_poll_timeout(infracfg, INFRA_TOPAXI_PROTECTSTA1,
+ val, (val & mask) == mask,
+ MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
+
+ return ret;
}
static int scpsys_bus_protect_disable(struct scp_domain *scpd)
{
struct scp *scp = scpd->scp;
+ struct regmap *infracfg = scp->infracfg;
+ u32 mask = scpd->data->bus_prot_mask;
+ bool reg_update = scp->bus_prot_reg_update;
+ u32 val;
+ int ret;
- if (!scpd->data->bus_prot_mask)
+ if (!mask)
return 0;
- return mtk_infracfg_clear_bus_protection(scp->infracfg,
- scpd->data->bus_prot_mask,
- scp->bus_prot_reg_update);
+ if (reg_update)
+ regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, 0);
+ else
+ regmap_write(infracfg, INFRA_TOPAXI_PROTECTEN_CLR, mask);
+
+ ret = regmap_read_poll_timeout(infracfg, INFRA_TOPAXI_PROTECTSTA1,
+ val, !(val & mask),
+ MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
+
+ return ret;
}
static int scpsys_power_on(struct generic_pm_domain *genpd)
diff --git a/include/linux/soc/mediatek/infracfg.h b/include/linux/soc/mediatek/infracfg.h
deleted file mode 100644
index fd25f01..0000000
--- a/include/linux/soc/mediatek/infracfg.h
+++ /dev/null
@@ -1,39 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef __SOC_MEDIATEK_INFRACFG_H
-#define __SOC_MEDIATEK_INFRACFG_H
-
-#define MT8173_TOP_AXI_PROT_EN_MCI_M2 BIT(0)
-#define MT8173_TOP_AXI_PROT_EN_MM_M0 BIT(1)
-#define MT8173_TOP_AXI_PROT_EN_MM_M1 BIT(2)
-#define MT8173_TOP_AXI_PROT_EN_MMAPB_S BIT(6)
-#define MT8173_TOP_AXI_PROT_EN_L2C_M2 BIT(9)
-#define MT8173_TOP_AXI_PROT_EN_L2SS_SMI BIT(11)
-#define MT8173_TOP_AXI_PROT_EN_L2SS_ADD BIT(12)
-#define MT8173_TOP_AXI_PROT_EN_CCI_M2 BIT(13)
-#define MT8173_TOP_AXI_PROT_EN_MFG_S BIT(14)
-#define MT8173_TOP_AXI_PROT_EN_PERI_M0 BIT(15)
-#define MT8173_TOP_AXI_PROT_EN_PERI_M1 BIT(16)
-#define MT8173_TOP_AXI_PROT_EN_DEBUGSYS BIT(17)
-#define MT8173_TOP_AXI_PROT_EN_CQ_DMA BIT(18)
-#define MT8173_TOP_AXI_PROT_EN_GCPU BIT(19)
-#define MT8173_TOP_AXI_PROT_EN_IOMMU BIT(20)
-#define MT8173_TOP_AXI_PROT_EN_MFG_M0 BIT(21)
-#define MT8173_TOP_AXI_PROT_EN_MFG_M1 BIT(22)
-#define MT8173_TOP_AXI_PROT_EN_MFG_SNOOP_OUT BIT(23)
-
-#define MT2701_TOP_AXI_PROT_EN_MM_M0 BIT(1)
-#define MT2701_TOP_AXI_PROT_EN_CONN_M BIT(2)
-#define MT2701_TOP_AXI_PROT_EN_CONN_S BIT(8)
-
-#define MT7622_TOP_AXI_PROT_EN_ETHSYS (BIT(3) | BIT(17))
-#define MT7622_TOP_AXI_PROT_EN_HIF0 (BIT(24) | BIT(25))
-#define MT7622_TOP_AXI_PROT_EN_HIF1 (BIT(26) | BIT(27) | \
- BIT(28))
-#define MT7622_TOP_AXI_PROT_EN_WB (BIT(2) | BIT(6) | \
- BIT(7) | BIT(8))
-
-int mtk_infracfg_set_bus_protection(struct regmap *infracfg, u32 mask,
- bool reg_update);
-int mtk_infracfg_clear_bus_protection(struct regmap *infracfg, u32 mask,
- bool reg_update);
-#endif /* __SOC_MEDIATEK_INFRACFG_H */
--
1.8.1.1.dirty
_______________________________________________
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