From: Peter Maydell <peter.maydell@linaro.org>
To: qemu-arm@nongnu.org, qemu-devel@nongnu.org
Cc: patches@linaro.org, Igor Mammedov <imammedo@redhat.com>,
Hongbo Zhang <hongbo.zhang@linaro.org>
Subject: [Qemu-devel] [PATCH 1/5] hw/arm/boot: Fix block comment style in arm_load_kernel()
Date: Thu, 31 Jan 2019 11:22:36 +0000 [thread overview]
Message-ID: <20190131112240.8395-2-peter.maydell@linaro.org> (raw)
In-Reply-To: <20190131112240.8395-1-peter.maydell@linaro.org>
Fix the block comment style in arm_load_kernel() to QEMU's
current style preferences. This will allow us to do some
refactoring of this function without checkpatch complaining
about the code-motion patches.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
hw/arm/boot.c | 30 ++++++++++++++++++++----------
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/hw/arm/boot.c b/hw/arm/boot.c
index c7a67af7a97..6f9ceeb0e89 100644
--- a/hw/arm/boot.c
+++ b/hw/arm/boot.c
@@ -965,7 +965,8 @@ void arm_load_kernel(ARMCPU *cpu, struct arm_boot_info *info)
static const ARMInsnFixup *primary_loader;
AddressSpace *as = arm_boot_address_space(cpu, info);
- /* CPU objects (unlike devices) are not automatically reset on system
+ /*
+ * CPU objects (unlike devices) are not automatically reset on system
* reset, so we must always register a handler to do so. If we're
* actually loading a kernel, the handler is also responsible for
* arranging that we start it correctly.
@@ -974,7 +975,8 @@ void arm_load_kernel(ARMCPU *cpu, struct arm_boot_info *info)
qemu_register_reset(do_cpu_reset, ARM_CPU(cs));
}
- /* The board code is not supposed to set secure_board_setup unless
+ /*
+ * The board code is not supposed to set secure_board_setup unless
* running its code in secure mode is actually possible, and KVM
* doesn't support secure.
*/
@@ -987,7 +989,8 @@ void arm_load_kernel(ARMCPU *cpu, struct arm_boot_info *info)
if (!info->kernel_filename || info->firmware_loaded) {
if (have_dtb(info)) {
- /* If we have a device tree blob, but no kernel to supply it to (or
+ /*
+ * If we have a device tree blob, but no kernel to supply it to (or
* the kernel is supposed to be loaded by the bootloader), copy the
* DTB to the base of RAM for the bootloader to pick up.
*/
@@ -1002,7 +1005,8 @@ void arm_load_kernel(ARMCPU *cpu, struct arm_boot_info *info)
try_decompressing_kernel = arm_feature(&cpu->env,
ARM_FEATURE_AARCH64);
- /* Expose the kernel, the command line, and the initrd in fw_cfg.
+ /*
+ * Expose the kernel, the command line, and the initrd in fw_cfg.
* We don't process them here at all, it's all left to the
* firmware.
*/
@@ -1022,7 +1026,8 @@ void arm_load_kernel(ARMCPU *cpu, struct arm_boot_info *info)
}
}
- /* We will start from address 0 (typically a boot ROM image) in the
+ /*
+ * We will start from address 0 (typically a boot ROM image) in the
* same way as hardware.
*/
return;
@@ -1049,7 +1054,8 @@ void arm_load_kernel(ARMCPU *cpu, struct arm_boot_info *info)
if (info->nb_cpus == 0)
info->nb_cpus = 1;
- /* We want to put the initrd far enough into RAM that when the
+ /*
+ * We want to put the initrd far enough into RAM that when the
* kernel is uncompressed it will not clobber the initrd. However
* on boards without much RAM we must ensure that we still leave
* enough room for a decent sized initrd, and on boards with large
@@ -1066,12 +1072,14 @@ void arm_load_kernel(ARMCPU *cpu, struct arm_boot_info *info)
kernel_size = arm_load_elf(info, &elf_entry, &elf_low_addr,
&elf_high_addr, elf_machine, as);
if (kernel_size > 0 && have_dtb(info)) {
- /* If there is still some room left at the base of RAM, try and put
+ /*
+ * If there is still some room left at the base of RAM, try and put
* the DTB there like we do for images loaded with -bios or -pflash.
*/
if (elf_low_addr > info->loader_start
|| elf_high_addr < info->loader_start) {
- /* Set elf_low_addr as address limit for arm_load_dtb if it may be
+ /*
+ * Set elf_low_addr as address limit for arm_load_dtb if it may be
* pointing into RAM, otherwise pass '0' (no limit)
*/
if (elf_low_addr < info->loader_start) {
@@ -1132,7 +1140,8 @@ void arm_load_kernel(ARMCPU *cpu, struct arm_boot_info *info)
fixupcontext[FIXUP_BOARDID] = info->board_id;
fixupcontext[FIXUP_BOARD_SETUP] = info->board_setup_addr;
- /* for device tree boot, we pass the DTB directly in r2. Otherwise
+ /*
+ * for device tree boot, we pass the DTB directly in r2. Otherwise
* we point to the kernel args.
*/
if (have_dtb(info)) {
@@ -1185,7 +1194,8 @@ void arm_load_kernel(ARMCPU *cpu, struct arm_boot_info *info)
info->write_board_setup(cpu, info);
}
- /* Notify devices which need to fake up firmware initialization
+ /*
+ * Notify devices which need to fake up firmware initialization
* that we're doing a direct kernel boot.
*/
object_child_foreach_recursive(object_get_root(),
--
2.20.1
next prev parent reply other threads:[~2019-01-31 11:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-31 11:22 [Qemu-devel] [PATCH 0/5] hw/arm/boot: Support DTB autoload for firmware-only boots Peter Maydell
2019-01-31 11:22 ` Peter Maydell [this message]
2019-01-31 11:22 ` [Qemu-devel] [PATCH 2/5] hw/arm/boot: Factor out "direct kernel boot" code into its own function Peter Maydell
2019-02-05 15:16 ` Igor Mammedov
2019-02-05 15:24 ` Peter Maydell
2019-01-31 11:22 ` [Qemu-devel] [PATCH 3/5] hw/arm/boot: Factor out "set up firmware boot" code Peter Maydell
2019-01-31 11:22 ` [Qemu-devel] [PATCH 4/5] hw/arm/boot: Clarify why arm_setup_firmware_boot() doesn't set env->boot_info Peter Maydell
2019-01-31 11:22 ` [Qemu-devel] [PATCH 5/5] hw/arm/boot: Support DTB autoload for firmware-only boots Peter Maydell
2019-01-31 22:44 ` [Qemu-devel] [PATCH 0/5] " Richard Henderson
2019-02-05 15:18 ` Igor Mammedov
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=20190131112240.8395-2-peter.maydell@linaro.org \
--to=peter.maydell@linaro.org \
--cc=hongbo.zhang@linaro.org \
--cc=imammedo@redhat.com \
--cc=patches@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.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).