* Re: [PATCH v3 03/20] exec: Let qemu_ram_*() functions take a const pointer argument
From: Philippe Mathieu-Daudé @ 2020-02-20 13:23 UTC (permalink / raw)
To: Paolo Bonzini, Peter Maydell, qemu-devel
Cc: Edgar E. Iglesias, Anthony Perard, Fam Zheng,
Hervé Poussineau, kvm, Laurent Vivier, Thomas Huth,
Stefan Weil, Eric Auger, Halil Pasic, Marcel Apfelbaum,
qemu-s390x, Aleksandar Rikalo, David Gibson, Michael Walle,
qemu-ppc, Gerd Hoffmann, Cornelia Huck, qemu-arm,
Alistair Francis, qemu-block, Cédric Le Goater, Jason Wang,
xen-devel, Christian Borntraeger, Dmitry Fleytman, Matthew Rosato,
Eduardo Habkost, Richard Henderson, Michael S. Tsirkin,
David Hildenbrand, Stefano Stabellini, Igor Mitsyanko,
Paul Durrant, Richard Henderson, John Snow
In-Reply-To: <fce0956e-e542-e8a5-bd02-a7941a9db627@redhat.com>
On 2/20/20 2:21 PM, Paolo Bonzini wrote:
> On 20/02/20 14:05, Philippe Mathieu-Daudé wrote:
>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>> ---
>> include/exec/cpu-common.h | 6 +++---
>> include/sysemu/xen-mapcache.h | 4 ++--
>> exec.c | 8 ++++----
>> hw/i386/xen/xen-mapcache.c | 2 +-
>> 4 files changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
>> index 81753bbb34..05ac1a5d69 100644
>> --- a/include/exec/cpu-common.h
>> +++ b/include/exec/cpu-common.h
>> @@ -48,11 +48,11 @@ typedef uint32_t CPUReadMemoryFunc(void *opaque, hwaddr addr);
>>
>> void qemu_ram_remap(ram_addr_t addr, ram_addr_t length);
>> /* This should not be used by devices. */
>> -ram_addr_t qemu_ram_addr_from_host(void *ptr);
>> +ram_addr_t qemu_ram_addr_from_host(const void *ptr);
>
> This is a bit ugly, because the pointer _can_ be modified via
> qemu_map_ram_ptr.
OK.
> Is this needed for the rest of the series to apply?
No!
> Paolo
>
>> RAMBlock *qemu_ram_block_by_name(const char *name);
>> -RAMBlock *qemu_ram_block_from_host(void *ptr, bool round_offset,
>> +RAMBlock *qemu_ram_block_from_host(const void *ptr, bool round_offset,
>> ram_addr_t *offset);
>> -ram_addr_t qemu_ram_block_host_offset(RAMBlock *rb, void *host);
>> +ram_addr_t qemu_ram_block_host_offset(RAMBlock *rb, const void *host);
>> void qemu_ram_set_idstr(RAMBlock *block, const char *name, DeviceState *dev);
>> void qemu_ram_unset_idstr(RAMBlock *block);
>> const char *qemu_ram_get_idstr(RAMBlock *rb);
>> diff --git a/include/sysemu/xen-mapcache.h b/include/sysemu/xen-mapcache.h
>> index c8e7c2f6cf..81e9aa2fa6 100644
>> --- a/include/sysemu/xen-mapcache.h
>> +++ b/include/sysemu/xen-mapcache.h
>> @@ -19,7 +19,7 @@ void xen_map_cache_init(phys_offset_to_gaddr_t f,
>> void *opaque);
>> uint8_t *xen_map_cache(hwaddr phys_addr, hwaddr size,
>> uint8_t lock, bool dma);
>> -ram_addr_t xen_ram_addr_from_mapcache(void *ptr);
>> +ram_addr_t xen_ram_addr_from_mapcache(const void *ptr);
>> void xen_invalidate_map_cache_entry(uint8_t *buffer);
>> void xen_invalidate_map_cache(void);
>> uint8_t *xen_replace_cache_entry(hwaddr old_phys_addr,
>> @@ -40,7 +40,7 @@ static inline uint8_t *xen_map_cache(hwaddr phys_addr,
>> abort();
>> }
>>
>> -static inline ram_addr_t xen_ram_addr_from_mapcache(void *ptr)
>> +static inline ram_addr_t xen_ram_addr_from_mapcache(const void *ptr)
>> {
>> abort();
>> }
>> diff --git a/exec.c b/exec.c
>> index 8e9cc3b47c..02b4e6ea41 100644
>> --- a/exec.c
>> +++ b/exec.c
>> @@ -2614,7 +2614,7 @@ static void *qemu_ram_ptr_length(RAMBlock *ram_block, ram_addr_t addr,
>> }
>>
>> /* Return the offset of a hostpointer within a ramblock */
>> -ram_addr_t qemu_ram_block_host_offset(RAMBlock *rb, void *host)
>> +ram_addr_t qemu_ram_block_host_offset(RAMBlock *rb, const void *host)
>> {
>> ram_addr_t res = (uint8_t *)host - (uint8_t *)rb->host;
>> assert((uintptr_t)host >= (uintptr_t)rb->host);
>> @@ -2640,11 +2640,11 @@ ram_addr_t qemu_ram_block_host_offset(RAMBlock *rb, void *host)
>> * pointer, such as a reference to the region that includes the incoming
>> * ram_addr_t.
>> */
>> -RAMBlock *qemu_ram_block_from_host(void *ptr, bool round_offset,
>> +RAMBlock *qemu_ram_block_from_host(const void *ptr, bool round_offset,
>> ram_addr_t *offset)
>> {
>> RAMBlock *block;
>> - uint8_t *host = ptr;
>> + const uint8_t *host = ptr;
>>
>> if (xen_enabled()) {
>> ram_addr_t ram_addr;
>> @@ -2705,7 +2705,7 @@ RAMBlock *qemu_ram_block_by_name(const char *name)
>>
>> /* Some of the softmmu routines need to translate from a host pointer
>> (typically a TLB entry) back to a ram offset. */
>> -ram_addr_t qemu_ram_addr_from_host(void *ptr)
>> +ram_addr_t qemu_ram_addr_from_host(const void *ptr)
>> {
>> RAMBlock *block;
>> ram_addr_t offset;
>> diff --git a/hw/i386/xen/xen-mapcache.c b/hw/i386/xen/xen-mapcache.c
>> index 5b120ed44b..432ad3354d 100644
>> --- a/hw/i386/xen/xen-mapcache.c
>> +++ b/hw/i386/xen/xen-mapcache.c
>> @@ -363,7 +363,7 @@ uint8_t *xen_map_cache(hwaddr phys_addr, hwaddr size,
>> return p;
>> }
>>
>> -ram_addr_t xen_ram_addr_from_mapcache(void *ptr)
>> +ram_addr_t xen_ram_addr_from_mapcache(const void *ptr)
>> {
>> MapCacheEntry *entry = NULL;
>> MapCacheRev *reventry;
>>
>
^ permalink raw reply
* Re: [Xen-devel] [PATCH v3 03/20] exec: Let qemu_ram_*() functions take a const pointer argument
From: Philippe Mathieu-Daudé @ 2020-02-20 13:23 UTC (permalink / raw)
To: Paolo Bonzini, Peter Maydell, qemu-devel
Cc: Fam Zheng, Dmitry Fleytman, kvm, Michael S. Tsirkin, Jason Wang,
Gerd Hoffmann, Edgar E. Iglesias, Stefano Stabellini,
Matthew Rosato, qemu-block, David Hildenbrand, Halil Pasic,
Christian Borntraeger, Hervé Poussineau, Marcel Apfelbaum,
Anthony Perard, xen-devel, Aleksandar Rikalo, Richard Henderson,
Laurent Vivier, Thomas Huth, Eduardo Habkost, Stefan Weil,
Alistair Francis, Richard Henderson, Paul Durrant, Eric Auger,
qemu-s390x, qemu-arm, Cédric Le Goater, John Snow,
David Gibson, Igor Mitsyanko, Cornelia Huck, Michael Walle,
qemu-ppc
In-Reply-To: <fce0956e-e542-e8a5-bd02-a7941a9db627@redhat.com>
On 2/20/20 2:21 PM, Paolo Bonzini wrote:
> On 20/02/20 14:05, Philippe Mathieu-Daudé wrote:
>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>> ---
>> include/exec/cpu-common.h | 6 +++---
>> include/sysemu/xen-mapcache.h | 4 ++--
>> exec.c | 8 ++++----
>> hw/i386/xen/xen-mapcache.c | 2 +-
>> 4 files changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
>> index 81753bbb34..05ac1a5d69 100644
>> --- a/include/exec/cpu-common.h
>> +++ b/include/exec/cpu-common.h
>> @@ -48,11 +48,11 @@ typedef uint32_t CPUReadMemoryFunc(void *opaque, hwaddr addr);
>>
>> void qemu_ram_remap(ram_addr_t addr, ram_addr_t length);
>> /* This should not be used by devices. */
>> -ram_addr_t qemu_ram_addr_from_host(void *ptr);
>> +ram_addr_t qemu_ram_addr_from_host(const void *ptr);
>
> This is a bit ugly, because the pointer _can_ be modified via
> qemu_map_ram_ptr.
OK.
> Is this needed for the rest of the series to apply?
No!
> Paolo
>
>> RAMBlock *qemu_ram_block_by_name(const char *name);
>> -RAMBlock *qemu_ram_block_from_host(void *ptr, bool round_offset,
>> +RAMBlock *qemu_ram_block_from_host(const void *ptr, bool round_offset,
>> ram_addr_t *offset);
>> -ram_addr_t qemu_ram_block_host_offset(RAMBlock *rb, void *host);
>> +ram_addr_t qemu_ram_block_host_offset(RAMBlock *rb, const void *host);
>> void qemu_ram_set_idstr(RAMBlock *block, const char *name, DeviceState *dev);
>> void qemu_ram_unset_idstr(RAMBlock *block);
>> const char *qemu_ram_get_idstr(RAMBlock *rb);
>> diff --git a/include/sysemu/xen-mapcache.h b/include/sysemu/xen-mapcache.h
>> index c8e7c2f6cf..81e9aa2fa6 100644
>> --- a/include/sysemu/xen-mapcache.h
>> +++ b/include/sysemu/xen-mapcache.h
>> @@ -19,7 +19,7 @@ void xen_map_cache_init(phys_offset_to_gaddr_t f,
>> void *opaque);
>> uint8_t *xen_map_cache(hwaddr phys_addr, hwaddr size,
>> uint8_t lock, bool dma);
>> -ram_addr_t xen_ram_addr_from_mapcache(void *ptr);
>> +ram_addr_t xen_ram_addr_from_mapcache(const void *ptr);
>> void xen_invalidate_map_cache_entry(uint8_t *buffer);
>> void xen_invalidate_map_cache(void);
>> uint8_t *xen_replace_cache_entry(hwaddr old_phys_addr,
>> @@ -40,7 +40,7 @@ static inline uint8_t *xen_map_cache(hwaddr phys_addr,
>> abort();
>> }
>>
>> -static inline ram_addr_t xen_ram_addr_from_mapcache(void *ptr)
>> +static inline ram_addr_t xen_ram_addr_from_mapcache(const void *ptr)
>> {
>> abort();
>> }
>> diff --git a/exec.c b/exec.c
>> index 8e9cc3b47c..02b4e6ea41 100644
>> --- a/exec.c
>> +++ b/exec.c
>> @@ -2614,7 +2614,7 @@ static void *qemu_ram_ptr_length(RAMBlock *ram_block, ram_addr_t addr,
>> }
>>
>> /* Return the offset of a hostpointer within a ramblock */
>> -ram_addr_t qemu_ram_block_host_offset(RAMBlock *rb, void *host)
>> +ram_addr_t qemu_ram_block_host_offset(RAMBlock *rb, const void *host)
>> {
>> ram_addr_t res = (uint8_t *)host - (uint8_t *)rb->host;
>> assert((uintptr_t)host >= (uintptr_t)rb->host);
>> @@ -2640,11 +2640,11 @@ ram_addr_t qemu_ram_block_host_offset(RAMBlock *rb, void *host)
>> * pointer, such as a reference to the region that includes the incoming
>> * ram_addr_t.
>> */
>> -RAMBlock *qemu_ram_block_from_host(void *ptr, bool round_offset,
>> +RAMBlock *qemu_ram_block_from_host(const void *ptr, bool round_offset,
>> ram_addr_t *offset)
>> {
>> RAMBlock *block;
>> - uint8_t *host = ptr;
>> + const uint8_t *host = ptr;
>>
>> if (xen_enabled()) {
>> ram_addr_t ram_addr;
>> @@ -2705,7 +2705,7 @@ RAMBlock *qemu_ram_block_by_name(const char *name)
>>
>> /* Some of the softmmu routines need to translate from a host pointer
>> (typically a TLB entry) back to a ram offset. */
>> -ram_addr_t qemu_ram_addr_from_host(void *ptr)
>> +ram_addr_t qemu_ram_addr_from_host(const void *ptr)
>> {
>> RAMBlock *block;
>> ram_addr_t offset;
>> diff --git a/hw/i386/xen/xen-mapcache.c b/hw/i386/xen/xen-mapcache.c
>> index 5b120ed44b..432ad3354d 100644
>> --- a/hw/i386/xen/xen-mapcache.c
>> +++ b/hw/i386/xen/xen-mapcache.c
>> @@ -363,7 +363,7 @@ uint8_t *xen_map_cache(hwaddr phys_addr, hwaddr size,
>> return p;
>> }
>>
>> -ram_addr_t xen_ram_addr_from_mapcache(void *ptr)
>> +ram_addr_t xen_ram_addr_from_mapcache(const void *ptr)
>> {
>> MapCacheEntry *entry = NULL;
>> MapCacheRev *reventry;
>>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* [PATCH v3 19/20] Let cpu_[physical]_memory() calls pass a boolean 'is_write' argument
From: Philippe Mathieu-Daudé @ 2020-02-20 13:05 UTC (permalink / raw)
To: Peter Maydell, qemu-devel
Cc: Fam Zheng, Dmitry Fleytman, kvm, Michael S. Tsirkin, Jason Wang,
Gerd Hoffmann, Edgar E. Iglesias, Stefano Stabellini,
Matthew Rosato, qemu-block, David Hildenbrand, Halil Pasic,
Christian Borntraeger, Hervé Poussineau, Anthony Perard,
xen-devel, Aleksandar Rikalo, Richard Henderson,
Philippe Mathieu-Daudé, Laurent Vivier, Thomas Huth,
Eduardo Habkost, Stefan Weil, Alistair Francis, Richard Henderson,
Paul Durrant, Eric Auger, qemu-s390x, qemu-arm,
Cédric Le Goater, John Snow, David Gibson, Igor Mitsyanko,
Cornelia Huck, Michael Walle, qemu-ppc, Paolo Bonzini
In-Reply-To: <20200220130548.29974-1-philmd@redhat.com>
Use an explicit boolean type.
This commit was produced with the included Coccinelle script
scripts/coccinelle/exec_rw_const.
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
---
scripts/coccinelle/exec_rw_const.cocci | 14 ++++++++++++++
include/exec/cpu-common.h | 4 ++--
hw/display/exynos4210_fimd.c | 3 ++-
hw/display/milkymist-tmu2.c | 8 ++++----
hw/display/omap_dss.c | 2 +-
hw/display/ramfb.c | 2 +-
hw/misc/pc-testdev.c | 2 +-
hw/nvram/spapr_nvram.c | 4 ++--
hw/ppc/ppc440_uc.c | 6 ++++--
hw/ppc/spapr_hcall.c | 4 ++--
hw/s390x/ipl.c | 2 +-
hw/s390x/s390-pci-bus.c | 2 +-
hw/s390x/virtio-ccw.c | 2 +-
hw/xen/xen_pt_graphics.c | 2 +-
target/i386/hax-all.c | 4 ++--
target/s390x/excp_helper.c | 2 +-
target/s390x/helper.c | 6 +++---
17 files changed, 43 insertions(+), 26 deletions(-)
diff --git a/scripts/coccinelle/exec_rw_const.cocci b/scripts/coccinelle/exec_rw_const.cocci
index ee98ce988e..54b1cab8cd 100644
--- a/scripts/coccinelle/exec_rw_const.cocci
+++ b/scripts/coccinelle/exec_rw_const.cocci
@@ -11,6 +11,20 @@ expression E1, E2, E3, E4, E5;
|
- address_space_rw(E1, E2, E3, E4, E5, 1)
+ address_space_rw(E1, E2, E3, E4, E5, true)
+|
+
+- cpu_physical_memory_rw(E1, E2, E3, 0)
++ cpu_physical_memory_rw(E1, E2, E3, false)
+|
+- cpu_physical_memory_rw(E1, E2, E3, 1)
++ cpu_physical_memory_rw(E1, E2, E3, true)
+|
+
+- cpu_physical_memory_map(E1, E2, 0)
++ cpu_physical_memory_map(E1, E2, false)
+|
+- cpu_physical_memory_map(E1, E2, 1)
++ cpu_physical_memory_map(E1, E2, true)
)
// Use address_space_write instead of casting to non-const
diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
index 6bfe201779..e7fd5781ea 100644
--- a/include/exec/cpu-common.h
+++ b/include/exec/cpu-common.h
@@ -74,12 +74,12 @@ void cpu_physical_memory_rw(hwaddr addr, void *buf,
static inline void cpu_physical_memory_read(hwaddr addr,
void *buf, hwaddr len)
{
- cpu_physical_memory_rw(addr, buf, len, 0);
+ cpu_physical_memory_rw(addr, buf, len, false);
}
static inline void cpu_physical_memory_write(hwaddr addr,
const void *buf, hwaddr len)
{
- cpu_physical_memory_rw(addr, (void *)buf, len, 1);
+ cpu_physical_memory_rw(addr, (void *)buf, len, true);
}
void *cpu_physical_memory_map(hwaddr addr,
hwaddr *plen,
diff --git a/hw/display/exynos4210_fimd.c b/hw/display/exynos4210_fimd.c
index c1071ecd46..ec6776680e 100644
--- a/hw/display/exynos4210_fimd.c
+++ b/hw/display/exynos4210_fimd.c
@@ -1164,7 +1164,8 @@ static void fimd_update_memory_section(Exynos4210fimdState *s, unsigned win)
goto error_return;
}
- w->host_fb_addr = cpu_physical_memory_map(fb_start_addr, &fb_mapped_len, 0);
+ w->host_fb_addr = cpu_physical_memory_map(fb_start_addr, &fb_mapped_len,
+ false);
if (!w->host_fb_addr) {
DPRINT_ERROR("Failed to map window %u framebuffer\n", win);
goto error_return;
diff --git a/hw/display/milkymist-tmu2.c b/hw/display/milkymist-tmu2.c
index 199f1227e7..513c0d5bab 100644
--- a/hw/display/milkymist-tmu2.c
+++ b/hw/display/milkymist-tmu2.c
@@ -218,7 +218,7 @@ static void tmu2_start(MilkymistTMU2State *s)
glGenTextures(1, &texture);
glBindTexture(GL_TEXTURE_2D, texture);
fb_len = 2ULL * s->regs[R_TEXHRES] * s->regs[R_TEXVRES];
- fb = cpu_physical_memory_map(s->regs[R_TEXFBUF], &fb_len, 0);
+ fb = cpu_physical_memory_map(s->regs[R_TEXFBUF], &fb_len, false);
if (fb == NULL) {
glDeleteTextures(1, &texture);
glXMakeContextCurrent(s->dpy, None, None, NULL);
@@ -262,7 +262,7 @@ static void tmu2_start(MilkymistTMU2State *s)
/* Read the QEMU dest. framebuffer into the OpenGL framebuffer */
fb_len = 2ULL * s->regs[R_DSTHRES] * s->regs[R_DSTVRES];
- fb = cpu_physical_memory_map(s->regs[R_DSTFBUF], &fb_len, 0);
+ fb = cpu_physical_memory_map(s->regs[R_DSTFBUF], &fb_len, false);
if (fb == NULL) {
glDeleteTextures(1, &texture);
glXMakeContextCurrent(s->dpy, None, None, NULL);
@@ -281,7 +281,7 @@ static void tmu2_start(MilkymistTMU2State *s)
/* Map the texture */
mesh_len = MESH_MAXSIZE*MESH_MAXSIZE*sizeof(struct vertex);
- mesh = cpu_physical_memory_map(s->regs[R_VERTICESADDR], &mesh_len, 0);
+ mesh = cpu_physical_memory_map(s->regs[R_VERTICESADDR], &mesh_len, false);
if (mesh == NULL) {
glDeleteTextures(1, &texture);
glXMakeContextCurrent(s->dpy, None, None, NULL);
@@ -298,7 +298,7 @@ static void tmu2_start(MilkymistTMU2State *s)
/* Write back the OpenGL framebuffer to the QEMU framebuffer */
fb_len = 2ULL * s->regs[R_DSTHRES] * s->regs[R_DSTVRES];
- fb = cpu_physical_memory_map(s->regs[R_DSTFBUF], &fb_len, 1);
+ fb = cpu_physical_memory_map(s->regs[R_DSTFBUF], &fb_len, true);
if (fb == NULL) {
glDeleteTextures(1, &texture);
glXMakeContextCurrent(s->dpy, None, None, NULL);
diff --git a/hw/display/omap_dss.c b/hw/display/omap_dss.c
index 637aae8d39..32dc0d6aa7 100644
--- a/hw/display/omap_dss.c
+++ b/hw/display/omap_dss.c
@@ -632,7 +632,7 @@ static void omap_rfbi_transfer_start(struct omap_dss_s *s)
len = s->rfbi.pixels * 2;
data_addr = s->dispc.l[0].addr[0];
- data = cpu_physical_memory_map(data_addr, &len, 0);
+ data = cpu_physical_memory_map(data_addr, &len, false);
if (data && len != s->rfbi.pixels * 2) {
cpu_physical_memory_unmap(data, len, 0, 0);
data = NULL;
diff --git a/hw/display/ramfb.c b/hw/display/ramfb.c
index cd94940223..7ba07c80f6 100644
--- a/hw/display/ramfb.c
+++ b/hw/display/ramfb.c
@@ -57,7 +57,7 @@ static DisplaySurface *ramfb_create_display_surface(int width, int height,
}
size = (hwaddr)linesize * height;
- data = cpu_physical_memory_map(addr, &size, 0);
+ data = cpu_physical_memory_map(addr, &size, false);
if (size != (hwaddr)linesize * height) {
cpu_physical_memory_unmap(data, size, 0, 0);
return NULL;
diff --git a/hw/misc/pc-testdev.c b/hw/misc/pc-testdev.c
index 0fb84ddc6b..8aa8e6549f 100644
--- a/hw/misc/pc-testdev.c
+++ b/hw/misc/pc-testdev.c
@@ -125,7 +125,7 @@ static void test_flush_page_write(void *opaque, hwaddr addr, uint64_t data,
unsigned len)
{
hwaddr page = 4096;
- void *a = cpu_physical_memory_map(data & ~0xffful, &page, 0);
+ void *a = cpu_physical_memory_map(data & ~0xffful, &page, false);
/* We might not be able to get the full page, only mprotect what we actually
have mapped */
diff --git a/hw/nvram/spapr_nvram.c b/hw/nvram/spapr_nvram.c
index 877ddef7b9..15d08281d4 100644
--- a/hw/nvram/spapr_nvram.c
+++ b/hw/nvram/spapr_nvram.c
@@ -89,7 +89,7 @@ static void rtas_nvram_fetch(PowerPCCPU *cpu, SpaprMachineState *spapr,
assert(nvram->buf);
- membuf = cpu_physical_memory_map(buffer, &len, 1);
+ membuf = cpu_physical_memory_map(buffer, &len, true);
memcpy(membuf, nvram->buf + offset, len);
cpu_physical_memory_unmap(membuf, len, 1, len);
@@ -127,7 +127,7 @@ static void rtas_nvram_store(PowerPCCPU *cpu, SpaprMachineState *spapr,
return;
}
- membuf = cpu_physical_memory_map(buffer, &len, 0);
+ membuf = cpu_physical_memory_map(buffer, &len, false);
alen = len;
if (nvram->blk) {
diff --git a/hw/ppc/ppc440_uc.c b/hw/ppc/ppc440_uc.c
index 1a6a8fac22..d5ea962249 100644
--- a/hw/ppc/ppc440_uc.c
+++ b/hw/ppc/ppc440_uc.c
@@ -909,8 +909,10 @@ static void dcr_write_dma(void *opaque, int dcrn, uint32_t val)
sidx = didx = 0;
width = 1 << ((val & DMA0_CR_PW) >> 25);
- rptr = cpu_physical_memory_map(dma->ch[chnl].sa, &rlen, 0);
- wptr = cpu_physical_memory_map(dma->ch[chnl].da, &wlen, 1);
+ rptr = cpu_physical_memory_map(dma->ch[chnl].sa, &rlen,
+ false);
+ wptr = cpu_physical_memory_map(dma->ch[chnl].da, &wlen,
+ true);
if (rptr && wptr) {
if (!(val & DMA0_CR_DEC) &&
val & DMA0_CR_SAI && val & DMA0_CR_DAI) {
diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
index b8bb66b5c0..caf55ab044 100644
--- a/hw/ppc/spapr_hcall.c
+++ b/hw/ppc/spapr_hcall.c
@@ -832,7 +832,7 @@ static target_ulong h_page_init(PowerPCCPU *cpu, SpaprMachineState *spapr,
if (!is_ram_address(spapr, dst) || (dst & ~TARGET_PAGE_MASK) != 0) {
return H_PARAMETER;
}
- pdst = cpu_physical_memory_map(dst, &len, 1);
+ pdst = cpu_physical_memory_map(dst, &len, true);
if (!pdst || len != TARGET_PAGE_SIZE) {
return H_PARAMETER;
}
@@ -843,7 +843,7 @@ static target_ulong h_page_init(PowerPCCPU *cpu, SpaprMachineState *spapr,
ret = H_PARAMETER;
goto unmap_out;
}
- psrc = cpu_physical_memory_map(src, &len, 0);
+ psrc = cpu_physical_memory_map(src, &len, false);
if (!psrc || len != TARGET_PAGE_SIZE) {
ret = H_PARAMETER;
goto unmap_out;
diff --git a/hw/s390x/ipl.c b/hw/s390x/ipl.c
index 7773499d7f..0817874b48 100644
--- a/hw/s390x/ipl.c
+++ b/hw/s390x/ipl.c
@@ -626,7 +626,7 @@ static void s390_ipl_prepare_qipl(S390CPU *cpu)
uint8_t *addr;
uint64_t len = 4096;
- addr = cpu_physical_memory_map(cpu->env.psa, &len, 1);
+ addr = cpu_physical_memory_map(cpu->env.psa, &len, true);
if (!addr || len < QIPL_ADDRESS + sizeof(QemuIplParameters)) {
error_report("Cannot set QEMU IPL parameters");
return;
diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
index 7c6a2b3c63..ed8be124da 100644
--- a/hw/s390x/s390-pci-bus.c
+++ b/hw/s390x/s390-pci-bus.c
@@ -641,7 +641,7 @@ static uint8_t set_ind_atomic(uint64_t ind_loc, uint8_t to_be_set)
hwaddr len = 1;
uint8_t *ind_addr;
- ind_addr = cpu_physical_memory_map(ind_loc, &len, 1);
+ ind_addr = cpu_physical_memory_map(ind_loc, &len, true);
if (!ind_addr) {
s390_pci_generate_error_event(ERR_EVENT_AIRERR, 0, 0, 0, 0);
return -1;
diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
index 13f57e7b67..50cf95b781 100644
--- a/hw/s390x/virtio-ccw.c
+++ b/hw/s390x/virtio-ccw.c
@@ -790,7 +790,7 @@ static uint8_t virtio_set_ind_atomic(SubchDev *sch, uint64_t ind_loc,
hwaddr len = 1;
uint8_t *ind_addr;
- ind_addr = cpu_physical_memory_map(ind_loc, &len, 1);
+ ind_addr = cpu_physical_memory_map(ind_loc, &len, true);
if (!ind_addr) {
error_report("%s(%x.%x.%04x): unable to access indicator",
__func__, sch->cssid, sch->ssid, sch->schid);
diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
index b69732729b..b11e4e0546 100644
--- a/hw/xen/xen_pt_graphics.c
+++ b/hw/xen/xen_pt_graphics.c
@@ -222,7 +222,7 @@ void xen_pt_setup_vga(XenPCIPassthroughState *s, XenHostPCIDevice *dev,
}
/* Currently we fixed this address as a primary for legacy BIOS. */
- cpu_physical_memory_rw(0xc0000, bios, bios_size, 1);
+ cpu_physical_memory_rw(0xc0000, bios, bios_size, true);
}
uint32_t igd_read_opregion(XenPCIPassthroughState *s)
diff --git a/target/i386/hax-all.c b/target/i386/hax-all.c
index a9cc51e6ce..38936d7af6 100644
--- a/target/i386/hax-all.c
+++ b/target/i386/hax-all.c
@@ -376,8 +376,8 @@ static int hax_handle_fastmmio(CPUArchState *env, struct hax_fastmmio *hft)
* hft->direction == 2: gpa ==> gpa2
*/
uint64_t value;
- cpu_physical_memory_rw(hft->gpa, &value, hft->size, 0);
- cpu_physical_memory_rw(hft->gpa2, &value, hft->size, 1);
+ cpu_physical_memory_rw(hft->gpa, &value, hft->size, false);
+ cpu_physical_memory_rw(hft->gpa2, &value, hft->size, true);
}
return 0;
diff --git a/target/s390x/excp_helper.c b/target/s390x/excp_helper.c
index 1e9d6f20c1..3b58d10df3 100644
--- a/target/s390x/excp_helper.c
+++ b/target/s390x/excp_helper.c
@@ -393,7 +393,7 @@ static int mchk_store_vregs(CPUS390XState *env, uint64_t mcesao)
MchkExtSaveArea *sa;
int i;
- sa = cpu_physical_memory_map(mcesao, &len, 1);
+ sa = cpu_physical_memory_map(mcesao, &len, true);
if (!sa) {
return -EFAULT;
}
diff --git a/target/s390x/helper.c b/target/s390x/helper.c
index a3a49164e4..b810ad431e 100644
--- a/target/s390x/helper.c
+++ b/target/s390x/helper.c
@@ -151,7 +151,7 @@ LowCore *cpu_map_lowcore(CPUS390XState *env)
LowCore *lowcore;
hwaddr len = sizeof(LowCore);
- lowcore = cpu_physical_memory_map(env->psa, &len, 1);
+ lowcore = cpu_physical_memory_map(env->psa, &len, true);
if (len < sizeof(LowCore)) {
cpu_abort(env_cpu(env), "Could not map lowcore\n");
@@ -246,7 +246,7 @@ int s390_store_status(S390CPU *cpu, hwaddr addr, bool store_arch)
hwaddr len = sizeof(*sa);
int i;
- sa = cpu_physical_memory_map(addr, &len, 1);
+ sa = cpu_physical_memory_map(addr, &len, true);
if (!sa) {
return -EFAULT;
}
@@ -298,7 +298,7 @@ int s390_store_adtl_status(S390CPU *cpu, hwaddr addr, hwaddr len)
hwaddr save = len;
int i;
- sa = cpu_physical_memory_map(addr, &save, 1);
+ sa = cpu_physical_memory_map(addr, &save, true);
if (!sa) {
return -EFAULT;
}
--
2.21.1
^ permalink raw reply related
* [PATCH v5 2/6] doc: board: verdin-imx8mm: convert readme to reST
From: Bin Meng @ 2020-02-20 13:24 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20200212151433.9713-3-igor.opaniuk@gmail.com>
On Wed, Feb 12, 2020 at 11:14 PM Igor Opaniuk <igor.opaniuk@gmail.com> wrote:
>
> From: Igor Opaniuk <igor.opaniuk@toradex.com>
>
> Convert README to reStructuredText format.
>
> Signed-off-by: Igor Opaniuk <igor.opaniuk@toradex.com>
> ---
>
> board/toradex/verdin-imx8mm/README | 88 ----------------------
> doc/board/toradex/index.rst | 1 +
> doc/board/toradex/verdin-imx8mm.rst | 112 ++++++++++++++++++++++++++++
> 3 files changed, 113 insertions(+), 88 deletions(-)
> delete mode 100644 board/toradex/verdin-imx8mm/README
> create mode 100644 doc/board/toradex/verdin-imx8mm.rst
>
> diff --git a/board/toradex/verdin-imx8mm/README b/board/toradex/verdin-imx8mm/README
> deleted file mode 100644
> index 1dac969476..0000000000
> --- a/board/toradex/verdin-imx8mm/README
> +++ /dev/null
> @@ -1,88 +0,0 @@
> -U-Boot for the Toradex Verdin iMX8M Mini Module
> -
> -Quick Start
> -===========
> -
> -- Build the ARM trusted firmware binary
> -- Get the DDR firmware
> -- Build U-Boot
> -- Flash to eMMC
> -- Boot
> -
> -Get and Build the ARM Trusted Firmware (Trusted Firmware A)
> -===========================================================
> -
> -$ echo "Downloading and building TF-A..."
> -$ git clone -b imx_4.14.98_2.3.0 https://source.codeaurora.org/external/imx/imx-atf
> -$ cd imx-atf
> -
> -Please edit `plat/imx/imx8mm/include/platform_def.h` so it contains proper
> -values for UART configuration and BL31 base address (correct values listed
> -below):
> -#define BL31_BASE 0x910000
> -#define IMX_BOOT_UART_BASE 0x30860000
> -#define DEBUG_CONSOLE 1
> -
> -Then build ATF (TF-A):
> -$ make PLAT=imx8mm bl31
> -
> -Get the DDR Firmware
> -====================
> -
> -$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.4.1.bin
> -$ chmod +x firmware-imx-8.4.1.bin
> -$ ./firmware-imx-8.4.1.bin
> -$ cp firmware-imx-8.4.1/firmware/ddr/synopsys/lpddr4*.bin ./
> -
> -Build U-Boot
> -============
> -
> -$ export CROSS_COMPILE=aarch64-linux-gnu-
> -$ make verdin-imx8mm_defconfig
> -$ make flash.bin
> -
> -Flash to eMMC
> -=============
> -
> -> tftpboot ${loadaddr} flash.bin
> -> setexpr blkcnt ${filesize} + 0x1ff && setexpr blkcnt ${blkcnt} / 0x200
> -> mmc dev 0 1 && mmc write ${loadaddr} 0x2 ${blkcnt}
> -
> -As a convenience, instead of the last two commands one may also use the update
> -U-Boot wrapper:
> -> run update_uboot
> -
> -Boot
> -====
> -
> -ATF, U-boot proper and u-boot.dtb images are packed into FIT image,
nits: U-Boot
> -which is loaded and parsed by SPL.
> -
> -Boot sequence is:
> -SPL ---> ATF (TF-A) ---> U-boot proper
nits: U-Boot
> -
> -Output:
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Will fix the nits when applying
^ permalink raw reply
* Re: [PATCH v1 07/13] migrate/ram: Get rid of "place_source" in ram_load_postcopy()
From: David Hildenbrand @ 2020-02-20 13:22 UTC (permalink / raw)
To: Peter Xu
Cc: Eduardo Habkost, Juan Quintela, qemu-devel,
Dr . David Alan Gilbert, Paolo Bonzini, Richard Henderson
In-Reply-To: <20200219205533.GG37550@xz-x1>
On 19.02.20 21:55, Peter Xu wrote:
> On Wed, Feb 19, 2020 at 03:47:30PM -0500, Peter Xu wrote:
>> On Wed, Feb 19, 2020 at 05:17:19PM +0100, David Hildenbrand wrote:
>>> It's always the same value.
>>
>> I guess not, because...
>>
>>>
>>> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
>>> Cc: Juan Quintela <quintela@redhat.com>
>>> Cc: Peter Xu <peterx@redhat.com>
>>> Signed-off-by: David Hildenbrand <david@redhat.com>
>>> ---
>>> migration/ram.c | 8 +++-----
>>> 1 file changed, 3 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/migration/ram.c b/migration/ram.c
>>> index cbd54947fb..75014717f6 100644
>>> --- a/migration/ram.c
>>> +++ b/migration/ram.c
>>> @@ -3119,7 +3119,6 @@ static int ram_load_postcopy(QEMUFile *f)
>>> ram_addr_t addr;
>>> void *host = NULL;
>>> void *page_buffer = NULL;
>>> - void *place_source = NULL;
>>> RAMBlock *block = NULL;
>>> uint8_t ch;
>>> int len;
>>> @@ -3188,7 +3187,6 @@ static int ram_load_postcopy(QEMUFile *f)
>>> place_needed = true;
>>> target_pages = 0;
>>> }
>>> - place_source = postcopy_host_page;
>>> }
>>>
>>> switch (flags & ~RAM_SAVE_FLAG_CONTINUE) {
>>> @@ -3220,7 +3218,7 @@ static int ram_load_postcopy(QEMUFile *f)
>>> * buffer to make sure the buffer is valid when
>>> * placing the page.
>>> */
>>> - qemu_get_buffer_in_place(f, (uint8_t **)&place_source,
>>
>> ... it can be modified inside the call.
>>
>> I feel like this patch could even fail the QEMU unit test. It would
>> be good to mention what tests have been carried out in the cover
>> letter or with RFC tag if no test is done yet.
>>
>> For a series like this, I'll try at least the unit tests and smoke on
>> both precopy and postcopy. The resizing test would be even better but
>> seems untrivial, so maybe optional.
>
> For resizing test, an easy way (I can think of) is to temporarily
> remove the size check below in your test branch:
Yeah, it's especially hard to have a reliable test one can materialize.
I played with manual tests like this myself.
I'm thinking about testing this with a device that can trigger resizes
on demand, e.g., virtio-mem, for now on my private branch. But I'd
really like to have some test one can automate at one point ... however,
there seems to be no easy way to achieve that right now.
Thanks!
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
From: Paolo Bonzini @ 2020-02-20 13:17 UTC (permalink / raw)
To: Marc Zyngier, Marek Szyprowski
Cc: Vladimir Murzin, Russell King, kvm, Arnd Bergmann,
Suzuki K Poulose, Quentin Perret, Christoffer Dall,
Krzysztof Kozlowski, Bartlomiej Zolnierkiewicz, James Morse,
Julien Thierry, Will Deacon, kvmarm, linux-arm-kernel
In-Reply-To: <43446bd5e884ae92f243799cbe748871@kernel.org>
On 20/02/20 14:15, Marc Zyngier wrote:
>> That is a bit sad information. Mainline Exynos finally got everything
>> that was needed to run it on the quite popular Samsung Exynos5422-based
>> Odroid XU4/HC1/MC1 boards. According to the Odroid related forums it is
>> being used. We also use it internally at Samsung.
>
> Something like "too little, too late" springs to mind, but let's be
> constructive. Is anyone using it in a production environment, where
> they rely on the latest mainline kernel having KVM support?
Depends if you consider "production environment" somebody playing at
home with a SBC. But it's true that, these days, most of those that
support EL2 do support ARM64, even if they are used with a 32-bit userland.
Paolo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] sound: Replace zero-length array with flexible-array member
From: Gustavo A. R. Silva @ 2020-02-20 13:24 UTC (permalink / raw)
To: Jaroslav Kysela, Takashi Iwai, Liam Girdwood, Mark Brown,
Clemens Ladisch, Takashi Sakamoto, Cezary Rojewski,
Pierre-Louis Bossart, Jie Yang
Cc: alsa-devel, linux-kernel, Gustavo A. R. Silva
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
include/sound/control.h | 2 +-
include/sound/intel-nhlt.h | 6 +++---
include/sound/soc-dapm.h | 2 +-
include/sound/soc.h | 2 +-
include/uapi/sound/asound.h | 2 +-
include/uapi/sound/skl-tplg-interface.h | 2 +-
sound/core/oss/pcm_plugin.h | 2 +-
sound/firewire/fireworks/fireworks.h | 2 +-
sound/soc/intel/atom/sst-atom-controls.h | 2 +-
sound/soc/intel/skylake/skl-i2s.h | 2 +-
sound/soc/intel/skylake/skl-topology.h | 4 ++--
sound/soc/intel/skylake/skl.h | 2 +-
sound/usb/usx2y/usbusx2y.h | 2 +-
13 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/include/sound/control.h b/include/sound/control.h
index 11feeee31e35..aeaed2a05bae 100644
--- a/include/sound/control.h
+++ b/include/sound/control.h
@@ -75,7 +75,7 @@ struct snd_kcontrol {
unsigned long private_value;
void *private_data;
void (*private_free)(struct snd_kcontrol *kcontrol);
- struct snd_kcontrol_volatile vd[0]; /* volatile data */
+ struct snd_kcontrol_volatile vd[]; /* volatile data */
};
#define snd_kcontrol(n) list_entry(n, struct snd_kcontrol, list)
diff --git a/include/sound/intel-nhlt.h b/include/sound/intel-nhlt.h
index f657fd8fc0ad..743c2f442280 100644
--- a/include/sound/intel-nhlt.h
+++ b/include/sound/intel-nhlt.h
@@ -50,7 +50,7 @@ enum nhlt_device_type {
struct nhlt_specific_cfg {
u32 size;
- u8 caps[0];
+ u8 caps[];
} __packed;
struct nhlt_fmt_cfg {
@@ -60,7 +60,7 @@ struct nhlt_fmt_cfg {
struct nhlt_fmt {
u8 fmt_count;
- struct nhlt_fmt_cfg fmt_config[0];
+ struct nhlt_fmt_cfg fmt_config[];
} __packed;
struct nhlt_endpoint {
@@ -80,7 +80,7 @@ struct nhlt_endpoint {
struct nhlt_acpi_table {
struct acpi_table_header header;
u8 endpoint_count;
- struct nhlt_endpoint desc[0];
+ struct nhlt_endpoint desc[];
} __packed;
struct nhlt_resource_desc {
diff --git a/include/sound/soc-dapm.h b/include/sound/soc-dapm.h
index 1a9c5dd40228..f870f927b70c 100644
--- a/include/sound/soc-dapm.h
+++ b/include/sound/soc-dapm.h
@@ -688,7 +688,7 @@ struct snd_soc_dapm_context {
/* A list of widgets associated with an object, typically a snd_kcontrol */
struct snd_soc_dapm_widget_list {
int num_widgets;
- struct snd_soc_dapm_widget *widgets[0];
+ struct snd_soc_dapm_widget *widgets[];
};
#define for_each_dapm_widgets(list, i, widget) \
diff --git a/include/sound/soc.h b/include/sound/soc.h
index f0e4f36f83bf..9944b978ae70 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -1146,7 +1146,7 @@ struct snd_soc_pcm_runtime {
unsigned int fe_compr:1; /* for Dynamic PCM */
int num_components;
- struct snd_soc_component *components[0]; /* CPU/Codec/Platform */
+ struct snd_soc_component *components[]; /* CPU/Codec/Platform */
};
#define for_each_rtd_components(rtd, i, component) \
for ((i) = 0; \
diff --git a/include/uapi/sound/asound.h b/include/uapi/sound/asound.h
index 535a7229e1d9..3809993f6cb4 100644
--- a/include/uapi/sound/asound.h
+++ b/include/uapi/sound/asound.h
@@ -1071,7 +1071,7 @@ struct snd_ctl_elem_value {
struct snd_ctl_tlv {
unsigned int numid; /* control element numeric identification */
unsigned int length; /* in bytes aligned to 4 */
- unsigned int tlv[0]; /* first TLV */
+ unsigned int tlv[]; /* first TLV */
};
#define SNDRV_CTL_IOCTL_PVERSION _IOR('U', 0x00, int)
diff --git a/include/uapi/sound/skl-tplg-interface.h b/include/uapi/sound/skl-tplg-interface.h
index 9eee32f5e407..62f76f154d19 100644
--- a/include/uapi/sound/skl-tplg-interface.h
+++ b/include/uapi/sound/skl-tplg-interface.h
@@ -149,7 +149,7 @@ struct skl_dfw_algo_data {
__u32 rsvd:30;
__u32 param_id;
__u32 max;
- char params[0];
+ char params[];
} __packed;
enum skl_tkn_dir {
diff --git a/sound/core/oss/pcm_plugin.h b/sound/core/oss/pcm_plugin.h
index 8d2f7a4e3ab6..46e273bd4a78 100644
--- a/sound/core/oss/pcm_plugin.h
+++ b/sound/core/oss/pcm_plugin.h
@@ -64,7 +64,7 @@ struct snd_pcm_plugin {
char *buf;
snd_pcm_uframes_t buf_frames;
struct snd_pcm_plugin_channel *buf_channels;
- char extra_data[0];
+ char extra_data[];
};
int snd_pcm_plugin_build(struct snd_pcm_substream *handle,
diff --git a/sound/firewire/fireworks/fireworks.h b/sound/firewire/fireworks/fireworks.h
index dda797209a27..654e28a6669f 100644
--- a/sound/firewire/fireworks/fireworks.h
+++ b/sound/firewire/fireworks/fireworks.h
@@ -177,7 +177,7 @@ struct snd_efw_phys_meters {
u32 in_meters;
u32 reserved4;
u32 reserved5;
- u32 values[0];
+ u32 values[];
} __packed;
enum snd_efw_clock_source {
SND_EFW_CLOCK_SOURCE_INTERNAL = 0,
diff --git a/sound/soc/intel/atom/sst-atom-controls.h b/sound/soc/intel/atom/sst-atom-controls.h
index 5356e954a732..620b48d2a064 100644
--- a/sound/soc/intel/atom/sst-atom-controls.h
+++ b/sound/soc/intel/atom/sst-atom-controls.h
@@ -410,7 +410,7 @@ struct sst_cmd_set_gain_dual {
struct sst_cmd_set_params {
struct sst_destination_id dst;
u16 command_id;
- char params[0];
+ char params[];
} __packed;
diff --git a/sound/soc/intel/skylake/skl-i2s.h b/sound/soc/intel/skylake/skl-i2s.h
index d7c15873c0d4..dfce91e11be1 100644
--- a/sound/soc/intel/skylake/skl-i2s.h
+++ b/sound/soc/intel/skylake/skl-i2s.h
@@ -46,7 +46,7 @@ struct skl_i2s_config_mclk {
struct skl_i2s_config_mclk_ext {
u32 mdivctrl;
u32 mdivr_count;
- u32 mdivr[0];
+ u32 mdivr[];
} __packed;
struct skl_i2s_config_blob_signature {
diff --git a/sound/soc/intel/skylake/skl-topology.h b/sound/soc/intel/skylake/skl-topology.h
index e967800dbb62..d2cd8ef8e97f 100644
--- a/sound/soc/intel/skylake/skl-topology.h
+++ b/sound/soc/intel/skylake/skl-topology.h
@@ -119,7 +119,7 @@ struct skl_cpr_gtw_cfg {
struct skl_dma_control {
u32 node_id;
u32 config_length;
- u32 config_data[0];
+ u32 config_data[];
} __packed;
struct skl_cpr_cfg {
@@ -152,7 +152,7 @@ struct skl_up_down_mixer_cfg {
struct skl_algo_cfg {
struct skl_base_cfg base_cfg;
- char params[0];
+ char params[];
} __packed;
struct skl_base_outfmt_cfg {
diff --git a/sound/soc/intel/skylake/skl.h b/sound/soc/intel/skylake/skl.h
index 2bfbf59277c4..26057f38a014 100644
--- a/sound/soc/intel/skylake/skl.h
+++ b/sound/soc/intel/skylake/skl.h
@@ -49,7 +49,7 @@ struct skl_astate_param {
struct skl_astate_config {
u32 count;
- struct skl_astate_param astate_table[0];
+ struct skl_astate_param astate_table[];
};
struct skl_fw_config {
diff --git a/sound/usb/usx2y/usbusx2y.h b/sound/usb/usx2y/usbusx2y.h
index e0f77172ce8f..144b85f57bd2 100644
--- a/sound/usb/usx2y/usbusx2y.h
+++ b/sound/usb/usx2y/usbusx2y.h
@@ -18,7 +18,7 @@ struct snd_usX2Y_AsyncSeq {
struct snd_usX2Y_urbSeq {
int submitted;
int len;
- struct urb *urb[0];
+ struct urb *urb[];
};
#include "usx2yhwdeppcm.h"
--
2.25.0
^ permalink raw reply related
* Re: [PATCH v3 03/20] exec: Let qemu_ram_*() functions take a const pointer argument
From: Philippe Mathieu-Daudé @ 2020-02-20 13:23 UTC (permalink / raw)
To: Paolo Bonzini, Peter Maydell, qemu-devel
Cc: Fam Zheng, Dmitry Fleytman, kvm, Michael S. Tsirkin, Jason Wang,
Gerd Hoffmann, Edgar E. Iglesias, Stefano Stabellini,
Matthew Rosato, qemu-block, David Hildenbrand, Halil Pasic,
Christian Borntraeger, Hervé Poussineau, Anthony Perard,
xen-devel, Aleksandar Rikalo, Richard Henderson, Laurent Vivier,
Thomas Huth, Eduardo Habkost, Stefan Weil, Alistair Francis,
Richard Henderson, Paul Durrant, Eric Auger, qemu-s390x, qemu-arm,
Cédric Le Goater, John Snow, David Gibson, Igor Mitsyanko,
Cornelia Huck, Michael Walle, qemu-ppc
In-Reply-To: <fce0956e-e542-e8a5-bd02-a7941a9db627@redhat.com>
On 2/20/20 2:21 PM, Paolo Bonzini wrote:
> On 20/02/20 14:05, Philippe Mathieu-Daudé wrote:
>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>> ---
>> include/exec/cpu-common.h | 6 +++---
>> include/sysemu/xen-mapcache.h | 4 ++--
>> exec.c | 8 ++++----
>> hw/i386/xen/xen-mapcache.c | 2 +-
>> 4 files changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
>> index 81753bbb34..05ac1a5d69 100644
>> --- a/include/exec/cpu-common.h
>> +++ b/include/exec/cpu-common.h
>> @@ -48,11 +48,11 @@ typedef uint32_t CPUReadMemoryFunc(void *opaque, hwaddr addr);
>>
>> void qemu_ram_remap(ram_addr_t addr, ram_addr_t length);
>> /* This should not be used by devices. */
>> -ram_addr_t qemu_ram_addr_from_host(void *ptr);
>> +ram_addr_t qemu_ram_addr_from_host(const void *ptr);
>
> This is a bit ugly, because the pointer _can_ be modified via
> qemu_map_ram_ptr.
OK.
> Is this needed for the rest of the series to apply?
No!
> Paolo
>
>> RAMBlock *qemu_ram_block_by_name(const char *name);
>> -RAMBlock *qemu_ram_block_from_host(void *ptr, bool round_offset,
>> +RAMBlock *qemu_ram_block_from_host(const void *ptr, bool round_offset,
>> ram_addr_t *offset);
>> -ram_addr_t qemu_ram_block_host_offset(RAMBlock *rb, void *host);
>> +ram_addr_t qemu_ram_block_host_offset(RAMBlock *rb, const void *host);
>> void qemu_ram_set_idstr(RAMBlock *block, const char *name, DeviceState *dev);
>> void qemu_ram_unset_idstr(RAMBlock *block);
>> const char *qemu_ram_get_idstr(RAMBlock *rb);
>> diff --git a/include/sysemu/xen-mapcache.h b/include/sysemu/xen-mapcache.h
>> index c8e7c2f6cf..81e9aa2fa6 100644
>> --- a/include/sysemu/xen-mapcache.h
>> +++ b/include/sysemu/xen-mapcache.h
>> @@ -19,7 +19,7 @@ void xen_map_cache_init(phys_offset_to_gaddr_t f,
>> void *opaque);
>> uint8_t *xen_map_cache(hwaddr phys_addr, hwaddr size,
>> uint8_t lock, bool dma);
>> -ram_addr_t xen_ram_addr_from_mapcache(void *ptr);
>> +ram_addr_t xen_ram_addr_from_mapcache(const void *ptr);
>> void xen_invalidate_map_cache_entry(uint8_t *buffer);
>> void xen_invalidate_map_cache(void);
>> uint8_t *xen_replace_cache_entry(hwaddr old_phys_addr,
>> @@ -40,7 +40,7 @@ static inline uint8_t *xen_map_cache(hwaddr phys_addr,
>> abort();
>> }
>>
>> -static inline ram_addr_t xen_ram_addr_from_mapcache(void *ptr)
>> +static inline ram_addr_t xen_ram_addr_from_mapcache(const void *ptr)
>> {
>> abort();
>> }
>> diff --git a/exec.c b/exec.c
>> index 8e9cc3b47c..02b4e6ea41 100644
>> --- a/exec.c
>> +++ b/exec.c
>> @@ -2614,7 +2614,7 @@ static void *qemu_ram_ptr_length(RAMBlock *ram_block, ram_addr_t addr,
>> }
>>
>> /* Return the offset of a hostpointer within a ramblock */
>> -ram_addr_t qemu_ram_block_host_offset(RAMBlock *rb, void *host)
>> +ram_addr_t qemu_ram_block_host_offset(RAMBlock *rb, const void *host)
>> {
>> ram_addr_t res = (uint8_t *)host - (uint8_t *)rb->host;
>> assert((uintptr_t)host >= (uintptr_t)rb->host);
>> @@ -2640,11 +2640,11 @@ ram_addr_t qemu_ram_block_host_offset(RAMBlock *rb, void *host)
>> * pointer, such as a reference to the region that includes the incoming
>> * ram_addr_t.
>> */
>> -RAMBlock *qemu_ram_block_from_host(void *ptr, bool round_offset,
>> +RAMBlock *qemu_ram_block_from_host(const void *ptr, bool round_offset,
>> ram_addr_t *offset)
>> {
>> RAMBlock *block;
>> - uint8_t *host = ptr;
>> + const uint8_t *host = ptr;
>>
>> if (xen_enabled()) {
>> ram_addr_t ram_addr;
>> @@ -2705,7 +2705,7 @@ RAMBlock *qemu_ram_block_by_name(const char *name)
>>
>> /* Some of the softmmu routines need to translate from a host pointer
>> (typically a TLB entry) back to a ram offset. */
>> -ram_addr_t qemu_ram_addr_from_host(void *ptr)
>> +ram_addr_t qemu_ram_addr_from_host(const void *ptr)
>> {
>> RAMBlock *block;
>> ram_addr_t offset;
>> diff --git a/hw/i386/xen/xen-mapcache.c b/hw/i386/xen/xen-mapcache.c
>> index 5b120ed44b..432ad3354d 100644
>> --- a/hw/i386/xen/xen-mapcache.c
>> +++ b/hw/i386/xen/xen-mapcache.c
>> @@ -363,7 +363,7 @@ uint8_t *xen_map_cache(hwaddr phys_addr, hwaddr size,
>> return p;
>> }
>>
>> -ram_addr_t xen_ram_addr_from_mapcache(void *ptr)
>> +ram_addr_t xen_ram_addr_from_mapcache(const void *ptr)
>> {
>> MapCacheEntry *entry = NULL;
>> MapCacheRev *reventry;
>>
>
^ permalink raw reply
* Re: [dpdk-dev] [RFC] service: stop lcore threads before 'finalize'
From: David Marchand @ 2020-02-20 13:25 UTC (permalink / raw)
To: Van Haaren, Harry; +Cc: Aaron Conole, dev
In-Reply-To: <MN2PR11MB4447E9C17B3505FFC271EBD7D7190@MN2PR11MB4447.namprd11.prod.outlook.com>
On Mon, Feb 10, 2020 at 3:16 PM Van Haaren, Harry
<harry.van.haaren@intel.com> wrote:
> > > We need a fix for this issue.
> >
> > +1
>
> > > Interestingly, Stephen patch that joins all pthreads at
> > > rte_eal_cleanup [1] makes this issue disappear.
> > > So my understanding is that we are missing a api (well, I could not
> > > find a way) to synchronously stop service lcores.
> >
> > Maybe we can take that patch as a fix. I hate to see this segfault
> > in the field. I need to figure out what I missed in my cleanup
> > (probably missed a synchronization point).
>
> I haven't easily reproduced this yet - so I'll investigate a way to
> reproduce with close to 100% rate, then we can identify the root cause
> and actually get a clean fix. If you have pointers to reproduce easily,
> please let me know.
>
ping.
I want a fix in 20.05, or I will start considering how to drop this thing.
--
David Marchand
^ permalink raw reply
* [dpdk-dev] [PATCH] app/testpmd: fix wrong return value in parse_port_list
From: Hariprasad Govindharajan @ 2020-02-20 13:26 UTC (permalink / raw)
To: Wenzhuo Lu, Jingjing Wu, Bernard Iremonger
Cc: dev, ferruh.yigit, stephen, david.marchand,
Hariprasad Govindharajan
The function parse_port_list() is designed to return
unsigned int value. After sanitizing the inputs,
it is returning -1. Changed it to return 0.
Fixes: 2df00d562d20 ("app/testpmd: add --portlist option")
Cc: hariprasad.govindharajan@intel.com
Signed-off-by: Hariprasad Govindharajan <hariprasad.govindharajan@intel.com>
---
app/test-pmd/config.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 9d95202..91db508 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -2642,7 +2642,7 @@ parse_port_list(const char *list, unsigned int *values, unsigned int maxsize)
unsigned int marked[maxsize];
if (list == NULL || values == NULL)
- return -1;
+ return 0;
for (i = 0; i < (int)maxsize; i++)
marked[i] = 0;
--
2.7.4
^ permalink raw reply related
* [PATCH v5 1/6] doc: board: toradex: add colibri_imx7.rst
From: Bin Meng @ 2020-02-20 13:26 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20200212151433.9713-2-igor.opaniuk@gmail.com>
On Wed, Feb 12, 2020 at 11:14 PM Igor Opaniuk <igor.opaniuk@gmail.com> wrote:
>
> From: Igor Opaniuk <igor.opaniuk@toradex.com>
>
> - add initial index for toradex boards reST documentation
> - add initial colibri_imx7.rst doc file which provides all needed
> information for obtaining a workable image ready for flashing
> for both eMMC/NAND versions of Colibri iMX7.
>
> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
> Signed-off-by: Igor Opaniuk <igor.opaniuk@toradex.com>
> ---
>
> doc/board/index.rst | 1 +
> doc/board/toradex/colibri_imx7.rst | 127 +++++++++++++++++++++++++++++
> doc/board/toradex/index.rst | 9 ++
> 3 files changed, 137 insertions(+)
> create mode 100644 doc/board/toradex/colibri_imx7.rst
> create mode 100644 doc/board/toradex/index.rst
>
> diff --git a/doc/board/index.rst b/doc/board/index.rst
> index 00e72f57cd..f2f5907b8c 100644
> --- a/doc/board/index.rst
> +++ b/doc/board/index.rst
> @@ -15,4 +15,5 @@ Board-specific doc
> intel/index
> renesas/index
> sifive/index
> + toradex/index
> xilinx/index
> diff --git a/doc/board/toradex/colibri_imx7.rst b/doc/board/toradex/colibri_imx7.rst
> new file mode 100644
> index 0000000000..0c7ae082d0
> --- /dev/null
> +++ b/doc/board/toradex/colibri_imx7.rst
> @@ -0,0 +1,127 @@
> +.. SPDX-License-Identifier: GPL-2.0+
> +
> +Colibri iMX7
> +============
> +
> +Quick Start
> +-----------
> +
> +- Build U-Boot
> +- NAND IMX image adjustments before flashing
> +- Flashing manually U-Boot to eMMC
> +- Flashing manually U-Boot to NAND
> +- Using ``update_uboot`` script
> +
> +Build U-Boot
> +------------
> +
> +.. code-block:: bash
> +
> + $ export CROSS_COMPILE=arm-linux-gnueabi-
> + $ export ARCH=arm
> + $ make colibri_imx7_emmc_defconfig # For NAND: colibri_imx7_defconfig
> + $ make
> +
> +After build succeeds, you will obtain final ``u-boot-dtb.imx`` IMX specific
> +image, ready for flashing (but check next section for additional
> +adjustments).
> +
> +Final IMX program image includes (section ``6.6.7`` from `IMX7DRM
> +<https://www.nxp.com/webapp/Download?colCode=IMX7DRM>`_):
> +
> +* **Image vector table** (IVT) for BootROM
> +* **Boot data** -indicates the program image location, program image size
> + in bytes, and the plugin flag.
> +* **Device configuration data**
> +* **User image**: U-Boot image (``u-boot-dtb.bin``)
> +
> +
> +IMX image adjustments prior to flashing
> +--------------------------------------------
nits: title underline length should match the title
> +
> +1. U-Boot for both Colibri iMX7 NAND and eMMC versions
> +is built with HABv4 support (`AN4581.pdf
> +<https://www.nxp.com/docs/en/application-note/AN4581.pdf>`_)
> +enabled by default, which requires to generate a proper
> +Command Sequence File (CSF) by srktool from NXP (not included in the
> +U-Boot tree, check additional details in introduction_habv4.txt)
> +and concatenate it to the final ``u-boot-dtb.imx``.
> +
> +2. In case if you don't want to generate a proper ``CSF`` (for any reason),
> +you still need to pad the IMX image so i has the same size as specified in
> +in **Boot Data** section of IMX image.
> +To obtain this value, run:
> +
Will fix the nits when applying.
Tested the doc build, no warnings
Tested-by: Bin Meng <bmeng.cn@gmail.com>
^ permalink raw reply
* [PATCH bpf-next v5 0/3] libbpf: Add support for dynamic program attach target
From: Eelco Chaudron @ 2020-02-20 13:26 UTC (permalink / raw)
To: bpf; +Cc: davem, netdev, ast, daniel, kafai, songliubraving, yhs, andriin,
toke
Currently when you want to attach a trace program to a bpf program
the section name needs to match the tracepoint/function semantics.
However the addition of the bpf_program__set_attach_target() API
allows you to specify the tracepoint/function dynamically.
The call flow would look something like this:
xdp_fd = bpf_prog_get_fd_by_id(id);
trace_obj = bpf_object__open_file("func.o", NULL);
prog = bpf_object__find_program_by_title(trace_obj,
"fentry/myfunc");
bpf_program__set_expected_attach_type(prog, BPF_TRACE_FENTRY);
bpf_program__set_attach_target(prog, xdp_fd,
"xdpfilt_blk_all");
bpf_object__load(trace_obj)
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
v1 -> v2: Remove requirement for attach type hint in API
v2 -> v3: Moved common warning to __find_vmlinux_btf_id, requested by Andrii
Updated the xdp_bpf2bpf test to use this new API
v3 -> v4: Split up patch, update libbpf.map version
v4 -> v5: Fix return code, and prog assignment in test case
^ permalink raw reply
* [PATCH bpf-next v5 1/3] libbpf: Bump libpf current version to v0.0.8
From: Eelco Chaudron @ 2020-02-20 13:26 UTC (permalink / raw)
To: bpf; +Cc: davem, netdev, ast, daniel, kafai, songliubraving, yhs, andriin,
toke
In-Reply-To: <158220517358.127661.1514720920408191215.stgit@xdp-tutorial>
New development cycles starts, bump to v0.0.8.
Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
---
tools/lib/bpf/libbpf.map | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map
index b035122142bb..45be19c9d752 100644
--- a/tools/lib/bpf/libbpf.map
+++ b/tools/lib/bpf/libbpf.map
@@ -235,3 +235,6 @@ LIBBPF_0.0.7 {
btf__align_of;
libbpf_find_kernel_btf;
} LIBBPF_0.0.6;
+
+LIBBPF_0.0.8 {
+} LIBBPF_0.0.7;
^ permalink raw reply related
* [PATCH bpf-next v5 2/3] libbpf: Add support for dynamic program attach target
From: Eelco Chaudron @ 2020-02-20 13:26 UTC (permalink / raw)
To: bpf; +Cc: davem, netdev, ast, daniel, kafai, songliubraving, yhs, andriin,
toke
In-Reply-To: <158220517358.127661.1514720920408191215.stgit@xdp-tutorial>
Currently when you want to attach a trace program to a bpf program
the section name needs to match the tracepoint/function semantics.
However the addition of the bpf_program__set_attach_target() API
allows you to specify the tracepoint/function dynamically.
The call flow would look something like this:
xdp_fd = bpf_prog_get_fd_by_id(id);
trace_obj = bpf_object__open_file("func.o", NULL);
prog = bpf_object__find_program_by_title(trace_obj,
"fentry/myfunc");
bpf_program__set_expected_attach_type(prog, BPF_TRACE_FENTRY);
bpf_program__set_attach_target(prog, xdp_fd,
"xdpfilt_blk_all");
bpf_object__load(trace_obj)
Acked-by: Andrii Nakryiko <andriin@fb.com>
Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
---
tools/lib/bpf/libbpf.c | 34 ++++++++++++++++++++++++++++++----
tools/lib/bpf/libbpf.h | 4 ++++
tools/lib/bpf/libbpf.map | 2 ++
3 files changed, 36 insertions(+), 4 deletions(-)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 514b1a524abb..76628d482d69 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -4939,8 +4939,8 @@ int bpf_program__load(struct bpf_program *prog, char *license, __u32 kern_ver)
{
int err = 0, fd, i, btf_id;
- if (prog->type == BPF_PROG_TYPE_TRACING ||
- prog->type == BPF_PROG_TYPE_EXT) {
+ if ((prog->type == BPF_PROG_TYPE_TRACING ||
+ prog->type == BPF_PROG_TYPE_EXT) && !prog->attach_btf_id) {
btf_id = libbpf_find_attach_btf_id(prog);
if (btf_id <= 0)
return btf_id;
@@ -6583,6 +6583,9 @@ static inline int __find_vmlinux_btf_id(struct btf *btf, const char *name,
else
err = btf__find_by_name_kind(btf, name, BTF_KIND_FUNC);
+ if (err <= 0)
+ pr_warn("%s is not found in vmlinux BTF\n", name);
+
return err;
}
@@ -6655,8 +6658,6 @@ static int libbpf_find_attach_btf_id(struct bpf_program *prog)
err = __find_vmlinux_btf_id(prog->obj->btf_vmlinux,
name + section_defs[i].len,
attach_type);
- if (err <= 0)
- pr_warn("%s is not found in vmlinux BTF\n", name);
return err;
}
pr_warn("failed to identify btf_id based on ELF section name '%s'\n", name);
@@ -8132,6 +8133,31 @@ void bpf_program__bpil_offs_to_addr(struct bpf_prog_info_linear *info_linear)
}
}
+int bpf_program__set_attach_target(struct bpf_program *prog,
+ int attach_prog_fd,
+ const char *attach_func_name)
+{
+ int btf_id;
+
+ if (!prog || attach_prog_fd < 0 || !attach_func_name)
+ return -EINVAL;
+
+ if (attach_prog_fd)
+ btf_id = libbpf_find_prog_btf_id(attach_func_name,
+ attach_prog_fd);
+ else
+ btf_id = __find_vmlinux_btf_id(prog->obj->btf_vmlinux,
+ attach_func_name,
+ prog->expected_attach_type);
+
+ if (btf_id < 0)
+ return btf_id;
+
+ prog->attach_btf_id = btf_id;
+ prog->attach_prog_fd = attach_prog_fd;
+ return 0;
+}
+
int parse_cpu_mask_str(const char *s, bool **mask, int *mask_sz)
{
int err = 0, n, len, start, end = -1;
diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
index 3fe12c9d1f92..02fc58a21a7f 100644
--- a/tools/lib/bpf/libbpf.h
+++ b/tools/lib/bpf/libbpf.h
@@ -334,6 +334,10 @@ LIBBPF_API void
bpf_program__set_expected_attach_type(struct bpf_program *prog,
enum bpf_attach_type type);
+LIBBPF_API int
+bpf_program__set_attach_target(struct bpf_program *prog, int attach_prog_fd,
+ const char *attach_func_name);
+
LIBBPF_API bool bpf_program__is_socket_filter(const struct bpf_program *prog);
LIBBPF_API bool bpf_program__is_tracepoint(const struct bpf_program *prog);
LIBBPF_API bool bpf_program__is_raw_tracepoint(const struct bpf_program *prog);
diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map
index 45be19c9d752..7b014c8cdece 100644
--- a/tools/lib/bpf/libbpf.map
+++ b/tools/lib/bpf/libbpf.map
@@ -237,4 +237,6 @@ LIBBPF_0.0.7 {
} LIBBPF_0.0.6;
LIBBPF_0.0.8 {
+ global:
+ bpf_program__set_attach_target;
} LIBBPF_0.0.7;
^ permalink raw reply related
* Re: [Xen-devel] [PATCH 2/2] xen/mm: Introduce PG_state_uninitialised
From: Julien Grall @ 2020-02-20 13:27 UTC (permalink / raw)
To: Jan Beulich, David Woodhouse
Cc: sstabellini@kernel.org, wl@xen.org, konrad.wilk@oracle.com,
george.dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
ian.jackson@eu.citrix.com, george.dunlap@citrix.com,
jeff.kubascik@dornerworks.com, Xia, Hongyan,
stewart.hildebrand@dornerworks.com,
xen-devel@lists.xenproject.org
In-Reply-To: <af374a90-f060-7239-5a02-c98df409819c@suse.com>
Hi,
On 20/02/2020 11:59, Jan Beulich wrote:
> On 07.02.2020 19:04, David Woodhouse wrote:
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -488,7 +488,8 @@ void share_xen_page_with_guest(struct page_info *page, struct domain *d,
>>
>> page_set_owner(page, d);
>> smp_wmb(); /* install valid domain ptr before updating refcnt. */
>> - ASSERT((page->count_info & ~PGC_xen_heap) == 0);
>> + ASSERT((page->count_info & ~PGC_xen_heap) == PGC_state_inuse ||
>> + (page->count_info & ~PGC_xen_heap) == PGC_state_uninitialised);
>
> Can uninitialized pages really make it here?
IIRC, arch_init_memory() will share the first 1MB of the RAM but they
were never given to the page allocator.
01,10 +2316,11 @@ int assign_pages(
>> for ( i = 0; i < (1 << order); i++ )
>> {
>> ASSERT(page_get_owner(&pg[i]) == NULL);
>> - ASSERT(!pg[i].count_info);
>> + ASSERT(pg[i].count_info == PGC_state_inuse ||
>> + pg[i].count_info == PGC_state_uninitialised);
>
> Same question here: Can uninitialized pages make it here?
Yes, in dom0_construct_pv() when the initrd is assigned to the guest.
> If
> so, wouldn't it be better to correct this, rather than having
> the more permissive assertion?
We would need to rework init_heap_pages() (or create a new function) so
the allocator initialize the state but it is marked as "reserved/used"
rather than "freed".
Most likely we will need a similar function for liveupdate. This is
because the pages belonging to guests should be untouched.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* [PATCH bpf-next v5 3/3] selftests/bpf: update xdp_bpf2bpf test to use new set_attach_target API
From: Eelco Chaudron @ 2020-02-20 13:26 UTC (permalink / raw)
To: bpf; +Cc: davem, netdev, ast, daniel, kafai, songliubraving, yhs, andriin,
toke
In-Reply-To: <158220517358.127661.1514720920408191215.stgit@xdp-tutorial>
Use the new bpf_program__set_attach_target() API in the xdp_bpf2bpf
selftest so it can be referenced as an example on how to use it.
Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
---
.../testing/selftests/bpf/prog_tests/xdp_bpf2bpf.c | 16 +++++++++++++---
.../testing/selftests/bpf/progs/test_xdp_bpf2bpf.c | 4 ++--
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/tools/testing/selftests/bpf/prog_tests/xdp_bpf2bpf.c b/tools/testing/selftests/bpf/prog_tests/xdp_bpf2bpf.c
index 6b56bdc73ebc..4ba011031d4c 100644
--- a/tools/testing/selftests/bpf/prog_tests/xdp_bpf2bpf.c
+++ b/tools/testing/selftests/bpf/prog_tests/xdp_bpf2bpf.c
@@ -14,7 +14,7 @@ void test_xdp_bpf2bpf(void)
struct test_xdp *pkt_skel = NULL;
struct test_xdp_bpf2bpf *ftrace_skel = NULL;
struct vip key4 = {.protocol = 6, .family = AF_INET};
- DECLARE_LIBBPF_OPTS(bpf_object_open_opts, opts);
+ struct bpf_program *prog;
/* Load XDP program to introspect */
pkt_skel = test_xdp__open_and_load();
@@ -27,11 +27,21 @@ void test_xdp_bpf2bpf(void)
bpf_map_update_elem(map_fd, &key4, &value4, 0);
/* Load trace program */
- opts.attach_prog_fd = pkt_fd,
- ftrace_skel = test_xdp_bpf2bpf__open_opts(&opts);
+ ftrace_skel = test_xdp_bpf2bpf__open();
if (CHECK(!ftrace_skel, "__open", "ftrace skeleton failed\n"))
goto out;
+ /* Demonstrate the bpf_program__set_attach_target() API rather than
+ * the load with options, i.e. opts.attach_prog_fd.
+ */
+ prog = ftrace_skel->progs.trace_on_entry;
+ bpf_program__set_expected_attach_type(prog, BPF_TRACE_FENTRY);
+ bpf_program__set_attach_target(prog, pkt_fd, "_xdp_tx_iptunnel");
+
+ prog = ftrace_skel->progs.trace_on_exit;
+ bpf_program__set_expected_attach_type(prog, BPF_TRACE_FEXIT);
+ bpf_program__set_attach_target(prog, pkt_fd, "_xdp_tx_iptunnel");
+
err = test_xdp_bpf2bpf__load(ftrace_skel);
if (CHECK(err, "__load", "ftrace skeleton failed\n"))
goto out;
diff --git a/tools/testing/selftests/bpf/progs/test_xdp_bpf2bpf.c b/tools/testing/selftests/bpf/progs/test_xdp_bpf2bpf.c
index cb8a04ab7a78..b840fc9e3ed5 100644
--- a/tools/testing/selftests/bpf/progs/test_xdp_bpf2bpf.c
+++ b/tools/testing/selftests/bpf/progs/test_xdp_bpf2bpf.c
@@ -28,7 +28,7 @@ struct xdp_buff {
} __attribute__((preserve_access_index));
__u64 test_result_fentry = 0;
-SEC("fentry/_xdp_tx_iptunnel")
+SEC("fentry/FUNC")
int BPF_PROG(trace_on_entry, struct xdp_buff *xdp)
{
test_result_fentry = xdp->rxq->dev->ifindex;
@@ -36,7 +36,7 @@ int BPF_PROG(trace_on_entry, struct xdp_buff *xdp)
}
__u64 test_result_fexit = 0;
-SEC("fexit/_xdp_tx_iptunnel")
+SEC("fexit/FUNC")
int BPF_PROG(trace_on_exit, struct xdp_buff *xdp, int ret)
{
test_result_fexit = ret;
^ permalink raw reply related
* [PATCH] arm64: defconfig: Enable REGULATOR_MP8859
From: sunil @ 2020-02-20 13:27 UTC (permalink / raw)
To: heiko, catalin.marinas, will
Cc: linux-arm-kernel, linux-kernel, linux-rockchip, Jagan Teki,
Markus Reichl
From: Jagan Teki <jagan@amarulasolutions.com>
RK3399 boards like ROC-RK3399-PC is using MP8859 DC/DC converter
for 12V supply.
roc-rk3399-pc initially used 12V fixed regulator for this supply,
but the below commit has switched to use MP8859.
commit <1fc61ed04d309b0b8b3562acf701ab988eee12de> "arm64: dts: rockchip:
Enable mp8859 regulator on rk3399-roc-pc"
So, enable bydefault on the defconfig.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Cc: Markus Reichl <m.reichl@fivetechno.de>
Tested-by: Suniel Mahesh <sunil@amarulasolutions.com>
---
Note:
This change set is applied on top of linux-rockchip, branch v5.7-armsoc/dts64.
(git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git -b v5.7-armsoc/dts64)
This change set was tested on ROC-RK3399-PC, an rk3399 based target.
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 0f21288..973a493 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -505,6 +505,7 @@ CONFIG_REGULATOR_QCOM_RPMH=y
CONFIG_REGULATOR_QCOM_SMD_RPM=y
CONFIG_REGULATOR_QCOM_SPMI=y
CONFIG_REGULATOR_RK808=y
+CONFIG_REGULATOR_MP8859=y
CONFIG_REGULATOR_S2MPS11=y
CONFIG_REGULATOR_VCTRL=m
CONFIG_RC_CORE=m
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] s390/sclp: improve special wait psw logic
From: David Hildenbrand @ 2020-02-20 13:26 UTC (permalink / raw)
To: Christian Borntraeger, Cornelia Huck
Cc: Janosch Frank, qemu-s390x, qemu-stable, qemu-devel,
Richard Henderson
In-Reply-To: <1582204582-22995-1-git-send-email-borntraeger@de.ibm.com>
On 20.02.20 14:16, Christian Borntraeger wrote:
> There is a special quiesce PSW that we check for "shutdown". Otherwise disabled
> wait is detected as "crashed". Architecturally we must only check PSW bits
> 116-127. Fix this.
>
> Cc: qemu-stable@nongnu.org
Is this really stable material?
Reviewed-by: David Hildenbrand <david@redhat.com>
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH] drm/amdgpu/display: fix logic inversion in program_timing_sync()
From: Alex Deucher @ 2020-02-20 13:27 UTC (permalink / raw)
To: Kazlauskas, Nicholas
Cc: Bhawanpreet Lakha, Wenjing Liu, amd-gfx list, Laktyushkin, Dmytro,
Alex Deucher, Harry Wentland
In-Reply-To: <07041392-d18f-821e-4271-c94008818399@amd.com>
On Tue, Feb 4, 2020 at 9:06 AM Kazlauskas, Nicholas
<nicholas.kazlauskas@amd.com> wrote:
>
> Comments inline.
>
> On 2020-02-03 4:07 p.m., Alex Deucher wrote:
> > Ping?
> >
> > On Fri, Jan 10, 2020 at 3:11 PM Alex Deucher <alexdeucher@gmail.com> wrote:
> >>
> >> It looks like we should be reducing the group size when we don't
> >> have a plane rather than when we do.
> >>
> >> Bug: https://gitlab.freedesktop.org/drm/amd/issues/781
> >> Fixes: 5fc0cbfad45648 ("drm/amd/display: determine if a pipe is synced by plane state")
> >> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
> >> ---
> >> drivers/gpu/drm/amd/display/dc/core/dc.c | 4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c b/drivers/gpu/drm/amd/display/dc/core/dc.c
> >> index 3d89904003f0..01b27726d9c5 100644
> >> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> >> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> >> @@ -1003,9 +1003,9 @@ static void program_timing_sync(
> >> status->timing_sync_info.master = false;
> >>
> >> }
> >> - /* remove any other pipes with plane as they have already been synced */
> >> + /* remove any other pipes without plane as they have already been synced */
>
> This took a while to wrap my head around but I think I understand what
> this was originally trying to do.
>
> The original logic seems to have been checking for blanked streams and
> trying to remove anything that was blanked from the group to try and
> avoid having to enable timing synchronization.
>
> However, the logic for blanked is *not* the same as having a
> plane_state. Technically you can drive an OTG without anything connected
> in the front end and it'll just draw out the back color - which is
> distinct from having the OTG be blanked.
>
> The problem is really this iteration below:
>
> >> for (j = j + 1; j < group_size; j++) {
>
> There could still be pipes in here (depending on the ordering) that have
> planes and could be synchronized with the master OTG. I think starting
> at j + 1 is a mistake for this logic as well.
>
> I wonder if we can just drop this loop altogether. If we add planes or
> unblank the OTG later then we'll still want the synchronization.
>
> Dymtro, Wenjing - feel free to correct my understanding if I'm mistaken
> about this.
Ping? Any thoughts on this? It would be nice to get this fixed.
Alex
>
> Regards,
> Nicholas Kazlauskas
>
> >> - if (pipe_set[j]->plane_state) {
> >> + if (!pipe_set[j]->plane_state) {
> >> group_size--;
> >> pipe_set[j] = pipe_set[group_size];
> >> j--;
> >> --
> >> 2.24.1
> >>
> > _______________________________________________
> > amd-gfx mailing list
> > amd-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> >
>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* [PATCH] arm64: defconfig: Enable REGULATOR_MP8859
From: sunil @ 2020-02-20 13:27 UTC (permalink / raw)
To: heiko, catalin.marinas, will
Cc: Markus Reichl, linux-rockchip, linux-kernel, linux-arm-kernel,
Jagan Teki
From: Jagan Teki <jagan@amarulasolutions.com>
RK3399 boards like ROC-RK3399-PC is using MP8859 DC/DC converter
for 12V supply.
roc-rk3399-pc initially used 12V fixed regulator for this supply,
but the below commit has switched to use MP8859.
commit <1fc61ed04d309b0b8b3562acf701ab988eee12de> "arm64: dts: rockchip:
Enable mp8859 regulator on rk3399-roc-pc"
So, enable bydefault on the defconfig.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Cc: Markus Reichl <m.reichl@fivetechno.de>
Tested-by: Suniel Mahesh <sunil@amarulasolutions.com>
---
Note:
This change set is applied on top of linux-rockchip, branch v5.7-armsoc/dts64.
(git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git -b v5.7-armsoc/dts64)
This change set was tested on ROC-RK3399-PC, an rk3399 based target.
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 0f21288..973a493 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -505,6 +505,7 @@ CONFIG_REGULATOR_QCOM_RPMH=y
CONFIG_REGULATOR_QCOM_SMD_RPM=y
CONFIG_REGULATOR_QCOM_SPMI=y
CONFIG_REGULATOR_RK808=y
+CONFIG_REGULATOR_MP8859=y
CONFIG_REGULATOR_S2MPS11=y
CONFIG_REGULATOR_VCTRL=m
CONFIG_RC_CORE=m
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v6 2/4] dt-bindings: power: add Amlogic secure power domains bindings
From: Rob Herring @ 2020-02-20 13:27 UTC (permalink / raw)
To: Jianxin Pan
Cc: Kevin Hilman, open list:ARM/Amlogic Meson..., Neil Armstrong,
Jerome Brunet, Martin Blumenstingl, open list:THERMAL,
linux-kernel@vger.kernel.org,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
devicetree, Jian Hu, Hanjie Lin, Victor Wan, Xingyu Chen
In-Reply-To: <1579087831-94965-3-git-send-email-jianxin.pan@amlogic.com>
On Wed, Jan 15, 2020 at 5:30 AM Jianxin Pan <jianxin.pan@amlogic.com> wrote:
>
> Add the bindings for the Amlogic Secure power domains, controlling the
> secure power domains.
>
> The bindings targets the Amlogic A1 and C1 compatible SoCs, in which the
> power domain registers are in secure world.
>
> Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
> ---
> .../bindings/power/amlogic,meson-sec-pwrc.yaml | 40 ++++++++++++++++++++++
> include/dt-bindings/power/meson-a1-power.h | 32 +++++++++++++++++
> 2 files changed, 72 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml
> create mode 100644 include/dt-bindings/power/meson-a1-power.h
>
> diff --git a/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml b/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml
> new file mode 100644
> index 00000000..af32209
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml
> @@ -0,0 +1,40 @@
> +# SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +# Copyright (c) 2019 Amlogic, Inc
> +# Author: Jianxin Pan <jianxin.pan@amlogic.com>
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/power/amlogic,meson-sec-pwrc.yaml#"
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> +
> +title: Amlogic Meson Secure Power Domains
> +
> +maintainers:
> + - Jianxin Pan <jianxin.pan@amlogic.com>
> +
> +description: |+
> + Secure Power Domains used in Meson A1/C1 SoCs, and should be the child node
> + of secure-monitor.
> +
> +properties:
> + compatible:
> + enum:
> + - amlogic,meson-a1-pwrc
> +
> + "#power-domain-cells":
> + const: 1
> +
> +required:
> + - compatible
> + - "#power-domain-cells"
> +
> +examples:
> + - |
> + secure-monitor {
> + compatible = "amlogic,meson-gxbb-sm";
> +
> + pwrc: power-controller {
> + compatible = "amlogic,meson-a1-pwrc";
> + #power-domain-cells = <1>;
> + };
> + }
Missing ';':
Error: Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.example.dts:27.5-6
syntax error
FATAL ERROR: Unable to parse input tree
Please fix this as linux-next is now failing dt_binding_check.
Rob
^ permalink raw reply
* 回复: [PATCH] drm/amdgpu: fix a bug NULL pointer dereference
From: Liu, Monk @ 2020-02-20 13:28 UTC (permalink / raw)
To: Li, Dennis, Koenig, Christian, Zhang, Hawking,
amd-gfx@lists.freedesktop.org, Deucher, Alexander, Zhou1, Tao,
Chen, Guchun
In-Reply-To: <MN2PR12MB3167C68A5B6AF0E97613A6A4ED130@MN2PR12MB3167.namprd12.prod.outlook.com>
so the scenario is:
KMD doing page update -> ECC -> baco reset (mute SDMA scheduler) -> drm_sched_entity_get_free_sched() return NULL -> you get your NULL pointer
And your approach is to introduce a bail out in the amdgpu_vm_sdma_commit() so the original amdgpu vm update jobs will be dropped,
That really can fix your NULL pointer issue, but actually bring another issue: you didn't finish the vm update work !
my initial idea is you do something like:
static int amdgpu_vm_sdma_commit(struct amdgpu_vm_update_params *p,
...
struct amdgpu_device *adev = p->adev;
while (!mutex_trylock(&adev->lock_reset)) //means GPU is under recovering
msleep(xxx);
....
mutex_unlock(&adev->lock_reset); //this put at the end of this routine
}
that do make our implement more complicated, but at least it doesn't drop the necessary vm update, otherwise you will run into other problems ...
@Koenig, Christian do you have another solution ?
Thanks
-----邮件原件-----
发件人: Li, Dennis <Dennis.Li@amd.com>
发送时间: 2020年2月20日 16:41
收件人: Liu, Monk <Monk.Liu@amd.com>; Koenig, Christian <Christian.Koenig@amd.com>; Zhang, Hawking <Hawking.Zhang@amd.com>; amd-gfx@lists.freedesktop.org; Deucher, Alexander <Alexander.Deucher@amd.com>; Zhou1, Tao <Tao.Zhou1@amd.com>; Chen, Guchun <Guchun.Chen@amd.com>
主题: RE: [PATCH] drm/amdgpu: fix a bug NULL pointer dereference
[AMD Official Use Only - Internal Distribution Only]
Hi, Christian and Monk,
When doing SDMA copy, a RAS uncorrectable error happens, which will cause this issue. The RAS uncorrectable error event will trigger driver to do BACO reset which will set the status of SDMA scheduler to no ready. And then drm_sched_entity_get_free_sched will return NULL in drm_sched_entity_select_rq, which cause entity->rq to NULL.
Best Regards
Dennis Li
-----Original Message-----
From: Liu, Monk <Monk.Liu@amd.com>
Sent: Wednesday, February 19, 2020 7:30 PM
To: Koenig, Christian <Christian.Koenig@amd.com>; Zhang, Hawking <Hawking.Zhang@amd.com>; Li, Dennis <Dennis.Li@amd.com>; amd-gfx@lists.freedesktop.org; Deucher, Alexander <Alexander.Deucher@amd.com>; Zhou1, Tao <Tao.Zhou1@amd.com>; Chen, Guchun <Guchun.Chen@amd.com>
Subject: 回复: [PATCH] drm/amdgpu: fix a bug NULL pointer dereference
> + if (!entity->rq)
> + return 0;
> +
Yes, supposedly we shouldn't get 'entity->rq == NULL' case , that looks the true bug
-----邮件原件-----
发件人: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> 代表 Christian K?nig
发送时间: 2020年2月19日 18:50
收件人: Zhang, Hawking <Hawking.Zhang@amd.com>; Li, Dennis <Dennis.Li@amd.com>; amd-gfx@lists.freedesktop.org; Deucher, Alexander <Alexander.Deucher@amd.com>; Zhou1, Tao <Tao.Zhou1@amd.com>; Chen, Guchun <Guchun.Chen@amd.com>
主题: Re: [PATCH] drm/amdgpu: fix a bug NULL pointer dereference
Well of hand this patch looks like a clear NAK to me.
Returning without raising an error is certainly the wrong thing to do here because we just drop the necessary page table updates.
How does the entity->rq ends up as NULL in the first place?
Regards,
Christian.
Am 19.02.20 um 07:26 schrieb Zhang, Hawking:
> [AMD Official Use Only - Internal Distribution Only]
>
> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
>
> Regards,
> Hawking
> -----Original Message-----
> From: Dennis Li <Dennis.Li@amd.com>
> Sent: Wednesday, February 19, 2020 12:05
> To: amd-gfx@lists.freedesktop.org; Deucher, Alexander
> <Alexander.Deucher@amd.com>; Zhou1, Tao <Tao.Zhou1@amd.com>; Zhang,
> Hawking <Hawking.Zhang@amd.com>; Chen, Guchun <Guchun.Chen@amd.com>
> Cc: Li, Dennis <Dennis.Li@amd.com>
> Subject: [PATCH] drm/amdgpu: fix a bug NULL pointer dereference
>
> check whether the queue of entity is null to avoid null pointer dereference.
>
> Change-Id: I08d56774012cf229ba2fe7a011c1359e8d1e2781
> Signed-off-by: Dennis Li <Dennis.Li@amd.com>
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c
> index 4cc7881f438c..67cca463ddcc 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c
> @@ -95,6 +95,9 @@ static int amdgpu_vm_sdma_commit(struct amdgpu_vm_update_params *p,
> int r;
>
> entity = p->direct ? &p->vm->direct : &p->vm->delayed;
> + if (!entity->rq)
> + return 0;
> +
> ring = container_of(entity->rq->sched, struct amdgpu_ring, sched);
>
> WARN_ON(ib->length_dw == 0);
> --
> 2.17.1
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cmo
> nk.liu%40amd.com%7C28e7260af3a24eec758f08d7b52975e3%7C3dd8961fe4884e60
> 8e11a82d994e183d%7C0%7C0%7C637177062003213431&sdata=vMXmhwTlN8lAav
> uqhYhpmKLM6V%2F%2B2%2FubFBbsk%2BGY%2Bjw%3D&reserved=0
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cmonk.liu%40amd.com%7C28e7260af3a24eec758f08d7b52975e3%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637177062003213431&sdata=vMXmhwTlN8lAavuqhYhpmKLM6V%2F%2B2%2FubFBbsk%2BGY%2Bjw%3D&reserved=0
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* Re: [PATCH v6 2/4] dt-bindings: power: add Amlogic secure power domains bindings
From: Rob Herring @ 2020-02-20 13:27 UTC (permalink / raw)
To: Jianxin Pan
Cc: devicetree, Hanjie Lin, Victor Wan, open list:THERMAL,
Martin Blumenstingl, Kevin Hilman, Neil Armstrong,
linux-kernel@vger.kernel.org, Jian Hu, Xingyu Chen,
open list:ARM/Amlogic Meson...,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Jerome Brunet
In-Reply-To: <1579087831-94965-3-git-send-email-jianxin.pan@amlogic.com>
On Wed, Jan 15, 2020 at 5:30 AM Jianxin Pan <jianxin.pan@amlogic.com> wrote:
>
> Add the bindings for the Amlogic Secure power domains, controlling the
> secure power domains.
>
> The bindings targets the Amlogic A1 and C1 compatible SoCs, in which the
> power domain registers are in secure world.
>
> Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
> ---
> .../bindings/power/amlogic,meson-sec-pwrc.yaml | 40 ++++++++++++++++++++++
> include/dt-bindings/power/meson-a1-power.h | 32 +++++++++++++++++
> 2 files changed, 72 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml
> create mode 100644 include/dt-bindings/power/meson-a1-power.h
>
> diff --git a/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml b/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml
> new file mode 100644
> index 00000000..af32209
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml
> @@ -0,0 +1,40 @@
> +# SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +# Copyright (c) 2019 Amlogic, Inc
> +# Author: Jianxin Pan <jianxin.pan@amlogic.com>
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/power/amlogic,meson-sec-pwrc.yaml#"
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> +
> +title: Amlogic Meson Secure Power Domains
> +
> +maintainers:
> + - Jianxin Pan <jianxin.pan@amlogic.com>
> +
> +description: |+
> + Secure Power Domains used in Meson A1/C1 SoCs, and should be the child node
> + of secure-monitor.
> +
> +properties:
> + compatible:
> + enum:
> + - amlogic,meson-a1-pwrc
> +
> + "#power-domain-cells":
> + const: 1
> +
> +required:
> + - compatible
> + - "#power-domain-cells"
> +
> +examples:
> + - |
> + secure-monitor {
> + compatible = "amlogic,meson-gxbb-sm";
> +
> + pwrc: power-controller {
> + compatible = "amlogic,meson-a1-pwrc";
> + #power-domain-cells = <1>;
> + };
> + }
Missing ';':
Error: Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.example.dts:27.5-6
syntax error
FATAL ERROR: Unable to parse input tree
Please fix this as linux-next is now failing dt_binding_check.
Rob
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply
* Re: [PATCH v6 2/4] dt-bindings: power: add Amlogic secure power domains bindings
From: Rob Herring @ 2020-02-20 13:27 UTC (permalink / raw)
To: Jianxin Pan
Cc: devicetree, Hanjie Lin, Victor Wan, open list:THERMAL,
Martin Blumenstingl, Kevin Hilman, Neil Armstrong,
linux-kernel@vger.kernel.org, Jian Hu, Xingyu Chen,
open list:ARM/Amlogic Meson...,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Jerome Brunet
In-Reply-To: <1579087831-94965-3-git-send-email-jianxin.pan@amlogic.com>
On Wed, Jan 15, 2020 at 5:30 AM Jianxin Pan <jianxin.pan@amlogic.com> wrote:
>
> Add the bindings for the Amlogic Secure power domains, controlling the
> secure power domains.
>
> The bindings targets the Amlogic A1 and C1 compatible SoCs, in which the
> power domain registers are in secure world.
>
> Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
> ---
> .../bindings/power/amlogic,meson-sec-pwrc.yaml | 40 ++++++++++++++++++++++
> include/dt-bindings/power/meson-a1-power.h | 32 +++++++++++++++++
> 2 files changed, 72 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml
> create mode 100644 include/dt-bindings/power/meson-a1-power.h
>
> diff --git a/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml b/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml
> new file mode 100644
> index 00000000..af32209
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml
> @@ -0,0 +1,40 @@
> +# SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +# Copyright (c) 2019 Amlogic, Inc
> +# Author: Jianxin Pan <jianxin.pan@amlogic.com>
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/power/amlogic,meson-sec-pwrc.yaml#"
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> +
> +title: Amlogic Meson Secure Power Domains
> +
> +maintainers:
> + - Jianxin Pan <jianxin.pan@amlogic.com>
> +
> +description: |+
> + Secure Power Domains used in Meson A1/C1 SoCs, and should be the child node
> + of secure-monitor.
> +
> +properties:
> + compatible:
> + enum:
> + - amlogic,meson-a1-pwrc
> +
> + "#power-domain-cells":
> + const: 1
> +
> +required:
> + - compatible
> + - "#power-domain-cells"
> +
> +examples:
> + - |
> + secure-monitor {
> + compatible = "amlogic,meson-gxbb-sm";
> +
> + pwrc: power-controller {
> + compatible = "amlogic,meson-a1-pwrc";
> + #power-domain-cells = <1>;
> + };
> + }
Missing ';':
Error: Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.example.dts:27.5-6
syntax error
FATAL ERROR: Unable to parse input tree
Please fix this as linux-next is now failing dt_binding_check.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Please pull mmc mmc-2-19-2020
From: Tom Rini @ 2020-02-20 13:28 UTC (permalink / raw)
To: u-boot
In-Reply-To: <DB7PR04MB449084B2D116FE705FCDFD3A88130@DB7PR04MB4490.eurprd04.prod.outlook.com>
On Thu, Feb 20, 2020 at 06:52:18AM +0000, Peng Fan wrote:
> > Subject: Re: Please pull mmc mmc-2-19-2020
> >
> > Hi Peng,
> >
> > On Thu, Feb 20, 2020 at 1:34 PM Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Feb 20, 2020 at 01:56:41AM +0000, Peng Fan wrote:
> > >
> > > > Hi Tom
> > > >
> > > > Please pull mmc-2-29-2020.
> > > >
> > >
> > > NAK, this breaks nios2:
> > > nios2: + 10m50 3c120
> > > +(10m50,3c120) ../drivers/net/altera_tse.c: In function 'altera_tse_probe':
> > > +(10m50,3c120) ../drivers/net/altera_tse.c:646:15: error: implicit
> > declaration of function 'dma_alloc_coherent'; did you mean 'lmb_alloc_addr'?
> > [-Werror=implicit-function-declaration]
> > > +(10m50,3c120) desc_mem = dma_alloc_coherent(len, &addr);
> > > +(10m50,3c120) ^~~~~~~~~~~~~~~~~~
> > > +(10m50,3c120) lmb_alloc_addr
> > > +(10m50,3c120) ../drivers/net/altera_tse.c:646:13: error: assignment
> > makes pointer from integer without a cast [-Werror=int-conversion]
> > > +(10m50,3c120) ^
> > > +(10m50,3c120) cc1: all warnings being treated as errors
> > > +(10m50,3c120) make[2]: *** [drivers/net/altera_tse.o] Error 1
> > > +(10m50,3c120) make[1]: *** [drivers/net] Error 2
> > > +(10m50,3c120) make: *** [sub-make] Error 2
>
> I not met such issue in github ci.
Travis is indeed missing nios2 tests but it's in GitLab / Azure.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200220/2ede6cda/attachment.sig>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.