A VM which has:
- a DMA capable device passed through to it (eg. network card);
- running a malicious kernel that ignores H_PUT_TCE failure;
- capability of using IOMMU pages bigger that physical pages
can create an IOMMU mapping that exposes (for example) 16MB of
the host physical memory to
This is to improve page boundaries checking and should probably
be cc:stable. I came accross this while debugging nvlink2 passthrough
but the lack of checking might be exploited by the existing userspace.
Changes:
v3:
* enforced huge pages not to cross preregistered chunk boundaries
v2:
* 2/2:
The size is always equal to 1 page so let's use this. Later on this will
be used for other checks which use page shifts to check the granularity
of access.
This should cause no behavioral change.
Reviewed-by: David Gibson
Acked-by: Alex Williamson
Signed-off-by: Alexey Kardashevskiy
---
As
On Tue, Jul 3, 2018 at 10:28 PM Rafael J. Wysocki wrote:
>
> On Tuesday, July 3, 2018 8:50:41 AM CEST Pingfan Liu wrote:
> > Clean up the referring to the code in commit 52cdbdd49853 ("driver core:
> > correct device's shutdown order"). So later we can revert it safely.
> >
> > Cc: Greg
On 07/03/18 at 11:57pm, Andy Shevchenko wrote:
> On Tue, Jul 3, 2018 at 5:55 PM, Baoquan He wrote:
> > On 06/12/18 at 05:24pm, Andy Shevchenko wrote:
> >> On Tue, Jun 12, 2018 at 5:20 PM, Andy Shevchenko
> >> wrote:
>
> >> > I briefly looked at the code and error codes we have, so, my proposal
For kexec_file loading, if kexec_buf.top_down is 'true', the memory which
is used to load kernel/initrd/purgatory is supposed to be allocated from
top to down. This is what we have been doing all along in the old kexec
loading interface and the kexec loading is still default setting in some
This function, being a variant of walk_system_ram_res() introduced in
commit 8c86e70acead ("resource: provide new functions to walk through
resources"), walks through a list of all the resources of System RAM
in reversed order, i.e., from higher to lower.
It will be used in kexec_file code.
The struct resource uses singly linked list to link siblings, implemented
by pointer operation. Replace it with list_head for better code readability.
Based on this list_head replacement, it will be very easy to do reverse
iteration on iomem_resource's sibling list in later patch.
Besides, type
reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c
and arch/powerpc/kernel/pci-common.c, so move it to kernel/resource.c
so that it's shared.
Signed-off-by: Baoquan He
---
arch/microblaze/pci/pci-common.c | 37 -
This patchset is doing:
1) Replace struct resource's sibling list from singly linked list to
list_head. Clearing out those pointer operation within singly linked
list for better code readability.
2) Based on list_head replacement, add a new function
walk_system_ram_res_rev() which can does
Hi.
Thanks for the update.
2018-07-04 8:34 GMT+09:00 Laura Abbott :
>
> The build id generated from --build-id can be generated in several different
> ways, with the default being the sha1 on the output of the linked file. For
> distributions, it can be useful to make sure this ID is unique,
Hi.
2018-07-04 8:21 GMT+09:00 Laura Abbott :
>
> Hi,
>
> This is v5 of the series to allow unique build ids in the kernel. As a
> reminder of the context:
> ""
> In Fedora, the debug information is packaged separately (foo-debuginfo) and
> can be installed separately. There's been a long
Hi.
2018-07-04 8:34 GMT+09:00 Laura Abbott :
>
> The vDSO needs to have a unique build id in a similar manner
> to the kernel and modules. Use the build salt macro.
>
> Signed-off-by: Laura Abbott
> ---
> v5: I was previously focused on x86 only but since powerpc gave a patch,
> I figured I
Hi Laurent,
For the test result on Intel 4s skylake platform (192 CPUs, 768G Memory), the
below test cases all were run 3 times.
I check the test results, only page_fault3_thread/enable THP have 6% stddev for
head commit, other tests have lower stddev.
And I did not find other high variation
On Tue, Jul 3, 2018 at 5:26 PM Pingfan Liu wrote:
>
> On Tue, Jul 3, 2018 at 3:51 PM Lukas Wunner wrote:
> >
> > On Tue, Jul 03, 2018 at 02:50:40PM +0800, Pingfan Liu wrote:
> > > commit 52cdbdd49853 ("driver core: correct device's shutdown order")
> > > places an assumption of
On Tue, Jul 3, 2018 at 10:36 PM Rafael J. Wysocki wrote:
>
> On Tuesday, July 3, 2018 8:50:38 AM CEST Pingfan Liu wrote:
> > commit 52cdbdd49853 ("driver core: correct device's shutdown order")
> > places an assumption of supplier<-consumer order on the process of probe.
> > But it turns out to
The vDSO needs to have a unique build id in a similar manner
to the kernel and modules. Use the build salt macro.
Signed-off-by: Laura Abbott
---
v5: I was previously focused on x86 only but since powerpc gave a patch,
I figured I would do arm64 since the changes were also fairly simple.
---
The vDSO needs to have a unique build id in a similar manner
to the kernel and modules. Use the build salt macro.
Signed-off-by: Laura Abbott
---
v5: New approach with the BUILD_SALT macro
---
arch/powerpc/kernel/vdso32/note.S | 3 +++
1 file changed, 3 insertions(+)
diff --git
The vDSO needs to have a unique build id in a similar manner
to the kernel and modules. Use the build salt macro.
Signed-off-by: Laura Abbott
---
v5: Switched to using the single line BUILD_SALT macro
---
arch/x86/entry/vdso/vdso-note.S | 3 +++
arch/x86/entry/vdso/vdso32/note.S | 3 +++
2
The build id generated from --build-id can be generated in several different
ways, with the default being the sha1 on the output of the linked file. For
distributions, it can be useful to make sure this ID is unique, even if the
actual file contents don't change. The easiest way to do this is to
Hi,
This is v5 of the series to allow unique build ids in the kernel. As a
reminder of the context:
""
In Fedora, the debug information is packaged separately (foo-debuginfo) and
can be installed separately. There's been a long standing issue where only one
version of a debuginfo info package
Hi,
This is v5 of the series to allow unique build ids in the kernel. As a
reminder of the context:
""
In Fedora, the debug information is packaged separately (foo-debuginfo) and
can be installed separately. There's been a long standing issue where only one
version of a debuginfo info package
Thank you Andy for the heads up. I might need to rebase my work
(http://lkml.kernel.org/r/20180629182541.6735-1-pasha.tatas...@oracle.com)
based on this change. But, it is possible it is going to be harder to
parallelize based on device tree. I will need to think about it.
Pavel
On Tue, Jul 3,
On Tue, Jul 3, 2018 at 5:55 PM, Baoquan He wrote:
> On 06/12/18 at 05:24pm, Andy Shevchenko wrote:
>> On Tue, Jun 12, 2018 at 5:20 PM, Andy Shevchenko
>> wrote:
>> > I briefly looked at the code and error codes we have, so, my proposal
>> > is one of the following
>>
>> > - use -ECANCELED (not
On Tue, Jul 03, 2018 at 11:59:14AM -0700, William Kennington wrote:
> Is there a bug tracking the issue?
https://bugs.kde.org/show_bug.cgi?id=386945
> Also, unless your malloc is
> guaranteed to be zeroing out the data or have a strcmp that is writing
> doubleworld aligned data to the string,
Hi!
On Tue, Jul 03, 2018 at 11:26:55AM -0700, William Kennington wrote:
> I've noticed while trying to do some valgrind testing on code linked
> against system libraries that have inlined strcmps that valgrind is
> unhappy about branches depending on uninitialized memory. I've read
The branches
Hi,
I've noticed while trying to do some valgrind testing on code linked
against system libraries that have inlined strcmps that valgrind is
unhappy about branches depending on uninitialized memory. I've read
through the generated inline assembly, and it looks like the assembly
will always
On Tue, Jul 03, 2018 at 04:33:51PM +0530, Gautham R. Shenoy wrote:
> From: "Gautham R. Shenoy"
>
> A pair of IBM POWER9 SMT4 cores can be fused together to form a big-core
> with 8 SMT threads. This can be discovered via the "ibm,thread-groups"
> CPU property in the device tree which will
On Tue, Jul 03, 2018 at 04:33:50PM +0530, Gautham R. Shenoy wrote:
> From: "Gautham R. Shenoy"
>
> On IBM POWER9, the device tree exposes a property array identifed by
> "ibm,thread-groups" which will indicate which groups of threads share a
> particular set of resources.
>
> As of today we
On Fri, 2018-06-29 at 00:42 +1000, Michael Ellerman wrote:
> Kent, Jens,
>
> This looks like it might be related to the recent bioset changes?
>
> cheers
>
> Abdul Haleem writes:
> > On Tue, 2018-06-26 at 23:36 +1000, Michael Ellerman wrote:
> >> Abdul Haleem writes:
> ...
> > I was able to
> -Original Message-
> From: York Sun
> Sent: Tuesday, July 3, 2018 10:27 AM
> To: jo...@infinera.com ; Leo Li
>
> Cc: linuxppc-dev@lists.ozlabs.org; m...@ellerman.id.au; Qiang Zhao
>
> Subject: Re: [PATCH] QE GPIO: Add qe_gpio_set_multiple
>
> +Leo
>
> On 07/03/2018 03:30 AM, Joakim
On 20/05/18 14:49, Nipun Gupta wrote:
fsl-mc bus support the new iommu-map property. Comply to this binding
for fsl_mc bus.
Signed-off-by: Nipun Gupta
Reviewed-by: Laurentiu Tudor
---
arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
On 20/05/18 14:49, Nipun Gupta wrote:
of_dma_configure() API expects coherent_dma_mask to be correctly
set in the devices. This patch does the needful.
Reviewed-by: Robin Murphy
Signed-off-by: Nipun Gupta
---
drivers/bus/fsl-mc/fsl-mc-bus.c | 1 +
1 file changed, 1 insertion(+)
diff
On 20/05/18 14:49, Nipun Gupta wrote:
This patch adds support of dma configuration for devices on fsl-mc
bus using 'dma_configure' callback for busses. Also, directly calling
arch_setup_dma_ops is removed from the fsl-mc bus.
Looks like this is the final arch_setup_dma_ops offender, yay!
On 20/05/18 14:49, Nipun Gupta wrote:
Implement bus specific support for the fsl-mc bus including
registering arm_smmu_ops and bus specific device add operations.
Signed-off-by: Nipun Gupta
---
drivers/iommu/arm-smmu.c | 7 +++
drivers/iommu/iommu.c| 21 +
On 20/05/18 14:49, Nipun Gupta wrote:
With of_pci_map_rid available for all the busses, use the function
for configuration of devices on fsl-mc bus
FWIW I had a quick hack at factoring out the commonality with
of_pci_iommu_init(), at which point I reckon this change is easier to
follow as-is
+Leo
On 07/03/2018 03:30 AM, Joakim Tjernlund wrote:
> On Tue, 2018-06-26 at 23:41 +1000, Michael Ellerman wrote:
>>
>> Joakim Tjernlund writes:
>>> On Thu, 2018-06-21 at 02:38 +, Qiang Zhao wrote:
On 06/19/2018 09:22 AM, Joakim Tjernlund wrote:
-Original Message-
Hi Andy,
On 06/12/18 at 05:24pm, Andy Shevchenko wrote:
> On Tue, Jun 12, 2018 at 5:20 PM, Andy Shevchenko
> wrote:
> >> Hmm, I just copied it from arch/powerpc/kernel/pci-common.c. The
> >> function interface expects an integer returned value, not sure what a
> >> real error codes look like,
On 20/05/18 14:49, Nipun Gupta wrote:
iommu-map property is also used by devices with fsl-mc. This
patch moves the of_pci_map_rid to generic location, so that it
can be used by other busses too.
'of_pci_map_rid' is renamed here to 'of_map_rid' and there is no
functional change done in the API.
On 20/05/18 14:49, Nipun Gupta wrote:
The existing IOMMU bindings cannot be used to specify the relationship
between fsl-mc devices and IOMMUs. This patch adds a generic binding for
mapping fsl-mc devices to IOMMUs, using iommu-map property.
Signed-off-by: Nipun Gupta
Reviewed-by: Rob Herring
On Tuesday, July 3, 2018 8:50:38 AM CEST Pingfan Liu wrote:
> commit 52cdbdd49853 ("driver core: correct device's shutdown order")
> places an assumption of supplier<-consumer order on the process of probe.
> But it turns out to break down the parent <- child order in some scene.
> E.g in pci, a
On Tuesday, July 3, 2018 8:50:41 AM CEST Pingfan Liu wrote:
> Clean up the referring to the code in commit 52cdbdd49853 ("driver core:
> correct device's shutdown order"). So later we can revert it safely.
>
> Cc: Greg Kroah-Hartman
> Cc: Rafael J. Wysocki
> Cc: Grygorii Strashko
> Cc:
Kernel Oops at 0xc0334d5c for reading at address 0xc2236450 which
corresponds to r30 + 80
But r30 should contain what's at r3 + 16 that is at 0xc619ec10 so r30
should be c6236400 as shown below (print_hex_dump(regs->gpr[3]) added at
end of __die() )
So how can r30 contain 0xc2236400 instead
On Tue, 3 Jul 2018 13:40:55 +0200
Mathieu Malaterre wrote:
> On Tue, Jul 3, 2018 at 11:40 AM Mathieu Malaterre wrote:
> >
> > Hi Nick,
> >
> > Would you consider this a bug:
> >
> > $ touch drivers/macintosh/via-pmu.c
> > $ CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=n make ARCH=powerpc
> >
On Tue, Jul 3, 2018 at 11:40 AM Mathieu Malaterre wrote:
>
> Hi Nick,
>
> Would you consider this a bug:
>
> $ touch drivers/macintosh/via-pmu.c
> $ CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=n make ARCH=powerpc
> CROSS_COMPILE=powerpc-linux-gnu-
> ...
> LD vmlinux.o
> MODPOST vmlinux.o
>
Le 03/07/2018 à 10:51, Christophe LEROY a écrit :
Hi,
I was having strange unexpected memory corruption, therefore I activated
DEBUG_PAGEALLOC and I now end up with the following Oops, which tends to
make me think we have somewhere in the network code a use-after-free
bug. I saw a few of
From: "Gautham R. Shenoy"
On IBM POWER9, the device tree exposes a property array identifed by
"ibm,thread-groups" which will indicate which groups of threads share a
particular set of resources.
As of today we only have one form of grouping identifying the group of
threads in the core that
From: "Gautham R. Shenoy"
Hi,
This is the second iteration of the patchset to add support for big-core on
POWER9.
The earlier version can be found here: https://lkml.org/lkml/2018/5/11/245.
The changes from the previous version:
- Added comments explaining the "ibm,thread-groups" device
From: "Gautham R. Shenoy"
A pair of IBM POWER9 SMT4 cores can be fused together to form a big-core
with 8 SMT threads. This can be discovered via the "ibm,thread-groups"
CPU property in the device tree which will indicate which group of
threads that share the L1 cache, translation cache and
I think Pavel would be interested to see this as well (he is doing
some parallel device shutdown stuff)
On Tue, Jul 3, 2018 at 9:50 AM, Pingfan Liu wrote:
> commit 52cdbdd49853 ("driver core: correct device's shutdown order")
> places an assumption of supplier<-consumer order on the process of
On Tue, 3 Jul 2018 08:08:14 +1000
Nicholas Piggin wrote:
> On Mon, 02 Jul 2018 11:17:06 +0530
> Mahesh J Salgaonkar wrote:
>
> > From: Mahesh Salgaonkar
> >
> > On pseries, as of today system crashes if we get a machine check
> > exceptions due to SLB errors. These are soft errors and can be
On 07/03/2018 08:55 AM, Nicholas Piggin wrote:
> On Mon, 02 Jul 2018 11:16:29 +0530
> Mahesh J Salgaonkar wrote:
>
>> From: Mahesh Salgaonkar
>>
>> rtas_log_buf is a buffer to hold RTAS event data that are communicated
>> to kernel by hypervisor. This buffer is then used to pass RTAS event
>>
On Tue, 2018-06-26 at 23:41 +1000, Michael Ellerman wrote:
>
> Joakim Tjernlund writes:
> > On Thu, 2018-06-21 at 02:38 +, Qiang Zhao wrote:
> > > On 06/19/2018 09:22 AM, Joakim Tjernlund wrote:
> > > -Original Message-
> > > From: Linuxppc-dev
> > >
Le 03/07/2018 à 11:40, Mathieu Malaterre a écrit :
Hi Nick,
Would you consider this a bug:
Looks more like a feature ...
In /drivers/macintosh/adb.c you have, and it's the only place
via_pmu_driver is used.
#if defined(CONFIG_ADB_PMU) || defined(CONFIG_ADB_PMU68K)
_pmu_driver,
Hi Akshay,
On Tue, Jul 03, 2018 at 02:50:56PM +0530, Akshay Adiga wrote:
> Export pnv_idle_states and nr_pnv_idle_states so that its accessible to
> cpuidle driver. Use properties from pnv_idle_states structure for powernv
> cpuidle_init.
>
> Signed-off-by: Akshay Adiga
> Reviewed-by: Nicholas
Hi Akshay,
On Tue, Jul 03, 2018 at 02:50:55PM +0530, Akshay Adiga wrote:
> Device-tree parsing happens twice, once while deciding idle state to be
> used for hotplug and once during cpuidle init. Hence, parsing the device
> tree and caching it will reduce code duplication. Parsing code has been
>
Hi Nick,
Would you consider this a bug:
$ touch drivers/macintosh/via-pmu.c
$ CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=n make ARCH=powerpc
CROSS_COMPILE=powerpc-linux-gnu-
...
LD vmlinux.o
MODPOST vmlinux.o
WARNING: vmlinux.o(.data+0x216018): Section mismatch in reference from
the variable
On Tue, Jul 3, 2018 at 3:51 PM Lukas Wunner wrote:
>
> On Tue, Jul 03, 2018 at 02:50:40PM +0800, Pingfan Liu wrote:
> > commit 52cdbdd49853 ("driver core: correct device's shutdown order")
> > places an assumption of supplier<-consumer order on the process of probe.
> > But it turns out to break
Export pnv_idle_states and nr_pnv_idle_states so that its accessible to
cpuidle driver. Use properties from pnv_idle_states structure for powernv
cpuidle_init.
Signed-off-by: Akshay Adiga
Reviewed-by: Nicholas Piggin
---
arch/powerpc/include/asm/cpuidle.h | 2 +
Device-tree parsing happens twice, once while deciding idle state to be
used for hotplug and once during cpuidle init. Hence, parsing the device
tree and caching it will reduce code duplication. Parsing code has been
moved to pnv_parse_cpuidle_dt() from pnv_probe_idle_states(). In addition
to the
Device-tree parsed multiple time in powernv cpuidle and powernv
hotplug code.
First to identify supported flags. Second time, to identify deepest_state
and first deep state. Third time, during cpuidle init to find the available
idle states. Any change in device-tree format will lead to make
Hi,
I was having strange unexpected memory corruption, therefore I activated
DEBUG_PAGEALLOC and I now end up with the following Oops, which tends to
make me think we have somewhere in the network code a use-after-free
bug. I saw a few of such bugs have been fixed for IPv4 and IPv6. Maybe
we
* Ard Biesheuvel wrote:
> On 27 June 2018 at 17:15, Will Deacon wrote:
> > Hi Ard,
> >
> > On Tue, Jun 26, 2018 at 08:27:55PM +0200, Ard Biesheuvel wrote:
> >> This adds support for emitting special sections such as initcall arrays,
> >> PCI fixups and tracepoints as relative references
On Tue, Jul 3, 2018 at 9:23 AM Nicholas Piggin wrote:
>
> On Tue, 3 Jul 2018 09:03:46 +0200
> Mathieu Malaterre wrote:
>
> > Hi Nick,
> >
> > I am building my kernel (ppc32) with both
> > CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y and CONFIG_UBSAN=y. This leads
> > to ~316428 warnings such as:
> >
>
Hi Diana,
A few comments below ...
Diana Craciun writes:
> Implement the barrier_nospec as a isync;sync instruction sequence.
> The implementation uses the infrastructure built for BOOK3S 64.
Do you have any details on why that sequence functions as an effective
barrier on your chips?
In a
Michal Suchánek writes:
> On Tue, 12 Jun 2018 02:59:11 +
> Bharat Bhushan wrote:
>
>> Hi Diana,
>>
>> > -Original Message-
>> > From: Diana Craciun [mailto:diana.crac...@nxp.com]
>> > Sent: Monday, June 11, 2018 6:23 PM
>> > To: linuxppc-dev@lists.ozlabs.org
>> > Cc:
Diana Craciun writes:
> The speculation barrier can be disabled from the command line
> with the parameter: "nospectre_v1".
Can you please send another patch adding it to
Documentation/admin-guide/kernel-parameters.txt
You should mark it as "PPC" only for now.
cheers
On Tue, 3 Jul 2018 09:03:46 +0200
Mathieu Malaterre wrote:
> Hi Nick,
>
> I am building my kernel (ppc32) with both
> CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y and CONFIG_UBSAN=y. This leads
> to ~316428 warnings such as:
>
> + powerpc-linux-gnu-ld -EB -m elf32ppc -Bstatic --orphan-handling=warn
On 07/03/2018 03:38 AM, Nicholas Piggin wrote:
> On Mon, 02 Jul 2018 11:17:06 +0530
> Mahesh J Salgaonkar wrote:
>
>> From: Mahesh Salgaonkar
>>
>> On pseries, as of today system crashes if we get a machine check
>> exceptions due to SLB errors. These are soft errors and can be fixed by
>>
Hi Nick,
I am building my kernel (ppc32) with both
CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y and CONFIG_UBSAN=y. This leads
to ~316428 warnings such as:
+ powerpc-linux-gnu-ld -EB -m elf32ppc -Bstatic --orphan-handling=warn
--build-id --gc-sections -X -o .tmp_vmlinux1 -T
This reverts commit 52cdbdd49853dfa856082edb0f4c4c0249d9df07.
Since the device_shutdown() does not rely on the order in devices_kset any
more, reverting that commit safely.
Cc: Greg Kroah-Hartman
Cc: Rafael J. Wysocki
Cc: Grygorii Strashko
Cc: Christoph Hellwig
Cc: Bjorn Helgaas
Cc: Dave
Clean up the referring to the code in commit 52cdbdd49853 ("driver core:
correct device's shutdown order"). So later we can revert it safely.
Cc: Greg Kroah-Hartman
Cc: Rafael J. Wysocki
Cc: Grygorii Strashko
Cc: Christoph Hellwig
Cc: Bjorn Helgaas
Cc: Dave Young
Cc:
commit 52cdbdd49853 ("driver core: correct device's shutdown order")
places an assumption of supplier<-consumer order on the process of probe.
But it turns out to break down the parent <- child order in some scene.
E.g in pci, a bridge is enabled by pci core, and behind it, the devices
have been
Pack the code into a function to ease the using and reading.
Cc: Greg Kroah-Hartman
Cc: Rafael J. Wysocki
Cc: Grygorii Strashko
Cc: Christoph Hellwig
Cc: Bjorn Helgaas
Cc: Dave Young
Cc: linux-...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Pingfan Liu
---
commit 52cdbdd49853 ("driver core: correct device's shutdown order")
places an assumption of supplier<-consumer order on the process of probe.
But it turns out to break down the parent <- child order in some scene.
E.g in pci, a bridge is enabled by pci core, and behind it, the devices
have been
On Tue, Jun 26, 2018 at 7:54 PM Greg Kroah-Hartman
wrote:
>
> On Tue, Jun 26, 2018 at 11:29:48AM +0800, Pingfan Liu wrote:
> > On Mon, Jun 25, 2018 at 6:45 PM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Mon, Jun 25, 2018 at 03:47:39PM +0800, Pingfan Liu wrote:
> > > > commit 52cdbdd49853
On Mon, 2018-07-02 at 18:47 +1000, Alexey Kardashevskiy wrote:
> On Fri, 29 Jun 2018 17:34:36 +1000
> Russell Currey wrote:
>
> > DMA pseudo-bypass is a new set of DMA operations that solve some
> > issues for
> > devices that want to address more than 32 bits but can't address
> > the 59
> >
77 matches
Mail list logo
