flight 169502 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169502/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
On Mon, 18 Apr 2022, Alaa Mohamed wrote:
> The use of kmap() is being deprecated in favor of kmap_local_page()
> where it is feasible.
>
> With kmap_local_page(), the mapping is per thread, CPU local and not
> globally visible. Therefore __del_gref() is a function
> where the use of kmap_local_
flight 169503 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169503/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On 4/18/22 13:53, Christoph Hellwig wrote:
> The discard_alignment queue limit is named a bit misleading means the
> offset into the block device at which the discard granularity starts.
> Setting it to the discard granularity as done by dm-zoned is mostly
> harmless but also useless.
>
> Signed-o
On 4/18/22 13:53, Christoph Hellwig wrote:
> The discard_alignment queue limit is named a bit misleading means the
> offset into the block device at which the discard granularity starts.
> Setting it to the discard granularity as done by null_blk is mostly
> harmless but also useless.
>
> Signed-o
On 4/18/22 13:53, Christoph Hellwig wrote:
> The nvme driver never sets a discard_alignment, so it also doens't need
> to clear it to zero.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/nvme/host/core.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/nvme/host/core.c b/dr
On 4/18/22 13:53, Christoph Hellwig wrote:
> Use bdev_discard_alignment to calculate the correct discard alignment
> offset even for partitions instead of just looking at the queue limit.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/block/rnbd/rnbd-srv-dev.h | 2 +-
> 1 file changed, 1 i
On 4/18/22 13:53, Christoph Hellwig wrote:
> Use bdev_discard_alignment to calculate the correct discard alignment
> offset even for partitions instead of just looking at the queue limit.
>
> Also switch to use bdev_discard_granularity to get rid of the last direct
> queue reference in xen_blkbk_d
On 4/18/22 13:53, Christoph Hellwig wrote:
> The loop driver never sets a discard_alignment, so it also doens't need
> to clear it to zero.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/block/loop.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/block/loop.c b/drivers/bl
flight 169504 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169504/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169505 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169505/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
(The Arm device tree based NUMA support patch set contains 35
patches. In order to make stuff easier for reviewers, I split
them into 3 parts:
1. Preparation. I have re-sorted the patch series. And moved
independent patches to the head of the series.
2. Move generically usable code from x86 to c
Current putn function that is using for early print
only can print low 32-bit of AArch64 register. This
will lose some important messages while debugging
with early console. For example:
(XEN) Bringing up CPU5
- CPU 00010100 booting -
Will be truncated to
(XEN) Bringing up CPU5
- CPU 01
Most of the functions in x86 EFI stub.c can be reused for other
architectures. So we move them to common and keep the x86 specific
function in stub-x86.c.
Signed-off-by: Wei Chen
---
v1 -> v2:
1. Drop the copy of stub.c from Arm EFI.
2. Share common codes of x86 EFI stub for other architectures.
x86 is using compiler feature testing to decide EFI
build enable or not. When EFI build is disabled, x86
will use a efi/stub.c file to replace efi/runtime.c
for build objects. Following this idea, we introduce
a stub file for Arm, but use CONFIG_ARM_EFI to decide
EFI build enable or not.
Signed-of
In current code, when Xen is running in a multiple nodes
NUMA system, it will set dma_bitsize in end_boot_allocator
to reserve some low address memory as DMA zone.
There are some x86 implications in the implementation.
Because on x86, memory starts from 0. On a multiple-nodes
NUMA system, if a sin
In current Xen code only implements x86 ACPI-based NUMA support.
So in Xen Kconfig system, NUMA equals to ACPI_NUMA. x86 selects
NUMA by default, and CONFIG_ACPI_NUMA is hardcode in config.h.
In a follow-up patch, we will introduce support for NUMA using
the device tree. That means we will have tw
In current code, when Xen is booting from EFI, it will delete
all memory nodes in device tree. This would work well in current
stage, because Xen can get memory map from EFI system table.
However, EFI system table cannot completely replace memory nodes
of device tree. EFI system table doesn't conta
We have introduced CONFIG_NUMA in a previous patch. And this
option is enabled only on x86 at the current stage. In a follow
up patch, we will enable this option for Arm. But we still
want users to be able to disable the CONFIG_NUMA via Kconfig. In
this case, keep the fake NUMA API, will make Arm c
VIRTUAL_BUG_ON is an empty macro used in phys_to_nid. This
results in two lines of error-checking code in phys_to_nid
that is not actually working and causing two compilation
errors:
1. error: "MAX_NUMNODES" undeclared (first use in this function).
This is because in the common header file, "MAX
One NUMA node may contain several memory blocks. In current Xen
code, Xen will maintain a node memory range for each node to cover
all its memory blocks. But here comes the problem, in the gap of
one node's two memory blocks, if there are some memory blocks don't
belong to this node (remote memory
flight 169506 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169506/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169499 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169499/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169472
test-amd64-amd64-qemuu-nested-amd 20
flight 169508 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169508/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
The use of kmap() is being deprecated in favor of kmap_local_page()
where it is feasible.
With kmap_local_page(), the mapping is per thread, CPU local and not
globally visible. Therefore __del_gref() is a function
where the use of kmap_local_page() in place of kmap() is correctly
suited.
Signed-o
flight 169495 linux-linus real [real]
flight 169507 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/169495/
http://logs.test-lab.xenproject.org/osstest/logs/169507/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm64-
flight 169509 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169509/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
Pages as guest RAM for static domain, shall be reserved to this domain only.
So in case reserved pages being used for other purpose, users
shall not free them back to heap, even when last ref gets dropped.
free_staticmem_pages will be called by free_domheap_pages in runtime
for static domain freei
Today when a domain unpopulates the memory on runtime, they will always
hand the memory over to the heap allocator. And it will be a problem if it
is a static domain. Pages as guest RAM for static domain shall always be
reserved to only this domain and not be used for any other purposes, so
they sh
There is a slim chance that free_heap_pages() may decide to merge a chunk
from the static region(PGC_reserved) with the about-to-be-free chunk.
So in order to avoid the above scenario, this commit updates free_heap_pages()
to check whether the predecessor and/or successor has PGC_reserved set,
whe
Today when a domain unpopulates the memory on runtime, they will always
hand the memory back to the heap allocator. And it will be a problem if domain
is static.
Pages as guest RAM for static domain shall be reserved to only this domain
and not be used for any other purposes, so they shall never g
With more and more CDF_xxx internal flags in and to save the space, this
commit introduces a new field "flags" in struct domain to store CDF_*
internal flags directly.
Another new CDF_xxx will be introduced in the next patch.
Signed-off-by: Penny Zheng
---
v2 changes:
- let "flags" live in the s
In order to have an easy and quick way to find out whether this domain memory
is statically configured, this commit introduces a new flag CDF_staticmem and a
new helper is_domain_static to tell.
Signed-off-by: Penny Zheng
---
v2 changes:
- change name from "is_domain_on_static_allocation" to "is_
When static domain populates memory through populate_physmap on runtime,
other than allocating from heap, it shall retrieve reserved pages from
resv_page_list to make sure that guest RAM is still restricted in statically
configured memory regions. And this commit introduces a new helper
acquire_res
flight 169510 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169510/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On Fri, 15 Apr 2022 06:52:31 +0200, Christoph Hellwig wrote:
> this series cleanups up the block layer API so that APIs consumed
> by file systems are (almost) only struct block_devic based, so that
> file systems don't have to poke into block layer internals like the
> request_queue.
>
> I also f
flight 169511 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169511/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169512 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169512/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169513 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169513/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169514 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169514/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169515 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169515/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
The startup_xen() kernel entry point is referenced by the ".note.Xen"
section, but is presumably not indirect-branched to. Add ANNOTATE_ENDBR
to silence future objtool warnings.
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: xen-devel@lists.xenproject.org
Signed-off-by: Josh
flight 169516 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169516/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169517 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169517/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169518 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169518/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On Fri, Mar 25, 2022 at 9:34 AM Tamas K Lengyel wrote:
>
> During VM forking and resetting a failed vmentry has been observed due
> to the guest non-register state going out-of-sync with the guest register
> state. For example, a VM fork reset right after a STI instruction can trigger
> the failed
On Sun, 17 Apr 2022, Oleksandr wrote:
> On 16.04.22 01:01, Stefano Stabellini wrote:
> > On Thu, 14 Apr 2022, Oleksandr Tyshchenko wrote:
> > > From: Juergen Gross
> > >
> > > In order to support virtio in Xen guests add a config option enabling
> > > the user to specify whether in all Xen guests
On Mon, 18 Apr 2022, Oleksandr wrote:
> On 16.04.22 09:07, Christoph Hellwig wrote:
>
> Hello Christoph
>
> > On Fri, Apr 15, 2022 at 03:02:45PM -0700, Stefano Stabellini wrote:
> > > This makes sense overall. Considering that the swiotlb-xen case and the
> > > virtio case are mutually exclusive,
On Sun, 17 Apr 2022, Oleksandr wrote:
> On 16.04.22 01:02, Stefano Stabellini wrote:
> > On Thu, 14 Apr 2022, Oleksandr Tyshchenko wrote:
> > > From: Oleksandr Tyshchenko
> > >
> > > In the context of current patch do the following:
> > > 1. Update code to support virtio-mmio devices
> > > 2. Int
flight 169519 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169519/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169520 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169520/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On Sun, 17 Apr 2022, Rahul Singh wrote:
> > On 15 Apr 2022, at 6:40 pm, Stefano Stabellini
> > wrote:
> > On Fri, 15 Apr 2022, Christoph Hellwig wrote:
> >> On Thu, Apr 14, 2022 at 01:39:23PM -0700, Stefano Stabellini wrote:
> >>> OK, now we know that the code path with Xen is correct and it is t
flight 169521 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169521/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On Fri, 1 Apr 2022, Julien Grall wrote:
> On 24/03/2022 13:37, Ayan Kumar Halder wrote:
> > /*
> >* At this point, we know that the instruction is either valid or has
> > been
> >* decoded successfully. Thus, Xen should be allowed to execute the
> > diff --git a/xen/arch/arm/i
On 4/17/22 21:53, Christoph Hellwig wrote:
> The loop driver never sets a discard_alignment, so it also doens't need
s/doens't/doesn't/
> to clear it to zero.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Chaitanya Kulkarni
-ck
On 4/17/22 21:53, Christoph Hellwig wrote:
> The discard_alignment queue limit is named a bit misleading means the
> offset into the block device at which the discard granularity starts.
> Setting it to the discard granularity as done by null_blk is mostly
> harmless but also useless.
>
> Signed-o
On 4/17/22 21:53, Christoph Hellwig wrote:
> The nvme driver never sets a discard_alignment, so it also doens't need
> to clear it to zero.
>
> Signed-off-by: Christoph Hellwig
> ---
Reviewed-by: Chaitanya Kulkarni
-ck
flight 169522 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169522/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On Wed, Apr 06, 2022 at 12:10:17PM +0200, Jan Beulich wrote:
> On 02.04.2022 01:14, Demi Marie Obenour wrote:
> > The EFI System Resource Table (ESRT) is necessary for fwupd to identify
> > firmware updates to install. According to the UEFI specification §23.4,
> > the table shall be stored in mem
> From: Oleksandr Tyshchenko
>
> This patch adds basic support for configuring and assisting virtio-mmio
> based virtio-disk backend (emualator) which is intended to run out of
^ emulator
On Fri, 8 Apr 2022, Oleksandr Tyshchenko wrote:
> From: Julien Grall
>
> This patch introduces helpers to allocate Virtio MMIO params
> (IRQ and memory region) and create specific device node in
> the Guest device-tree with allocated params. In order to deal
> with multiple Virtio devices, reserv
On Thu, 14 Apr 2022, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> This is needed for grant table based DMA ops layer (CONFIG_XEN_VIRTIO)
> at the guest side to retrieve the ID of Xen domain where the corresponding
> backend resides (it is used as an argument to the grant table API
flight 169523 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169523/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
Hi,
Sorry for the formatting issues.
On Mon, 18 Apr 2022, 21:41 Stefano Stabellini,
wrote:
> > +static uint64_t virtio_mmio_base;
> > +static uint32_t virtio_mmio_irq;
>
> No need for these two variables to be global in this file, they could be
> local variables in libxl__arch_domain_prepare_co
flight 169524 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169524/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169525 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169525/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
+rust-...@lists.opendev.org
On Thu, 14 Apr 2022 at 14:54, Viresh Kumar wrote:
>
> +xen-devel
>
> On 14-04-22, 14:45, Viresh Kumar wrote:
> > Hello,
> >
> > We verified our hypervisor-agnostic Rust based vhost-user backends with Qemu
> > based setup earlier, and there was growing concern if they w
flight 169526 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169526/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
Hi Stefano,
> -Original Message-
> From: Stefano Stabellini
> Sent: 2022年4月15日 8:41
> To: Wei Chen
> Cc: xen-devel@lists.xenproject.org; jul...@xen.org; Stefano Stabellini
> ; Bertrand Marquis ;
> Penny Zheng
> Subject: Re: Proposal for Porting Xen to Armv8-R64 - DraftB
>
> On Fri, 25
flight 169527 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169527/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
From: Peng Fan
V6:
Fix a stale variable check per Stefano's comments.
V5:
Align code
drop early_uart_init
V4:
Wrong v3 version, some BIT definition are mixed in patch 1,2.
V3:
Addressed Michal's comments.
Add Henry's T-b
V2:
Per Julien's comments, fix coding style issue, drop unneeded
From: Peng Fan
Signed-off-by: Peng Fan
---
xen/arch/arm/Kconfig.debug | 14
xen/arch/arm/arm64/debug-imx-lpuart.inc | 48 +
2 files changed, 62 insertions(+)
create mode 100644 xen/arch/arm/arm64/debug-imx-lpuart.inc
diff --git a/xen/arch/arm/Kcon
From: Peng Fan
The i.MX LPUART Documentation:
https://www.nxp.com/webapp/Download?colCode=IMX8QMIEC
Chatper 13.6 Low Power Universal Asynchronous Receiver/
Transmitter (LPUART)
Tested-by: Henry Wang
Signed-off-by: Peng Fan
---
xen/arch/arm/include/asm/imx-lpuart.h | 64 ++
xen/drivers/ch
flight 169529 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169529/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On Mon, Apr 18, 2022 at 6:53 AM Christoph Hellwig wrote:
>
> Use bdev_discard_alignment to calculate the correct discard alignment
> offset even for partitions instead of just looking at the queue limit.
>
> Signed-off-by: Christoph Hellwig
Thx!
Acked-by: Jack Wang
> ---
> drivers/block/rnbd/rn
flight 169530 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169530/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
Good day,
You're looking for this document i was focusing on a week ago, i believe. Anyway, here's the url to this doc below:
https://tutiendafit.com.mx/olea/sndaem
On 3/15/22 7:38 AM, Jan Beulich wrote:
> On 14.03.2022 04:41, Chuck Zmudzinski wrote:
>> Fixes: abfb006f1ff4 (tools/libxl: explici
On 18.04.22 21:11, Stefano Stabellini wrote:
On Sun, 17 Apr 2022, Oleksandr wrote:
On 16.04.22 01:01, Stefano Stabellini wrote:
On Thu, 14 Apr 2022, Oleksandr Tyshchenko wrote:
From: Juergen Gross
In order to support virtio in Xen guests add a config option enabling
the user to specify wheth
Hi Stefano,
On 16.04.2022 01:10, Stefano Stabellini wrote:
> On Thu, 14 Apr 2022, Michal Orzel wrote:
>> DT_MATCH_TIMER stores the compatible timer ids and as such should be
>> used in all the places where we need to refer to them. make_timer_node
>> explicitly lists the same ids as the ones defin
Hi Stefano,
On 16.04.2022 02:17, Stefano Stabellini wrote:
> Add a minimal ARM32 smoke test based on qemu-system-arm, as provided by
> the test-artifacts qemu container. The minimal test simply boots Xen
> (built from previous build stages) and Dom0.
>
> The test needs a working kernel and minima
Hello Stefano, Juergen
On 19.04.22 09:21, Juergen Gross wrote:
On 18.04.22 21:11, Stefano Stabellini wrote:
On Sun, 17 Apr 2022, Oleksandr wrote:
On 16.04.22 01:01, Stefano Stabellini wrote:
On Thu, 14 Apr 2022, Oleksandr Tyshchenko wrote:
From: Juergen Gross
In order to support virtio
Hi Peng,
On 19.04.2022 06:39, Peng Fan (OSS) wrote:
> From: Peng Fan
>
> Signed-off-by: Peng Fan
In the v5, I gave you R-by and Bertrand gave A-by so you should have
carried them as you haven't done any modificiation in this patch since v5.
Anyway,
Reviewed-by: Michal Orzel
Cheers,
Michal
On 18.04.22 21:11, Stefano Stabellini wrote:
On Sun, 17 Apr 2022, Oleksandr wrote:
On 16.04.22 01:02, Stefano Stabellini wrote:
On Thu, 14 Apr 2022, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
In the context of current patch do the following:
1. Update code to support virtio-mmio
Hi Peng,
On 19.04.2022 06:39, Peng Fan (OSS) wrote:
> From: Peng Fan
>
> The i.MX LPUART Documentation:
> https://www.nxp.com/webapp/Download?colCode=IMX8QMIEC
> Chatper 13.6 Low Power Universal Asynchronous Receiver/
> Transmitter (LPUART)
>
> Tested-by: Henry Wang
> Signed-off-by: Peng Fan
84 matches
Mail list logo
