Use L1_CACHE_BYTES as the dma alignment size, use 'sizeof(long)'
is wrong.
Signed-off-by: Xianting Tian
Reviewed-by: Shile Zhang
---
drivers/tty/hvc/hvc_console.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
Dear all,
This patch series make hvc framework pass DMA capable memory to
put_chars() of hvc backend(eg, virtio-console), and revert commit
c4baad5029 ("virtio-console: avoid DMA from stack”)
V1
virtio-console: avoid DMA from vmalloc area
https://lkml.org/lkml/2021/7/27/494
For v1 patch, Arnd
在 2021/10/9 下午7:58, Greg KH 写道:
Did you look at the placement using pahole as to how this structure now
looks?
thanks for all your commnts. for this one, do you mean I need to remove
the blank line? thanks
On Sat, Oct 9, 2021, at 12:10, Wolfram Sang wrote:
>> I still don't have access to any old PASemi hardware but the changes from
>> v1 are pretty small and I expect them to still work. Would still be nice
>> if someone with access to such hardware could give this a quick test.
>
> Looks good to me.
On Sat, Oct 9, 2021, at 12:09, Wolfram Sang wrote:
>> F: arch/arm64/boot/dts/apple/
>> +F: drivers/i2c/busses/i2c-pasemi-platform.c
>
> We have no dedicated maintainer for PASEMI. Are maybe you or your
> project interested in maintaining the pasemi-core, too? I guess not many
> patches will
From: Ben Widawsky
Reduce maintenance burden of DVSEC query implementation by using the
centralized PCI core implementation.
There are two obvious places to simply drop in the new core
implementation. There remains find_dvsec_from_pos() which would benefit
from using a core implementation. As
From: Ben Widawsky
Add pci_find_dvsec_capability to locate a Designated Vendor-Specific
Extended Capability with the specified Vendor ID and Capability ID.
The Designated Vendor-Specific Extended Capability (DVSEC) allows one or
more "vendor" specific capabilities that are not tied to the
Changes since v2 [1]:
- Rework some of the changelogs per feedback (Bjorn, and I)
- Move the cxl_register_map refactor earlier in the series to make the
cxl_setup_pci_regs() refactor easier to read.
- Fix a bug added in v5.14 for handling the error return case
cxl_pci_map_regblock()
- Split
[Cc: +linuxppc-dev@lists.ozlabs.org]
Dear Arnd,
Am 28.09.21 um 09:50 schrieb Arnd Bergmann:
From: Arnd Bergmann
Compile-testing drivers that require access to a firmware layer
fails when that firmware symbol is unavailable. This happened
twice this week:
- My proposed to change to rework
On Sat, Oct 09, 2021 at 07:48:28PM +0800, Xianting Tian wrote:
> --- a/drivers/tty/hvc/hvc_console.h
> +++ b/drivers/tty/hvc/hvc_console.h
> @@ -32,13 +32,21 @@
> */
> #define HVC_ALLOC_TTY_ADAPTERS 8
>
> +/*
> + * These sizes are most efficient for vio, because they are the
> + *
Arf, I have sent this patchset with the wrong email address. @Palmer
tell me if you want me to resend it correctly.
Thanks,
Alex
On 10/9/21 7:12 PM, Alexandre Ghiti wrote:
> From: Alexandre Ghiti
>
> This config allows to compile 64b kernel as PIE and to relocate it at
> any virtual address at
> F: arch/arm64/boot/dts/apple/
> +F: drivers/i2c/busses/i2c-pasemi-platform.c
We have no dedicated maintainer for PASEMI. Are maybe you or your
project interested in maintaining the pasemi-core, too? I guess not many
patches will show up and they will likely be for M1 anyhow.
If so, then
> I still don't have access to any old PASemi hardware but the changes from
> v1 are pretty small and I expect them to still work. Would still be nice
> if someone with access to such hardware could give this a quick test.
Looks good to me. I will wait a few more days so that people can report
On Sat, Oct 09, 2021 at 07:48:28PM +0800, Xianting Tian wrote:
> As well known, hvc backend can register its opertions to hvc backend.
> the operations contain put_chars(), get_chars() and so on.
>
> Some hvc backend may do dma in its operations. eg, put_chars() of
> virtio-console. But in the
On 09 October 2021 at 12:10 pm, Wolfram Sang wrote:
I still don't have access to any old PASemi hardware but the changes from
v1 are pretty small and I expect them to still work. Would still be nice
if someone with access to such hardware could give this a quick test.
Looks good to me. I will
As well known, hvc backend can register its opertions to hvc backend.
the operations contain put_chars(), get_chars() and so on.
Some hvc backend may do dma in its operations. eg, put_chars() of
virtio-console. But in the code of hvc framework, it may pass DMA
incapable memory to put_chars()
This revert commit c4baad5029 ("virtio-console: avoid DMA from stack")
hvc framework will never pass stack memory to the put_chars() function,
So the calling of kmemdup() is unnecessary, we can remove it.
Signed-off-by: Xianting Tian
Reviewed-by: Shile Zhang
---
drivers/char/virtio_console.c
allmodconfig
i386 randconfig-c001-20211009
sh se7206_defconfig
sh sh7724_generic_defconfig
powerpc pasemi_defconfig
x86_64 defconfig
armcerfcube_defconfig
powerpc
From: Alexandre Ghiti
This config allows to compile 64b kernel as PIE and to relocate it at
any virtual address at runtime: this paves the way to KASLR.
Runtime relocation is possible since relocation metadata are embedded into
the kernel.
Note that relocating at runtime introduces an overhead
From: Alexandre Ghiti
Relocating kernel at runtime is done very early in the boot process, so
it is not convenient to check for relocations there and react in case a
relocation was not expected.
There exists a script in scripts/ that extracts the relocations from
vmlinux that is then used at
After multiple attempts, this patchset is now based on the fact that the
64b kernel mapping was moved outside the linear mapping.
The first patch allows to build relocatable kernels but is not selected
by default. That patch should ease KASLR implementation a lot.
From: Alexandre Ghiti
Relocating kernel at runtime is done very early in the boot process, so
it is not convenient to check for relocations there and react in case a
relocation was not expected.
Powerpc architecture has a script that allows to check at compile time
for such unexpected
On Sat, Oct 09, 2021 at 11:45:23PM +0800, Xianting Tian wrote:
>
> 在 2021/10/9 下午7:58, Greg KH 写道:
> > Did you look at the placement using pahole as to how this structure now
> > looks?
>
> thanks for all your commnts. for this one, do you mean I need to remove the
> blank line? thanks
>
No, I
Olof,
Thank you for the hint.
I think I have found them.
Link: https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=266104
Mbox: https://patchwork.ozlabs.org/series/266104/mbox/
$ wget -O mbox https://patchwork.ozlabs.org/series/266104/mbox/
$ git am mbox
Thanks,
Christian
On 8.
24 matches
Mail list logo
