* Re: [PATCH 0/3] STMFX power related fixes
From: Lee Jones @ 2020-05-26 7:27 UTC (permalink / raw)
To: Amelie DELAUNAY
Cc: linux-arm-kernel, linux-kernel, Alexandre Torgue, Maxime Coquelin,
linux-stm32
In-Reply-To: <f5b3df45-a01a-7cb6-c158-e6edc0117f0f@st.com>
On Mon, 25 May 2020, Amelie DELAUNAY wrote:
> Hi,
>
> Gentle reminder regarding this series sent one month ago.
Apologies Amelie, this fell through the gaps.
If this happens in the future just submit a [RESEND].
I'll take a look at this, this time however.
> On 4/22/20 11:08 AM, Amelie Delaunay wrote:
> > With suspend/resume tests on STM32MP157C-EV1 board, on which STMFX is used by
> > several devices, some errors could occurred: -6 when trying to restore STMFX
> > registers, spurious interrupts after disabling supply...
> > This patchset fixes all these issues and cleans IRQ init error path.
> >
> > Amelie Delaunay (3):
> > mfd: stmfx: reset chip on resume as supply was disabled
> > mfd: stmfx: fix stmfx_irq_init error path
> > mfd: stmfx: disable irq in suspend to avoid spurious interrupt
> >
> > drivers/mfd/stmfx.c | 22 ++++++++++++++++++++--
> > include/linux/mfd/stmfx.h | 1 +
> > 2 files changed, 21 insertions(+), 2 deletions(-)
> >
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
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 03/16] mfd: mfd-core: match device tree node against reg property
From: Lee Jones @ 2020-05-26 7:24 UTC (permalink / raw)
To: Michael Walle
Cc: linux-pwm, Linus Walleij, Thierry Reding, linux-watchdog,
Andy Shevchenko, Marc Zyngier, Bartosz Golaszewski,
Uwe Kleine-König, Guenter Roeck, devicetree, Jean Delvare,
Jason Cooper, linux-gpio, Rob Herring, Thomas Gleixner,
Wim Van Sebroeck, linux-arm-kernel, linux-hwmon,
Greg Kroah-Hartman, linux-kernel, Li Yang, Mark Brown, Shawn Guo
In-Reply-To: <159e68b4ce53630ef906b2fcbca925bd@walle.cc>
On Mon, 25 May 2020, Michael Walle wrote:
> Am 2020-05-15 12:28, schrieb Lee Jones:
> > On Thu, 30 Apr 2020, Michael Walle wrote:
> >
> > > Hi Lee,
> > >
> > > Am 2020-04-23 19:45, schrieb Michael Walle:
> > > > There might be multiple children with the device tree compatible, for
> > > > example if a MFD has multiple instances of the same function. In this
> > > > case only the first is matched and the other children get a wrong
> > > > of_node reference.
> > > > Add a new option to match also against the unit address of the child
> > > > node. Additonally, a new helper OF_MFD_CELL_REG is added.
> > >
> > >
> > > Do you think this is feasible? I guess this is the biggest uncertainty
> > > for me at the moment in this patch series.
> >
> > I think it sounds fine in principle. So long as it doesn't change the
> > existing behaviour when of_reg isn't set.
> >
> > > > Signed-off-by: Michael Walle <michael@walle.cc>
> > > > ---
> > > > drivers/mfd/mfd-core.c | 29 ++++++++++++++++++++---------
> > > > include/linux/mfd/core.h | 26 ++++++++++++++++++++------
> > > > 2 files changed, 40 insertions(+), 15 deletions(-)
[...]
> > > > diff --git a/include/linux/mfd/core.h b/include/linux/mfd/core.h
> > > > index d01d1299e49d..c2c0ad6b14f3 100644
> > > > --- a/include/linux/mfd/core.h
> > > > +++ b/include/linux/mfd/core.h
> > > > @@ -13,8 +13,11 @@
> > > > #include <linux/platform_device.h>
> > > >
> > > > #define MFD_RES_SIZE(arr) (sizeof(arr) / sizeof(struct resource))
> > > > +#define MFD_OF_REG_VALID BIT(31)
> >
> > What about 64bit platforms?
>
> The idea was to have this as a logical number. I.e. for now you may only
> have one subdevice per unique compatible string. In fact, if you have a
> look at the ab8500.c, there are multiple "stericsson,ab8500-pwm"
> subdevices. But there is only one DT node for all three of it. I guess
> this works as long as you don't use phandles to reference the pwm node
> in the device tree. Or you don't want to use device tree properties
> per subdevice (for example the "timeout-sec" of a watchdog device).
>
> So to circumvent this, I thought of having the unit-address (and thus
> the "reg" property) to differentiate between multiple subdevices. Now
> there is one special case for me: this board management controller
> might be upgradable and it might change internally. Thus I came up
> with that logical numbering of subdevices. Rob doesn't seem to be a
> fan of that, though. Therefore, having bit 31 as a valid indicator
> leaves you with 2^31 logical devices, which should be enough ;)
>
> Rob proposed to have the internal offset as the unit-address. But
> in that case I can also use devm_of_platform_populate() and don't
> need the OF_MFD_CELL_REG; I'd just parse the reg offset in each
> individual subdevice driver. But like I said, I wanted to keep the
> internal offsets out of the device tree.
Oh, I see what you're doing.
So you're adding an arbitrary ID to the device's reg property in DT?
How is this not a hack?
Why don't you use the full address for identification?
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Microchip USB2642 Hub not resuming from USB autosuspend
From: Martin Kepplinger @ 2020-05-26 7:04 UTC (permalink / raw)
To: mathias.nyman@intel.com, gregkh@linuxfoundation.org, Felipe Balbi,
p.zabel@pengutronix.de, nicolas.ferre, ludovic.desroches,
cristian.birsan, iain.galloway
Cc: linux-usb@vger.kernel.org, kernel@puri.sm,
linux-arm-kernel@lists.infradead.org
hi all,
our Librem 5 includes the microchip USB2642 hub with
integrated/connected SD cardcreader (and we connect the baseband modem
to it): https://www.microchip.com/wwwproducts/en/USB2642
When we remove the (integrated) SD cardreader entirely (in sysfs), the
Hub suspends as long as the modem doesn't need a connection. But then
the modem fails to *resume* the Hub. Linux xhci host times out and dies
during resuming, which leaves a system without the Hub entirely. You can
see some logs and tests here
https://source.puri.sm/Librem5/linux-next/issues/170#note_89808 (when
scrolling down).
Microchip says the their product has the following bug which results in
our problem:
https://microchipsupport.force.com/s/article/Device-attached-to-Hub-Downstream-Facing-Port-does-not-Resume-from-Suspend
(that may or may not be the real and only reason for our problem)
That issue suggests working around it in the HC by somehow
sending "HS SOF as soon as possible after the HS RESUME EOP".
We use imx8mq and the dwc3 driver for the designware USB hardware that
NXP documents in chapter 11.1.3 of the reference manual:
https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/i-mx-applications-processors/i-mx-8-processors/i-mx-8m-family-armcortex-a53-cortex-m4-audio-voice-video:i.MX8M?tab=Documentation_Tab
What can we try to change in dwc3 or xhci drivers in order to achieve
sending SOF earlier after resume?
What else that I don't currently think of could lead to the USB
suspend/resume problem here?
I'm happy for any hint, question or thought about this and hope that
this is useful for others too.
thanks,
martin
p.s.: A follow-up for Microchip: The Hub doesn't suspend when the SD
cardreader is connected *without* and SD card inserted (as described
above, we remove the cardreader for testing here). What could cause this?
_______________________________________________
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 6/6] dt-bindings: drm: bridge: adi, adv7511.txt: convert to yaml
From: Geert Uytterhoeven @ 2020-05-26 7:03 UTC (permalink / raw)
To: Laurent Pinchart
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Geert Uytterhoeven, Wei Xu, Rob Herring, Collabora Kernel ML,
Ricardo Cañuelo, Linux ARM
In-Reply-To: <20200526014444.GB6179@pendragon.ideasonboard.com>
Hi Laurent,
On Tue, May 26, 2020 at 3:44 AM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Mon, May 25, 2020 at 09:43:35AM +0200, Ricardo Cañuelo wrote:
> > On jue 14-05-2020 18:22:39, Laurent Pinchart wrote:
> > > > If we want to be more strict and require the definition of all the
> > > > supplies, there will be many more DTs changes in the series, and I'm not
> > > > sure I'll be able to do that in a reasonable amount of time. I'm looking
> > > > at them and it's not always clear which regulators to use or if they are
> > > > even defined.
> > >
> > > We can decouple the two though (I think). The bindings should reflect
> > > what we consider right, and the dts files could be fixed on top.
> >
> > Do you have a suggestion on how to do this? If we decouple the two
> > tasks most of the work would be searching for DTs to fix and finding a
> > way to fix each one of them, and unless I do this _before_ the binding
> > conversion I'll get a lot of dtbs_check errors.
>
> Rob should answer this question as it will be his decision, but I've
> personally never considered non-compliant DT sources to be an obstacle
> to bindings conversion to YAML. The DT sources should be fixed, but I
> don't see it as a prerequisite (although it's a good practice).
I do my best to avoid introducing regressions when the binding conversions
go upstream.
FTR, hence patches 1-3 are already in v5.7-rc7.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv3 0/2] Add support for replicators which loses context on clock removal
From: Sai Prakash Ranjan @ 2020-05-26 7:01 UTC (permalink / raw)
To: Mathieu Poirier, devicetree, Rob Herring
Cc: devicetree-owner, Suzuki K Poulose, linux-arm-msm, linux-kernel,
Stephen Boyd, linux-arm-kernel, Mike Leach
In-Reply-To: <20200525161553.GA31527@xps15>
Hi Mathieu,
On 2020-05-25 21:45, Mathieu Poirier wrote:
> Hi Sai,
>
> On Sat, May 23, 2020 at 12:06:50AM +0530, Sai Prakash Ranjan wrote:
>> This series is mainly to add support for replicators
>> which lose context on removing AMBA clock like on SC7180
>> SoC where replicator in AOSS domain loses context.
>>
>
> I am good with this set but need a reviewed-by on the DT binding before
> I can
> add it to my tree. The same goes for your other set[1].
>
Sure, let's wait for an ack from Rob and thanks for the reviews.
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
_______________________________________________
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 00/38] DRM: fix struct sg_table nents vs. orig_nents misuse
From: Marek Szyprowski @ 2020-05-26 7:01 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Bartlomiej Zolnierkiewicz, David Airlie, linux-kernel, dri-devel,
linaro-mm-sig, iommu, Daniel Vetter, Robin Murphy,
linux-arm-kernel
In-Reply-To: <20200513134741.GA12712@lst.de>
Hi
On 13.05.2020 15:47, Christoph Hellwig wrote:
> I've pushed out a branch with the first three patches here:
>
> git://git.infradead.org/users/hch/dma-mapping.git dma-sg_table-helper
>
> Gitweb:
>
> http://git.infradead.org/users/hch/dma-mapping.git/shortlog/refs/heads/dma-sg_table-helper
>
> and merged it into the dma-mapping for-next tree. Unless someone shouts
> the branch should be considered immutable in 24 hours.
David & Daniel: could you merge all the DRM related changes on top of
the provided branch? Merging those changes separately would take a lots
of time because of the dependencies on the sgtable helpers and changes
in the DRM core.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
_______________________________________________
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 1/6] arm64: Detect the ARMv8.4 TTL feature
From: Zhenyu Ye @ 2020-05-26 6:40 UTC (permalink / raw)
To: Anshuman Khandual, catalin.marinas, peterz, mark.rutland, will,
aneesh.kumar, akpm, npiggin, arnd, rostedt, maz, suzuki.poulose,
tglx, yuzhao, Dave.Martin, steven.price, broonie, guohanjun
Cc: linux-arch, linux-kernel, xiexiangyou, zhangshaokun, linux-mm,
arm, prime.zeng, kuhn.chenqun, linux-arm-kernel
In-Reply-To: <c6b6eb07-2606-9fc0-280a-e53b81a6491c@arm.com>
Hi Anshuman,
On 2020/5/26 10:39, Anshuman Khandual wrote:
> This patch (https://patchwork.kernel.org/patch/11557359/) is adding some
> more ID_AA64MMFR2 features including the TTL. I am going to respin parts
> of the V4 series patches along with the above mentioned patch. So please
> rebase this series accordingly, probably on latest next.
>
I noticed that some patches of your series have been merged into arm64
tree (for-next/cpufeature), such as TLB range, but this one not. Why?
BTW, this patch is provided by Marc in his NV series [1], maybe you
should also let him know.
I will rebase my series after your patch is merged.
[1] https://lore.kernel.org/linux-arm-kernel/d6032191-ba0e-82a4-4dde-11beef369a11@arm.com/
Thanks,
Zhenyu
_______________________________________________
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 4/7] KVM: PPC: clean up redundant 'kvm_run' parameters
From: Paul Mackerras @ 2020-05-26 5:49 UTC (permalink / raw)
To: Tianjia Zhang
Cc: wanpengli, kvm, david, benh, heiko.carstens, peterx, linux-mips,
hpa, kvmarm, linux-s390, frankja, chenhuacai, maz, joro, x86,
borntraeger, mingo, julien.thierry.kdev, thuth, gor,
suzuki.poulose, kvm-ppc, bp, tglx, linux-arm-kernel, jmattson,
tsbogend, cohuck, christoffer.dall, sean.j.christopherson,
linux-kernel, james.morse, mpe, pbonzini, vkuznets, linuxppc-dev
In-Reply-To: <20200427043514.16144-5-tianjia.zhang@linux.alibaba.com>
On Mon, Apr 27, 2020 at 12:35:11PM +0800, Tianjia Zhang wrote:
> In the current kvm version, 'kvm_run' has been included in the 'kvm_vcpu'
> structure. For historical reasons, many kvm-related function parameters
> retain the 'kvm_run' and 'kvm_vcpu' parameters at the same time. This
> patch does a unified cleanup of these remaining redundant parameters.
>
> Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
This looks OK, though possibly a little larger than it needs to be
because of variable name changes (kvm_run -> run) that aren't strictly
necessary.
Reviewed-by: Paul Mackerras <paulus@ozlabs.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 5/7] KVM: PPC: clean up redundant kvm_run parameters in assembly
From: Paul Mackerras @ 2020-05-26 5:59 UTC (permalink / raw)
To: Tianjia Zhang
Cc: wanpengli, kvm, david, benh, heiko.carstens, peterx, linux-mips,
hpa, kvmarm, linux-s390, frankja, chenhuacai, maz, joro, x86,
borntraeger, mingo, julien.thierry.kdev, thuth, gor,
suzuki.poulose, kvm-ppc, bp, tglx, linux-arm-kernel, jmattson,
tsbogend, cohuck, christoffer.dall, sean.j.christopherson,
linux-kernel, james.morse, mpe, pbonzini, vkuznets, linuxppc-dev
In-Reply-To: <20200427043514.16144-6-tianjia.zhang@linux.alibaba.com>
On Mon, Apr 27, 2020 at 12:35:12PM +0800, Tianjia Zhang wrote:
> In the current kvm version, 'kvm_run' has been included in the 'kvm_vcpu'
> structure. For historical reasons, many kvm-related function parameters
> retain the 'kvm_run' and 'kvm_vcpu' parameters at the same time. This
> patch does a unified cleanup of these remaining redundant parameters.
Some of these changes don't look completely correct to me, see below.
If you're expecting these patches to go through my tree, I can fix up
the patch and commit it (with you as author), noting the changes I
made in the commit message. Do you want me to do that?
> diff --git a/arch/powerpc/kvm/book3s_interrupts.S b/arch/powerpc/kvm/book3s_interrupts.S
> index f7ad99d972ce..0eff749d8027 100644
> --- a/arch/powerpc/kvm/book3s_interrupts.S
> +++ b/arch/powerpc/kvm/book3s_interrupts.S
> @@ -55,8 +55,7 @@
> ****************************************************************************/
>
> /* Registers:
> - * r3: kvm_run pointer
> - * r4: vcpu pointer
> + * r3: vcpu pointer
> */
> _GLOBAL(__kvmppc_vcpu_run)
>
> @@ -68,8 +67,8 @@ kvm_start_entry:
> /* Save host state to the stack */
> PPC_STLU r1, -SWITCH_FRAME_SIZE(r1)
>
> - /* Save r3 (kvm_run) and r4 (vcpu) */
> - SAVE_2GPRS(3, r1)
> + /* Save r3 (vcpu) */
> + SAVE_GPR(3, r1)
>
> /* Save non-volatile registers (r14 - r31) */
> SAVE_NVGPRS(r1)
> @@ -82,11 +81,11 @@ kvm_start_entry:
> PPC_STL r0, _LINK(r1)
>
> /* Load non-volatile guest state from the vcpu */
> - VCPU_LOAD_NVGPRS(r4)
> + VCPU_LOAD_NVGPRS(r3)
>
> kvm_start_lightweight:
> /* Copy registers into shadow vcpu so we can access them in real mode */
> - mr r3, r4
> + mr r4, r3
This mr doesn't seem necessary.
> bl FUNC(kvmppc_copy_to_svcpu)
> nop
> REST_GPR(4, r1)
This should be loading r4 from GPR3(r1), not GPR4(r1) - which is what
REST_GPR(4, r1) will do.
Then, in the file but not in the patch context, there is this line:
PPC_LL r3, GPR4(r1) /* vcpu pointer */
where once again GPR4 needs to be GPR3.
> @@ -191,10 +190,10 @@ after_sprg3_load:
> PPC_STL r31, VCPU_GPR(R31)(r7)
>
> /* Pass the exit number as 3rd argument to kvmppc_handle_exit */
The comment should be modified to say "2nd" instead of "3rd",
otherwise it is confusing.
The rest of the patch looks OK.
Paul.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] coresight: Use devm_kcalloc() in coresight_alloc_conns()
From: Xu Wang @ 2020-05-26 5:52 UTC (permalink / raw)
To: mathieu.poirier, suzuki.poulose, mike.leach, alexander.shishkin
Cc: linux-kernel, linux-arm-kernel
A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus use the corresponding function "devm_kcalloc".
Signed-off-by: Xu Wang <vulab@iscas.ac.cn>
---
drivers/hwtracing/coresight/coresight-platform.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-platform.c b/drivers/hwtracing/coresight/coresight-platform.c
index 43418a2126ff..6720049409f3 100644
--- a/drivers/hwtracing/coresight/coresight-platform.c
+++ b/drivers/hwtracing/coresight/coresight-platform.c
@@ -27,9 +27,8 @@ static int coresight_alloc_conns(struct device *dev,
struct coresight_platform_data *pdata)
{
if (pdata->nr_outport) {
- pdata->conns = devm_kzalloc(dev, pdata->nr_outport *
- sizeof(*pdata->conns),
- GFP_KERNEL);
+ pdata->conns = devm_kcalloc(dev, pdata->nr_outport,
+ sizeof(*pdata->conns), GFP_KERNEL);
if (!pdata->conns)
return -ENOMEM;
}
--
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: [PATCH v4 3/7] KVM: PPC: Remove redundant kvm_run from vcpu_arch
From: Paul Mackerras @ 2020-05-26 4:36 UTC (permalink / raw)
To: Tianjia Zhang
Cc: wanpengli, kvm, david, benh, heiko.carstens, peterx, linux-mips,
hpa, kvmarm, linux-s390, frankja, chenhuacai, maz, joro, x86,
borntraeger, mingo, julien.thierry.kdev, thuth, gor,
suzuki.poulose, kvm-ppc, bp, tglx, linux-arm-kernel, jmattson,
tsbogend, cohuck, christoffer.dall, sean.j.christopherson,
linux-kernel, james.morse, mpe, pbonzini, vkuznets, linuxppc-dev
In-Reply-To: <20200427043514.16144-4-tianjia.zhang@linux.alibaba.com>
On Mon, Apr 27, 2020 at 12:35:10PM +0800, Tianjia Zhang wrote:
> The 'kvm_run' field already exists in the 'vcpu' structure, which
> is the same structure as the 'kvm_run' in the 'vcpu_arch' and
> should be deleted.
>
> Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
This looks fine.
I assume each architecture sub-maintainer is taking the relevant
patches from this series via their tree - is that right?
Reviewed-by: Paul Mackerras <paulus@ozlabs.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH][V3] arm64: perf: Get the wrong PC value in REGS_ABI_32 mode
From: Jiping Ma @ 2020-05-26 2:46 UTC (permalink / raw)
To: will.deacon, paul.gortmaker, mark.rutland, catalin.marinas,
bruce.ashfield, yue.tao
Cc: zhe.he, linux-kernel, linux-arm-kernel
In-Reply-To: <1589165527-188401-1-git-send-email-jiping.ma2@windriver.com>
Hi, Will
Please help to review the change.
Thanks,
Jiping
On 05/11/2020 10:52 AM, Jiping Ma wrote:
> Modified the patch subject and the change description.
>
> PC value is get from regs[15] in REGS_ABI_32 mode, but correct PC
> is regs->pc(regs[PERF_REG_ARM64_PC]) in arm64 kernel, which caused
> that perf can not parser the backtrace of app with dwarf mode in the
> 32bit system and 64bit kernel.
>
> Signed-off-by: Jiping Ma <jiping.ma2@windriver.com>
> ---
> arch/arm64/kernel/perf_regs.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm64/kernel/perf_regs.c b/arch/arm64/kernel/perf_regs.c
> index 0bbac61..0ef2880 100644
> --- a/arch/arm64/kernel/perf_regs.c
> +++ b/arch/arm64/kernel/perf_regs.c
> @@ -32,6 +32,10 @@ u64 perf_reg_value(struct pt_regs *regs, int idx)
> if ((u32)idx == PERF_REG_ARM64_PC)
> return regs->pc;
>
> + if (perf_reg_abi(current) == PERF_SAMPLE_REGS_ABI_32
> + && idx == 15)
> + return regs->pc;
> +
> return regs->regs[idx];
> }
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [EXT] Re: [PATCH] arm64: dts: ls1028a: add one more thermal zone support
From: Andy Tang @ 2020-05-26 2:45 UTC (permalink / raw)
To: Daniel Lezcano, shawnguo@kernel.org, robh+dt@kernel.org,
mark.rutland@arm.com, catalin.marinas@arm.com,
will.deacon@arm.com
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <bdfd7018-aed8-ddbe-8bd2-2fa834013218@linaro.org>
-----Original Message-----
From: Daniel Lezcano <daniel.lezcano@linaro.org>
Sent: 2020年5月25日 19:08
To: Andy Tang <andy.tang@nxp.com>; shawnguo@kernel.org; robh+dt@kernel.org; mark.rutland@arm.com; catalin.marinas@arm.com; will.deacon@arm.com
Cc: devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org
Subject: [EXT] Re: [PATCH] arm64: dts: ls1028a: add one more thermal zone support
Caution: EXT Email
On 25/05/2020 09:38, Yuantian Tang wrote:
> There are 2 thermal zones in ls1028a soc. Current dts only includes
> one. This patch adds the other thermal zone node in dts to enable it.
For my personal information, is there a cooling device for the DDR?
A: There is only one cooling device which is used by core-cluster sensor zone.
So there is no cooling device for DDR.
BR,
Andy
> Signed-off-by: Yuantian Tang <andy.tang@nxp.com>
> ---
> .../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 22
> ++++++++++++++++++-
> 1 file changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> index 055f114cf848..bc6f0c0f85da 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> @@ -129,11 +129,31 @@
> };
>
> thermal-zones {
> - core-cluster {
> + ddr-controller {
> polling-delay-passive = <1000>;
> polling-delay = <5000>;
> thermal-sensors = <&tmu 0>;
>
> + trips {
> + ddr-ctrler-alert {
> + temperature = <85000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> +
> + ddr-ctrler-crit {
> + temperature = <95000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + };
> +
> + core-cluster {
> + polling-delay-passive = <1000>;
> + polling-delay = <5000>;
> + thermal-sensors = <&tmu 1>;
> +
> trips {
> core_cluster_alert: core-cluster-alert {
> temperature = <85000>;
>
--
<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linaro.org%2F&data=02%7C01%7Candy.tang%40nxp.com%7Cfb12ed47db3c4912bf1b08d8009be7d0%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637260016892509132&sdata=WUnbHs3O1yLfoRZ2usPXAu7EGBoSL7vypnmrhTGHaGI%3D&reserved=0> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.facebook.com%2Fpages%2FLinaro&data=02%7C01%7Candy.tang%40nxp.com%7Cfb12ed47db3c4912bf1b08d8009be7d0%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637260016892509132&sdata=W4k8Vs3wVVvfeGN4xVxKgBl3mG2j%2FjMJj07NEAqpAck%3D&reserved=0> Facebook | <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftwitter.com%2F%23!%2Flinaroorg&data=02%7C01%7Candy.tang%40nxp.com%7Cfb12ed47db3c4912bf1b08d8009be7d0%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637260016892509132&sdata=OeFLPA0lZHuvGkm1OuT38PxAUpLMsr7fBXEBkEGWXc8%3D&reserved=0> Twitter | <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linaro.org%2Flinaro-blog%2F&data=02%7C01%7Candy.tang%40nxp.com%7Cfb12ed47db3c4912bf1b08d8009be7d0%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637260016892509132&sdata=aYR%2FaUzcFxsMDG9QaH0Ge7AKg0kJniSOSPE6fXoJpzw%3D&reserved=0> Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1] clk: mediatek: assign the initial value to clk_init_data of mtk_mux
From: Weiyi Lu @ 2020-05-26 2:43 UTC (permalink / raw)
To: Matthias Brugger
Cc: James Liao, Nicolas Boichat, srv_heupstream, Stephen Boyd,
linux-kernel, stable, Fan Chen, linux-mediatek, Owen Chen,
linux-clk, linux-arm-kernel
In-Reply-To: <1abb3571-75ad-10d8-ff62-17be270b5b71@gmail.com>
On Mon, 2020-05-25 at 11:08 +0200, Matthias Brugger wrote:
>
> On 25/05/2020 08:41, Weiyi Lu wrote:
> > It'd be dangerous when struct clk_core have new memebers.
> > Add the missing initial value to clk_init_data.
> >
>
> Sorry I don't really understand this commit message, can please explain.
> In any case if this is a problem, then we probably we should fix it for all drivers.
> Apart from drivers/clk/mediatek/clk-cpumux.c
>
Actually, we were looking into an android kernel patch "ANDROID: GKI:
clk: Add support for voltage voting" [1]
In this patch, there adds a new member struct clk_vdd_class *vdd_class;
in struct clk_init_data and struct clk_core
And then in clk_register(...)
core->vdd_class = hw->init->vdd_class;
In many clock APIs, it will check the core->vdd_class to select the
correct control flow.
So, if we don't assign an initial value to clk_init_data of mtk_mux
clock type, something might go wrong. And assigning an initial value
might be the easiest and good way to avoid such problem if any new clock
support added in the future.
[1] https://android-review.googlesource.com/c/kernel/common/+/1278046
> It's a widely used pattern:
> $ git grep "struct clk_init_data init;"| wc -l
> 235
>
> Regards,
> Matthias
>
> > Fixes: a3ae549917f1 ("clk: mediatek: Add new clkmux register API")
> > Cc: <stable@vger.kernel.org>
> > Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
> > ---
> > drivers/clk/mediatek/clk-mux.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/clk/mediatek/clk-mux.c b/drivers/clk/mediatek/clk-mux.c
> > index 76f9cd0..14e127e 100644
> > --- a/drivers/clk/mediatek/clk-mux.c
> > +++ b/drivers/clk/mediatek/clk-mux.c
> > @@ -160,7 +160,7 @@ struct clk *mtk_clk_register_mux(const struct mtk_mux *mux,
> > spinlock_t *lock)
> > {
> > struct mtk_clk_mux *clk_mux;
> > - struct clk_init_data init;
> > + struct clk_init_data init = {};
> > struct clk *clk;
> >
> > clk_mux = kzalloc(sizeof(*clk_mux), GFP_KERNEL);
> >
_______________________________________________
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 1/6] arm64: Detect the ARMv8.4 TTL feature
From: Anshuman Khandual @ 2020-05-26 2:39 UTC (permalink / raw)
To: Zhenyu Ye, catalin.marinas, peterz, mark.rutland, will,
aneesh.kumar, akpm, npiggin, arnd, rostedt, maz, suzuki.poulose,
tglx, yuzhao, Dave.Martin, steven.price, broonie, guohanjun
Cc: linux-arch, linux-kernel, xiexiangyou, zhangshaokun, linux-mm,
arm, prime.zeng, kuhn.chenqun, linux-arm-kernel
In-Reply-To: <20200525125300.794-2-yezhenyu2@huawei.com>
Hello Zhenyu,
On 05/25/2020 06:22 PM, Zhenyu Ye wrote:
> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> index c4ac0ac25a00..477d84ba1056 100644
> --- a/arch/arm64/include/asm/sysreg.h
> +++ b/arch/arm64/include/asm/sysreg.h
> @@ -725,6 +725,7 @@
>
> /* id_aa64mmfr2 */
> #define ID_AA64MMFR2_E0PD_SHIFT 60
> +#define ID_AA64MMFR2_TTL_SHIFT 48
> #define ID_AA64MMFR2_FWB_SHIFT 40
> #define ID_AA64MMFR2_AT_SHIFT 32
> #define ID_AA64MMFR2_LVA_SHIFT 16
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 9fac745aa7bb..d993dc6dc7d5 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -244,6 +244,7 @@ static const struct arm64_ftr_bits ftr_id_aa64mmfr1[] = {
>
> static const struct arm64_ftr_bits ftr_id_aa64mmfr2[] = {
> ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR2_E0PD_SHIFT, 4, 0),
> + ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR2_TTL_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR2_FWB_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR2_AT_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR2_LVA_SHIFT, 4, 0),
> @@ -1622,6 +1623,16 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
> .matches = has_cpuid_feature,
> .cpu_enable = cpu_has_fwb,
> },
This patch (https://patchwork.kernel.org/patch/11557359/) is adding some
more ID_AA64MMFR2 features including the TTL. I am going to respin parts
of the V4 series patches along with the above mentioned patch. So please
rebase this series accordingly, probably on latest next.
- Anshuman
_______________________________________________
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 v8 0/5] support reserving crashkernel above 4G on arm64 kdump
From: chenzhou @ 2020-05-26 2:28 UTC (permalink / raw)
To: Baoquan He
Cc: horms, John.p.donnelly, arnd, will, devicetree, catalin.marinas,
linux-doc, kexec, linux-kernel, robh+dt, mingo, guohanjun, tglx,
pkushwaha, dyoung, linux-arm-kernel
In-Reply-To: <20200526014242.GF20045@MiWiFi-R3L-srv>
Hi Baoquan,
Thanks for your suggestions.
You are right, some details should be made in the commit log.
Thanks,
Chen Zhou
On 2020/5/26 9:42, Baoquan He wrote:
> On 05/21/20 at 05:38pm, Chen Zhou wrote:
>> 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.
> OK, moving x86 CRASH_ALIGN to 2M is suggested by Dave. Because
> CONFIG_PHYSICAL_ALIGN can be selected from 2M to 16M. So 2M seems good.
> But, anyway, we should tell the reason why it need be changed in commit
> log.
>
>
> arch/x86/Kconfig:
> config PHYSICAL_ALIGN
> hex "Alignment value to which kernel should be aligned"
> default "0x200000"
> range 0x2000 0x1000000 if X86_32
> range 0x200000 0x1000000 if X86_64
>
>> - 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.
> And the crashkernel=X,high being deleted need be told too. Otherwise
> people reading the commit have to check why themselves. I didn't follow
> the old version, can't see why ,high can't be specified explicitly.
>
>> - 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
>>
>>
>> _______________________________________________
>> kexec mailing list
>> kexec@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec
>>
>
> .
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 0/7] kvm: arm64: Support stage2 hardware DBM
From: zhukeqian @ 2020-05-26 2:08 UTC (permalink / raw)
To: Marc Zyngier
Cc: Andrew Morton, kvm, Suzuki K Poulose, Catalin Marinas,
linux-kernel, Sean Christopherson, Alexios Zavras, zhengxiang9,
Mark Brown, James Morse, Julien Thierry, wanghaibin.wang,
Thomas Gleixner, Will Deacon, kvmarm, linux-arm-kernel
In-Reply-To: <4b8a939172395bf38e581634abecf925@kernel.org>
Hi Marc,
On 2020/5/25 23:44, Marc Zyngier wrote:
> On 2020-05-25 12:23, Keqian Zhu wrote:
>> This patch series add support for stage2 hardware DBM, and it is only
>> used for dirty log for now.
>>
>> It works well under some migration test cases, including VM with 4K
>> pages or 2M THP. I checked the SHA256 hash digest of all memory and
>> they keep same for source VM and destination VM, which means no dirty
>> pages is missed under hardware DBM.
>>
>> However, there are some known issues not solved.
>>
>> 1. Some mechanisms that rely on "write permission fault" become invalid,
>> such as kvm_set_pfn_dirty and "mmap page sharing".
>>
>> kvm_set_pfn_dirty is called in user_mem_abort when guest issues write
>> fault. This guarantees physical page will not be dropped directly when
>> host kernel recycle memory. After using hardware dirty management, we
>> have no chance to call kvm_set_pfn_dirty.
>
> Then you will end-up with memory corruption under memory pressure.
> This also breaks things like CoW, which we depend on.
>
Yes, these problems looks knotty. But I think x86 PML support will face these
problems too. I believe there must be some methods to solve them.
>>
>> For "mmap page sharing" mechanism, host kernel will allocate a new
>> physical page when guest writes a page that is shared with other page
>> table entries. After using hardware dirty management, we have no chance
>> to do this too.
>>
>> I need to do some survey on how stage1 hardware DBM solve these problems.
>> It helps if anyone can figure it out.
>>
>> 2. Page Table Modification Races: Though I have found and solved some data
>> races when kernel changes page table entries, I still doubt that there
>> are data races I am not aware of. It's great if anyone can figure them out.
>>
>> 3. Performance: Under Kunpeng 920 platform, for every 64GB memory, KVM
>> consumes about 40ms to traverse all PTEs to collect dirty log. It will
>> cause unbearable downtime for migration if memory size is too big. I will
>> try to solve this problem in Patch v1.
>
> This, in my opinion, is why Stage-2 DBM is fairly useless.
> From a performance perspective, this is the worse possible
> situation. You end up continuously scanning page tables, at
> an arbitrary rate, without a way to evaluate the fault rate.
>
> One thing S2-DBM would be useful for is SVA, where a device
> write would mark the S2 PTs dirty as they are shared between
> CPU and SMMU. Another thing is SPE, which is essentially a DMA
> agent using the CPU's PTs.
>
> But on its own, and just to log the dirty pages, S2-DBM is
> pretty rubbish. I wish arm64 had something like Intel's PML,
> which looks far more interesting for the purpose of tracking
> accesses.
Sure, PML is a better solution on hardware management of dirty state.
However, compared to optimizing hardware, optimizing software is with
shorter cycle time.
Here I have an optimization in mind to solve it. Scanning page tables
can be done parallel, which can greatly reduce time consumption. For there
is no communication between parallel CPUs, we can achieve high speedup
ratio.
>
> Thanks,
>
> M.
Thanks,
Keqian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [soc:amlogic/ee-power-control] BUILD SUCCESS 53773f2dfd9c847304b184d5617e36aeafdf5d87
From: kbuild test robot @ 2020-05-26 1:58 UTC (permalink / raw)
To: Kevin Hilman; +Cc: arm, linux-arm-kernel
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git amlogic/ee-power-control
branch HEAD: 53773f2dfd9c847304b184d5617e36aeafdf5d87 soc: amlogic: meson-ee-pwrc: add support for the Meson GX SoCs
elapsed time: 8684m
configs tested: 183
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
mips allyesconfig
m68k allyesconfig
sparc allyesconfig
arm davinci_all_defconfig
mips db1xxx_defconfig
c6x defconfig
arm64 alldefconfig
sh sh2007_defconfig
sh sdk7786_defconfig
arm u8500_defconfig
parisc generic-32bit_defconfig
sparc64 allyesconfig
mips lasat_defconfig
h8300 h8s-sim_defconfig
m68k m5208evb_defconfig
sh ecovec24_defconfig
sh se7721_defconfig
mips sb1250_swarm_defconfig
powerpc ps3_defconfig
sh r7780mp_defconfig
arm sama5_defconfig
sh se7712_defconfig
arm iop32x_defconfig
i386 allnoconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 defconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
xtensa defconfig
arc defconfig
arc allyesconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
mips allnoconfig
mips allmodconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
powerpc defconfig
i386 randconfig-a001-20200521
i386 randconfig-a004-20200521
i386 randconfig-a006-20200521
i386 randconfig-a003-20200521
i386 randconfig-a002-20200521
i386 randconfig-a005-20200521
i386 randconfig-a001-20200520
i386 randconfig-a004-20200520
i386 randconfig-a006-20200520
i386 randconfig-a003-20200520
i386 randconfig-a002-20200520
i386 randconfig-a005-20200520
i386 randconfig-a006-20200519
i386 randconfig-a005-20200519
i386 randconfig-a001-20200519
i386 randconfig-a003-20200519
i386 randconfig-a004-20200519
i386 randconfig-a002-20200519
i386 randconfig-a001-20200524
i386 randconfig-a004-20200524
i386 randconfig-a006-20200524
i386 randconfig-a003-20200524
i386 randconfig-a002-20200524
i386 randconfig-a005-20200524
x86_64 randconfig-a003-20200519
x86_64 randconfig-a005-20200519
x86_64 randconfig-a004-20200519
x86_64 randconfig-a006-20200519
x86_64 randconfig-a002-20200519
x86_64 randconfig-a001-20200519
x86_64 randconfig-a013-20200520
x86_64 randconfig-a015-20200520
x86_64 randconfig-a016-20200520
x86_64 randconfig-a012-20200520
x86_64 randconfig-a014-20200520
x86_64 randconfig-a011-20200520
x86_64 randconfig-a013-20200524
x86_64 randconfig-a015-20200524
x86_64 randconfig-a016-20200524
x86_64 randconfig-a012-20200524
x86_64 randconfig-a014-20200524
x86_64 randconfig-a011-20200524
x86_64 randconfig-a015-20200522
x86_64 randconfig-a013-20200522
x86_64 randconfig-a016-20200522
x86_64 randconfig-a012-20200522
x86_64 randconfig-a014-20200522
x86_64 randconfig-a011-20200522
x86_64 randconfig-a002-20200521
x86_64 randconfig-a006-20200521
x86_64 randconfig-a005-20200521
x86_64 randconfig-a004-20200521
x86_64 randconfig-a003-20200521
x86_64 randconfig-a001-20200521
i386 randconfig-a013-20200520
i386 randconfig-a012-20200520
i386 randconfig-a015-20200520
i386 randconfig-a011-20200520
i386 randconfig-a016-20200520
i386 randconfig-a014-20200520
i386 randconfig-a013-20200522
i386 randconfig-a012-20200522
i386 randconfig-a015-20200522
i386 randconfig-a011-20200522
i386 randconfig-a016-20200522
i386 randconfig-a014-20200522
i386 randconfig-a012-20200519
i386 randconfig-a014-20200519
i386 randconfig-a016-20200519
i386 randconfig-a011-20200519
i386 randconfig-a015-20200519
i386 randconfig-a013-20200519
i386 randconfig-a013-20200521
i386 randconfig-a012-20200521
i386 randconfig-a015-20200521
i386 randconfig-a011-20200521
i386 randconfig-a016-20200521
i386 randconfig-a014-20200521
i386 randconfig-a013-20200524
i386 randconfig-a015-20200524
i386 randconfig-a012-20200524
i386 randconfig-a011-20200524
i386 randconfig-a016-20200524
i386 randconfig-a014-20200524
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
s390 defconfig
x86_64 defconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allmodconfig
um allnoconfig
um defconfig
um allyesconfig
um allmodconfig
x86_64 rhel
x86_64 rhel-7.6
x86_64 rhel-7.6-kselftests
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 15/21] drm/rcar-du: Use GEM CMA object functions
From: Laurent Pinchart @ 2020-05-26 1:50 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: alexandre.belloni, linux-aspeed, narmstrong, airlied, liviu.dudau,
dri-devel, paul, mihail.atanassov, sam, marex, khilman, abrodkin,
kong.kongxinwei, xinliang.liu, ludovic.desroches, tomi.valkeinen,
james.qian.wang, joel, linux-imx, alexandre.torgue, puck.chen,
s.hauer, alison.wang, jsarha, wens, vincent.abriou,
linux-arm-kernel, mcoquelin.stm32, bbrezillon, andrew,
philippe.cornu, yannick.fertre, kieran.bingham+renesas, kernel,
zourongrong, shawnguo
In-Reply-To: <816a8a0e-bb98-ea6c-5016-94b18e045fb5@suse.de>
Hi Thomas,
On Mon, May 25, 2020 at 02:49:46PM +0200, Thomas Zimmermann wrote:
> Am 22.05.20 um 22:12 schrieb Laurent Pinchart:
> > On Fri, May 22, 2020 at 03:52:40PM +0200, Thomas Zimmermann wrote:
> >> The rcar-du driver uses the default implementation for CMA functions;
> >> except for the .dumb_create callback. The __DRM_GEM_CMA_DRIVER_OPS macro
> >> now sets these defaults and .dumb_create in struct drm_driver. All
> >> remaining operations are provided by CMA GEM object functions.
> >>
> >> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> >> ---
> >> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 11 +----------
> >> 1 file changed, 1 insertion(+), 10 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> >> index 3e67cf70f0402..3728038cec1d1 100644
> >> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> >> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> >> @@ -476,16 +476,7 @@ DEFINE_DRM_GEM_CMA_FOPS(rcar_du_fops);
> >>
> >> static struct drm_driver rcar_du_driver = {
> >> .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> >> - .gem_free_object_unlocked = drm_gem_cma_free_object,
> >> - .gem_vm_ops = &drm_gem_cma_vm_ops,
> >> - .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> >> - .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> >> - .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> >> - .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> >> - .gem_prime_vmap = drm_gem_cma_prime_vmap,
> >> - .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
> >> - .gem_prime_mmap = drm_gem_cma_prime_mmap,
> >> - .dumb_create = rcar_du_dumb_create,
> >> + __DRM_GEM_CMA_DRIVER_OPS(rcar_du_dumb_create),
> >
> > Your __DRM_GEM_CMA_DRIVER_OPS is defined as
> >
> > #define __DRM_GEM_CMA_DRIVER_OPS(__dumb_create) \
> > .gem_create_object = drm_cma_gem_create_object_default_funcs, \
> > .dumb_create = (__dumb_create), \
> > .prime_handle_to_fd = drm_gem_prime_handle_to_fd, \
> > .prime_fd_to_handle = drm_gem_prime_fd_to_handle, \
> > .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table_vmap, \
> > .gem_prime_mmap = drm_gem_prime_mmap
> >
> > The patch thus introduces several changes:
> >
> > - drm_gem_cma_prime_import_sg_table_vmap() is used instead of
> > drm_gem_cma_prime_import_sg_table() combined with .gem_prime_vmap()
> > and .gem_prime_vunmap(). I believe that's fine, but splitting that
> > change in a separate commit, or at the very least explaining it in
> > details in the commit message, would make review easier.
> >
> > - .gem_create_object() is now set. That seems to be OK, but I'm not sure
> > to grasp all the implications. This should also be explained in the
> > commit message, and ideally split to a separate patch.
>
> That's relevant during object creation and sets the object functions.
> See one of my other replies for how this can go away after all CMA
> drivers have been updated to GEM object functions.
I don't dispute that's fine, but I think it should really be explained
in the commit message, and ideally split to a separate patch.
> > - drm_gem_cma_prime_mmap() is replaced with drm_gem_prime_mmap(). Same
> > comments :-)
>
> I relied on the aspeed driver to be correct. After Sam's comment on
> that, I read the code once again several times. The original
> implementation clears VM_PFNMAP. And I cannot find that code any longer.
> Going back to the original function might be better.
>
> > This patch hides way too many changes in what is documented as just
> > innocent refactoring. It seems other drivers are affected too.
>
> Could you test the patchset? I don't have the HW.
Kieran has beaten me to it :-)
> >> .fops = &rcar_du_fops,
> >> .name = "rcar-du",
> >> .desc = "Renesas R-Car Display Unit",
--
Regards,
Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 1/4] rcu/kasan: record and print call_rcu() call stack
From: Walter Wu @ 2020-05-26 1:34 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: wsd_upstream, Paul E . McKenney, Linux-MM, Andrey Konovalov,
Lai Jiangshan, Josh Triplett, kasan-dev, LKML, Joel Fernandes,
linux-mediatek, Alexander Potapenko, Matthias Brugger,
Andrey Ryabinin, Andrew Morton, Linux ARM, Mathieu Desnoyers
In-Reply-To: <CACT4Y+Zn9eMAPwCMEo710NnsUEoXP+H7xge8a1essu2F9DeFRw@mail.gmail.com>
On Mon, 2020-05-25 at 11:56 +0200, Dmitry Vyukov wrote:
> On Fri, May 22, 2020 at 4:01 AM Walter Wu <walter-zh.wu@mediatek.com> wrote:
> >
> > This feature will record the last two call_rcu() call stacks and
> > prints up to 2 call_rcu() call stacks in KASAN report.
> >
> > When call_rcu() is called, we store the call_rcu() call stack into
> > slub alloc meta-data, so that the KASAN report can print rcu stack.
> >
> > [1]https://bugzilla.kernel.org/show_bug.cgi?id=198437
> > [2]https://groups.google.com/forum/#!searchin/kasan-dev/better$20stack$20traces$20for$20rcu%7Csort:date/kasan-dev/KQsjT_88hDE/7rNUZprRBgAJ
>
> Hi Walter,
>
> The series look good to me. Thanks for bearing with me. I am eager to
> see this in syzbot reports.
>
> Reviewed-and-tested-by: Dmitry Vyukov <dvyukov@google.com>
>
Hi Dmitry,
I appreciate for your response. This patches make KASAN report more
better and let me learn a lot. Thank you for good suggestion and
detailed explanation.
Walter
> > Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
> > Suggested-by: Dmitry Vyukov <dvyukov@google.com>
> > Acked-by: Paul E. McKenney <paulmck@kernel.org>
> > Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
> > Cc: Dmitry Vyukov <dvyukov@google.com>
> > Cc: Alexander Potapenko <glider@google.com>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Josh Triplett <josh@joshtriplett.org>
> > Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> > Cc: Lai Jiangshan <jiangshanlai@gmail.com>
> > Cc: Joel Fernandes <joel@joelfernandes.org>
> > Cc: Andrey Konovalov <andreyknvl@google.com>
> > ---
> > include/linux/kasan.h | 2 ++
> > kernel/rcu/tree.c | 2 ++
> > mm/kasan/common.c | 4 ++--
> > mm/kasan/generic.c | 21 +++++++++++++++++++++
> > mm/kasan/kasan.h | 10 ++++++++++
> > mm/kasan/report.c | 28 +++++++++++++++++++++++-----
> > 6 files changed, 60 insertions(+), 7 deletions(-)
> >
> > diff --git a/include/linux/kasan.h b/include/linux/kasan.h
> > index 31314ca7c635..23b7ee00572d 100644
> > --- a/include/linux/kasan.h
> > +++ b/include/linux/kasan.h
> > @@ -174,11 +174,13 @@ static inline size_t kasan_metadata_size(struct kmem_cache *cache) { return 0; }
> >
> > void kasan_cache_shrink(struct kmem_cache *cache);
> > void kasan_cache_shutdown(struct kmem_cache *cache);
> > +void kasan_record_aux_stack(void *ptr);
> >
> > #else /* CONFIG_KASAN_GENERIC */
> >
> > static inline void kasan_cache_shrink(struct kmem_cache *cache) {}
> > static inline void kasan_cache_shutdown(struct kmem_cache *cache) {}
> > +static inline void kasan_record_aux_stack(void *ptr) {}
> >
> > #endif /* CONFIG_KASAN_GENERIC */
> >
> > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > index 06548e2ebb72..36a4ff7f320b 100644
> > --- a/kernel/rcu/tree.c
> > +++ b/kernel/rcu/tree.c
> > @@ -57,6 +57,7 @@
> > #include <linux/slab.h>
> > #include <linux/sched/isolation.h>
> > #include <linux/sched/clock.h>
> > +#include <linux/kasan.h>
> > #include "../time/tick-internal.h"
> >
> > #include "tree.h"
> > @@ -2668,6 +2669,7 @@ __call_rcu(struct rcu_head *head, rcu_callback_t func)
> > head->func = func;
> > head->next = NULL;
> > local_irq_save(flags);
> > + kasan_record_aux_stack(head);
> > rdp = this_cpu_ptr(&rcu_data);
> >
> > /* Add the callback to our list. */
> > diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> > index 2906358e42f0..8bc618289bb1 100644
> > --- a/mm/kasan/common.c
> > +++ b/mm/kasan/common.c
> > @@ -41,7 +41,7 @@
> > #include "kasan.h"
> > #include "../slab.h"
> >
> > -static inline depot_stack_handle_t save_stack(gfp_t flags)
> > +depot_stack_handle_t kasan_save_stack(gfp_t flags)
> > {
> > unsigned long entries[KASAN_STACK_DEPTH];
> > unsigned int nr_entries;
> > @@ -54,7 +54,7 @@ static inline depot_stack_handle_t save_stack(gfp_t flags)
> > static inline void set_track(struct kasan_track *track, gfp_t flags)
> > {
> > track->pid = current->pid;
> > - track->stack = save_stack(flags);
> > + track->stack = kasan_save_stack(flags);
> > }
> >
> > void kasan_enable_current(void)
> > diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
> > index 56ff8885fe2e..8acf48882ba2 100644
> > --- a/mm/kasan/generic.c
> > +++ b/mm/kasan/generic.c
> > @@ -325,3 +325,24 @@ DEFINE_ASAN_SET_SHADOW(f2);
> > DEFINE_ASAN_SET_SHADOW(f3);
> > DEFINE_ASAN_SET_SHADOW(f5);
> > DEFINE_ASAN_SET_SHADOW(f8);
> > +
> > +void kasan_record_aux_stack(void *addr)
> > +{
> > + struct page *page = kasan_addr_to_page(addr);
> > + struct kmem_cache *cache;
> > + struct kasan_alloc_meta *alloc_info;
> > + void *object;
> > +
> > + if (!(page && PageSlab(page)))
> > + return;
> > +
> > + cache = page->slab_cache;
> > + object = nearest_obj(cache, page, addr);
> > + alloc_info = get_alloc_info(cache, object);
> > +
> > + /*
> > + * record the last two call_rcu() call stacks.
> > + */
> > + alloc_info->aux_stack[1] = alloc_info->aux_stack[0];
> > + alloc_info->aux_stack[0] = kasan_save_stack(GFP_NOWAIT);
> > +}
> > diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
> > index e8f37199d885..a7391bc83070 100644
> > --- a/mm/kasan/kasan.h
> > +++ b/mm/kasan/kasan.h
> > @@ -104,7 +104,15 @@ struct kasan_track {
> >
> > struct kasan_alloc_meta {
> > struct kasan_track alloc_track;
> > +#ifdef CONFIG_KASAN_GENERIC
> > + /*
> > + * call_rcu() call stack is stored into struct kasan_alloc_meta.
> > + * The free stack is stored into struct kasan_free_meta.
> > + */
> > + depot_stack_handle_t aux_stack[2];
> > +#else
> > struct kasan_track free_track[KASAN_NR_FREE_STACKS];
> > +#endif
> > #ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
> > u8 free_pointer_tag[KASAN_NR_FREE_STACKS];
> > u8 free_track_idx;
> > @@ -159,6 +167,8 @@ void kasan_report_invalid_free(void *object, unsigned long ip);
> >
> > struct page *kasan_addr_to_page(const void *addr);
> >
> > +depot_stack_handle_t kasan_save_stack(gfp_t flags);
> > +
> > #if defined(CONFIG_KASAN_GENERIC) && \
> > (defined(CONFIG_SLAB) || defined(CONFIG_SLUB))
> > void quarantine_put(struct kasan_free_meta *info, struct kmem_cache *cache);
> > diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> > index 80f23c9da6b0..2421a4bd9227 100644
> > --- a/mm/kasan/report.c
> > +++ b/mm/kasan/report.c
> > @@ -105,15 +105,20 @@ static void end_report(unsigned long *flags)
> > kasan_enable_current();
> > }
> >
> > +static void print_stack(depot_stack_handle_t stack)
> > +{
> > + unsigned long *entries;
> > + unsigned int nr_entries;
> > +
> > + nr_entries = stack_depot_fetch(stack, &entries);
> > + stack_trace_print(entries, nr_entries, 0);
> > +}
> > +
> > static void print_track(struct kasan_track *track, const char *prefix)
> > {
> > pr_err("%s by task %u:\n", prefix, track->pid);
> > if (track->stack) {
> > - unsigned long *entries;
> > - unsigned int nr_entries;
> > -
> > - nr_entries = stack_depot_fetch(track->stack, &entries);
> > - stack_trace_print(entries, nr_entries, 0);
> > + print_stack(track->stack);
> > } else {
> > pr_err("(stack is not available)\n");
> > }
> > @@ -192,6 +197,19 @@ static void describe_object(struct kmem_cache *cache, void *object,
> > free_track = kasan_get_free_track(cache, object, tag);
> > print_track(free_track, "Freed");
> > pr_err("\n");
> > +
> > +#ifdef CONFIG_KASAN_GENERIC
> > + if (alloc_info->aux_stack[0]) {
> > + pr_err("Last call_rcu():\n");
> > + print_stack(alloc_info->aux_stack[0]);
> > + pr_err("\n");
> > + }
> > + if (alloc_info->aux_stack[1]) {
> > + pr_err("Second to last call_rcu():\n");
> > + print_stack(alloc_info->aux_stack[1]);
> > + pr_err("\n");
> > + }
> > +#endif
> > }
> >
> > describe_object_addr(cache, object, addr);
> > --
> > 2.18.0
> >
> > --
> > You received this message because you are subscribed to the Google Groups "kasan-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com.
> > To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20200522020059.22332-1-walter-zh.wu%40mediatek.com.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
From: Laurent Pinchart @ 2020-05-26 1:44 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: devicetree, geert+renesas, xuwei5, robh+dt, kernel,
linux-arm-kernel
In-Reply-To: <20200525074335.grnjvdjnipq5g3kf@rcn-XPS-13-9360>
Hi Ricardo,
On Mon, May 25, 2020 at 09:43:35AM +0200, Ricardo Cañuelo wrote:
> On jue 14-05-2020 18:22:39, Laurent Pinchart wrote:
> > > If we want to be more strict and require the definition of all the
> > > supplies, there will be many more DTs changes in the series, and I'm not
> > > sure I'll be able to do that in a reasonable amount of time. I'm looking
> > > at them and it's not always clear which regulators to use or if they are
> > > even defined.
> >
> > We can decouple the two though (I think). The bindings should reflect
> > what we consider right, and the dts files could be fixed on top.
>
> Do you have a suggestion on how to do this? If we decouple the two
> tasks most of the work would be searching for DTs to fix and finding a
> way to fix each one of them, and unless I do this _before_ the binding
> conversion I'll get a lot of dtbs_check errors.
Rob should answer this question as it will be his decision, but I've
personally never considered non-compliant DT sources to be an obstacle
to bindings conversion to YAML. The DT sources should be fixed, but I
don't see it as a prerequisite (although it's a good practice).
> The binding conversion itself is done, if we go this route the only
> additional change would be to make the supplies required.
--
Regards,
Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 0/5] support reserving crashkernel above 4G on arm64 kdump
From: Baoquan He @ 2020-05-26 1:42 UTC (permalink / raw)
To: Chen Zhou
Cc: horms, John.p.donnelly, arnd, will, devicetree, catalin.marinas,
linux-doc, kexec, linux-kernel, robh+dt, mingo, guohanjun, tglx,
pkushwaha, dyoung, linux-arm-kernel
In-Reply-To: <20200521093805.64398-1-chenzhou10@huawei.com>
On 05/21/20 at 05:38pm, Chen Zhou wrote:
> 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.
OK, moving x86 CRASH_ALIGN to 2M is suggested by Dave. Because
CONFIG_PHYSICAL_ALIGN can be selected from 2M to 16M. So 2M seems good.
But, anyway, we should tell the reason why it need be changed in commit
log.
arch/x86/Kconfig:
config PHYSICAL_ALIGN
hex "Alignment value to which kernel should be aligned"
default "0x200000"
range 0x2000 0x1000000 if X86_32
range 0x200000 0x1000000 if X86_64
> - 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.
And the crashkernel=X,high being deleted need be told too. Otherwise
people reading the commit have to check why themselves. I didn't follow
the old version, can't see why ,high can't be specified explicitly.
> - 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
>
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [EXT] Re: [PATCH net 1/2] net: ethernet: dwmac: add Ethernet glue logic for NXP imx8 chip
From: Andy Duan @ 2020-05-26 1:26 UTC (permalink / raw)
To: David Miller
Cc: p.zabel@pengutronix.de, alexandre.torgue@st.com,
netdev@vger.kernel.org, joabreu@synopsys.com,
mcoquelin.stm32@gmail.com, kuba@kernel.org,
peppe.cavallaro@st.com, linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20200525.181317.1216905484376882401.davem@davemloft.net>
From: David Miller <davem@davemloft.net> Sent: Tuesday, May 26, 2020 9:13 AM
> From: Fugang Duan <fugang.duan@nxp.com>
> Date: Mon, 25 May 2020 18:29:13 +0800
>
> > +static int imx_dwmac_init(struct platform_device *pdev, void *priv) {
> > + struct imx_priv_data *dwmac = priv;
> > + struct plat_stmmacenet_data *plat_dat = dwmac->plat_dat;
> > + int ret;
> > +
>
> Please code these sequences as:
>
> struct plat_stmmacenet_data *plat_dat;
> struct imx_priv_data *dwmac = priv;
> int ret;
>
> plat_dat = dwmac->plat_dat;
>
> In order to have reverse christmas three local variable ordering.
>
> THank you.
Thanks, David.
I will update the change in v2.
Andy
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH net 1/2] net: ethernet: dwmac: add Ethernet glue logic for NXP imx8 chip
From: David Miller @ 2020-05-26 1:13 UTC (permalink / raw)
To: fugang.duan
Cc: p.zabel, alexandre.torgue, netdev, joabreu, mcoquelin.stm32, kuba,
peppe.cavallaro, linux-stm32, linux-arm-kernel
In-Reply-To: <1590402554-13175-2-git-send-email-fugang.duan@nxp.com>
From: Fugang Duan <fugang.duan@nxp.com>
Date: Mon, 25 May 2020 18:29:13 +0800
> +static int imx_dwmac_init(struct platform_device *pdev, void *priv)
> +{
> + struct imx_priv_data *dwmac = priv;
> + struct plat_stmmacenet_data *plat_dat = dwmac->plat_dat;
> + int ret;
> +
Please code these sequences as:
struct plat_stmmacenet_data *plat_dat;
struct imx_priv_data *dwmac = priv;
int ret;
plat_dat = dwmac->plat_dat;
In order to have reverse christmas three local variable ordering.
THank you.
_______________________________________________
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 v8 2/5] arm64: kdump: reserve crashkenel above 4G for crash dump kernel
From: Baoquan He @ 2020-05-26 0:59 UTC (permalink / raw)
To: Chen Zhou
Cc: horms, John.p.donnelly, arnd, will, devicetree, catalin.marinas,
linux-doc, kexec, linux-kernel, robh+dt, mingo, guohanjun, tglx,
pkushwaha, dyoung, linux-arm-kernel
In-Reply-To: <20200521093805.64398-3-chenzhou10@huawei.com>
On 05/21/20 at 05:38pm, Chen Zhou wrote:
> 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.
Wondering why crashkernel=,high is not introduced to arm64 to be
consistent with x86_64, to make the behaviour be the same on all
architecutres.
>
> 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
>
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox