From: "Alex Bennée" <alex.bennee@linaro.org>
To: Ruslan Ruslichenko <ruslichenko.r@gmail.com>
Cc: BALATON Zoltan <balaton@eik.bme.hu>,
Peter Maydell <peter.maydell@linaro.org>,
qemu-devel@nongnu.org, qemu-arm@nongnu.org,
artem_mygaiev@epam.com, volodymyr_babchuk@epam.com,
takahiro.nakata.wr@renesas.com,
"Edgar E . Iglesias" <edgar.iglesias@gmail.com>,
Ruslan_Ruslichenko@epam.com
Subject: Re: [PATCH 00/27] hw/arm: Add generic FDT-based machine and infrastructure
Date: Fri, 06 Feb 2026 18:34:51 +0000 [thread overview]
Message-ID: <87h5rtn2k4.fsf@draig.linaro.org> (raw)
In-Reply-To: <CAN-aV1F5SjqBw-OP7v68mOAy=3+53HgqjBCrCOUAwTMHUUJAHw@mail.gmail.com> (Ruslan Ruslichenko's message of "Thu, 29 Jan 2026 16:39:27 +0100")
Ruslan Ruslichenko <ruslichenko.r@gmail.com> writes:
> On Thu, Jan 29, 2026 at 1:23 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>> BALATON Zoltan <balaton@eik.bme.hu> writes:
>>
>> > On Wed, 28 Jan 2026, Alex Bennée wrote:
>> >> Ruslan Ruslichenko <ruslichenko.r@gmail.com> writes:
>> >>> On Tue, Jan 27, 2026 at 11:03 AM Peter Maydell <peter.maydell@linaro.org> wrote:
>> >>>> On Mon, 26 Jan 2026 at 17:43, Ruslan Ruslichenko
>> >>>> <ruslichenko.r@gmail.com> wrote:
>> >>>>>
>> >>>>> From: Ruslan Ruslichenko <Ruslan_Ruslichenko@epam.com>
>> >>>>>
>> >>>>> This patch series introduces new ARM machine model, arm-generic-fdt, and the underlying infrastructure required to instantiate a QEMU machine from a Device Tree.
>> >>>>
>> >>>> I'm afraid this has been a feature that has been suggested from
>> >>>> time to time, but which I don't think is workable in general.
>> >>>>
>> >>>> Device tree files are designed to provide enough information to
>> >>>> the guest kernel to allow it to find non-probeable hardware. They
>> >>>> are not designed to provide enough information to QEMU to allow
>> >>>> it to create and wire up all the hardware present on the system.
>> >>>>
>> >>>> There are specific niches where it can be made to work -- I think
>> >>>> Xilinx have or had a setup where they were generating an FPGA
>> >>>> model and a device tree and a guest kernel all from the same
>> >>>> single data source, so they could put everything necessary into
>> >>>> the dtb, for example -- but I don't think it works in the
>> >>>> general case. As one simple example, the DTB doesn't generally
>> >>>> have any information about how the Secure world works in an Arm
>> >>>> system, because Linux doesn't care about the Secure world. It
>> >>>> also doesn't usually have information that the guest OS can
>> >>>> probe for itself at runtime.
>> >>>>
>> >>>> There has been periodic discussion of more flexible user-driven
>> >>>> board creation, but that has generally been with the idea of using
>> >>>> the QMP monitor to orchestrate creation and connection of device
>> >>>> models.
>> >>>>
>> >>> I agree that a guest Device Tree is insufficient for describing a
>> >>> complete QEMU machine model.
>> >>> However, we separate the guest configuration from the machine
>> >>> definition. The -hw-dtb option allows the user to provide a
>> >>> QEMU-specific system description.
>> >>> Those hw-dtb would not be passed to Linux Guest VM.
>> >>>
>> >>> The fact that this workflow has been successfully used in production
>> >>> by AMD/Xilinx demonstrates that FDT is a feasible format.
>> >>
>> >> Where are the extensions to the FDT used for hw-dtb documented? How does
>> >> it deal with PCI devices and the Secure world?
>> >
>> > PCI devices don't need to be included in a machine description as they
>> > are not part of the machine only the PCI host is. PCI devices are
>> > plugged into the host with -device as with boards defined in C.
>>
>> But if we are talking about a general purpose HW description DSL then we
>> do need to describe systems with embedded PCI busses and soldered on PCI
>> devices.
>>
>> > For
>> > PCI devices that are instantiated by default on some machines
>> > including a node below the PCI host should likely work. I know nothing
>> > about secure world, that may need some extensions but fdt is basically
>> > describing objects and their properties so if it's one or a hierarchy
>> > of QOM objects that needs to be instantiated with defined properties
>> > it should be possible to describe it in fdt.
>>
>> OK - hence I was asking for the documentation for how this is done. You
>> can't just assert that anything can be described in DTB because its
>> original use case is purely for OS descriptions. If we want to explore
>> this series further then I would suggest including some hw-dtb's in the
>> series to replicate some of our more embedded machines in the next
>> revision.
>>
>
> Sure, we can consider more functional examples for the v2 patch series.
> Would you like to see some specific machine constructed with hw-dtb?
>
> Also answering the previous question regarding Secure world.
> We can define parent nodes in the FDT that represent Memory Region
> containers, which are then mapped into the CPU's Secure Address Space.
>
> Any child devices defined under these nodes in the FDT are automatically
> instantiated as subregions of that parent container. This ensures they
> are only visible to the Secure World.
I would suggest we pick a representative sample of non-virt machine
types to model in hw-dtb and extend the functional tests to run both. We
have these tests (trimmed of virt, pc, and q35 machines):
riscv64/test_boston.py:36: self.set_machine('boston-aia')
riscv64/test_sifive_u.py:30: self.set_machine('sifive_u')
riscv64/test_migration.py:17: self.set_machine('spike')
riscv64/test_opensbi.py:24: self.set_machine('spike')
riscv64/test_opensbi.py:28: self.set_machine('sifive_u')
sparc64/test_tuxrun.py:27: self.set_machine('sun4u')
sparc64/test_sun4u.py:28: self.set_machine('sun4u')
sparc64/test_migration.py:13: self.set_machine('sun4u')
sparc64/test_migration.py:17: self.set_machine('sun4u')
sparc64/test_migration.py:21: self.set_machine('sun4u')
mipsel/test_malta.py:41: self.set_machine('malta')
mipsel/test_malta.py:97: self.set_machine('malta')
ppc/test_74xx.py:19: self.set_machine('g3beige')
ppc/test_74xx.py:28: self.set_machine('g3beige')
ppc/test_74xx.py:37: self.set_machine('g3beige')
ppc/test_74xx.py:46: self.set_machine('g3beige')
ppc/test_74xx.py:55: self.set_machine('g3beige')
ppc/test_74xx.py:64: self.set_machine('g3beige')
ppc/test_74xx.py:73: self.set_machine('g3beige')
ppc/test_74xx.py:82: self.set_machine('g3beige')
ppc/test_74xx.py:91: self.set_machine('g3beige')
ppc/test_74xx.py:100: self.set_machine('g3beige')
ppc/test_74xx.py:109: self.set_machine('g3beige')
ppc/test_74xx.py:118: self.set_machine('g3beige')
mips64el/test_malta.py:46: self.set_machine('malta')
mips64el/test_malta.py:72: self.set_machine('malta')
mips64el/test_malta.py:145: self.set_machine('malta')
ppc/test_tuxrun.py:27: self.set_machine('ppce500')
mipsel/test_tuxrun.py:27: self.set_machine('malta')
ppc/test_bamboo.py:29: self.set_machine('bamboo')
sparc/test_sun4m.py:18: self.set_machine('SS-20')
ppc/test_replay.py:25: self.set_machine('g3beige')
ppc/test_replay.py:29: self.set_machine('mac99')
mipsel/test_replay.py:30: self.set_machine('malta')
sparc/test_replay.py:19: self.set_machine('SS-10')
mips64el/test_tuxrun.py:27: self.set_machine('malta')
mips64/test_tuxrun.py:27: self.set_machine('malta')
ppc/test_40p.py:40: self.set_machine('40p')
ppc/test_40p.py:55: self.set_machine('40p')
ppc/test_40p.py:66: self.set_machine('40p')
ppc/test_40p.py:81: self.set_machine('40p')
sparc/test_migration.py:13: self.set_machine('SS-4')
sparc/test_migration.py:17: self.set_machine('SS-5')
sparc/test_migration.py:21: self.set_machine('SS-4')
mips64el/test_replay.py:22: self.set_machine('malta')
mips64el/test_replay.py:45: self.set_machine('malta')
ppc/test_amiga.py:25: self.set_machine('amigaone')
avr/test_uno.py:21: self.set_machine('arduino-uno')
ppc/test_ppe42.py:68: self.set_machine('ppe42_machine')
avr/test_mega2560.py:38: self.set_machine('arduino-mega-2560-v3')
mips64el/test_fuloong2e.py:33: self.set_machine('fuloong2e')
mips64el/test_fuloong2e.py:54: self.set_machine('fuloong2e')
ppc/test_migration.py:13: self.set_machine('sam460ex')
ppc/test_migration.py:17: self.set_machine('sam460ex')
ppc/test_migration.py:21: self.set_machine('sam460ex')
ppc/test_mpc8544ds.py:27: self.set_machine('mpc8544ds')
ppc/test_sam460ex.py:19: self.set_machine('sam460ex')
ppc/test_mac.py:28: self.set_machine('g3beige')
ppc/test_mac.py:32: self.set_machine('mac99')
ppc/test_virtex_ml507.py:27: self.set_machine('virtex-ml507')
riscv32/test_migration.py:13: self.set_machine('spike')
riscv32/test_migration.py:21: self.set_machine('spike')
mips/test_malta.py:57: test.set_machine('malta')
mips/test_malta.py:108: self.set_machine('malta')
mips/test_malta.py:131: self.set_machine('malta')
sh4eb/test_r2d.py:18: self.set_machine('r2d')
or1k/test_sim.py:18: self.set_machine('or1k-sim')
alpha/test_replay.py:20: self.set_machine('clipper')
mips/test_tuxrun.py:27: self.set_machine('malta')
or1k/test_replay.py:19: self.set_machine('or1k-sim')
alpha/test_clipper.py:19: self.set_machine('clipper')
mips/test_replay.py:22: self.set_machine('malta')
mips/test_replay.py:43: self.set_machine('malta')
arm/test_tuxrun.py:30: self.set_machine('versatilepb')
alpha/test_migration.py:13: self.set_machine('clipper')
alpha/test_migration.py:17: self.set_machine('clipper')
alpha/test_migration.py:21: self.set_machine('clipper')
m68k/test_mcf5208evb.py:18: self.set_machine('mcf5208evb')
m68k/test_replay.py:21: self.set_machine('q800')
m68k/test_replay.py:35: self.set_machine('mcf5208evb')
arm/test_bpim2u.py:40: self.set_machine('bpim2u')
arm/test_bpim2u.py:61: self.set_machine('bpim2u')
arm/test_bpim2u.py:94: self.set_machine('bpim2u')
arm/test_bpim2u.py:142: self.set_machine('bpim2u')
rx/test_gdbsim.py:37: self.set_machine('gdbsim-r5f562n8')
rx/test_gdbsim.py:57: self.set_machine('gdbsim-r5f562n7')
m68k/test_nextcube.py:49: self.set_machine('next-cube')
m68k/test_nextcube.py:61: self.set_machine('next-cube')
s390x/test_reverse_debug.py:15: self.set_machine('s390-ccw-virtio')
arm/test_integratorcp.py:45: self.set_machine('integratorcp')
hppa/test_cdboot.py:19: self.set_machine('B160L')
m68k/test_q800.py:19: self.set_machine('q800')
hppa/test_seabios.py:27: self.set_machine('B160L')
hppa/test_seabios.py:31: self.set_machine('C3700')
arm/test_cubieboard.py:38: self.set_machine('cubieboard')
arm/test_cubieboard.py:69: self.set_machine('cubieboard')
arm/test_cubieboard.py:107: self.set_machine('cubieboard')
arm/test_realview.py:21: self.set_machine('realview-eb-mpcore')
s390x/test_pxelinux.py:56: self.set_machine('s390-ccw-virtio')
arm/test_sx1.py:40: self.set_machine('sx1')
arm/test_sx1.py:51: self.set_machine('sx1')
arm/test_sx1.py:62: self.set_machine('sx1')
arm/test_replay.py:38: self.set_machine('cubieboard')
arm/test_replay.py:60: self.set_machine('vexpress-a9')
arm/test_aspeed_ast2600_buildroot.py:25: self.set_machine('ast2600-evb')
arm/test_aspeed_ast2600_buildroot.py:99: self.set_machine('ast2600-evb')
arm/test_canona1100.py:27: self.set_machine('canon-a1100')
sh4/test_r2d.py:21: self.set_machine('r2d')
xtensa/test_replay.py:19: self.set_machine('lx60')
arm/test_max78000fthr.py:19: self.set_machine('max78000fthr')
arm/test_raspi2.py:42: self.set_machine('raspi2b')
arm/test_raspi2.py:68: self.set_machine('raspi2b')
microblaze/test_replay.py:20: self.set_machine('petalogix-s3adsp1800')
sh4/test_tuxrun.py:27: self.set_machine('r2d')
xtensa/test_lx60.py:18: self.set_machine('lx60')
arm/test_smdkc210.py:24: self.set_machine('smdkc210')
arm/test_microbit.py:19: self.set_machine('microbit')
arm/test_collie.py:22: self.set_machine('collie')
arm/test_quanta_gsj.py:35: self.set_machine('quanta-gsj')
arm/test_quanta_gsj.py:71: self.set_machine('quanta-gsj')
arm/test_vexpress.py:18: self.set_machine('vexpress-a9')
microblaze/test_s3adsp1800.py:29: self.set_machine('petalogix-s3adsp1800')
microblaze/test_s3adsp1800.py:46: self.set_machine('petalogix-s3adsp1800')
arm/test_emcraft_sf2.py:26: self.set_machine('emcraft-sf2')
arm/test_aspeed_ast1060.py:21: self.set_machine('ast1060-evb')
arm/test_aspeed_ast1060.py:35: self.vm.set_machine("ast1060-evb")
arm/test_aspeed_rainier.py:16: self.set_machine('rainier-bmc')
arm/test_aspeed_rainier.py:42: self.set_machine('rainier-bmc')
arm/test_aspeed_ast1030.py:21: self.set_machine('ast1030-evb')
arm/test_aspeed_ast1030.py:40: self.set_machine('ast1030-evb')
arm/test_aspeed_ast1030.py:72: self.vm.set_machine("ast1030-evb")
arm/test_aspeed_ast2600_sdk.py:35: self.set_machine('ast2600-evb')
arm/test_aspeed_ast2600_sdk.py:74: self.vm.set_machine("ast2600-evb")
arm/test_stellaris.py:18: self.set_machine('lm3s6965evb')
arm/test_stellaris.py:32: self.set_machine('lm3s811evb')
arm/test_migration.py:13: self.set_machine('npcm750-evb')
arm/test_migration.py:17: self.set_machine('npcm750-evb')
arm/test_migration.py:21: self.set_machine('npcm750-evb')
arm/test_aspeed_ast2500.py:19: self.set_machine('ast2500-evb')
arm/test_aspeed_ast2500.py:45: self.set_machine('ast2500-evb')
aarch64/test_raspi4.py:37: self.set_machine('raspi4b')
aarch64/test_raspi4.py:67: self.set_machine('raspi4b')
arm/test_orangepi.py:51: self.set_machine('orangepi-pc')
arm/test_orangepi.py:72: self.set_machine('orangepi-pc')
arm/test_orangepi.py:105: self.set_machine('orangepi-pc')
arm/test_orangepi.py:149: self.set_machine('orangepi-pc')
arm/test_orangepi.py:185: self.set_machine('orangepi-pc')
ppc64/test_reverse_debug.py:25: self.set_machine('pseries')
ppc64/test_reverse_debug.py:33: self.set_machine('powernv')
aarch64/test_imx8mp_evk.py:53: self.set_machine('imx8mp-evk')
ppc64/test_migration.py:14: self.set_machine('mac99')
ppc64/test_migration.py:18: self.set_machine('mac99')
ppc64/test_migration.py:22: self.set_machine('mac99')
ppc64/test_e500.py:22: self.set_machine('ppce500')
aarch64/test_raspi3.py:24: self.set_machine('raspi3b')
ppc64/test_mac99.py:23: self.set_machine('mac99')
ppc64/test_replay.py:21: self.set_machine('ppce500')
ppc64/test_replay.py:34: self.set_machine('pseries')
aarch64/test_aspeed_ast2700.py:151: self.set_machine('ast2700a1-evb')
aarch64/test_aspeed_ast2700.py:163: self.set_machine('ast2700a1-evb')
aarch64/test_aspeed_ast2700.py:174: self.set_machine('ast2700a1-evb')
aarch64/test_aspeed_ast2700.py:178: self.vm.set_machine('ast2700a1-evb,fmc-model=w25q512jv')
aarch64/test_migration.py:13: self.set_machine('quanta-gsj')
aarch64/test_migration.py:17: self.set_machine('quanta-gsj')
aarch64/test_migration.py:21: self.set_machine('quanta-gsj')
aarch64/test_aspeed_ast2700fc.py:152: self.set_machine('ast2700fc')
aarch64/test_aspeed_ast2700fc.py:164: self.set_machine('ast2700fc')
Thinking about it Arm's sbsa-ref would be an interesting one to check
for fidelity as the firmware stack targets an explicit HW platform.
>
>> >>> In contrast, QMP usage may end up even more complex and less
>> >>> maintainable for the task of full system modeling.
>> >>> To my understanding, this would need to generate too long configs,
>> >>> which may eventually require some intermediate format by itself.
>> >>>
>> >>> I am proposing to use FDT as a serialization format to describe a
>> >>> machine configuration. Theoretically we can use other formats, like
>> >>> XML, but in my opinion FDT perfectly matches the requirements.
>> >>
>> >> The QMP interface is self-documenting and introspectable and used for
>> >> the management of QEMU including things like hotplug. It is also QOM
>> >> aware so a natural fit for dealing with the underlying QOM machinery.
>> >
>> > QOM seems to be more about operating a machine rather than defining it
>> > for which fdt is an already established common way.
>> >
>> >> Previous discussions have entertained the idea of making the parsing of
>> >> hw-dtb an external script which would then translate into QMP commands
>> >> to build up the machine.
>> >
>> > That would be possible but it seems that directly parsing fdt in QEMU
>> > could be done with very few code and with some additional support from
>> > devices the latter of which is probably also needed when trying to
>> > interactively define a machine from command line, monitor or QMP.
>>
>> I agree QMP would need some new APIs to support this - and also have
>> some examples of how to replicate the existing machines over a pure QMP
>> interface.
>>
>> >
>> > Regards,
>> > BALATON Zoltan
>>
>> --
>> Alex Bennée
>> Virtualisation Tech Lead @ Linaro
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
next prev parent reply other threads:[~2026-02-06 18:35 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-26 17:42 [PATCH 00/27] hw/arm: Add generic FDT-based machine and infrastructure Ruslan Ruslichenko
2026-01-26 17:42 ` [PATCH 01/27] system/device_tree: update qemu_fdt_getprop/_cell Ruslan Ruslichenko
2026-01-27 1:56 ` David Gibson
2026-01-26 17:42 ` [PATCH 02/27] system/device_tree: add few parsing and traversal helpers Ruslan Ruslichenko
2026-01-27 2:19 ` David Gibson
2026-01-27 21:22 ` Ruslan Ruslichenko
2026-01-26 17:42 ` [PATCH 03/27] util/log: add log entry for fdt generic utils Ruslan Ruslichenko
2026-01-26 17:42 ` [PATCH 04/27] hw/core: introduce generic FDT device model registry Ruslan Ruslichenko
2026-01-26 17:42 ` [PATCH 05/27] hw/core/fdt_generic: implement FDT machine creation helpers Ruslan Ruslichenko
2026-01-26 17:42 ` [PATCH 06/27] hw/core/fdt_generic: add cpu clusters management Ruslan Ruslichenko
2026-01-26 17:42 ` [PATCH 07/27] hw/core/fdt_generic_util: implement main fdt parse routine Ruslan Ruslichenko
2026-01-26 17:42 ` [PATCH 08/27] hw/core/fdt_generic_util: implement fdt_init_qdev Ruslan Ruslichenko
2026-01-26 17:42 ` [PATCH 09/27] hw/core/fdt_generic_util: initilize qdev properties from fdt Ruslan Ruslichenko
2026-01-26 17:42 ` [PATCH 10/27] hw/core/fdt_generic_util: actually realize device Ruslan Ruslichenko
2026-01-26 17:42 ` [PATCH 11/27] hw/core/fdt_generic_util: add TYPE_FDT_GENERIC_MMAP Ruslan Ruslichenko
2026-01-26 17:42 ` [PATCH 12/27] hw/core/fdt_generic_util: add TYPE_FDT_GENERIC_INTC Ruslan Ruslichenko
2026-01-26 17:42 ` [PATCH 13/27] hw/core/fdt_generic_util: implement fdt_get_irq/_info API Ruslan Ruslichenko
2026-01-26 17:43 ` [PATCH 14/27] hw/core/fdt_generic_util: map device memory Ruslan Ruslichenko
2026-01-26 17:43 ` [PATCH 15/27] hw/core/fdt_generic_util: Connect device irqs Ruslan Ruslichenko
2026-01-26 17:43 ` [PATCH 16/27] hw/core/fdt_generic_util: realize cpu clusters Ruslan Ruslichenko
2026-01-26 17:43 ` [PATCH 17/27] hw/core: add fdt_generic to the build Ruslan Ruslichenko
2026-01-26 17:43 ` [PATCH 18/27] hw/core/machine: add '-hw-dtb' option for machine Ruslan Ruslichenko
2026-01-27 8:40 ` Zhao Liu
2026-01-27 20:12 ` Ruslan Ruslichenko
2026-01-26 17:43 ` [PATCH 19/27] hw/arm: add generic ARM machine initialized by FDT Ruslan Ruslichenko
2026-01-26 17:43 ` [PATCH 20/27] hw/core/sysbus: implement FDT_GENERIC_MMAP_CLASS interface Ruslan Ruslichenko
2026-01-26 17:43 ` [PATCH 21/27] hw/intc/arm_gic: implement FDT_GENERIC_INTC and fdt support Ruslan Ruslichenko
2026-01-26 17:43 ` [PATCH 22/27] target/arm/cpu: add fdt support for armv8-timer Ruslan Ruslichenko
2026-01-26 17:43 ` [PATCH 23/27] qom/object: export object_resolve_link() Ruslan Ruslichenko
2026-01-26 17:43 ` [PATCH 24/27] system/memory: add setters for MemoryRegion properties Ruslan Ruslichenko
2026-01-26 17:43 ` [PATCH 25/27] system/memory: implement FDT_GENERIC_MMAP interface Ruslan Ruslichenko
2026-01-26 17:43 ` [PATCH 26/27] hw/core/fdt_generic_util: initialize serial devices Ruslan Ruslichenko
2026-01-26 17:43 ` [PATCH 27/27] system/memory: add QOM aliases for fdt support Ruslan Ruslichenko
2026-01-27 10:02 ` [PATCH 00/27] hw/arm: Add generic FDT-based machine and infrastructure Peter Maydell
2026-01-27 14:29 ` BALATON Zoltan
2026-01-27 18:18 ` Ruslan Ruslichenko
2026-01-28 17:48 ` Alex Bennée
2026-01-28 21:41 ` BALATON Zoltan
2026-01-29 12:23 ` Alex Bennée
2026-01-29 15:39 ` Ruslan Ruslichenko
2026-02-06 18:34 ` Alex Bennée [this message]
2026-01-29 16:11 ` Edgar E. Iglesias
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=87h5rtn2k4.fsf@draig.linaro.org \
--to=alex.bennee@linaro.org \
--cc=Ruslan_Ruslichenko@epam.com \
--cc=artem_mygaiev@epam.com \
--cc=balaton@eik.bme.hu \
--cc=edgar.iglesias@gmail.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=ruslichenko.r@gmail.com \
--cc=takahiro.nakata.wr@renesas.com \
--cc=volodymyr_babchuk@epam.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.