RE: [PATCH] Documentation: add link to stm32mp157 docs
Hi Jonathan > From: Jonathan Corbet > > On Thu, 3 Oct 2019 10:05:46 + > Gerald BAEZA wrote: > > > > > Adding the URL is a fine idea. But you don't need the extra > > > > syntax to create a link if you're not going to actually make a link out > > > > of it. > > > > So I'd take the ".. _STM32MP157:" part out and life will be good. > > > > > > > > > > We also did it for older stm32 product. Idea was to not have the "full" > > > address but just a shortcut of the link when html file is read. It > > > maybe makes no sens ? (if yes we will have to update older stm32 > > > overview :)) > > > > Example in > > https://www.kernel.org/doc/html/latest/arm/stm32/stm32h743- > overview.ht > > ml > > > > Do you agree to continue like this ? > > If you actually use the reference then it's OK, I guess; in the posted > document that wasn't happening. I still think it might be a bit more > straightforward to just put the URL; that will make the plain-text file a > little > more readable. In the end, though, it's up to you, go with whichever you > prefer. So I prefer to keep the patch as it, for better consistency with the others stm32 overviews. Thank you. > > Thanks, > > jon
Re: [PATCH v7 0/8] efi/firmware/platform-x86: Add EFI embedded fw support
Hi Ingo, On 07-10-2019 16:19, Ingo Molnar wrote: * Hans de Goede wrote: Hi All, Here is v7 of my patch-set to add support for EFI embedded fw to the kernel. v6 was posted a long time ago, around the 4.18 days. The long wait was for a suitable secure-hash for checking the firmware we find embedded in the EFI is the one we expect. With 5.4-rc1 we finally have a standalone sha256 lib, so that hurdle for this patch-set is now gone. I've tried to address all review-remarks against v6 in this new version: Changes in v7: - Split drivers/firmware/efi and drivers/base/firmware_loader changes into 2 patches - Use new, standalone, lib/crypto/sha256.c code - Address kdoc comments from Randy Dunlap - Add new FW_OPT_FALLBACK_PLATFORM flag and firmware_request_platform() _request_firmware() wrapper, as requested by Luis R. Rodriguez - Stop using "efi-embedded-firmware" device-property, now that drivers need to use the new firmware_request_platform() to enable fallback to a device fw copy embedded in the platform's main firmware, we no longer need a property on the device to trigger this behavior - Use security_kernel_load_data instead of calling security_kernel_read_file with a NULL file pointer argument - Move the docs to Documentation/driver-api/firmware/fallback-mechanisms.rst - Document the new firmware_request_platform() function in Documentation/driver-api/firmware/request_firmware.rst - Add 2 new patches for the silead and chipone-icn8505 touchscreen drivers to use the new firmware_request_platform() method - Rebased on top of 5.4-rc1 I guess this will probably need another round (or two) of review + fixing, but eventually this can hopefully be merged. Since this touches a bunch of different subsystems the question is how to merge this? Most of the touched files outside of the firmware-loader code do not see a lot of churn, so my proposal would be to merge patches 1-6 through the tree which carries firmware-loader changes; and then provide an immutable branch for the platform/x86 maintainers to merge and then they can merge the last 2 patches (as the touchscreen_dmi.c file does see quite a bit of changes every release). So I was looking for a high level 0/ boilerplate description of this series, to explain what "EFI embedded fw" is, what problems it solves and how it helps the kernel in general - and found this in 2/8: Sorry you had to dig into the individual patch changelogs for that I sorta assumed that everyone involved would still vaguely remember what this series is about. Just like with PCI options ROMs, which we save in the setup_efi_pci* functions from arch/x86/boot/compressed/eboot.c, the EFI code / ROM itself sometimes may contain data which is useful/necessary for peripheral drivers to have access to. Specifically the EFI code may contain an embedded copy of firmware which needs to be (re)loaded into the peripheral. Normally such firmware would be part of linux-firmware, but in some cases this is not feasible, for 2 reasons: 1) The firmware is customized for a specific use-case of the chipset / use with a specific hardware model, so we cannot have a single firmware file for the chipset. E.g. touchscreen controller firmwares are compiled specifically for the hardware model they are used with, as they are calibrated for a specific model digitizer. 2) Despite repeated attempts we have failed to get permission to redistribute the firmware. This is especially a problem with customized firmwares, these get created by the chip vendor for a specific ODM and the copyright may partially belong with the ODM, so the chip vendor cannot give a blanket permission to distribute these. This commit adds support for finding peripheral firmware embedded in the EFI code and makes the found firmware available through the new efi_get_embedded_fw() function. Support for loading these firmwares through the standard firmware loading mechanism is added in a follow-up commit in this patch-series. Note we check the EFI_BOOT_SERVICES_CODE for embedded firmware near the end of start_kernel(), just before calling rest_init(), this is on purpose because the typical EFI_BOOT_SERVICES_CODE memory-segment is too large for early_memremap(), so the check must be done after mm_init(). This relies on EFI_BOOT_SERVICES_CODE not being free-ed until efi_free_boot_services() is called, which means that this will only work on x86 for now. Reported-by: Dave Olsthoorn Suggested-by: Peter Jones Acked-by: Ard Biesheuvel Signed-off-by: Hans de Goede There's also patch #3, which explains how this is used: This commit adds a new platform fallback mechanism to the firmware loader which will try to lookup a device fw copy embedded in the platform's main firmware if direct filesystem lookup fails. Drivers which need such embedded fw copies can enable this fallback mechanism by using the new firmware_request_platform() function. Note that for now this is only supported on EFI platforms and even on t
Re: [PATCH v7 0/8] efi/firmware/platform-x86: Add EFI embedded fw support
* Hans de Goede wrote: > > So I was looking for a high level 0/ boilerplate description of this > > series, to explain what "EFI embedded fw" is, what problems it solves and > > how it helps the kernel in general - and found this in 2/8: > > Sorry you had to dig into the individual patch changelogs for that > I sorta assumed that everyone involved would still vaguely remember > what this series is about. Wasn't *that* hard to do and I intended to read the patches anyway. ;-) Thanks for the explanation and the answers, this all looks good to me in principle and in implementation as well. Thanks, Ingo
Re: [PATCH 3/3] dt-bindings: iio: Add ltc2947 documentation
On Fri, 2019-10-04 at 10:23 -0500, Rob Herring wrote: > > On Fri, Oct 4, 2019 at 9:59 AM Sa, Nuno wrote: > > Hi Rob, > > > > Just wanted to clarify something which I don't know if is something > > I'm > > doing wrong or if it is some issue. > > > > On Wed, 2019-10-02 at 14:06 -0500, Rob Herring wrote: > > > On Wed, Oct 2, 2019 at 10:09 AM Sa, Nuno > > > wrote: > > > > On Wed, 2019-10-02 at 09:19 -0500, Rob Herring wrote: > > > > > On Tue, Sep 24, 2019 at 02:49:45PM +0200, Nuno Sá wrote: > > > > > > Document the LTC2947 device devicetree bindings. > > > > > > > > > > > > Signed-off-by: Nuno Sá > > > > > > --- > > > > > > .../bindings/hwmon/adi,ltc2947.yaml | 101 > > > > > > ++ > > > > > > MAINTAINERS | 1 + > > > > > > 2 files changed, 102 insertions(+) > > > > > > create mode 100644 > > > > > > Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml > > > > > > > > > > > > diff --git > > > > > > a/Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml > > > > > > b/Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml > > > > > > new file mode 100644 > > > > > > index ..2ea0187421d4 > > > > > > --- /dev/null > > > > > > +++ > > > > > > b/Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml > > > > > > @@ -0,0 +1,101 @@ > > > > > > > > > > Missing license. Please make new bindings (GPL-2.0-only OR > > > > > BSD-2- > > > > > Clause) > > > > > > > > ack. > > > > > > > > > > +%YAML 1.2 > > > > > > +--- > > > > > > +$id: > > > > > > http://devicetree.org/schemas/bindings/hwmon/adi,ltc2947.yaml# > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > > > + > > > > > > +title: Analog Devices LTC2947 high precision power and > > > > > > energy > > > > > > monitor > > > > > > + > > > > > > +maintainers: > > > > > > + - Nuno Sá > > > > > > + > > > > > > +description: | > > > > > > + Analog Devices LTC2947 high precision power and energy > > > > > > monitor > > > > > > over SPI or I2C. > > > > > > + > > > > > > + > > > > > > https://www.analog.com/media/en/technical-documentation/data-sheets/LTC2947.pdf > > > > > > + > > > > > > +properties: > > > > > > + compatible: > > > > > > +enum: > > > > > > + - adi,ltc2947 > > > > > > + > > > > > > + reg: > > > > > > +maxItems: 1 > > > > > > + > > > > > > + clocks: > > > > > > +description: > > > > > > + The LTC2947 uses either a trimmed internal > > > > > > oscillator or > > > > > > an > > > > > > external clock > > > > > > + as the time base for determining the integration > > > > > > period > > > > > > to > > > > > > represent time, > > > > > > + charge and energy. When an external clock is used, > > > > > > this > > > > > > property must be > > > > > > + set accordingly. > > > > > > +maxItems: 1 > > > > > > + > > > > > > + adi,accumulator-ctl-pol: > > > > > > +description: > > > > > > + This property controls the polarity of current that > > > > > > is > > > > > > accumulated to > > > > > > + calculate charge and energy so that, they can be > > > > > > only > > > > > > accumulated for > > > > > > + positive current for example. Since there are two > > > > > > sets > > > > > > of > > > > > > registers for > > > > > > + the accumulated values, this entry can also have two > > > > > > items > > > > > > which sets > > > > > > + energy1/charge1 and energy2/charger2 respectively. > > > > > > Check > > > > > > table 12 of the > > > > > > + datasheet for more information on the supported > > > > > > options. > > > > > > +allOf: > > > > > > + - $ref: /schemas/types.yaml#/definitions/uint32- > > > > > > array > > > > > > + - enum: [0, 1, 2, 3] > > > > > > + - minItems: 2 > > > > > > + - maxItems: 2 > > > > > > +default: [0, 0] > > > > > > > > > > This should be: > > > > > > > > > > allOf: > > > > > - $ref: ... > > > > > items: > > > > > enum: [0, 1, 2, 3] > > > > > default: 0 > > > > > minItems: 2 > > > > > maxItems: 2 > > > > When trying the above I get: > > > > "ltc2947@0: adi,accumulator-ctl-pol:0: [0, 1] is not valid under > > any of > > the given schemas" > > Is dtschema up to date with the latest. I think I fixed this case > recently, though with the wonderful json-schema errors it is hard to > tell. With latest dtschema works. Thanks! Nuno Sa > Rob -- Analog Devices GmbH Otl-Aicher Strasse 60-64 80807 München Sitz der Gesellschaft München, Registergericht München HRB 40368, Geschäftsführer: Stefan Steyerl, Thomas Edward Cribben, Michael Paul Sondel
Re: [PATCH v11 3/6] of: property: Add functional dependency link from DT bindings
Quoting Greg Kroah-Hartman (2019-10-04 08:37:50)
> On Wed, Sep 11, 2019 at 03:29:25AM -0700, Stephen Boyd wrote:
> > Quoting Saravana Kannan (2019-09-04 14:11:22)
> > > + int ret = 0;
> > > + struct device_node *tmp_np = sup_np;
> > > +
> > > + of_node_get(sup_np);
> > > + /*
> > > +* Find the device node that contains the supplier phandle. It
> > > may be
> > > +* @sup_np or it may be an ancestor of @sup_np.
> > > +*/
> > > + while (sup_np && !of_find_property(sup_np, "compatible", NULL))
> > > + sup_np = of_get_next_parent(sup_np);
> >
> > I don't get this. This is assuming that drivers are only probed for
> > device nodes that have a compatible string? What about drivers that make
> > sub-devices for clk support that have drivers in drivers/clk/ that then
> > attach at runtime later? This happens sometimes for MFDs that want to
> > split the functionality across the driver tree to the respective
> > subsystems.
>
> For that, the link would not be there, correct?
The parent device (MFD) would have the links because that is the device
node with the provider property like '#clock-cells'. The child clk
device that's populated by the MFD would be the one actually providing
the clk via a driver that may probe any time later, or never, depending
on if the clk driver is configured as a module or not. I fail to see how
this will work for these cases.
Is this logic there to find the parent of a regulator phandle and match
that to some driver? It looks like it.
>
> > > +static int of_link_property(struct device *dev, struct device_node
> > > *con_np,
> > > +const char *prop_name)
> > > +{
> > > + struct device_node *phandle;
> > > + const struct supplier_bindings *s = bindings;
> > > + unsigned int i = 0;
> > > + bool matched = false;
> > > + int ret = 0;
> > > +
> > > + /* Do not stop at first failed link, link all available
> > > suppliers. */
> > > + while (!matched && s->parse_prop) {
> > > + while ((phandle = s->parse_prop(con_np, prop_name, i))) {
> > > + matched = true;
> > > + i++;
> > > + if (of_link_to_phandle(dev, phandle) == -EAGAIN)
> > > + ret = -EAGAIN;
> >
> > And don't break?
>
> There was comments before about how this is not needed. Frank asked
> that the comment be removed. And now you point it out again :)
>
> Look at the comment a few lines up, we have to go through all of the
> suppliers.
>
Ok. The comment tells me what is happening but it misses the essential
part which is _why_ we must make links to each supplier and return
-EAGAIN.
[PATCH for-stable-v4.19 10/16] arm64: Provide a command line to disable spectre_v2 mitigation
From: Jeremy Linton
[ Upstream commit e5ce5e7267ddcbe13ab9ead2542524e1b7993e5a ]
There are various reasons, such as benchmarking, to disable spectrev2
mitigation on a machine. Provide a command-line option to do so.
Signed-off-by: Jeremy Linton
Reviewed-by: Suzuki K Poulose
Reviewed-by: Andre Przywara
Reviewed-by: Catalin Marinas
Tested-by: Stefan Wahren
Cc: Jonathan Corbet
Cc: linux-doc@vger.kernel.org
Signed-off-by: Will Deacon
Signed-off-by: Ard Biesheuvel
---
Documentation/admin-guide/kernel-parameters.txt | 8
arch/arm64/kernel/cpu_errata.c | 13 +
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index e8ddf0ef232e..cc2f5c9a8161 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2866,10 +2866,10 @@
(bounds check bypass). With this option data leaks
are possible in the system.
- nospectre_v2[X86,PPC_FSL_BOOK3E] Disable all mitigations for the
Spectre variant 2
- (indirect branch prediction) vulnerability. System may
- allow data leaks with this option, which is equivalent
- to spectre_v2=off.
+ nospectre_v2[X86,PPC_FSL_BOOK3E,ARM64] Disable all mitigations for
+ the Spectre variant 2 (indirect branch prediction)
+ vulnerability. System may allow data leaks with this
+ option.
nospec_store_bypass_disable
[HW] Disable all mitigations for the Speculative Store
Bypass vulnerability
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 10571a378f4c..2394a105ebf4 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -189,6 +189,14 @@ static void qcom_link_stack_sanitization(void)
: "=&r" (tmp));
}
+static bool __nospectre_v2;
+static int __init parse_nospectre_v2(char *str)
+{
+ __nospectre_v2 = true;
+ return 0;
+}
+early_param("nospectre_v2", parse_nospectre_v2);
+
static void
enable_smccc_arch_workaround_1(const struct arm64_cpu_capabilities *entry)
{
@@ -200,6 +208,11 @@ enable_smccc_arch_workaround_1(const struct
arm64_cpu_capabilities *entry)
if (!entry->matches(entry, SCOPE_LOCAL_CPU))
return;
+ if (__nospectre_v2) {
+ pr_info_once("spectrev2 mitigation disabled by command line
option\n");
+ return;
+ }
+
if (psci_ops.smccc_version == SMCCC_VERSION_1_0)
return;
--
2.20.1
Re: [PATCH] doc: move namespaces.rst from kbuild/ to core-api/
+++ Masahiro Yamada [08/10/19 12:10 +0900]: We discussed a better location for this file, and agreed that core-api/ is a good fit. Rename it to symbol-namespaces.rst for disambiguation, and also add it to index.rst and MAINTAINERS. Signed-off-by: Masahiro Yamada Applied, thanks! Jessica
Re: [PATCH v11 3/6] of: property: Add functional dependency link from DT bindings
On Tue, Oct 8, 2019 at 7:53 AM Stephen Boyd wrote:
>
> Quoting Greg Kroah-Hartman (2019-10-04 08:37:50)
> > On Wed, Sep 11, 2019 at 03:29:25AM -0700, Stephen Boyd wrote:
> > > Quoting Saravana Kannan (2019-09-04 14:11:22)
> > > > + int ret = 0;
> > > > + struct device_node *tmp_np = sup_np;
> > > > +
> > > > + of_node_get(sup_np);
> > > > + /*
> > > > +* Find the device node that contains the supplier phandle. It
> > > > may be
> > > > +* @sup_np or it may be an ancestor of @sup_np.
> > > > +*/
> > > > + while (sup_np && !of_find_property(sup_np, "compatible", NULL))
> > > > + sup_np = of_get_next_parent(sup_np);
> > >
> > > I don't get this. This is assuming that drivers are only probed for
> > > device nodes that have a compatible string? What about drivers that make
> > > sub-devices for clk support that have drivers in drivers/clk/ that then
> > > attach at runtime later? This happens sometimes for MFDs that want to
> > > split the functionality across the driver tree to the respective
> > > subsystems.
> >
> > For that, the link would not be there, correct?
>
> The parent device (MFD) would have the links because that is the device
> node with the provider property like '#clock-cells'. The child clk
> device that's populated by the MFD would be the one actually providing
> the clk via a driver that may probe any time later, or never, depending
> on if the clk driver is configured as a module or not. I fail to see how
> this will work for these cases.
>
> Is this logic there to find the parent of a regulator phandle and match
> that to some driver? It looks like it.
In the case of an MFD creating "fake" children devices, the parent MFD
device's driver is responsible for handling the sync state callback.
It'll get the sync_state callback after all the child devices'
consumers have probed. The MFD driver will need to do the sync state
clean up for the children devices or pass it on to the child devices'
drivers (whatever makes sense for that specific MFD) by whatever means
those specific drivers talk to each other (direct calls, registering
callbacks, etc).
If they are real sub-devices, then they should really be captured in
DT as child devices and then the child device's drivers will get the
sync state callback directly.
> >
> > > > +static int of_link_property(struct device *dev, struct device_node
> > > > *con_np,
> > > > +const char *prop_name)
> > > > +{
> > > > + struct device_node *phandle;
> > > > + const struct supplier_bindings *s = bindings;
> > > > + unsigned int i = 0;
> > > > + bool matched = false;
> > > > + int ret = 0;
> > > > +
> > > > + /* Do not stop at first failed link, link all available
> > > > suppliers. */
> > > > + while (!matched && s->parse_prop) {
> > > > + while ((phandle = s->parse_prop(con_np, prop_name, i)))
> > > > {
> > > > + matched = true;
> > > > + i++;
> > > > + if (of_link_to_phandle(dev, phandle) == -EAGAIN)
> > > > + ret = -EAGAIN;
> > >
> > > And don't break?
> >
> > There was comments before about how this is not needed. Frank asked
> > that the comment be removed. And now you point it out again :)
> >
> > Look at the comment a few lines up, we have to go through all of the
> > suppliers.
> >
>
> Ok. The comment tells me what is happening but it misses the essential
> part which is _why_ we must make links to each supplier and return
> -EAGAIN.
To be clear the -EAGAIN is only if any of the linking fails.
The reason was already discussion in the email thread [1] but I agree
it needs to be documented.
I thought I had documented the _why_ in the documentation for
fwnode.add_links(), but it's not there. I'll check to make sure I
didn't capture it elsewhere and if not, I'll update fwnode.add_links
documentation.
To copy-paste the discussion from the earlier thread:
"Actually, there is a point for this. Say Device-C depends on suppliers
Device-S1 and Device-S2 and they are listed in DT in that order.
Say, S1 gets populated after late_initcall_sync but S2 is probes way
before that. If I don't continue past a "failed linking" to S1 and
also link up to S2, then S2 will get a sync_state() callback before C
is probed. So I have to go through all possible suppliers and [link] as many
as possible."
-Saravana
[1] -
https://lore.kernel.org/lkml/cagetcx-hcruvy5whzbihueqqcxmf3odjfybjmoo3juu87ii...@mail.gmail.com/
Re: [tip: x86/urgent] x86/CPU/AMD: Clear RDRAND CPUID bit on AMD family 15h/16h
Hi! > >> x86/CPU/AMD: Clear RDRAND CPUID bit on AMD family 15h/16h > >> > >> There have been reports of RDRAND issues after resuming from suspend on > >> some AMD family 15h and family 16h systems. This issue stems from a BIOS > >> not performing the proper steps during resume to ensure RDRAND continues > >> to function properly. > > > > There are quite a few unanswered questions here. > > > > a) Is there/should there be CVE for this? > > > > b) Can we perform proper steps in kernel, thus making RDRAND usable > > even when BIOS is buggy? > > > > The kernel should at least be able to set its internal "CPUID" bit, visible > through /proc/cpuinfo. Actually, with hindsight I see two possible improvements here: 1) Not having enabled s2ram in config does not mean machine was not suspended/resumed, then new kernel executed via kexec. 2) We really can continue using the RDRAND: we know how it fails (constant pattern) so we can check for the failure in kernel, and can continue to use it... It will certainly work until first suspend, and there's good chance it will work after that, too. (We still need to prevent userspace from using it). Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
[PATCH] Documentation: admin-guide: add earlycon documentation for the sifive serial driver
Document earlycon usage for the SiFive serial port driver in the same fashion as for the other serial port IP blocks, since the SiFive serial port driver supports it. Signed-off-by: Paul Walmsley Reported-by: Andreas Schwab Cc: Christoph Hellwig --- Documentation/admin-guide/kernel-parameters.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index c7ac2f3ac99f..90becb00221b 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1106,6 +1106,12 @@ address must be provided, and the serial port must already be setup and configured. + sifive, + Start an early, polled-mode console on a SiFive + serial port at the specified address. The port must + already be setup and configured. Options are not + yet supported. + earlyprintk=[X86,SH,ARM,M68k,S390] earlyprintk=vga earlyprintk=sclp -- 2.23.0
[PATCH] RISC-V: Typo fixes in image header and documentation.
There are some typos in boot image header and riscv boot documentation.
Fix the typos.
Signed-off-by: Atish Patra
---
Documentation/riscv/boot-image-header.rst | 4 ++--
arch/riscv/include/asm/image.h| 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/riscv/boot-image-header.rst
b/Documentation/riscv/boot-image-header.rst
index 7b4d1d747585..8efb0596a33f 100644
--- a/Documentation/riscv/boot-image-header.rst
+++ b/Documentation/riscv/boot-image-header.rst
@@ -22,7 +22,7 @@ The following 64-byte header is present in decompressed Linux
kernel image::
u64 res2 = 0; /* Reserved */
u64 magic = 0x5643534952; /* Magic number, little endian, "RISCV" */
u32 magic2 = 0x56534905; /* Magic number 2, little endian, "RSC\x05" */
- u32 res4; /* Reserved for PE COFF offset */
+ u32 res3; /* Reserved for PE COFF offset */
This header format is compliant with PE/COFF header and largely inspired from
ARM64 header. Thus, both ARM64 & RISC-V header can be combined into one common
@@ -34,7 +34,7 @@ Notes
- This header can also be reused to support EFI stub for RISC-V in future. EFI
specification needs PE/COFF image header in the beginning of the kernel image
in order to load it as an EFI application. In order to support EFI stub,
- code0 should be replaced with "MZ" magic string and res5(at offset 0x3c)
should
+ code0 should be replaced with "MZ" magic string and res3(at offset 0x3c)
should
point to the rest of the PE/COFF header.
- version field indicate header version number
diff --git a/arch/riscv/include/asm/image.h b/arch/riscv/include/asm/image.h
index 344db5244547..4f8061a5ac4a 100644
--- a/arch/riscv/include/asm/image.h
+++ b/arch/riscv/include/asm/image.h
@@ -42,7 +42,7 @@
* @res2: reserved
* @magic: Magic number (RISC-V specific; deprecated)
* @magic2:Magic number 2 (to match the ARM64 'magic' field pos)
- * @res4: reserved (will be used for PE COFF offset)
+ * @res3: reserved (will be used for PE COFF offset)
*
* The intention is for this header format to be shared between multiple
* architectures to avoid a proliferation of image header formats.
@@ -59,7 +59,7 @@ struct riscv_image_header {
u64 res2;
u64 magic;
u32 magic2;
- u32 res4;
+ u32 res3;
};
#endif /* __ASSEMBLY__ */
#endif /* __ASM_IMAGE_H */
--
2.21.0
Re: [PATCH] Documentation: admin-guide: add earlycon documentation for the sifive serial driver
Hi Paul,
On Wed, Oct 9, 2019 at 1:09 AM Paul Walmsley wrote:
> Document earlycon usage for the SiFive serial port driver in the same
> fashion as for the other serial port IP blocks, since the SiFive
> serial port driver supports it.
>
> Signed-off-by: Paul Walmsley
> Reported-by: Andreas Schwab
> Cc: Christoph Hellwig
Thanks for your patch!
Why do you need this?
I believe risc-v is DT-only, so if chosen/stdout-path is set up, just
passing "earlycon" (without any options) should work.
> ---
> Documentation/admin-guide/kernel-parameters.txt | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt
> b/Documentation/admin-guide/kernel-parameters.txt
> index c7ac2f3ac99f..90becb00221b 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -1106,6 +1106,12 @@
> address must be provided, and the serial port must
> already be setup and configured.
>
> + sifive,
> + Start an early, polled-mode console on a SiFive
> + serial port at the specified address. The port must
> + already be setup and configured. Options are not
> + yet supported.
> +
> earlyprintk=[X86,SH,ARM,M68k,S390]
> earlyprintk=vga
> earlyprintk=sclp
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
