In preparation of the migration of the mailman mailing-list currently
hosted on the denx.de infrastructure, migrate the links in the code,
comments and documentation to https://patch.msgid.link to be future proof
and always link to the expected content data and uses the message-id in
the URL which will help find the appropriate e-mail in the future.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Fix the incorrect use of 'your' instead of 'you are' and reflow the text
around it.
Fixes: af9e6ad4ab ("board_f: Add new function to allow runtime DTB selection")
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
The patch is output from
scripts/mailmapper > tmp; mv tmp .mailmap
with moving <swarren@wwwdotorg.org> and <swarren@wwwdotorg.org> to the same
block with "This contributor prefers not to receive mails" description.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Name and email address has changed but format wasn't correct. Keep origin
line which is doing conversion from xilinx.com to amd.com and then have
conversion from AMD to Qualcomm. Also move name to proper location.
Fixes: f21920f7e7 (".mailmap: update e-mail address for Abbarapu Venkatesh Yadav")
Signed-off-by: Michal Simek <michal.simek@amd.com>
This reverts:
- commit e49c84f7bb ("doc: usage: cmd: reset: specify when the -edl
option is available")
- commit 1076feb8a3 ("cmd: boot: fix edl being shown when not
supported")
- commit 63c806ba0e ("qcom_defconfig: enable psci based sysreset")
- commit ef06c5d76f ("cmd: boot: Add '-edl' option to reset command
documentation")
- commit 32825eaddc ("sysreset: Implement PSCI based reset to EDL mode
for QCOM SoCs")
- commit fcb48b8981 ("drivers: sysreset: Add sysreset op that can take
arguments")
There was a conflict reverting commit 63c806ba0e ("qcom_defconfig:
enable psci based sysreset") due to commit 02ef1859b4 ("configs:
Resync with savedefconfig"), but the conflict resolution was trivial.
The args support for the sysreset uclass contains a logic bug. The first
sysreset device implementing the request_arg callback will consume the
args, not support the specified arg and thus return -EPROTONOSUPPORT
which will stop the iteration over all sysreset devices.
This is an issue if one has multiple sysreset devices and each with
support for different (valid) args. If a sysreset device implements a
-dummy argument and another -foo and a user calls reset -dummy from the
U-Boot CLI, it'll depend on which sysreset device will be attempted
first. If it is the one implementing -foo, it'll return it doesn't
support the argument with -EPROTONOSUPPORT in which case the device
implementing -dummy will never be attempted and instead we'll do a cold
reset which is very likely not what's expected from the user.
Casey suggested[1] we revert this and start from scratch again with a
different implementation instead.
[1] https://lore.kernel.org/u-boot/77ff0f56-5c3b-42e7-bdd1-bf90296da900@linaro.org/
Acked-by: Casey Connolly <casey.connolly@linaro.org>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
CI: https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/pipelines/30574
A last minute fix for the release, the UFS controller on the new Milos
SoC (used in the Fairphone Gen. 6) needs a stub driver for it's ref
clock (similar to SM8650 before) and a handful of other clocks to get
the UFS controller probed.
This change shouldn't impact any other platforms.
The fractional PLL used on iMX8MQ is not pll14xx, it is different
PLL and not exist in u-boot. Add this fractional PLL driver and
update iMX8MQ clock driver to adapt this fraction PLL.
Fixes: 11c8ab01f3 ("clk: imx8mq: Add a clock driver for the imx8mq")
Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Replace mac[5] += offset with a proper 48-bit MAC address add to avoid
overflow issues when mac[5] was close to 255.
Example:
i.MX95 MAC2: 00:11:22:33:44:FE + 6
Old: 00:11:22:33:44:04 (overflow, wraps to 0)
New: 00:11:22:33:45:04 (correct carry from mac[5] to mac[4])
Signed-off-by: Alice Guo <alice.guo@nxp.com>
Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
After supporting get DRAM size from SM, the trampoline buffer address
still depends on PHYS_SDRAM_SIZE. If the real DDR size is less than
PHYS_SDRAM_SIZE, the trampoline buffer address is invalid and SPL will
crash. So use board_phys_sdram_size to get real DDR size to calculate
correct address.
Fixes: e1cc7117b6 ("imx9: scmi: Get DDR size through SM SCMI API")
Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Tested-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
Corechips SL6341 is a 4-port USB 2.0 and 3.0 hub controller. It always
requires external 1V1 power and can optionally use external 3V3 power
(or alternatively it has a 5V->3V3 LDO built in to derive 3V3 power from
VBUS). It also exposes a reset pin.
Device tree bindings are merged for upstream release with Linux 7.1 as
commit bfcb86e58f3a ("dt-bindings: usb: Add Corechips SL6341 USB2.0/3.0
hub controller") [1]
Link: https://github.com/torvalds/linux/commit/bfcb86e58f3a58d05b95970d81b94cb011982780 [1]
Signed-off-by: Alexey Charkov <alchark@flipper.net>
Reviewed-by: Marek Vasut <marek.vasut+usb@mailbox.org>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Use board_get_usable_ram_top() instead of get_effective_memsize() to
limit gd->ram_top.
Both board_get_usable_ram_top() and get_effective_memsize() are used to
set gd->ram_top in setup_dest_addr(). However, get_effective_memsize()
also sets gd->bd->bi_dram[0].size in dram_init_banksize(), which is
undesirable.
Prior to commit b9e6281632 ("arm: mediatek: mt8512:
drop dram_init_banksize()"), gd->bd->bi_dram[0].size was overridden in
a board-specific dram_init_banksize() implementation.
We can just use board_get_usable_ram_top() now to set gd->ram_top to the
correct value instead. Overriding gd->bd->bi_dram[0].size was a bit
confusing since it isn't easily apparent which order the functions that
set it are called.
Fixes: b9e6281632 ("arm: mediatek: mt8512: drop dram_init_banksize()")
Link: https://patch.msgid.link/20260615-mtk-fix-ram-size-v2-8-f72cfc52ce58@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>
Use board_get_usable_ram_top() instead of get_effective_memsize() to
set gd->ram_top to something <= 4GiB.
Both board_get_usable_ram_top() and get_effective_memsize() are used to
set gd->ram_top in setup_dest_addr(). However, get_effective_memsize()
also sets gd->bd->bi_dram[0].size in dram_init_banksize(), which is
undesirable.
Prior to commit d83bd9729d ("arm: mediatek: mt8195:
drop dram_init_banksize()"), gd->bd->bi_dram[0].size was overridden in
a board-specific dram_init_banksize() implementation. When that was
removed get_effective_memsize() set gd->bd->bi_dram[0].size to the wrong
value because of get_effective_memsize() being overridden in commit
af4cba9a05 ("arm: mediatek: mt8195: fix gd->ram_top limit")
We can just use board_get_usable_ram_top() now to set gd->ram_top to the
correct value instead. This is possible now, thanks to
LMB_LIMIT_DMA_BELOW_RAM_TOP being set by default for 64-bit Mediatek
ARM SoCs.
Fixes: d83bd9729d ("arm: mediatek: mt8195: drop dram_init_banksize()")
Link: https://patch.msgid.link/20260615-mtk-fix-ram-size-v2-7-f72cfc52ce58@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>
Use board_get_usable_ram_top() instead of get_effective_memsize() to
set gd->ram_top to something <= 4GiB.
Both board_get_usable_ram_top() and get_effective_memsize() are used to
set gd->ram_top in setup_dest_addr(). However, get_effective_memsize()
also sets gd->bd->bi_dram[0].size in dram_init_banksize(), which is
undesirable.
We can just use board_get_usable_ram_top() now to set gd->ram_top to the
correct value instead. This is possible now, thanks to
LMB_LIMIT_DMA_BELOW_RAM_TOP being set by default for 64-bit Mediatek
ARM SoCs.
Fixes: a7c682565b ("arm: mediatek: add support of MT8189 SoC family")
Link: https://patch.msgid.link/20260615-mtk-fix-ram-size-v2-6-f72cfc52ce58@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>
Use board_get_usable_ram_top() instead of get_effective_memsize() to
set gd->ram_top to something <= 4GiB.
Both board_get_usable_ram_top() and get_effective_memsize() are used to
set gd->ram_top in setup_dest_addr(). However, get_effective_memsize()
also sets gd->bd->bi_dram[0].size in dram_init_banksize(), which is
undesirable.
Prior to commit b3467e51e9 ("arm: mediatek: mt8188:
drop dram_init_banksize()"), gd->bd->bi_dram[0].size was overridden in
a board-specific dram_init_banksize() implementation. When that was
removed get_effective_memsize() set gd->bd->bi_dram[0].size to the wrong
value because of get_effective_memsize() being overridden in commit
7518e10cd2 ("arm: mediatek: mt8188: fix gd->ram_top limit").
We can just use board_get_usable_ram_top() now to set gd->ram_top to the
correct value instead. This is possible now, thanks to
LMB_LIMIT_DMA_BELOW_RAM_TOP being set by default for 64-bit Mediatek
ARM SoCs.
Fixes: b3467e51e9 ("arm: mediatek: mt8188: drop dram_init_banksize()")
Link: https://patch.msgid.link/20260615-mtk-fix-ram-size-v2-5-f72cfc52ce58@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>
Use board_get_usable_ram_top() instead of get_effective_memsize() to
set gd->ram_top to something <= 4GiB.
Both board_get_usable_ram_top() and get_effective_memsize() are used to
set gd->ram_top in setup_dest_addr(). However, get_effective_memsize()
also sets gd->bd->bi_dram[0].size in dram_init_banksize(), which is
undesirable.
Prior to commit bddd6bbef3 ("arm: mediatek: mt7988:
drop dram_init_banksize()"), gd->bd->bi_dram[0].size was overridden in
a board-specific dram_init_banksize() implementation. When that was
removed get_effective_memsize() set gd->bd->bi_dram[0].size to the wrong
value because of CFG_MAX_MEM_MAPPED.
Rather than continue to use an old-style CFG_ option and the potentially
confusing overriding of gd->bd->bi_dram[0].size (it is difficult to see
which order the functions that set it are called), we can just use
board_get_usable_ram_top() to set gd->ram_top to the correct value
instead. This is possible now, thanks to LMB_LIMIT_DMA_BELOW_RAM_TOP
being set by default for 64-bit Mediatek ARM SoCs.
The CFG_MAX_MEM_MAPPED option is removed since it is no longer needed.
The config header and Kconfig option are also removed since that was
the last CFG_ option.
Reported-by: Rudy Andram <rmandrad@gmail.com>
Closes: https://lore.kernel.org/u-boot/20260602162233.2418471-1-rmandrad@gmail.com/
Fixes: bddd6bbef3 ("arm: mediatek: mt7988: drop dram_init_banksize()")
Link: https://patch.msgid.link/20260615-mtk-fix-ram-size-v2-4-f72cfc52ce58@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>
Use board_get_usable_ram_top() instead of get_effective_memsize() to
set gd->ram_top to something <= 4GiB.
Both board_get_usable_ram_top() and get_effective_memsize() are used to
set gd->ram_top in setup_dest_addr(). However, get_effective_memsize()
also sets gd->bd->bi_dram[0].size in dram_init_banksize(), which is
undesirable.
Prior to commit 56183fb025 ("arm: mediatek: mt7987: drop
dram_init_banksize()"), gd->bd->bi_dram[0].size was overridden in
a board-specific dram_init_banksize() implementation. When that was
removed get_effective_memsize() set gd->bd->bi_dram[0].size to the wrong
value because of CFG_MAX_MEM_MAPPED.
Rather than continue to use an old-style CFG_ option and the potentially
confusing overriding of gd->bd->bi_dram[0].size (it is difficult to see
which order the functions that set it are called), we can just use
board_get_usable_ram_top() to set gd->ram_top to the correct value
instead. This is possible now, thanks to LMB_LIMIT_DMA_BELOW_RAM_TOP
being set by default for 64-bit Mediatek ARM SoCs.
On mt7987, there is already an implementation of
board_get_usable_ram_top() for other reasons, so it is modified to
also limit ram_top to 4GiB (mt7987 is currently the only thing that
sets CONFIG_MTK_TZ_MOVABLE=y so it is safe to change this here without
unintentional side-effects).
The CFG_MAX_MEM_MAPPED option is removed since it is no longer needed.
The config header and Kconfig option are also removed since that was
the last CFG_ option.
Fixes: 56183fb025 ("arm: mediatek: mt7987: drop dram_init_banksize()")
Link: https://patch.msgid.link/20260615-mtk-fix-ram-size-v2-3-f72cfc52ce58@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>
For AST2600 SPL with CONFIG_SPL_SEPARATE_BSS=y and
CONFIG_OF_SEPARATE=y, fdt_find_separate() expects the appended control
DTB at _image_binary_end.
The AST2600 SPL linker script aligned _image_binary_end via the
.binman_sym_table section. In builds where that section has no emitted
contents, objcopy -O binary does not include the alignment bytes in
spl/u-boot-spl-nodtb.bin. This causes the nodtb binary to end before
_image_binary_end, so the appended DTB is placed too early.
On evb-ast2600 this produced:
sizeof(spl/u-boot-spl-nodtb.bin) = 0xc92c
_image_binary_end = 0xc930
SPL then looked four bytes past the FDT header and failed with:
Missing DTB
No serial driver found
Move the 8-byte alignment into the preceding emitted __u_boot_list
section so the objcopy output and _image_binary_end agree.
Signed-off-by: Quentin Strydom <qstrydom0@gmail.com>
Pull request net-20260623.
net:
- airoha_eth: fix mt7531 mdio related initialization bug
net-legacy:
- cdp: reject CDP TLVs with a length below the 4-byte header
- Clear IP defragmentation state after returning a complete packet
net-lwip:
- Halt ethernet after network commands
cdp_receive() reads a 16-bit TLV length (tlen) from the packet and only
checks that it does not exceed the remaining buffer (tlen > len). It then
unconditionally does "tlen -= 4" to skip the TLV header. As tlen is a
u16, a crafted TLV with a length of 0..3 underflows tlen to ~65532-65535.
For a CDP_APPLIANCE_VLAN_TLV the underflowed length then drives the inner
"while (tlen > 0)" loop, which walks ~64KB past the receive buffer reading
*ss each step -> out-of-bounds read (crash / info-influence). A length of
0 additionally fails to advance pkt/len, hanging the parse loop.
Reject any TLV whose declared length is smaller than its own 4-byte
header. This is the same class of bug as the recent bootp/dhcpv6/sntp/nfs
fixes (unchecked length field), in a sibling LAN parser that was missed.
Verified with a standalone AddressSanitizer harness using the verbatim
cdp_receive()/cdp_compute_csum() routines: a 16-byte CDP frame with an
appliance-VLAN TLV of length 3 triggers a heap-buffer-overflow READ that
the check eliminates.
Fixes: f575ae1f7d ("net: Move CDP out of net.c")
Cc: stable@vger.kernel.org
Signed-off-by: Piyush Paliwal <piyushthepal@gmail.com>
Reviewed-by: Jerome Forissier <jerome.forissier@arm.com>
Add a introduce net_lwip_eth_stop() function and use that to stop the
network interface after each command that uses the network.
This makes the behavior the same as the legacy net code and avoids
potential issues with the network interface being left in an active
state after a command finishes.
The start/stop is reference-counted since there is at least one command
(dhcp) that calls another command (tftp) to avoid starting and stopping
the network interface multiple times in a single command.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Reviewed-by: Jerome Forissier <jerome.forissier@arm.com>
Change the return values of the lwip implementation of wget_do_request()
to be errno codes instead of command return codes.
wget_do_request() is not a command, so it does not make sense to return
command return codes from it. Also, the legacy network implementation of
wget_do_request() already returns errno codes so it is logical for the
lwip implementation to do the same.
This fixes a bug in try_load_from_uri_path() in efi_manager.c where it
checks that the return value of wget_do_request() is < 0. Before this
change, CMD_RET_FAILURE would not be considered an error since it has a
value of 1.
The value of ENODEV is used in places where there could actually be a
number of different causes of failure and it isn't possible to
discriminate (i.e. failing function returns NULL for all errors). Since
all callers of wget_do_request() don't propagate the error code, it
doesn't matter so much that this is not ideal, at least at this point in
time.
Fixes: 3c656c928b ("net: lwip: add wget command")
Reviewed-by: Jerome Forissier <jerome.forissier@arm.com>
Signed-off-by: David Lechner <dlechner@baylibre.com>
Split wget_do_request() into two functions to make error handling less
error-prone.
After a successful call to net_lwip_new_netif(), net_lwip_remove_netif()
must always be called to prevent leaks. This was missed in the CACERT
section of the code where we returned on error without cleaning up.
Instead of adding more calls to net_lwip_remove_netif(), refactor the
code into two functions. The outer function handles managing the netif
lifecycle. The inner function no longer has to worry about cleaning up
before returning on error.
To keep things simple, the `path` local variable is removed during the
refactoring. Instead, ctx.path is used directly everywhere.
Fixes: 3c656c928b ("net: lwip: add wget command")
Reviewed-by: Jerome Forissier <jerome.forissier@arm.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: David Lechner <dlechner@baylibre.com>
Add a unit test for the IP datagram reassembler (CONFIG_IP_DEFRAG) that
covers the duplicate-last-fragment scenario.
Without the fix the last fragment will re-trigger datagram delivery,
increasing udp_rx_count to 2 and effectively failing the test; with it
applied the test passes with udp_rx_count == 1.
Signed-off-by: Mateusz Furdyna <mateusz.furdyna@nokia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
During the IP defragmentation process, after the reassembly is finished
with the last packet arriving with MF=0, the reassembly state wrt.
static counters is not cleared. In case this last arriving packet with
MF=0 gets duplicated, payload bytes are mistakenly treated as hole data.
A malicious actor who can deliver fragmented IP traffic to a U-Boot
instance with CONFIG_IP_DEFRAG=y can corrupt memory via out-of-bound
writes and redirect control flow into attacker-supplied payload bytes
that already sit in `pkt_buff[]`.
Publicly available AI models are able to generate a reproducer based
on the provided information.
Fix: once the assembled packet has been handed back to the caller, mark
the reassembly state empty so that any further fragment (duplicate,
replay, or a brand-new datagram that happens to reuse the `ip_id`) goes
through the normal re-init path and rebuilds a clean hole list instead
of dereferencing payload bytes as struct hole.
Fixes: 5cfaa4e54d ("net: defragment IP packets")
Reported-by: Mariusz Madej <mariusz.madej@nokia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Alessandro Rubini <rubini@gnudd.com>
Signed-off-by: Mateusz Furdyna <mateusz.furdyna@nokia.com>
Private data isn't ready during bind time. The call of dev_get_priv()
function will return NULL. Thus we can't save mdio device pointer and
use it later during probe.
To solve an issue, we will move mt7531 mdio device binding to the probing
function of 'airoha-eth' driver.
All GDM ports (except of GDM1) are connected directly to their PHYs, so
corresponding mdio bus will be automatically probed during PHY setup.
GDM1 ports differ from other GDM ports. It connected to the airoha switch
device. The mt7531 mdio bus is used to manage link state of airoha switch
device ports (LAN ports 1-4 corresponds to PHYs 0x09-0x0C). Therefore,
manual probing of mt7531 mdio bus is required to be able set/query states
of corresponding LAN ports.
Fixes: 96d9e7c464 ("net: airoha: use mt7531 mdio for GDM1")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
It's possible to interrupt the fastboot command from the U-Boot shell
using the Ctrl-c keybinding.
Document this.
Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Reviewed-by: Sam Day <me@samcday.com>
When the `memory' efi selftest verifies the Devicetree memory reservation,
it accesses the memory_map buffer after it has been freed with free_pool().
Move the verification earlier to fix this.
Fixes: 34c96659ed ("efi_selftest: check fdt is marked as runtime data")
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Barebox has now ported some of the UEFI code. In the process
they found some bugs.
In this case when the variable buffer is too small, efi_var_collect()
returns EFI_BUFFER_TOO_SMALL but doesn't free the allocated 'buf'.
Fixes: 5f7dcf079d ("efi_loader: UEFI variable persistence")
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The `loaded image' efi selftest is comparing protocol GUIDs with the wrong
polarity.
This can be verified on the sandbox, where two protocols GUIDs are
retrieved by the test from the image handle in the following order:
1. Loaded Image Device Path Protocol GUID
2. Loaded Image Protocol GUID
The test matches on the first GUID, while it is in fact looking for the
second one; fix the comparison polarity.
Fixes: efe79a7c0d ("efi_selftest: test for loaded image protocol")
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Alexander Graf <agraf@csgraf.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Document support for Renesas Gray Hawk Single development board
based on Renesas R-Car V4M (R8A779H0) SoC.
Fixes: 53066deccb ("ARM: renesas: Add Renesas R8A779H0 V4M Gray Hawk board code")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Document support for Renesas Geist development board
based on Renesas R-Car M3Le (R8A779MD) SoC.
Fixes: c8523795d7 ("arm64: dts: renesas: r8a779md: Add support for R-Car M3Le R8A779MD Geist")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The RZ/N1D and RZ/N1S contain Cortex-A7 core, which is 32bit ARM core.
Document the SoC as 32bit ARM instead of aarch64.
Fixes: a5b9f95943 ("doc: renesas: add Renesas board docs")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Neil ArmstrongandTom Rini
Andrew GoodbodyandTom Rini
Michal SimekandTom Rini
João Marcos CostaandTom Rini
Quentin SchulzandTom Rini
Luca WeissandCasey Connolly
Ye LiandFabio Estevam
Alice GuoandFabio Estevam
Peng FanandFabio Estevam
Alexey CharkovandMarek Vasut
David Lechner
Quentin StrydomandTom Rini
Piyush PaliwalandJerome Forissier
Mateusz FurdynaandJerome Forissier
Mikhail KshevetskiyandJerome Forissier
Francois BerderandMarek Vasut
Mattijs KorpershoekandHeinrich Schuchardt
Vincent StehléandHeinrich Schuchardt
Ilias ApalodimasandHeinrich Schuchardt
Denis MukhinandHeinrich Schuchardt