From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Nick Kossifidis <mick@ics.forth.gr>
Cc: linux-riscv <linux-riscv@lists.infradead.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Rob Herring <robh+dt@kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>
Subject: Re: [PATCH v4 5/5] RISC-V: Add crash kernel support
Date: Tue, 15 Jun 2021 20:48:05 +0200 [thread overview]
Message-ID: <CAMuHMdXtT1L3yfzkTkbhqz3zgUQj89Bcm7mqz+m126NprAsK8Q@mail.gmail.com> (raw)
In-Reply-To: <fe02eb618eee141e8bc021e8e30906fc@mailhost.ics.forth.gr>
Hi Nick,
On Tue, Jun 15, 2021 at 8:29 PM Nick Kossifidis <mick@ics.forth.gr> wrote:
> Στις 2021-06-15 16:19, Geert Uytterhoeven έγραψε:
> > This does not match
> > https://github.com/devicetree-org/dt-schema/blob/master/schemas/chosen.yaml#L77:
> >
> > $ref: types.yaml#/definitions/uint64-array
> > maxItems: 2
> > description:
> > This property (currently used only on arm64) holds the memory
> > range,
> > the address and the size, of the elf core header which mainly
> > describes
> > the panicked kernel\'s memory layout as PT_LOAD segments of elf
> > format.
> >
> > Hence "linux,elfcorehdr" should be a property of the /chosen node,
> > instead of a memory node with a compatible value of "linux,elfcorehdr".
> >
>
> That's a binding for a property on the /chosen node, that as the text
> says it's defined for arm64 only and the code that handled it was also
That doesn't mean it must not be used on other architectures ;-)
Arm64 was just the first one to use it...
> on arm64. Instead the reserved-region binding I used is a standard
> binding, if you don't like the name used for the compatible string
> because it overlaps with that property we can change it. I want to use a
> reserved-region for this because we'll have to reserve it anyway so
> using a property on /chosen and then using that property to reserve the
> region seemed suboptimal.
>
> >> v2:
> >> * Use linux,usable-memory on /memory instead of a new binding
> >
> > This part seems to have been removed in v3 and later?
> > Note that "linux,usable-memory-range" should be a property of the
> > /chosen node, too, cfr.
> > https://github.com/devicetree-org/dt-schema/blob/master/schemas/chosen.yaml#L85
> >
>
> No special handling is needed when using linux,usable-memory on /memory,
> limiting the available memory is handled by generic code at
> drivers/of/fdt.c
It was my understanding both properties under /chosen are the
recommended methods for new platforms... Let's see what Rob has
to say...
Anyway, I sent a patch series to switch to generic "linux,elfcorehdr"
handling
https://lore.kernel.org/r/cover.1623780059.git.geert+renesas@glider.be/
Thanks!
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-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2021-06-15 21:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-19 0:55 [PATCH v4 0/5] RISC-V: Add kexec/kdump support Nick Kossifidis
2021-04-19 0:55 ` [PATCH v4 1/5] RISC-V: Add EM_RISCV to kexec UAPI header Nick Kossifidis
2021-04-19 0:55 ` [PATCH v4 2/5] RISC-V: Add kexec support Nick Kossifidis
2021-04-19 0:55 ` [PATCH v4 3/5] RISC-V: Improve init_resources Nick Kossifidis
2021-04-19 0:55 ` [PATCH v4 4/5] RISC-V: Add kdump support Nick Kossifidis
2021-04-19 0:55 ` [PATCH v4 5/5] RISC-V: Add crash kernel support Nick Kossifidis
2021-06-15 13:19 ` Geert Uytterhoeven
2021-06-15 18:29 ` Nick Kossifidis
2021-06-15 18:48 ` Geert Uytterhoeven [this message]
2021-06-15 19:21 ` Rob Herring
2021-06-15 23:29 ` Nick Kossifidis
2021-06-16 14:55 ` Rob Herring
2021-06-16 16:30 ` Ard Biesheuvel
2023-10-30 10:44 ` Andreas Schwab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMuHMdXtT1L3yfzkTkbhqz3zgUQj89Bcm7mqz+m126NprAsK8Q@mail.gmail.com \
--to=geert@linux-m68k.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=mick@ics.forth.gr \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).