| Age | Commit message (Collapse) | Author |
|---|
|
In case lists_driver_lookup_name("rst_gen3") fails, the clk_gen3 driver
has to be unbound before erroring out. Reorder the function such that
both clk_gen3 and rst_gen3 drivers are looked up first, if either look
up fails then the function errors out right away. Second, the clk_gen3
is bound, if binding fails, the function still errors out right away
because there is nothing to undo after either lists_driver_lookup_name()
call. Finally, rst_gen3 is bound and if this binding fails, then that
is the only place where clk_gen3 has to be unbound before erroring out.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
SCSI READ CAPACITY reports the address of the last block and the block
size. The total number of blocks is thus last block address plus one.
This also fixes the corresponding test case.
|
|
While we want to compile the SPI_STACKED_PARALLEL code everywhere we
can, it must first be guarded with an #if for DM_SPI as not all cases
where we have this code built, such as in SPL, will have the relevant
DM_SPI option enabled.
Fixes: 43423cdc5dc1 ("mtd: spi-nor: Always build SPI_STACKED_PARALLEL code")
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
test"
Tom Rini <trini@konsulko.com> says:
In the patch series "spi-nor: Add parallel and stacked memories support"
a number of issues have since been raised about problems that now exist
on a large number of previously working platforms. Marek Vasut has gone
and identified a number of issues and this series is the starting point
of attempting to address them and fix the problems with previously
existing platforms.
Link: https://patchwork.ozlabs.org/project/uboot/list/?series=429932&state=*
Link: https://lore.kernel.org/r/20241026201741.171073-1-marek.vasut+renesas@mailbox.org
|
|
Prevent the code gated by SPI_STACKED_PARALLEL from bitrot
by using if (CONFIG_IS_ENABLED(SPI_STACKED_PARALLEL)) around
it. That way, it is always at least compiled.
Fixes: 5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked memories support")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
The SPI_ADVANCE description does not explain what the switch does.
It does not have anything to do with any advanced functionality, it
only gates off support for stacked and parallel SPI NORs. Rename the
Kconfig symbol, update description, and move it right next to Xilinx
hardware as it seems to be specific to this hardware. Make sure the
symbol is also protected by if DM_SPI in Kconfig.
Fixes: 5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked memories support")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
Rewrite the code to make it clear exactly where the
SNOR_F_HAS_PARALLEL flag leads to *2 and /2 operation
compared to regular code path. No functional change.
Fixes: 5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked memories support")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
The offset variable is set, but never used afterward.
Fix indent. Fix predecrement without justification.
Remove use of parenthesis where unnecessary.
Fixes: 5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked memories support")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
Remove undocumented SST special case. This was added in commit
5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked memories support")
without any explanation in the commit message. Remove it.
Fixes: 5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked memories support")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
Remove undocumented write_disable() call. This was added in commit
5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked memories support")
without any explanation in the commit message. Remove it.
Fixes: 5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked memories support")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
Remove undocumented set_4byte() call. This was added in commit
5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked memories support")
without any explanation in the commit message. Remove it.
Fixes: 5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked memories support")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
Remove undocumented spi_nor_wait_till_ready() call. This was added in commit
5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked memories support")
without any explanation in the commit message. Remove it.
Fixes: 5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked memories support")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
Remove undocumented nor->addr_width == 3 test. This was added in commit
5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked memories support")
without any explanation in the commit message. Remove it.
This also has a bad side-effect which breaks READ operation of every SPI NOR
which does not use addr_width == 3, e.g. s25fs512s does not work at all. This
is because if addr_width != 3, rem_bank_len is always 0, and if rem_bank_len
is 0, then read_len is 0 and if read_len is 0, then the spi_nor_read() returns
-EIO.
Basic reproducer is as follows:
"
=> sf probe ; sf read 0x50000000 0 0x10000
SF: Detected s25fs512s with page size 256 Bytes, erase size 256 KiB, total 64 MiB
device 0 offset 0x0, size 0x10000
SF: 65536 bytes @ 0x0 Read: ERROR -5
"
Fixes: 5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked memories support")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
https://gitlab.denx.de/u-boot/custodians/u-boot-imx
CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/23092
- Implement i.MX93 erratum fix on the dwc_eth_qos driver to fix RMII.
- Add support for Emcraft Systems NavQ+.
- Fix the size of IVT + CSF blob tacked on to u-boot.itb.
|
|
Bastien Curutchet <bastien.curutchet@bootlin.com> says:
Hi all,
This patch series aims to add DM support for the AEMIF controller that
can be found in the DaVinci SoCs.
This controller has already a driver used by the Keystone SoCs so I
add my work to it.
As we can now easily import Linux device-trees, I try to stick the
most I can to the Linux bindings of the AEMIF controller. To do so I add
an 'intermediate' driver called 'ti-aemif-cs'. It's in charge of
configuring timings for a given chip select of the AEMIF controller.
Link: https://lore.kernel.org/r/20241021151330.1860929-1-bastien.curutchet@bootlin.com
|
|
The Linux bindings of the AEMIF offer properties that specify the
transaction timings for each chips select.
Add parsing of these properties to calculate the chip select's
configuration from them and the rate of the AEMIF's reference clock.
Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
|
|
The AEMIF's bindings in the Linux tree have a node for the AEMIF
controller and then a node for each AEMIF's chip select. This CS node
doesn't have a compatible property but describes the timing parameters
used by a given chip select.
The U-Boot DM framework expects every node to have a 'compatible'
property. If no 'compatible' is present in a node, its children won't be
parsed by u-boot.
Add DM support to the ti-aemif driver.
Add a new ti-aemif-cs driver to comply with the Linux bindings and the
U-Boot's DM philosophy. This driver handles the timing parameters
of an AEMIF's chip select so move aemif_cs_configure() from ti-aemif.c
to ti-aemif-cs.c.
Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
|
|
Wrap the CS configuration into a aemif_configure_cs() to ease its
migration to another driver when adding DM support.
Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
|
|
TI_AEMIF configuration doesn't depend on ARCH_DAVINCI while the AEMIF
controller is present in the DaVinci SoCs.
Add ARCH_DAVINCI to the potential users of the TI_AEMIF driver
Add <asm/io.h> to driver's includes to fix build issue on ARCH_DAVINCI
Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
AEMIF controller is present on other SoCs than the Keystone ones.
Remove Keystone specificities from the driver to be able to use it from
other architectures.
Adapt the ks2_evm/board.c to fit the new driver.
Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
Fix following CHECK pointed out by checkpatch:
CHECK: Macro argument 'cs' may be better as '(cs)' to avoid precedence issues
#62: FILE: drivers/memory/ti-aemif.c:15:
+#define AEMIF_CONFIG(cs) (0x10 + (cs * 4))
Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
Billy Tsai <billy_tsai@aspeedtech.com> says:
AST2600 SoC has 2 SGPIO master interfaces one with 128 pins another one
with 80 pins, AST2500/AST2400 SoC has 1 SGPIO master interface that
supports up to 80 pins.
Link: https://lore.kernel.org/r/20241016085955.314236-1-billy_tsai@aspeedtech.com
|
|
They were added with commit 0e9d23945ce0 ("net: eqos: implement callbaks
to get interface and set txclk rate") but were not removed with
commit 5fc783b5d9c9 ("net: dwc_eth_qos: move i.MX code out") when i.MX
specific code was moved to a separate file.
Signed-off-by: Erik Schumacher <erik.schumacher@iris-sensing.com>
|
|
The EQOS on i.MX93 fails to finish the reset procedure in RMII mode.
This is described in errata ERR051683. This patch implements the
provided workaround which sets the PS and FES bits after the SWR is set
by using the eqos_fix_soc_reset function.
Adapted from linux-kernel commit b536f32b5b03 ("net: stmmac: dwmac-imx:
use platform specific reset for imx93 SoCs")
Signed-off-by: Erik Schumacher <erik.schumacher@iris-sensing.com>
|
|
This patch adds support for optional platform specific reset logic in
the dwc_eth_qos driver. This new function 'eqos_fix_soc_reset' is called
after the EQOS_DMA_MODE_SWR is set and before the driver waits for this
bit to clear.
Signed-off-by: Erik Schumacher <erik.schumacher@iris-sensing.com>
|
|
Add SGPIO DTS node and enable them for AST2600 EVB.
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
|
|
Add SGPIO DTS node and enable it for AST2500 EVB.
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
|
|
The Aspeed SGPIO driver supports the SGPIO controllers found in the
AST2400, AST2500 and AST2600 BMC SoCs. The implementation is a cut-down
copy of the upstream Linux kernel driver, adapted for u-boot.
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
|
|
People complained that enabling (SPL_)DM_WARN was now totally unusable
due to the amount of messages printed on the console.
Let's downgrade the log level of some messages that are clearly not on
the error path.
Note that there's one pr_debug in there, because it is followed by
pr_cont so it made sense to reuse the same family of functions.
Reported-by: Alexander Dahl <ada@thorsis.com>
Fixes: 6afdb1585112 ("dm: core: migrate debug() messages to use dm_warn")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
|
|
Why get a devicetree description wrong once when you can get it wrong
twice? The original mistake, which the driver supports was failing to
describe the main PLL that the "cfg" and "periph" clocks parented by.
The second mistake was describing the "cfg" and "periph" clocks a
reg region within the clock controller, rather as two registers within
a syscon region that also contains pinctrl, interrupt muxing controls
and other functions.
Make up for lost time and describe these regions as they should have
been originally, preserving support for the existing two configurations
for the sake of existing systems with firmware-provided devicetrees.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
|
|
After the recent dts/upstream subtree merge, the sdhi compatible string
used in the device tree for RZ/G2L family SoCs is "renesas,rzg2l-sdhi"
not "renesas,rcar-gen3-sdhi". This broke the ability to access the eMMC
and SD card devices on RZ/G2L boards.
Fix this by adding the new compatible string to the sdhi driver.
Fixes: 136b7b6d2e98 ("Subtree merge tag 'v6.11-dts' of dts repo [1] into dts/upstream")
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
|
|
Starting with Linux commit 7569486d79ae ("gpio: dwapb: Add ngpios
DT-property support") the "snps,nr-gpios" property was marked
as deprecated.
And since all newly added dw-apb-gpio nodes are described using generic
"ngpios" property, it's time to add support for it.
Signed-off-by: Maksim Kiselev <bigunclemax@gmail.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
|
|
Patrick Rudolph <patrick.rudolph@9elements.com> says:
Based on the existing work done by Simon Glass this series adds
support for booting aarch64 devices using ACPI only.
As first target QEMU SBSA support is added, which relies on ACPI
only to boot an OS. As secondary target the Raspberry Pi4 was used,
which is broadly available and allows easy testing of the proposed
solution.
The series is split into ACPI cleanups and code movements, adding
Arm specific ACPI tables and finally SoC and mainboard related
changes to boot a Linux on the QEMU SBSA and RPi4. Currently only the
mandatory ACPI tables are supported, allowing to boot into Linux
without errors.
The QEMU SBSA support is feature complete and provides the same
functionality as the EDK2 implementation.
The changes were tested on real hardware as well on QEMU v9.0:
qemu-system-aarch64 -machine sbsa-ref -nographic -cpu cortex-a57 \
-pflash secure-world.rom \
-pflash unsecure-world.rom
qemu-system-aarch64 -machine raspi4b -kernel u-boot.bin -cpu cortex-a72 \
-smp 4 -m 2G -drive file=raspbian.img,format=raw,index=0 \
-dtb bcm2711-rpi-4-b.dtb -nographic
Tested against FWTS V24.03.00.
Known issues:
- The QEMU rpi4 support is currently limited as it doesn't emulate PCI,
USB or ethernet devices!
- The SMP bringup doesn't work on RPi4, but works in QEMU (Possibly
cache related).
- PCI on RPI4 isn't working on real hardware since the pcie_brcmstb
Linux kernel module doesn't support ACPI yet.
Link: https://lore.kernel.org/r/20241023132116.970117-1-patrick.rudolph@9elements.com
|
|
When ACPI is enabled over FDT the APs cannot be brought out of reset
by the OS using the "FDT spin-table" mechanism, as no FDT is provided
to the OS. The APs must be released out of reset in u-boot and then
brought up in an ACPI compliant fashion.
When ARMV8_MULTIENTRY is specified, the APs are released from reset
and will enter U-Boot after it has been relocated as well.
By default ARMV8_MULTIENTRY is not selected, keeping existing behaviour.
TEST: All APs enter U-Boot when run on qemu-system-aarch64 and on
real hardware.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Matthias Brugger <mbrugger@suse.com>
Cc: Peter Robinson <pbrobinson@gmail.com>
Cc: Tom Rini <trini@konsulko.com>
|
|
These header files presumably duplicate things already in the U-Boot
devicetree. For now, bring them in to get the ASL code and ACPI table
code to compile.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Matthias Brugger <mbrugger@suse.com>
Cc: Matthias Brugger <mbrugger@suse.com>
Cc: Peter Robinson <pbrobinson@gmail.com>
Cc: Tom Rini <trini@konsulko.com>
|
|
Fill the MADT table in the GIC driver and armv8 CPU driver to
drop SoC specific code. While the GIC only needs devicetree
data, the CPU driver needs additional information stored in
the cpu_plat struct.
While on it update the only board making use of the existing
drivers and writing ACPI MADT in mainboard code.
TEST: Booted on QEMU sbsa-ref using GICV3 driver model generated MADT.
Booted on QEMU raspb4 using GICV2 driver model generated MADT.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Simon Glass <sjg@chromium.org>
|
|
Support reading the "interrupts" property from the devicetree in case
the "interrupts-extended" property isn't found. As the "interrupts"
property is commonly used, this allows to parse all existing FDT and
makes irq_get_by_index() more useful.
The "interrupts" property doesn't contain a phandle as "interrupts-extended"
does, so implement a new method to locate the interrupt-parent called
irq_get_interrupt_parent().
TEST: Read the interrupts from the GIC node for ACPI MADT generation.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Moritz Fischer <moritzf@google.com>
|
|
Add a generic driver that binds to armv8 CPU nodes. The generic driver allows
- to enumerate CPUs present in a system, even when no other driver binds it
- generates ACPI SSDT code for each CPU
- Fill the ACPI MADT table (implemented in a follow up patch)
The newly introduced code could also be reused on other CPU drivers that are
compatible with armv8.
TEST: Booted on QEMU sbsa and verify the driver binds to CPU nodes.
Confirmed with FWTS that all ACPI processor devices are present.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Simon Glass <sjg@chromium.org>
|
|
Rename 'ahci_mvebu' to 'ahci_generic' and select it by default.
The AHCI driver contains no SoC specific code and only expects the
base address to be passed, thus rename it to ahci_generic and add the
DT compatible string "generic-ahci".
Update existing defconfigs to use the new Kconfig name as well.
TEST: Booted on QEMU sbsa using the generic-ahci node.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Cc: Tom Rini <trini@konsulko.com>
Cc: Stefan Roese <sr@denx.de>
Acked-by: Tony Dinh <mibodhi@gmail.com>
|
|
Add support for the generic XHCI driver that contains no SoC
specific code. It can be used on platforms that simply work out
of the box, like on emulated platforms.
TEST: Booted on QEMU sbsa machine using the generic xhci driver.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Cc: Tom Rini <trini@konsulko.com>
Cc: Marek Vasut <marex@denx.de>
|
|
Add a new method to acpi_ops to let drivers fill out ACPI MADT.
The code is unused for now until drivers implement the new ops.
TEST: Booted on QEMU sbsa using driver model generated MADT.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Simon Glass <sjg@chromium.org>
|
|
When ACPI is enabled on arm it will use the getinfo function to fill
the SPCR ACPI table.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Moritz Fischer <moritzf@google.com>
|
|
This patch series by Hanyuan Zhao <hanyuan-z@qq.com> provides a number of
improvements to the dc2114x driver.
Link: https://lore.kernel.org/r/tencent_BD4B002FC63A5F77969D9BD1FFF125371C08@qq.com
|
|
bus"
Romain Naour <romain.naour@smile.fr> says:
We are using a custom board where an ethernet switch device KSZ9896 is
available. This family of devices can use several types of serial bus
as management interface: mdio, i2c or SPI. Due to board design
constraints and because we initially planned to use this device only
from Linux, the SPI bus was used.
Luckily we are using a recent enough u-boot release where KSZ9477
driver is available... but only for the i2c interface. Indeed, unlike
the kernel driver, the KSZ9477 driver doesn't use the regmap API to
access the underlying bus since the regmap API is limited to direct
memory access [1].
Until regmap API with bus support is available in U-boot, we introduced
struct ksz_phy_ops to store low-level ksz bus operations (I2C or SPI).
This series has been tested on the current master branch (after v2024.10
release).
[1] https://source.denx.de/u-boot/u-boot/-/blob/v2024.10-rc5/drivers/core/Kconfig?ref_type=tags#L188
Link: https://lore.kernel.org/r/20241008075435.1572727-1-romain.naour@smile.fr
|
|
Frank Sae <Frank.Sae@motor-comm.com> says:
YT8531 as Gigabit transceiver uses bit15:14(bit9 reserved default 0) as phy
speed mask, YT8821 as 2.5 Gigabit transceiver uses bit9 bit15:14 as phy
speed mask.
Be compatible to YT8821, reform phy speed mask and phy speed macro.
Based on update above, add YT8821 2.5G phy driver.
Link: https://lore.kernel.org/r/20240912120225.28884-1-Frank.Sae@motor-comm.com
|
|
Some drivers do not behave properly when free_pkt() is called with a
length of zero. It is an issue I observed when developing the lwIP
series [1] (see "QEMU CI tests for r2dplus_i82557c, r2dplus_rtl8139"
in the change log) and which I fixed incorrectly by not calling
free_pkt() when recv() returns 0. That turned out to be wrong for two
reasons:
1. The DM documentation [2] clearly requires it:
"The **recv** function polls for availability of a new packet. [...]
If there is an error [...], return 0 if you require the packet to
be cleaned up normally, or a negative error code otherwise (cleanup
not necessary or already done).
If **free_pkt** is defined, U-Boot will call it after a received
packet has been processed [...]. free_pkt() will be called after
recv(), for the same packet [...]"
2. The imx8mp_evk platform will fail with OOM errors if free_pkt() is
not called after recv() returns 0:
u-boot=> tftp 192.168.0.16:50M
Using ethernet@30be0000 device
TFTP from server 192.168.0.16; our IP address is 192.168.0.48
Filename '50M'.
Load address: 0x40480000
Loading: #######################fecmxc_recv: error allocating packetp
fecmxc_recv: error allocating packetp
fecmxc_recv: error allocating packetp
...
Therefore, make recv() return -EAGAIN instead of 0 when no packet is
available and the driver doesn't expect free_pkt() to be called
subsequently.
[1] https://lists.denx.de/pipermail/u-boot/2024-August/562861.html
[2] doc/develop/driver-model/ethernet.rst
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
The Microchip KSZ Gigabit Ethernet Switches support
SGMII/RGMII/MII/RMII with register access via SPI, I2C, or MDIO.
Since this driver is now able to check the underlying bus type,
handle the case when the SPI bus is used.
The SPI bus is only used for 8/16/32 wide access of registers.
Reword Kconfig option to include SPI bus support.
Signed-off-by: Romain Naour <romain.naour@smile.fr>
|
|
With the upcoming ksz9477 SPI support added, the I2C support
will be optional. Either the I2C or the SPI bus will be used.
For now, DM_I2C is still mandatory.
Signed-off-by: Romain Naour <romain.naour@smile.fr>
|
|
In order to support management bus other than the I2C, rename
ksz_i2c_probe() to ksz_probe() since this function is no longer
specific to the I2C bus.
Signed-off-by: Romain Naour <romain.naour@smile.fr>
|
