* [PATCH v3 01/10] arm: remove the ARM HDLCD driver
2018-05-23 0:24 [PATCH v3 0/10] arm: more kconfig configurability and small default configs Stefano Stabellini
@ 2018-05-23 0:24 ` Stefano Stabellini
2018-05-29 13:37 ` Julien Grall
2018-05-23 0:25 ` [PATCH v3 02/10] arm: make it possible to disable HAS_GICV3 Stefano Stabellini
` (8 subsequent siblings)
9 siblings, 1 reply; 33+ messages in thread
From: Stefano Stabellini @ 2018-05-23 0:24 UTC (permalink / raw)
To: julien.grall
Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov, dfaggioli,
xen-devel
The ARM HDLCD driver is unused. The device itself can only be found on
Virtual Express boards that are for early development only. Remove the
driver.
Also remove vexpress_syscfg, now unused, and "select VIDEO" that is not
useful anymore.
Suggested-by: Julien Grall <julien.grall@arm.com>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
---
Changes in v3:
- remove "select VIDEO"
- remove vexpress_syscfg
Changes in v2:
- patch added
---
xen/arch/arm/Kconfig | 2 -
xen/arch/arm/platforms/vexpress.c | 35 ----
xen/drivers/video/Kconfig | 3 -
xen/drivers/video/Makefile | 1 -
xen/drivers/video/arm_hdlcd.c | 281 -------------------------------
xen/include/asm-arm/platforms/vexpress.h | 6 -
6 files changed, 328 deletions(-)
delete mode 100644 xen/drivers/video/arm_hdlcd.c
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 8174c0c..4dc7ef5 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -17,12 +17,10 @@ config ARM_64
config ARM
def_bool y
select HAS_ALTERNATIVE
- select HAS_ARM_HDLCD
select HAS_DEVICE_TREE
select HAS_MEM_ACCESS
select HAS_PASSTHROUGH
select HAS_PDX
- select VIDEO
config ARCH_DEFCONFIG
string
diff --git a/xen/arch/arm/platforms/vexpress.c b/xen/arch/arm/platforms/vexpress.c
index 70839d6..b6193f7 100644
--- a/xen/arch/arm/platforms/vexpress.c
+++ b/xen/arch/arm/platforms/vexpress.c
@@ -59,41 +59,6 @@ static inline int vexpress_ctrl_start(uint32_t *syscfg, int write,
return 0;
}
-int vexpress_syscfg(int write, int function, int device, uint32_t *data)
-{
- uint32_t *syscfg = (uint32_t *) FIXMAP_ADDR(FIXMAP_MISC);
- int ret = -1;
-
- set_fixmap(FIXMAP_MISC, maddr_to_mfn(V2M_SYS_MMIO_BASE),
- PAGE_HYPERVISOR_NOCACHE);
-
- if ( syscfg[V2M_SYS_CFGCTRL/4] & V2M_SYS_CFG_START )
- goto out;
-
- /* clear the complete bit in the V2M_SYS_CFGSTAT status register */
- syscfg[V2M_SYS_CFGSTAT/4] = 0;
-
- if ( write )
- {
- /* write data */
- syscfg[V2M_SYS_CFGDATA/4] = *data;
-
- if ( vexpress_ctrl_start(syscfg, write, function, device) < 0 )
- goto out;
- } else {
- if ( vexpress_ctrl_start(syscfg, write, function, device) < 0 )
- goto out;
- else
- /* read data */
- *data = syscfg[V2M_SYS_CFGDATA/4];
- }
-
- ret = 0;
-out:
- clear_fixmap(FIXMAP_MISC);
- return ret;
-}
-
/*
* TODO: Get base address from the device tree
* See arm,vexpress-reset node
diff --git a/xen/drivers/video/Kconfig b/xen/drivers/video/Kconfig
index 52e8ce6..41ca503 100644
--- a/xen/drivers/video/Kconfig
+++ b/xen/drivers/video/Kconfig
@@ -11,6 +11,3 @@ config VGA
Enable VGA output for the Xen hypervisor.
If unsure, say Y.
-
-config HAS_ARM_HDLCD
- bool
diff --git a/xen/drivers/video/Makefile b/xen/drivers/video/Makefile
index 2bb91d6..2b3fc76 100644
--- a/xen/drivers/video/Makefile
+++ b/xen/drivers/video/Makefile
@@ -4,4 +4,3 @@ obj-$(CONFIG_VIDEO) += font_8x16.o
obj-$(CONFIG_VIDEO) += font_8x8.o
obj-$(CONFIG_VIDEO) += lfb.o
obj-$(CONFIG_VGA) += vesa.o
-obj-$(CONFIG_HAS_ARM_HDLCD) += arm_hdlcd.o
diff --git a/xen/drivers/video/arm_hdlcd.c b/xen/drivers/video/arm_hdlcd.c
deleted file mode 100644
index e1174b2..0000000
--- a/xen/drivers/video/arm_hdlcd.c
+++ /dev/null
@@ -1,281 +0,0 @@
-/*
- * xen/drivers/video/arm_hdlcd.c
- *
- * Driver for ARM HDLCD Controller
- *
- * Stefano Stabellini <stefano.stabellini@eu.citrix.com>
- * Copyright (c) 2013 Citrix Systems.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- */
-
-#include <asm/delay.h>
-#include <asm/types.h>
-#include <asm/platforms/vexpress.h>
-#include <xen/device_tree.h>
-#include <xen/libfdt/libfdt.h>
-#include <xen/init.h>
-#include <xen/mm.h>
-#include "font.h"
-#include "lfb.h"
-#include "modelines.h"
-
-#define HDLCD ((volatile uint32_t *) FIXMAP_ADDR(FIXMAP_MISC))
-
-#define HDLCD_INTMASK (0x18/4)
-#define HDLCD_FBBASE (0x100/4)
-#define HDLCD_LINELENGTH (0x104/4)
-#define HDLCD_LINECOUNT (0x108/4)
-#define HDLCD_LINEPITCH (0x10C/4)
-#define HDLCD_BUS (0x110/4)
-#define HDLCD_VSYNC (0x200/4)
-#define HDLCD_VBACK (0x204/4)
-#define HDLCD_VDATA (0x208/4)
-#define HDLCD_VFRONT (0x20C/4)
-#define HDLCD_HSYNC (0x210/4)
-#define HDLCD_HBACK (0x214/4)
-#define HDLCD_HDATA (0x218/4)
-#define HDLCD_HFRONT (0x21C/4)
-#define HDLCD_POLARITIES (0x220/4)
-#define HDLCD_COMMAND (0x230/4)
-#define HDLCD_PF (0x240/4)
-#define HDLCD_RED (0x244/4)
-#define HDLCD_GREEN (0x248/4)
-#define HDLCD_BLUE (0x24C/4)
-
-struct color_masks {
- int red_shift;
- int red_size;
- int green_shift;
- int green_size;
- int blue_shift;
- int blue_size;
-};
-
-struct pixel_colors {
- const char* bpp;
- struct color_masks colors;
-};
-
-struct pixel_colors __initdata colors[] = {
- { "16", { 0, 5, 11, 5, 6, 5 } },
- { "24", { 0, 8, 16, 8, 8, 8 } },
- { "32", { 0, 8, 16, 8, 8, 8 } },
-};
-
-static void vga_noop_puts(const char *s) {}
-void (*video_puts)(const char *) = vga_noop_puts;
-
-static void hdlcd_flush(void)
-{
- dsb(sy);
-}
-
-static int __init get_color_masks(const char* bpp, struct color_masks **masks)
-{
- int i;
- for ( i = 0; i < ARRAY_SIZE(colors); i++ )
- {
- if ( !strncmp(colors[i].bpp, bpp, 2) )
- {
- *masks = &colors[i].colors;
- return 0;
- }
- }
- return -1;
-}
-
-static void __init set_pixclock(uint32_t pixclock)
-{
- if ( dt_find_compatible_node(NULL, NULL, "arm,vexpress") )
- vexpress_syscfg(1, V2M_SYS_CFG_OSC_FUNC,
- V2M_SYS_CFG_OSC5, &pixclock);
-}
-
-void __init video_init(void)
-{
- struct lfb_prop lfbp;
- unsigned char *lfb;
- paddr_t hdlcd_start, hdlcd_size;
- paddr_t framebuffer_start, framebuffer_size;
- const char *mode_string;
- char _mode_string[16];
- int bytes_per_pixel = 4;
- struct color_masks *c = NULL;
- struct modeline *videomode = NULL;
- int i;
- const struct dt_device_node *dev;
- const __be32 *cells;
- u32 lenp;
- int res;
-
- dev = dt_find_compatible_node(NULL, NULL, "arm,hdlcd");
-
- if ( !dev )
- {
- printk("HDLCD: Cannot find node compatible with \"arm,hdcld\"\n");
- return;
- }
-
- res = dt_device_get_address(dev, 0, &hdlcd_start, &hdlcd_size);
- if ( !res )
- {
- printk("HDLCD: Unable to retrieve MMIO base address\n");
- return;
- }
-
- cells = dt_get_property(dev, "framebuffer", &lenp);
- if ( !cells )
- {
- printk("HDLCD: Unable to retrieve framebuffer property\n");
- return;
- }
-
- framebuffer_start = dt_next_cell(dt_n_addr_cells(dev), &cells);
- framebuffer_size = dt_next_cell(dt_n_size_cells(dev), &cells);
-
- if ( !hdlcd_start )
- {
- printk(KERN_ERR "HDLCD: address missing from device tree, disabling driver\n");
- return;
- }
-
- if ( !framebuffer_start )
- {
- printk(KERN_ERR "HDLCD: framebuffer address missing from device tree, disabling driver\n");
- return;
- }
-
- res = dt_property_read_string(dev, "mode", &mode_string);
- if ( res )
- {
- get_color_masks("32", &c);
- memcpy(_mode_string, "1280x1024@60", strlen("1280x1024@60") + 1);
- bytes_per_pixel = 4;
- }
- else if ( strlen(mode_string) < strlen("800x600@60") ||
- strlen(mode_string) > sizeof(_mode_string) - 1 )
- {
- printk(KERN_ERR "HDLCD: invalid modeline=%s\n", mode_string);
- return;
- } else {
- char *s = strchr(mode_string, '-');
- if ( !s )
- {
- printk(KERN_INFO "HDLCD: bpp not found in modeline %s, assume 32 bpp\n",
- mode_string);
- get_color_masks("32", &c);
- memcpy(_mode_string, mode_string, strlen(mode_string) + 1);
- bytes_per_pixel = 4;
- } else {
- if ( strlen(s) < 6 )
- {
- printk(KERN_ERR "HDLCD: invalid mode %s\n", mode_string);
- return;
- }
- s++;
- if ( get_color_masks(s, &c) < 0 )
- {
- printk(KERN_WARNING "HDLCD: unsupported bpp %s\n", s);
- return;
- }
- bytes_per_pixel = simple_strtoll(s, NULL, 10) / 8;
- }
- i = s - mode_string - 1;
- memcpy(_mode_string, mode_string, i);
- memcpy(_mode_string + i, mode_string + i + 3, 4);
- }
-
- for ( i = 0; i < ARRAY_SIZE(videomodes); i++ ) {
- if ( !strcmp(_mode_string, videomodes[i].mode) )
- {
- videomode = &videomodes[i];
- break;
- }
- }
- if ( !videomode )
- {
- printk(KERN_WARNING "HDLCD: unsupported videomode %s\n",
- _mode_string);
- return;
- }
-
- if ( framebuffer_size < bytes_per_pixel * videomode->xres * videomode->yres )
- {
- printk(KERN_ERR "HDLCD: the framebuffer is too small, disabling the HDLCD driver\n");
- return;
- }
-
- printk(KERN_INFO "Initializing HDLCD driver\n");
-
- lfb = ioremap_wc(framebuffer_start, framebuffer_size);
- if ( !lfb )
- {
- printk(KERN_ERR "Couldn't map the framebuffer\n");
- return;
- }
- memset(lfb, 0x00, bytes_per_pixel * videomode->xres * videomode->yres);
-
- /* uses FIXMAP_MISC */
- set_pixclock(videomode->pixclock);
-
- set_fixmap(FIXMAP_MISC, maddr_to_mfn(hdlcd_start), PAGE_HYPERVISOR_NOCACHE);
- HDLCD[HDLCD_COMMAND] = 0;
-
- HDLCD[HDLCD_LINELENGTH] = videomode->xres * bytes_per_pixel;
- HDLCD[HDLCD_LINECOUNT] = videomode->yres - 1;
- HDLCD[HDLCD_LINEPITCH] = videomode->xres * bytes_per_pixel;
- HDLCD[HDLCD_PF] = ((bytes_per_pixel - 1) << 3);
- HDLCD[HDLCD_INTMASK] = 0;
- HDLCD[HDLCD_FBBASE] = framebuffer_start;
- HDLCD[HDLCD_BUS] = 0xf00 | (1 << 4);
- HDLCD[HDLCD_VBACK] = videomode->vback - 1;
- HDLCD[HDLCD_VSYNC] = videomode->vsync - 1;
- HDLCD[HDLCD_VDATA] = videomode->yres - 1;
- HDLCD[HDLCD_VFRONT] = videomode->vfront - 1;
- HDLCD[HDLCD_HBACK] = videomode->hback - 1;
- HDLCD[HDLCD_HSYNC] = videomode->hsync - 1;
- HDLCD[HDLCD_HDATA] = videomode->xres - 1;
- HDLCD[HDLCD_HFRONT] = videomode->hfront - 1;
- HDLCD[HDLCD_POLARITIES] = (1 << 2) | (1 << 3);
- HDLCD[HDLCD_RED] = (c->red_size << 8) | c->red_shift;
- HDLCD[HDLCD_GREEN] = (c->green_size << 8) | c->green_shift;
- HDLCD[HDLCD_BLUE] = (c->blue_size << 8) | c->blue_shift;
- HDLCD[HDLCD_COMMAND] = 1;
- clear_fixmap(FIXMAP_MISC);
-
- lfbp.pixel_on = (((1 << c->red_size) - 1) << c->red_shift) |
- (((1 << c->green_size) - 1) << c->green_shift) |
- (((1 << c->blue_size) - 1) << c->blue_shift);
- lfbp.lfb = lfb;
- lfbp.font = &font_vga_8x16;
- lfbp.bits_per_pixel = bytes_per_pixel*8;
- lfbp.bytes_per_line = bytes_per_pixel*videomode->xres;
- lfbp.width = videomode->xres;
- lfbp.height = videomode->yres;
- lfbp.flush = hdlcd_flush;
- lfbp.text_columns = videomode->xres / 8;
- lfbp.text_rows = videomode->yres / 16;
- if ( lfb_init(&lfbp) < 0 )
- return;
- video_puts = lfb_scroll_puts;
-}
-
-void __init video_endboot(void) { }
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/include/asm-arm/platforms/vexpress.h b/xen/include/asm-arm/platforms/vexpress.h
index 5cf3aba..8b45d3a 100644
--- a/xen/include/asm-arm/platforms/vexpress.h
+++ b/xen/include/asm-arm/platforms/vexpress.h
@@ -26,12 +26,6 @@
/* Board-specific: base address of system controller */
#define SP810_ADDRESS 0x1C020000
-#ifndef __ASSEMBLY__
-#include <xen/inttypes.h>
-
-int vexpress_syscfg(int write, int function, int device, uint32_t *data);
-#endif
-
#endif /* __ASM_ARM_PLATFORMS_VEXPRESS_H */
/*
* Local variables:
--
1.9.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 33+ messages in thread* Re: [PATCH v3 01/10] arm: remove the ARM HDLCD driver
2018-05-23 0:24 ` [PATCH v3 01/10] arm: remove the ARM HDLCD driver Stefano Stabellini
@ 2018-05-29 13:37 ` Julien Grall
0 siblings, 0 replies; 33+ messages in thread
From: Julien Grall @ 2018-05-29 13:37 UTC (permalink / raw)
To: Stefano Stabellini
Cc: artem_mygaiev, lars.kurth, dfaggioli, andrii_anisov, xen-devel
Hi Stefano,
On 23/05/18 01:24, Stefano Stabellini wrote:
> The ARM HDLCD driver is unused. The device itself can only be found on
> Virtual Express boards that are for early development only. Remove the
> driver.
>
> Also remove vexpress_syscfg, now unused, and "select VIDEO" that is not
> useful anymore.
>
> Suggested-by: Julien Grall <julien.grall@arm.com>
> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Julien Grall <julien.grall@arm.com>
Cheers,
> ---
> Changes in v3:
> - remove "select VIDEO"
> - remove vexpress_syscfg
> Changes in v2:
> - patch added
> ---
> xen/arch/arm/Kconfig | 2 -
> xen/arch/arm/platforms/vexpress.c | 35 ----
> xen/drivers/video/Kconfig | 3 -
> xen/drivers/video/Makefile | 1 -
> xen/drivers/video/arm_hdlcd.c | 281 -------------------------------
> xen/include/asm-arm/platforms/vexpress.h | 6 -
> 6 files changed, 328 deletions(-)
> delete mode 100644 xen/drivers/video/arm_hdlcd.c
>
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index 8174c0c..4dc7ef5 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -17,12 +17,10 @@ config ARM_64
> config ARM
> def_bool y
> select HAS_ALTERNATIVE
> - select HAS_ARM_HDLCD
> select HAS_DEVICE_TREE
> select HAS_MEM_ACCESS
> select HAS_PASSTHROUGH
> select HAS_PDX
> - select VIDEO
>
> config ARCH_DEFCONFIG
> string
> diff --git a/xen/arch/arm/platforms/vexpress.c b/xen/arch/arm/platforms/vexpress.c
> index 70839d6..b6193f7 100644
> --- a/xen/arch/arm/platforms/vexpress.c
> +++ b/xen/arch/arm/platforms/vexpress.c
> @@ -59,41 +59,6 @@ static inline int vexpress_ctrl_start(uint32_t *syscfg, int write,
> return 0;
> }
>
> -int vexpress_syscfg(int write, int function, int device, uint32_t *data)
> -{
> - uint32_t *syscfg = (uint32_t *) FIXMAP_ADDR(FIXMAP_MISC);
> - int ret = -1;
> -
> - set_fixmap(FIXMAP_MISC, maddr_to_mfn(V2M_SYS_MMIO_BASE),
> - PAGE_HYPERVISOR_NOCACHE);
> -
> - if ( syscfg[V2M_SYS_CFGCTRL/4] & V2M_SYS_CFG_START )
> - goto out;
> -
> - /* clear the complete bit in the V2M_SYS_CFGSTAT status register */
> - syscfg[V2M_SYS_CFGSTAT/4] = 0;
> -
> - if ( write )
> - {
> - /* write data */
> - syscfg[V2M_SYS_CFGDATA/4] = *data;
> -
> - if ( vexpress_ctrl_start(syscfg, write, function, device) < 0 )
> - goto out;
> - } else {
> - if ( vexpress_ctrl_start(syscfg, write, function, device) < 0 )
> - goto out;
> - else
> - /* read data */
> - *data = syscfg[V2M_SYS_CFGDATA/4];
> - }
> -
> - ret = 0;
> -out:
> - clear_fixmap(FIXMAP_MISC);
> - return ret;
> -}
> -
> /*
> * TODO: Get base address from the device tree
> * See arm,vexpress-reset node
> diff --git a/xen/drivers/video/Kconfig b/xen/drivers/video/Kconfig
> index 52e8ce6..41ca503 100644
> --- a/xen/drivers/video/Kconfig
> +++ b/xen/drivers/video/Kconfig
> @@ -11,6 +11,3 @@ config VGA
> Enable VGA output for the Xen hypervisor.
>
> If unsure, say Y.
> -
> -config HAS_ARM_HDLCD
> - bool
> diff --git a/xen/drivers/video/Makefile b/xen/drivers/video/Makefile
> index 2bb91d6..2b3fc76 100644
> --- a/xen/drivers/video/Makefile
> +++ b/xen/drivers/video/Makefile
> @@ -4,4 +4,3 @@ obj-$(CONFIG_VIDEO) += font_8x16.o
> obj-$(CONFIG_VIDEO) += font_8x8.o
> obj-$(CONFIG_VIDEO) += lfb.o
> obj-$(CONFIG_VGA) += vesa.o
> -obj-$(CONFIG_HAS_ARM_HDLCD) += arm_hdlcd.o
> diff --git a/xen/drivers/video/arm_hdlcd.c b/xen/drivers/video/arm_hdlcd.c
> deleted file mode 100644
> index e1174b2..0000000
> --- a/xen/drivers/video/arm_hdlcd.c
> +++ /dev/null
> @@ -1,281 +0,0 @@
> -/*
> - * xen/drivers/video/arm_hdlcd.c
> - *
> - * Driver for ARM HDLCD Controller
> - *
> - * Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> - * Copyright (c) 2013 Citrix Systems.
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation; either version 2 of the License, or
> - * (at your option) any later version.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> - * GNU General Public License for more details.
> - */
> -
> -#include <asm/delay.h>
> -#include <asm/types.h>
> -#include <asm/platforms/vexpress.h>
> -#include <xen/device_tree.h>
> -#include <xen/libfdt/libfdt.h>
> -#include <xen/init.h>
> -#include <xen/mm.h>
> -#include "font.h"
> -#include "lfb.h"
> -#include "modelines.h"
> -
> -#define HDLCD ((volatile uint32_t *) FIXMAP_ADDR(FIXMAP_MISC))
> -
> -#define HDLCD_INTMASK (0x18/4)
> -#define HDLCD_FBBASE (0x100/4)
> -#define HDLCD_LINELENGTH (0x104/4)
> -#define HDLCD_LINECOUNT (0x108/4)
> -#define HDLCD_LINEPITCH (0x10C/4)
> -#define HDLCD_BUS (0x110/4)
> -#define HDLCD_VSYNC (0x200/4)
> -#define HDLCD_VBACK (0x204/4)
> -#define HDLCD_VDATA (0x208/4)
> -#define HDLCD_VFRONT (0x20C/4)
> -#define HDLCD_HSYNC (0x210/4)
> -#define HDLCD_HBACK (0x214/4)
> -#define HDLCD_HDATA (0x218/4)
> -#define HDLCD_HFRONT (0x21C/4)
> -#define HDLCD_POLARITIES (0x220/4)
> -#define HDLCD_COMMAND (0x230/4)
> -#define HDLCD_PF (0x240/4)
> -#define HDLCD_RED (0x244/4)
> -#define HDLCD_GREEN (0x248/4)
> -#define HDLCD_BLUE (0x24C/4)
> -
> -struct color_masks {
> - int red_shift;
> - int red_size;
> - int green_shift;
> - int green_size;
> - int blue_shift;
> - int blue_size;
> -};
> -
> -struct pixel_colors {
> - const char* bpp;
> - struct color_masks colors;
> -};
> -
> -struct pixel_colors __initdata colors[] = {
> - { "16", { 0, 5, 11, 5, 6, 5 } },
> - { "24", { 0, 8, 16, 8, 8, 8 } },
> - { "32", { 0, 8, 16, 8, 8, 8 } },
> -};
> -
> -static void vga_noop_puts(const char *s) {}
> -void (*video_puts)(const char *) = vga_noop_puts;
> -
> -static void hdlcd_flush(void)
> -{
> - dsb(sy);
> -}
> -
> -static int __init get_color_masks(const char* bpp, struct color_masks **masks)
> -{
> - int i;
> - for ( i = 0; i < ARRAY_SIZE(colors); i++ )
> - {
> - if ( !strncmp(colors[i].bpp, bpp, 2) )
> - {
> - *masks = &colors[i].colors;
> - return 0;
> - }
> - }
> - return -1;
> -}
> -
> -static void __init set_pixclock(uint32_t pixclock)
> -{
> - if ( dt_find_compatible_node(NULL, NULL, "arm,vexpress") )
> - vexpress_syscfg(1, V2M_SYS_CFG_OSC_FUNC,
> - V2M_SYS_CFG_OSC5, &pixclock);
> -}
> -
> -void __init video_init(void)
> -{
> - struct lfb_prop lfbp;
> - unsigned char *lfb;
> - paddr_t hdlcd_start, hdlcd_size;
> - paddr_t framebuffer_start, framebuffer_size;
> - const char *mode_string;
> - char _mode_string[16];
> - int bytes_per_pixel = 4;
> - struct color_masks *c = NULL;
> - struct modeline *videomode = NULL;
> - int i;
> - const struct dt_device_node *dev;
> - const __be32 *cells;
> - u32 lenp;
> - int res;
> -
> - dev = dt_find_compatible_node(NULL, NULL, "arm,hdlcd");
> -
> - if ( !dev )
> - {
> - printk("HDLCD: Cannot find node compatible with \"arm,hdcld\"\n");
> - return;
> - }
> -
> - res = dt_device_get_address(dev, 0, &hdlcd_start, &hdlcd_size);
> - if ( !res )
> - {
> - printk("HDLCD: Unable to retrieve MMIO base address\n");
> - return;
> - }
> -
> - cells = dt_get_property(dev, "framebuffer", &lenp);
> - if ( !cells )
> - {
> - printk("HDLCD: Unable to retrieve framebuffer property\n");
> - return;
> - }
> -
> - framebuffer_start = dt_next_cell(dt_n_addr_cells(dev), &cells);
> - framebuffer_size = dt_next_cell(dt_n_size_cells(dev), &cells);
> -
> - if ( !hdlcd_start )
> - {
> - printk(KERN_ERR "HDLCD: address missing from device tree, disabling driver\n");
> - return;
> - }
> -
> - if ( !framebuffer_start )
> - {
> - printk(KERN_ERR "HDLCD: framebuffer address missing from device tree, disabling driver\n");
> - return;
> - }
> -
> - res = dt_property_read_string(dev, "mode", &mode_string);
> - if ( res )
> - {
> - get_color_masks("32", &c);
> - memcpy(_mode_string, "1280x1024@60", strlen("1280x1024@60") + 1);
> - bytes_per_pixel = 4;
> - }
> - else if ( strlen(mode_string) < strlen("800x600@60") ||
> - strlen(mode_string) > sizeof(_mode_string) - 1 )
> - {
> - printk(KERN_ERR "HDLCD: invalid modeline=%s\n", mode_string);
> - return;
> - } else {
> - char *s = strchr(mode_string, '-');
> - if ( !s )
> - {
> - printk(KERN_INFO "HDLCD: bpp not found in modeline %s, assume 32 bpp\n",
> - mode_string);
> - get_color_masks("32", &c);
> - memcpy(_mode_string, mode_string, strlen(mode_string) + 1);
> - bytes_per_pixel = 4;
> - } else {
> - if ( strlen(s) < 6 )
> - {
> - printk(KERN_ERR "HDLCD: invalid mode %s\n", mode_string);
> - return;
> - }
> - s++;
> - if ( get_color_masks(s, &c) < 0 )
> - {
> - printk(KERN_WARNING "HDLCD: unsupported bpp %s\n", s);
> - return;
> - }
> - bytes_per_pixel = simple_strtoll(s, NULL, 10) / 8;
> - }
> - i = s - mode_string - 1;
> - memcpy(_mode_string, mode_string, i);
> - memcpy(_mode_string + i, mode_string + i + 3, 4);
> - }
> -
> - for ( i = 0; i < ARRAY_SIZE(videomodes); i++ ) {
> - if ( !strcmp(_mode_string, videomodes[i].mode) )
> - {
> - videomode = &videomodes[i];
> - break;
> - }
> - }
> - if ( !videomode )
> - {
> - printk(KERN_WARNING "HDLCD: unsupported videomode %s\n",
> - _mode_string);
> - return;
> - }
> -
> - if ( framebuffer_size < bytes_per_pixel * videomode->xres * videomode->yres )
> - {
> - printk(KERN_ERR "HDLCD: the framebuffer is too small, disabling the HDLCD driver\n");
> - return;
> - }
> -
> - printk(KERN_INFO "Initializing HDLCD driver\n");
> -
> - lfb = ioremap_wc(framebuffer_start, framebuffer_size);
> - if ( !lfb )
> - {
> - printk(KERN_ERR "Couldn't map the framebuffer\n");
> - return;
> - }
> - memset(lfb, 0x00, bytes_per_pixel * videomode->xres * videomode->yres);
> -
> - /* uses FIXMAP_MISC */
> - set_pixclock(videomode->pixclock);
> -
> - set_fixmap(FIXMAP_MISC, maddr_to_mfn(hdlcd_start), PAGE_HYPERVISOR_NOCACHE);
> - HDLCD[HDLCD_COMMAND] = 0;
> -
> - HDLCD[HDLCD_LINELENGTH] = videomode->xres * bytes_per_pixel;
> - HDLCD[HDLCD_LINECOUNT] = videomode->yres - 1;
> - HDLCD[HDLCD_LINEPITCH] = videomode->xres * bytes_per_pixel;
> - HDLCD[HDLCD_PF] = ((bytes_per_pixel - 1) << 3);
> - HDLCD[HDLCD_INTMASK] = 0;
> - HDLCD[HDLCD_FBBASE] = framebuffer_start;
> - HDLCD[HDLCD_BUS] = 0xf00 | (1 << 4);
> - HDLCD[HDLCD_VBACK] = videomode->vback - 1;
> - HDLCD[HDLCD_VSYNC] = videomode->vsync - 1;
> - HDLCD[HDLCD_VDATA] = videomode->yres - 1;
> - HDLCD[HDLCD_VFRONT] = videomode->vfront - 1;
> - HDLCD[HDLCD_HBACK] = videomode->hback - 1;
> - HDLCD[HDLCD_HSYNC] = videomode->hsync - 1;
> - HDLCD[HDLCD_HDATA] = videomode->xres - 1;
> - HDLCD[HDLCD_HFRONT] = videomode->hfront - 1;
> - HDLCD[HDLCD_POLARITIES] = (1 << 2) | (1 << 3);
> - HDLCD[HDLCD_RED] = (c->red_size << 8) | c->red_shift;
> - HDLCD[HDLCD_GREEN] = (c->green_size << 8) | c->green_shift;
> - HDLCD[HDLCD_BLUE] = (c->blue_size << 8) | c->blue_shift;
> - HDLCD[HDLCD_COMMAND] = 1;
> - clear_fixmap(FIXMAP_MISC);
> -
> - lfbp.pixel_on = (((1 << c->red_size) - 1) << c->red_shift) |
> - (((1 << c->green_size) - 1) << c->green_shift) |
> - (((1 << c->blue_size) - 1) << c->blue_shift);
> - lfbp.lfb = lfb;
> - lfbp.font = &font_vga_8x16;
> - lfbp.bits_per_pixel = bytes_per_pixel*8;
> - lfbp.bytes_per_line = bytes_per_pixel*videomode->xres;
> - lfbp.width = videomode->xres;
> - lfbp.height = videomode->yres;
> - lfbp.flush = hdlcd_flush;
> - lfbp.text_columns = videomode->xres / 8;
> - lfbp.text_rows = videomode->yres / 16;
> - if ( lfb_init(&lfbp) < 0 )
> - return;
> - video_puts = lfb_scroll_puts;
> -}
> -
> -void __init video_endboot(void) { }
> -
> -/*
> - * Local variables:
> - * mode: C
> - * c-file-style: "BSD"
> - * c-basic-offset: 4
> - * indent-tabs-mode: nil
> - * End:
> - */
> diff --git a/xen/include/asm-arm/platforms/vexpress.h b/xen/include/asm-arm/platforms/vexpress.h
> index 5cf3aba..8b45d3a 100644
> --- a/xen/include/asm-arm/platforms/vexpress.h
> +++ b/xen/include/asm-arm/platforms/vexpress.h
> @@ -26,12 +26,6 @@
> /* Board-specific: base address of system controller */
> #define SP810_ADDRESS 0x1C020000
>
> -#ifndef __ASSEMBLY__
> -#include <xen/inttypes.h>
> -
> -int vexpress_syscfg(int write, int function, int device, uint32_t *data);
> -#endif
> -
> #endif /* __ASM_ARM_PLATFORMS_VEXPRESS_H */
> /*
> * Local variables:
>
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* [PATCH v3 02/10] arm: make it possible to disable HAS_GICV3
2018-05-23 0:24 [PATCH v3 0/10] arm: more kconfig configurability and small default configs Stefano Stabellini
2018-05-23 0:24 ` [PATCH v3 01/10] arm: remove the ARM HDLCD driver Stefano Stabellini
@ 2018-05-23 0:25 ` Stefano Stabellini
2018-05-29 13:38 ` Julien Grall
2018-05-23 0:25 ` [PATCH v3 03/10] arm: rename HAS_GICV3 to GICV3 Stefano Stabellini
` (7 subsequent siblings)
9 siblings, 1 reply; 33+ messages in thread
From: Stefano Stabellini @ 2018-05-23 0:25 UTC (permalink / raw)
To: julien.grall
Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov, dfaggioli,
xen-devel
Today it is a silent option. This patch adds a one line description and
makes it optional.
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
---
Changes in v3:
- remove any changes to MEM_ACCESS
- update commit message
Changes in v2:
- make HAS_GICv3 depend on ARM_64
- remove modifications to ARM_HDLCD kconfig, it has been removed
---
xen/arch/arm/Kconfig | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 4dc7ef5..fb69a66 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -12,7 +12,6 @@ config ARM_32
config ARM_64
def_bool y
depends on 64BIT
- select HAS_GICV3
config ARM
def_bool y
@@ -42,6 +41,13 @@ config ACPI
config HAS_GICV3
bool
+ prompt "GICv3 driver"
+ depends on ARM_64
+ default y
+ ---help---
+
+ Driver for the ARM Generic Interrupt Controller v3.
+ If unsure, say Y
config HAS_ITS
bool
--
1.9.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 33+ messages in thread* Re: [PATCH v3 02/10] arm: make it possible to disable HAS_GICV3
2018-05-23 0:25 ` [PATCH v3 02/10] arm: make it possible to disable HAS_GICV3 Stefano Stabellini
@ 2018-05-29 13:38 ` Julien Grall
0 siblings, 0 replies; 33+ messages in thread
From: Julien Grall @ 2018-05-29 13:38 UTC (permalink / raw)
To: Stefano Stabellini
Cc: artem_mygaiev, lars.kurth, dfaggioli, andrii_anisov, xen-devel
On 23/05/18 01:25, Stefano Stabellini wrote:
> Today it is a silent option. This patch adds a one line description and
> makes it optional.
>
> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Julien Grall <julien.grall@arm.com>
>
> ---
> Changes in v3:
> - remove any changes to MEM_ACCESS
> - update commit message
>
> Changes in v2:
> - make HAS_GICv3 depend on ARM_64
> - remove modifications to ARM_HDLCD kconfig, it has been removed
> ---
> xen/arch/arm/Kconfig | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index 4dc7ef5..fb69a66 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -12,7 +12,6 @@ config ARM_32
> config ARM_64
> def_bool y
> depends on 64BIT
> - select HAS_GICV3
>
> config ARM
> def_bool y
> @@ -42,6 +41,13 @@ config ACPI
>
> config HAS_GICV3
> bool
> + prompt "GICv3 driver"
> + depends on ARM_64
> + default y
> + ---help---
> +
> + Driver for the ARM Generic Interrupt Controller v3.
> + If unsure, say Y
>
> config HAS_ITS
> bool
>
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* [PATCH v3 03/10] arm: rename HAS_GICV3 to GICV3
2018-05-23 0:24 [PATCH v3 0/10] arm: more kconfig configurability and small default configs Stefano Stabellini
2018-05-23 0:24 ` [PATCH v3 01/10] arm: remove the ARM HDLCD driver Stefano Stabellini
2018-05-23 0:25 ` [PATCH v3 02/10] arm: make it possible to disable HAS_GICV3 Stefano Stabellini
@ 2018-05-23 0:25 ` Stefano Stabellini
2018-05-29 13:39 ` Julien Grall
2018-05-23 0:25 ` [PATCH v3 04/10] Make MEM_ACCESS configurable Stefano Stabellini
` (6 subsequent siblings)
9 siblings, 1 reply; 33+ messages in thread
From: Stefano Stabellini @ 2018-05-23 0:25 UTC (permalink / raw)
To: julien.grall
Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov, dfaggioli,
xen-devel
HAS_GICV3 has become selectable by the user. To mark the change, rename
the option from HAS_GICV3 to GICV3.
Suggested-by: Julien Grall <julien.grall@arm.com>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
---
Changes in v3:
- no changes
Changes in v2:
- patch added
---
xen/arch/arm/Kconfig | 4 ++--
xen/arch/arm/Makefile | 4 ++--
xen/arch/arm/vgic.c | 2 +-
xen/arch/arm/vgic/vgic.c | 2 +-
xen/include/asm-arm/gic.h | 4 ++--
xen/include/asm-arm/vgic.h | 4 ++--
6 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index fb69a66..66adce4 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -39,7 +39,7 @@ config ACPI
Advanced Configuration and Power Interface (ACPI) support for Xen is
an alternative to device tree on ARM64.
-config HAS_GICV3
+config GICV3
bool
prompt "GICv3 driver"
depends on ARM_64
@@ -52,7 +52,7 @@ config HAS_GICV3
config HAS_ITS
bool
prompt "GICv3 ITS MSI controller support" if EXPERT = "y"
- depends on HAS_GICV3 && !NEW_VGIC
+ depends on GICV3 && !NEW_VGIC
config NEW_VGIC
bool
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index a9533b1..b9c2fb7 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -17,7 +17,7 @@ obj-y += domctl.o
obj-$(EARLY_PRINTK) += early_printk.o
obj-y += gic.o
obj-y += gic-v2.o
-obj-$(CONFIG_HAS_GICV3) += gic-v3.o
+obj-$(CONFIG_GICV3) += gic-v3.o
obj-$(CONFIG_HAS_ITS) += gic-v3-its.o
obj-$(CONFIG_HAS_ITS) += gic-v3-lpi.o
obj-y += guestcopy.o
@@ -51,7 +51,7 @@ ifneq ($(CONFIG_NEW_VGIC),y)
obj-y += gic-vgic.o
obj-y += vgic.o
obj-y += vgic-v2.o
-obj-$(CONFIG_HAS_GICV3) += vgic-v3.o
+obj-$(CONFIG_GICV3) += vgic-v3.o
obj-$(CONFIG_HAS_ITS) += vgic-v3-its.o
endif
obj-y += vm_event.o
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 3fafdd0..7a2c455 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -98,7 +98,7 @@ int domain_vgic_register(struct domain *d, int *mmio_count)
{
switch ( d->arch.vgic.version )
{
-#ifdef CONFIG_HAS_GICV3
+#ifdef CONFIG_GICV3
case GIC_V3:
if ( vgic_v3_init(d, mmio_count) )
return -ENODEV;
diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index a35449b..832632a 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -974,7 +974,7 @@ unsigned int vgic_max_vcpus(const struct domain *d)
return min_t(unsigned int, MAX_VIRT_CPUS, vgic_vcpu_limit);
}
-#ifdef CONFIG_HAS_GICV3
+#ifdef CONFIG_GICV3
/* Dummy implementation to allow building without actual vGICv3 support. */
void vgic_v3_setup_hw(paddr_t dbase,
unsigned int nr_rdist_regions,
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 58b910f..22fa122 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -166,7 +166,7 @@
#define DT_MATCH_GIC_V3 DT_MATCH_COMPATIBLE("arm,gic-v3")
-#ifdef CONFIG_HAS_GICV3
+#ifdef CONFIG_GICV3
/*
* GICv3 registers that needs to be saved/restored
*/
@@ -194,7 +194,7 @@ struct gic_v2 {
*/
union gic_state_data {
struct gic_v2 v2;
-#ifdef CONFIG_HAS_GICV3
+#ifdef CONFIG_GICV3
struct gic_v3 v3;
#endif
};
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index 2a58ea3..374fdaa 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -156,7 +156,7 @@ struct vgic_dist {
struct pending_irq *pending_irqs;
/* Base address for guest GIC */
paddr_t dbase; /* Distributor base address */
-#ifdef CONFIG_HAS_GICV3
+#ifdef CONFIG_GICV3
/* GIC V3 addressing */
/* List of contiguous occupied by the redistributors */
struct vgic_rdist_region {
@@ -359,7 +359,7 @@ unsigned int vgic_max_vcpus(const struct domain *d);
void vgic_v2_setup_hw(paddr_t dbase, paddr_t cbase, paddr_t csize,
paddr_t vbase, uint32_t aliased_offset);
-#ifdef CONFIG_HAS_GICV3
+#ifdef CONFIG_GICV3
struct rdist_region;
void vgic_v3_setup_hw(paddr_t dbase,
unsigned int nr_rdist_regions,
--
1.9.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 33+ messages in thread* Re: [PATCH v3 03/10] arm: rename HAS_GICV3 to GICV3
2018-05-23 0:25 ` [PATCH v3 03/10] arm: rename HAS_GICV3 to GICV3 Stefano Stabellini
@ 2018-05-29 13:39 ` Julien Grall
0 siblings, 0 replies; 33+ messages in thread
From: Julien Grall @ 2018-05-29 13:39 UTC (permalink / raw)
To: Stefano Stabellini
Cc: artem_mygaiev, lars.kurth, dfaggioli, andrii_anisov, xen-devel
Hi Stefano,
On 23/05/18 01:25, Stefano Stabellini wrote:
> HAS_GICV3 has become selectable by the user. To mark the change, rename
> the option from HAS_GICV3 to GICV3.
>
> Suggested-by: Julien Grall <julien.grall@arm.com>
> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Julien Grall <julien.grall@arm.com>
Cheers,
>
> ---
> Changes in v3:
> - no changes
>
> Changes in v2:
> - patch added
> ---
> xen/arch/arm/Kconfig | 4 ++--
> xen/arch/arm/Makefile | 4 ++--
> xen/arch/arm/vgic.c | 2 +-
> xen/arch/arm/vgic/vgic.c | 2 +-
> xen/include/asm-arm/gic.h | 4 ++--
> xen/include/asm-arm/vgic.h | 4 ++--
> 6 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index fb69a66..66adce4 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -39,7 +39,7 @@ config ACPI
> Advanced Configuration and Power Interface (ACPI) support for Xen is
> an alternative to device tree on ARM64.
>
> -config HAS_GICV3
> +config GICV3
> bool
> prompt "GICv3 driver"
> depends on ARM_64
> @@ -52,7 +52,7 @@ config HAS_GICV3
> config HAS_ITS
> bool
> prompt "GICv3 ITS MSI controller support" if EXPERT = "y"
> - depends on HAS_GICV3 && !NEW_VGIC
> + depends on GICV3 && !NEW_VGIC
>
> config NEW_VGIC
> bool
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index a9533b1..b9c2fb7 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -17,7 +17,7 @@ obj-y += domctl.o
> obj-$(EARLY_PRINTK) += early_printk.o
> obj-y += gic.o
> obj-y += gic-v2.o
> -obj-$(CONFIG_HAS_GICV3) += gic-v3.o
> +obj-$(CONFIG_GICV3) += gic-v3.o
> obj-$(CONFIG_HAS_ITS) += gic-v3-its.o
> obj-$(CONFIG_HAS_ITS) += gic-v3-lpi.o
> obj-y += guestcopy.o
> @@ -51,7 +51,7 @@ ifneq ($(CONFIG_NEW_VGIC),y)
> obj-y += gic-vgic.o
> obj-y += vgic.o
> obj-y += vgic-v2.o
> -obj-$(CONFIG_HAS_GICV3) += vgic-v3.o
> +obj-$(CONFIG_GICV3) += vgic-v3.o
> obj-$(CONFIG_HAS_ITS) += vgic-v3-its.o
> endif
> obj-y += vm_event.o
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 3fafdd0..7a2c455 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -98,7 +98,7 @@ int domain_vgic_register(struct domain *d, int *mmio_count)
> {
> switch ( d->arch.vgic.version )
> {
> -#ifdef CONFIG_HAS_GICV3
> +#ifdef CONFIG_GICV3
> case GIC_V3:
> if ( vgic_v3_init(d, mmio_count) )
> return -ENODEV;
> diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
> index a35449b..832632a 100644
> --- a/xen/arch/arm/vgic/vgic.c
> +++ b/xen/arch/arm/vgic/vgic.c
> @@ -974,7 +974,7 @@ unsigned int vgic_max_vcpus(const struct domain *d)
> return min_t(unsigned int, MAX_VIRT_CPUS, vgic_vcpu_limit);
> }
>
> -#ifdef CONFIG_HAS_GICV3
> +#ifdef CONFIG_GICV3
> /* Dummy implementation to allow building without actual vGICv3 support. */
> void vgic_v3_setup_hw(paddr_t dbase,
> unsigned int nr_rdist_regions,
> diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
> index 58b910f..22fa122 100644
> --- a/xen/include/asm-arm/gic.h
> +++ b/xen/include/asm-arm/gic.h
> @@ -166,7 +166,7 @@
>
> #define DT_MATCH_GIC_V3 DT_MATCH_COMPATIBLE("arm,gic-v3")
>
> -#ifdef CONFIG_HAS_GICV3
> +#ifdef CONFIG_GICV3
> /*
> * GICv3 registers that needs to be saved/restored
> */
> @@ -194,7 +194,7 @@ struct gic_v2 {
> */
> union gic_state_data {
> struct gic_v2 v2;
> -#ifdef CONFIG_HAS_GICV3
> +#ifdef CONFIG_GICV3
> struct gic_v3 v3;
> #endif
> };
> diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
> index 2a58ea3..374fdaa 100644
> --- a/xen/include/asm-arm/vgic.h
> +++ b/xen/include/asm-arm/vgic.h
> @@ -156,7 +156,7 @@ struct vgic_dist {
> struct pending_irq *pending_irqs;
> /* Base address for guest GIC */
> paddr_t dbase; /* Distributor base address */
> -#ifdef CONFIG_HAS_GICV3
> +#ifdef CONFIG_GICV3
> /* GIC V3 addressing */
> /* List of contiguous occupied by the redistributors */
> struct vgic_rdist_region {
> @@ -359,7 +359,7 @@ unsigned int vgic_max_vcpus(const struct domain *d);
> void vgic_v2_setup_hw(paddr_t dbase, paddr_t cbase, paddr_t csize,
> paddr_t vbase, uint32_t aliased_offset);
>
> -#ifdef CONFIG_HAS_GICV3
> +#ifdef CONFIG_GICV3
> struct rdist_region;
> void vgic_v3_setup_hw(paddr_t dbase,
> unsigned int nr_rdist_regions,
>
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* [PATCH v3 04/10] Make MEM_ACCESS configurable
2018-05-23 0:24 [PATCH v3 0/10] arm: more kconfig configurability and small default configs Stefano Stabellini
` (2 preceding siblings ...)
2018-05-23 0:25 ` [PATCH v3 03/10] arm: rename HAS_GICV3 to GICV3 Stefano Stabellini
@ 2018-05-23 0:25 ` Stefano Stabellini
2018-05-29 11:50 ` Jan Beulich
2018-05-23 0:25 ` [PATCH v3 05/10] make it possible to enable/disable UART drivers Stefano Stabellini
` (5 subsequent siblings)
9 siblings, 1 reply; 33+ messages in thread
From: Stefano Stabellini @ 2018-05-23 0:25 UTC (permalink / raw)
To: julien.grall
Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov,
George.Dunlap, andrew.cooper3, ian.jackson, dfaggioli, tim,
jbeulich, wei.liu2, xen-devel
Have arm and x86 select HAS_MEM_ACCESS to mark that they can do
MEM_ACCESS.
Select an additional MEM_ACCESS_ALWAYS_ON on x86 to mark that MEM_ACCESS
is not configurable on x86.
Rename HAS_MEM_ACCESS to MEM_ACCESS everywhere else. Add a prompt and a
description to MEM_ACCESS in xen/common/Kconfig.
The result is that the user-visible option is MEM_ACCESS, and it is
configurable only on ARM (enabled by default).
Suggested-by: Julien Grall <julien.grall@arm.com>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
CC: andrew.cooper3@citrix.com
CC: George.Dunlap@eu.citrix.com
CC: ian.jackson@eu.citrix.com
CC: jbeulich@suse.com
CC: julien.grall@arm.com
CC: konrad.wilk@oracle.com
CC: sstabellini@kernel.org
CC: tim@xen.org
CC: wei.liu2@citrix.com
---
Changes in v3:
- keep HAS_MEM_ACCESS to mark that an arch can do MEM_ACCESS
- introduce MEM_ACCESS_ALWAYS_ON
- the main MEM_ACCESS option is in xen/common/Kconfig
Changes in v2:
- patch added
---
tools/firmware/xen-dir/shim.config | 2 +-
xen/arch/arm/Kconfig | 3 +++
xen/arch/x86/Kconfig | 7 +++++++
xen/common/Kconfig | 9 ++++++++-
xen/common/Makefile | 2 +-
xen/common/domctl.c | 2 +-
xen/include/xen/mem_access.h | 4 ++--
xen/include/xsm/dummy.h | 2 +-
xen/include/xsm/xsm.h | 4 ++--
xen/xsm/dummy.c | 2 +-
xen/xsm/flask/hooks.c | 4 ++--
11 files changed, 29 insertions(+), 12 deletions(-)
diff --git a/tools/firmware/xen-dir/shim.config b/tools/firmware/xen-dir/shim.config
index 4d5630f..21d7075 100644
--- a/tools/firmware/xen-dir/shim.config
+++ b/tools/firmware/xen-dir/shim.config
@@ -29,7 +29,7 @@ CONFIG_COMPAT=y
CONFIG_CORE_PARKING=y
CONFIG_HAS_ALTERNATIVE=y
CONFIG_HAS_EX_TABLE=y
-CONFIG_HAS_MEM_ACCESS=y
+CONFIG_MEM_ACCESS=y
CONFIG_HAS_MEM_PAGING=y
CONFIG_HAS_MEM_SHARING=y
CONFIG_HAS_PDX=y
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 66adce4..164cdc3 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -26,6 +26,9 @@ config ARCH_DEFCONFIG
default "arch/arm/configs/arm32_defconfig" if ARM_32
default "arch/arm/configs/arm64_defconfig" if ARM_64
+config HAS_MEM_ACCESS
+ def_bool y
+
menu "Architecture Features"
source "arch/Kconfig"
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index f64fc56..0c49d71 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -16,6 +16,7 @@ config X86
select HAS_IOPORTS
select HAS_KEXEC
select HAS_MEM_ACCESS
+ select HAS_MEM_ACCESS_ALWAYS_ON
select HAS_MEM_PAGING
select HAS_MEM_SHARING
select HAS_NS16550
@@ -30,6 +31,12 @@ config ARCH_DEFCONFIG
string
default "arch/x86/configs/x86_64_defconfig"
+config HAS_MEM_ACCESS
+ def_bool y
+
+config MEM_ACCESS_ALWAYS_ON
+ def_bool y
+
menu "Architecture Features"
source "arch/Kconfig"
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 9043dce..e675972 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -20,8 +20,15 @@ config HAS_DEVICE_TREE
config HAS_EX_TABLE
bool
-config HAS_MEM_ACCESS
+config MEM_ACCESS
bool
+ prompt "Memory Access and VM events" if !MEM_ACCESS_ALWAYS_ON
+ default y
+ depends on HAS_MEM_ACCESS
+ ---help---
+
+ Framework to configure memory access types for guests and receive
+ related events in userspace.
config HAS_MEM_PAGING
bool
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 24d4752..6f2b3fc 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -22,7 +22,7 @@ obj-y += lib.o
obj-$(CONFIG_NEEDS_LIST_SORT) += list_sort.o
obj-$(CONFIG_LIVEPATCH) += livepatch.o livepatch_elf.o
obj-y += lzo.o
-obj-$(CONFIG_HAS_MEM_ACCESS) += mem_access.o
+obj-$(CONFIG_MEM_ACCESS) += mem_access.o
obj-y += memory.o
obj-y += monitor.o
obj-y += multicall.o
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 9b7bc08..891ad58 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -1085,7 +1085,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
copyback = 1;
break;
-#ifdef CONFIG_HAS_MEM_ACCESS
+#ifdef CONFIG_MEM_ACCESS
case XEN_DOMCTL_set_access_required:
if ( unlikely(current->domain == d) ) /* no domain_pause() */
ret = -EPERM;
diff --git a/xen/include/xen/mem_access.h b/xen/include/xen/mem_access.h
index 5ab34c1..7e95eab 100644
--- a/xen/include/xen/mem_access.h
+++ b/xen/include/xen/mem_access.h
@@ -78,7 +78,7 @@ long p2m_set_mem_access_multi(struct domain *d,
*/
int p2m_get_mem_access(struct domain *d, gfn_t gfn, xenmem_access_t *access);
-#ifdef CONFIG_HAS_MEM_ACCESS
+#ifdef CONFIG_MEM_ACCESS
int mem_access_memop(unsigned long cmd,
XEN_GUEST_HANDLE_PARAM(xen_mem_access_op_t) arg);
#else
@@ -88,7 +88,7 @@ int mem_access_memop(unsigned long cmd,
{
return -ENOSYS;
}
-#endif /* CONFIG_HAS_MEM_ACCESS */
+#endif /* CONFIG_MEM_ACCESS */
#endif /* _XEN_MEM_ACCESS_H */
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index ff6b2db..b0ac1f6 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -584,7 +584,7 @@ static XSM_INLINE int xsm_vm_event_control(XSM_DEFAULT_ARG struct domain *d, int
return xsm_default_action(action, current->domain, d);
}
-#ifdef CONFIG_HAS_MEM_ACCESS
+#ifdef CONFIG_MEM_ACCESS
static XSM_INLINE int xsm_mem_access(XSM_DEFAULT_ARG struct domain *d)
{
XSM_ASSERT_ACTION(XSM_DM_PRIV);
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index f0c6fc7..7636bcb 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -143,7 +143,7 @@ struct xsm_operations {
int (*vm_event_control) (struct domain *d, int mode, int op);
-#ifdef CONFIG_HAS_MEM_ACCESS
+#ifdef CONFIG_MEM_ACCESS
int (*mem_access) (struct domain *d);
#endif
@@ -582,7 +582,7 @@ static inline int xsm_vm_event_control (xsm_default_t def, struct domain *d, int
return xsm_ops->vm_event_control(d, mode, op);
}
-#ifdef CONFIG_HAS_MEM_ACCESS
+#ifdef CONFIG_MEM_ACCESS
static inline int xsm_mem_access (xsm_default_t def, struct domain *d)
{
return xsm_ops->mem_access(d);
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 6e75119..3290d04 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -127,7 +127,7 @@ void __init xsm_fixup_ops (struct xsm_operations *ops)
set_to_dummy_if_null(ops, vm_event_control);
-#ifdef CONFIG_HAS_MEM_ACCESS
+#ifdef CONFIG_MEM_ACCESS
set_to_dummy_if_null(ops, mem_access);
#endif
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 78bc326..7a3ccfa 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1256,7 +1256,7 @@ static int flask_vm_event_control(struct domain *d, int mode, int op)
return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__VM_EVENT);
}
-#ifdef CONFIG_HAS_MEM_ACCESS
+#ifdef CONFIG_MEM_ACCESS
static int flask_mem_access(struct domain *d)
{
return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__MEM_ACCESS);
@@ -1803,7 +1803,7 @@ static struct xsm_operations flask_ops = {
.vm_event_control = flask_vm_event_control,
-#ifdef CONFIG_HAS_MEM_ACCESS
+#ifdef CONFIG_MEM_ACCESS
.mem_access = flask_mem_access,
#endif
--
1.9.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 33+ messages in thread* Re: [PATCH v3 04/10] Make MEM_ACCESS configurable
2018-05-23 0:25 ` [PATCH v3 04/10] Make MEM_ACCESS configurable Stefano Stabellini
@ 2018-05-29 11:50 ` Jan Beulich
2018-05-30 20:24 ` Stefano Stabellini
0 siblings, 1 reply; 33+ messages in thread
From: Jan Beulich @ 2018-05-29 11:50 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Artem Mygaiev, Lars Kurth, Wei Liu, George Dunlap, Andrew Cooper,
Ian Jackson, xen-devel, Julien Grall, Tim Deegan, andrii_anisov,
Dario Faggioli
>>> On 23.05.18 at 02:25, <sstabellini@kernel.org> wrote:
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -26,6 +26,9 @@ config ARCH_DEFCONFIG
> default "arch/arm/configs/arm32_defconfig" if ARM_32
> default "arch/arm/configs/arm64_defconfig" if ARM_64
>
> +config HAS_MEM_ACCESS
> + def_bool y
The more that you're not deleting the respective select-s, please
don't introduce such per-arch. Keep the arch-neutral one, ...
> @@ -30,6 +31,12 @@ config ARCH_DEFCONFIG
> string
> default "arch/x86/configs/x86_64_defconfig"
>
> +config HAS_MEM_ACCESS
> + def_bool y
> +
> +config MEM_ACCESS_ALWAYS_ON
> + def_bool y
... make this one similarly an arch-neutral one (select-ed further up
in this file).
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -20,8 +20,15 @@ config HAS_DEVICE_TREE
> config HAS_EX_TABLE
> bool
>
> -config HAS_MEM_ACCESS
> +config MEM_ACCESS
> bool
> + prompt "Memory Access and VM events" if !MEM_ACCESS_ALWAYS_ON
> + default y
Please combine bool and default to def_bool. Also - do we perhaps want the
prompt to additionally have an EXPERT dependency? Without you saying why
you want this configurable I can't tell whether this would make sense.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v3 04/10] Make MEM_ACCESS configurable
2018-05-29 11:50 ` Jan Beulich
@ 2018-05-30 20:24 ` Stefano Stabellini
2018-05-30 22:19 ` Tamas K Lengyel
2018-06-01 7:30 ` Jan Beulich
0 siblings, 2 replies; 33+ messages in thread
From: Stefano Stabellini @ 2018-05-30 20:24 UTC (permalink / raw)
To: Jan Beulich
Cc: Artem Mygaiev, Lars Kurth, Stefano Stabellini, Wei Liu,
George Dunlap, Andrew Cooper, Ian Jackson, xen-devel,
Julien Grall, Tim Deegan, andrii_anisov, Dario Faggioli
On Tue, 29 May 2018, Jan Beulich wrote:
> >>> On 23.05.18 at 02:25, <sstabellini@kernel.org> wrote:
> > --- a/xen/arch/arm/Kconfig
> > +++ b/xen/arch/arm/Kconfig
> > @@ -26,6 +26,9 @@ config ARCH_DEFCONFIG
> > default "arch/arm/configs/arm32_defconfig" if ARM_32
> > default "arch/arm/configs/arm64_defconfig" if ARM_64
> >
> > +config HAS_MEM_ACCESS
> > + def_bool y
>
> The more that you're not deleting the respective select-s, please
> don't introduce such per-arch. Keep the arch-neutral one, ...
OK
> > @@ -30,6 +31,12 @@ config ARCH_DEFCONFIG
> > string
> > default "arch/x86/configs/x86_64_defconfig"
> >
> > +config HAS_MEM_ACCESS
> > + def_bool y
> > +
> > +config MEM_ACCESS_ALWAYS_ON
> > + def_bool y
>
> ... make this one similarly an arch-neutral one (select-ed further up
> in this file).
OK
> > --- a/xen/common/Kconfig
> > +++ b/xen/common/Kconfig
> > @@ -20,8 +20,15 @@ config HAS_DEVICE_TREE
> > config HAS_EX_TABLE
> > bool
> >
> > -config HAS_MEM_ACCESS
> > +config MEM_ACCESS
> > bool
> > + prompt "Memory Access and VM events" if !MEM_ACCESS_ALWAYS_ON
> > + default y
>
> Please combine bool and default to def_bool.
OK
> Also - do we perhaps want the
> prompt to additionally have an EXPERT dependency? Without you saying why
> you want this configurable I can't tell whether this would make sense.
I am doing this mostly to reduce the code size. I think we should
security support configurations without MEM_ACCESS. I also don't think
it should take an "expert" to disable MEM_ACCESS in Xen. Thus, my
preference is to avoid adding the EXPERT dependency.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v3 04/10] Make MEM_ACCESS configurable
2018-05-30 20:24 ` Stefano Stabellini
@ 2018-05-30 22:19 ` Tamas K Lengyel
2018-06-01 7:30 ` Jan Beulich
1 sibling, 0 replies; 33+ messages in thread
From: Tamas K Lengyel @ 2018-05-30 22:19 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Artem Mygaiev, Lars Kurth, Wei Liu, George Dunlap, Andrew Cooper,
Ian Jackson, Xen-devel, Julien Grall, Tim Deegan, Jan Beulich,
andrii_anisov, Dario Faggioli
On Wed, May 30, 2018 at 2:24 PM, Stefano Stabellini
<sstabellini@kernel.org> wrote:
> On Tue, 29 May 2018, Jan Beulich wrote:
>> >>> On 23.05.18 at 02:25, <sstabellini@kernel.org> wrote:
>> > --- a/xen/arch/arm/Kconfig
>> > +++ b/xen/arch/arm/Kconfig
>> > @@ -26,6 +26,9 @@ config ARCH_DEFCONFIG
>> > default "arch/arm/configs/arm32_defconfig" if ARM_32
>> > default "arch/arm/configs/arm64_defconfig" if ARM_64
>> >
>> > +config HAS_MEM_ACCESS
>> > + def_bool y
>>
>> The more that you're not deleting the respective select-s, please
>> don't introduce such per-arch. Keep the arch-neutral one, ...
>
> OK
>
>
>> > @@ -30,6 +31,12 @@ config ARCH_DEFCONFIG
>> > string
>> > default "arch/x86/configs/x86_64_defconfig"
>> >
>> > +config HAS_MEM_ACCESS
>> > + def_bool y
>> > +
>> > +config MEM_ACCESS_ALWAYS_ON
>> > + def_bool y
>>
>> ... make this one similarly an arch-neutral one (select-ed further up
>> in this file).
>
> OK
>
>
>> > --- a/xen/common/Kconfig
>> > +++ b/xen/common/Kconfig
>> > @@ -20,8 +20,15 @@ config HAS_DEVICE_TREE
>> > config HAS_EX_TABLE
>> > bool
>> >
>> > -config HAS_MEM_ACCESS
>> > +config MEM_ACCESS
>> > bool
>> > + prompt "Memory Access and VM events" if !MEM_ACCESS_ALWAYS_ON
>> > + default y
>>
>> Please combine bool and default to def_bool.
>
> OK
>
>
>> Also - do we perhaps want the
>> prompt to additionally have an EXPERT dependency? Without you saying why
>> you want this configurable I can't tell whether this would make sense.
>
> I am doing this mostly to reduce the code size. I think we should
> security support configurations without MEM_ACCESS. I also don't think
> it should take an "expert" to disable MEM_ACCESS in Xen. Thus, my
> preference is to avoid adding the EXPERT dependency.
IMHO for ARM mem_access can be off by default. It is still experimental.
Tamas
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v3 04/10] Make MEM_ACCESS configurable
2018-05-30 20:24 ` Stefano Stabellini
2018-05-30 22:19 ` Tamas K Lengyel
@ 2018-06-01 7:30 ` Jan Beulich
1 sibling, 0 replies; 33+ messages in thread
From: Jan Beulich @ 2018-06-01 7:30 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Artem Mygaiev, Lars Kurth, Wei Liu, George Dunlap, Andrew Cooper,
Ian Jackson, xen-devel, Julien Grall, Tim Deegan, andrii_anisov,
Dario Faggioli
>>> On 30.05.18 at 22:24, <sstabellini@kernel.org> wrote:
> On Tue, 29 May 2018, Jan Beulich wrote:
>> Also - do we perhaps want the
>> prompt to additionally have an EXPERT dependency? Without you saying why
>> you want this configurable I can't tell whether this would make sense.
>
> I am doing this mostly to reduce the code size. I think we should
> security support configurations without MEM_ACCESS. I also don't think
> it should take an "expert" to disable MEM_ACCESS in Xen. Thus, my
> preference is to avoid adding the EXPERT dependency.
Well, okay, but please spell this out in the commit message.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* [PATCH v3 05/10] make it possible to enable/disable UART drivers
2018-05-23 0:24 [PATCH v3 0/10] arm: more kconfig configurability and small default configs Stefano Stabellini
` (3 preceding siblings ...)
2018-05-23 0:25 ` [PATCH v3 04/10] Make MEM_ACCESS configurable Stefano Stabellini
@ 2018-05-23 0:25 ` Stefano Stabellini
2018-05-29 12:02 ` Jan Beulich
2018-05-23 0:25 ` [PATCH v3 06/10] xen: remove HAS_ prefix from UART Kconfig options Stefano Stabellini
` (4 subsequent siblings)
9 siblings, 1 reply; 33+ messages in thread
From: Stefano Stabellini @ 2018-05-23 0:25 UTC (permalink / raw)
To: julien.grall
Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov,
andrew.cooper3, dfaggioli, jbeulich, xen-devel
All the UART drivers are silent options. Add one line descriptions so
that can be de/selected via menuconfig.
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
CC: jbeulich@suse.com
CC: andrew.cooper3@citrix.com
---
The next patch will take care of fixing arch dependencies.
Changes in v3:
- NS16550 prompt if ARM
Changes in v2:
- make HAS_EHCI depend on x86
---
xen/drivers/char/Kconfig | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index cc78ec3..c8f30b8 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -1,11 +1,11 @@
config HAS_NS16550
- bool
+ bool "NS16550 UART driver" if ARM
default y
help
This selects the 16550-series UART support. For most systems, say Y.
config HAS_CADENCE_UART
- bool
+ bool "Xilinx Cadence UART driver"
default y
depends on ARM_64
help
@@ -13,7 +13,7 @@ config HAS_CADENCE_UART
based board, say Y.
config HAS_MVEBU
- bool
+ bool "Marvell MVEBU UART driver"
default y
depends on ARM_64
help
@@ -21,7 +21,7 @@ config HAS_MVEBU
based board, say Y.
config HAS_PL011
- bool
+ bool "ARM PL011 UART driver"
default y
depends on ARM
help
@@ -29,7 +29,7 @@ config HAS_PL011
an Integrator/PP2, Integrator/CP or Versatile platform, say Y.
config HAS_EXYNOS4210
- bool
+ bool "Samsung Exynos 4210 UART driver"
default y
depends on ARM_32
help
@@ -37,7 +37,7 @@ config HAS_EXYNOS4210
Exynos based board, say Y.
config HAS_OMAP
- bool
+ bool "Texas Instruments OMAP UART driver"
default y
depends on ARM_32
help
@@ -45,7 +45,7 @@ config HAS_OMAP
Instruments based CPU, say Y.
config HAS_SCIF
- bool
+ bool "SuperH SCI(F) UART driver"
default y
depends on ARM
help
@@ -53,7 +53,8 @@ config HAS_SCIF
or Renesas R-Car Gen 2/3 based board say Y.
config HAS_EHCI
- bool
+ bool "EHCI UART driver"
+ depends on X86
help
This selects the USB based EHCI debug port to be used as a UART. If
you have an x86 based system with USB, say Y.
--
1.9.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 33+ messages in thread* Re: [PATCH v3 05/10] make it possible to enable/disable UART drivers
2018-05-23 0:25 ` [PATCH v3 05/10] make it possible to enable/disable UART drivers Stefano Stabellini
@ 2018-05-29 12:02 ` Jan Beulich
0 siblings, 0 replies; 33+ messages in thread
From: Jan Beulich @ 2018-05-29 12:02 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Artem Mygaiev, Lars Kurth, andrii_anisov, Andrew Cooper,
xen-devel, Julien Grall, Dario Faggioli
>>> On 23.05.18 at 02:25, <sstabellini@kernel.org> wrote:
> @@ -53,7 +53,8 @@ config HAS_SCIF
> or Renesas R-Car Gen 2/3 based board say Y.
>
> config HAS_EHCI
> - bool
> + bool "EHCI UART driver"
> + depends on X86
The added dependency needs explaining in the commit message. And I'm
sure we've settled on this not gaining a prompt in a prior review round.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* [PATCH v3 06/10] xen: remove HAS_ prefix from UART Kconfig options
2018-05-23 0:24 [PATCH v3 0/10] arm: more kconfig configurability and small default configs Stefano Stabellini
` (4 preceding siblings ...)
2018-05-23 0:25 ` [PATCH v3 05/10] make it possible to enable/disable UART drivers Stefano Stabellini
@ 2018-05-23 0:25 ` Stefano Stabellini
2018-05-29 12:06 ` Jan Beulich
2018-05-23 0:25 ` [PATCH v3 07/10] arm: make it possible to disable the SMMU driver Stefano Stabellini
` (3 subsequent siblings)
9 siblings, 1 reply; 33+ messages in thread
From: Stefano Stabellini @ 2018-05-23 0:25 UTC (permalink / raw)
To: julien.grall
Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov,
George.Dunlap, andrew.cooper3, ian.jackson, dfaggioli, tim,
jbeulich, wei.liu2, xen-devel
UART drivers are now selectable by the user. To mark the change, remove
the HAS_ prefix.
Use HAS_* options to mark which options are available on which
architecture. Use HAS_*_ALWAYS_ON options to mark which options are
silent and always enabled on a given architecture.
Make NS16550 and EHCI silent and always enabled on x86.
Make all the others selectable on ARM, default on.
Suggested-by: Julien Grall <julien.grall@arm.com>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
CC: andrew.cooper3@citrix.com
CC: George.Dunlap@eu.citrix.com
CC: ian.jackson@eu.citrix.com
CC: jbeulich@suse.com
CC: julien.grall@arm.com
CC: konrad.wilk@oracle.com
CC: sstabellini@kernel.org
CC: tim@xen.org
CC: wei.liu2@citrix.com
---
Changes in v3:
- use HAS_* options to mark which options are available on which arch
- use HAS_*_ALWAYS_ON options to mark which options are silent and
always enabled on a given arch
- mark UART appropriately on x86 and arm
- remove HAS_ prefix everywhere else
Changes in v2:
- patch added
---
tools/firmware/xen-dir/shim.config | 2 +-
xen/arch/arm/Kconfig | 28 ++++++++++++++++++++++++++
xen/arch/x86/Kconfig | 14 +++++++++++++
xen/drivers/char/Kconfig | 41 ++++++++++++++++++++++----------------
xen/drivers/char/Makefile | 16 +++++++--------
5 files changed, 75 insertions(+), 26 deletions(-)
diff --git a/tools/firmware/xen-dir/shim.config b/tools/firmware/xen-dir/shim.config
index 21d7075..d3a40e7 100644
--- a/tools/firmware/xen-dir/shim.config
+++ b/tools/firmware/xen-dir/shim.config
@@ -63,7 +63,7 @@ CONFIG_ACPI=y
CONFIG_ACPI_LEGACY_TABLES_LOOKUP=y
CONFIG_NUMA=y
CONFIG_HAS_NS16550=y
-CONFIG_HAS_EHCI=y
+CONFIG_EHCI=y
CONFIG_HAS_CPUFREQ=y
CONFIG_HAS_PASSTHROUGH=y
CONFIG_HAS_PCI=y
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 164cdc3..a5a6943 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -20,6 +20,13 @@ config ARM
select HAS_MEM_ACCESS
select HAS_PASSTHROUGH
select HAS_PDX
+ select HAS_NS16550
+ select HAS_CADENCE_UART
+ select HAS_MVEBU
+ select HAS_PL011
+ select HAS_EXYNOS4210
+ select HAS_OMAP
+ select HAS_SCIF
config ARCH_DEFCONFIG
string
@@ -29,6 +36,27 @@ config ARCH_DEFCONFIG
config HAS_MEM_ACCESS
def_bool y
+config HAS_NS16550
+ def_bool y
+
+config HAS_CADENCE_UART
+ def_bool y
+
+config HAS_MVEBU
+ def_bool y
+
+config HAS_PL011
+ def_bool y
+
+config HAS_EXYNOS4210
+ def_bool y
+
+config HAS_OMAP
+ def_bool y
+
+config HAS_SCIF
+ def_bool y
+
menu "Architecture Features"
source "arch/Kconfig"
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 0c49d71..e69f5ac 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -11,6 +11,7 @@ config X86
select HAS_ALTERNATIVE
select HAS_CPUFREQ
select HAS_EHCI
+ select HAS_EHCI_ALWAYS_ON
select HAS_EX_TABLE
select HAS_GDBSX
select HAS_IOPORTS
@@ -20,6 +21,7 @@ config X86
select HAS_MEM_PAGING
select HAS_MEM_SHARING
select HAS_NS16550
+ select HAS_NS16550_ALWAYS_ON
select HAS_PASSTHROUGH
select HAS_PCI
select HAS_PDX
@@ -37,6 +39,18 @@ config HAS_MEM_ACCESS
config MEM_ACCESS_ALWAYS_ON
def_bool y
+config HAS_NS16550
+ def_bool y
+
+config HAS_NS16550_ALWAYS_ON
+ def_bool y
+
+config HAS_EHCI
+ def_bool y
+
+config HAS_EHCI_ALWAYS_ON
+ def_bool y
+
menu "Architecture Features"
source "arch/Kconfig"
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index c8f30b8..7204d38 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -1,60 +1,67 @@
-config HAS_NS16550
- bool "NS16550 UART driver" if ARM
+config NS16550
+ bool "NS16550 UART driver" if !HAS_NS16550_ALWAYS_ON
+ depends on HAS_NS16550
default y
help
This selects the 16550-series UART support. For most systems, say Y.
-config HAS_CADENCE_UART
- bool "Xilinx Cadence UART driver"
+config CADENCE_UART
+ bool "Xilinx Cadence UART driver" if !HAS_CADENCE_UART_ALWAYS_ON
+ depends on HAS_CADENCE_UART
default y
depends on ARM_64
help
This selects the Xilinx Zynq Cadence UART. If you have a Xilinx Zynq
based board, say Y.
-config HAS_MVEBU
- bool "Marvell MVEBU UART driver"
+config MVEBU
+ bool "Marvell MVEBU UART driver" if !HAS_MVEBU_ALWAYS_ON
+ depends on HAS_MVEBU
default y
depends on ARM_64
help
This selects the Marvell MVEBU UART. If you have a ARMADA 3700
based board, say Y.
-config HAS_PL011
- bool "ARM PL011 UART driver"
+config PL011
+ bool "ARM PL011 UART driver" if !HAS_PL011_ALWAYS_ON
+ depends on HAS_PL011
default y
depends on ARM
help
This selects the ARM(R) AMBA(R) PrimeCell PL011 UART. If you have
an Integrator/PP2, Integrator/CP or Versatile platform, say Y.
-config HAS_EXYNOS4210
- bool "Samsung Exynos 4210 UART driver"
+config EXYNOS4210
+ bool "Samsung Exynos 4210 UART driver" if !HAS_EXYNOS4210_ALWAYS_ON
+ depends on HAS_EXYNOS4210
default y
depends on ARM_32
help
This selects the Samsung Exynos 4210 UART. If you have a Samsung
Exynos based board, say Y.
-config HAS_OMAP
- bool "Texas Instruments OMAP UART driver"
+config OMAP
+ bool "Texas Instruments OMAP UART driver" if !HAS_OMAP_ALWAYS_ON
+ depends on HAS_OMAP
default y
depends on ARM_32
help
This selects the Texas Instruments OMAP UART. If you have a Texas
Instruments based CPU, say Y.
-config HAS_SCIF
- bool "SuperH SCI(F) UART driver"
+config SCIF
+ bool "SuperH SCI(F) UART driver" if !HAS_SCIF_ALWAYS_ON
+ depends on HAS_SCIF
default y
depends on ARM
help
This selects the SuperH SCI(F) UART. If you have a SuperH based board,
or Renesas R-Car Gen 2/3 based board say Y.
-config HAS_EHCI
- bool "EHCI UART driver"
- depends on X86
+config EHCI
+ bool "EHCI UART driver" if !HAS_EHCI_ALWAYS_ON
+ depends on HAS_EHCI
help
This selects the USB based EHCI debug port to be used as a UART. If
you have an x86 based system with USB, say Y.
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index b68c330..94014c3 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -1,12 +1,12 @@
obj-y += console.o
-obj-$(CONFIG_HAS_NS16550) += ns16550.o
-obj-$(CONFIG_HAS_CADENCE_UART) += cadence-uart.o
-obj-$(CONFIG_HAS_PL011) += pl011.o
-obj-$(CONFIG_HAS_EXYNOS4210) += exynos4210-uart.o
-obj-$(CONFIG_HAS_MVEBU) += mvebu-uart.o
-obj-$(CONFIG_HAS_OMAP) += omap-uart.o
-obj-$(CONFIG_HAS_SCIF) += scif-uart.o
-obj-$(CONFIG_HAS_EHCI) += ehci-dbgp.o
+obj-$(CONFIG_NS16550) += ns16550.o
+obj-$(CONFIG_CADENCE_UART) += cadence-uart.o
+obj-$(CONFIG_PL011) += pl011.o
+obj-$(CONFIG_EXYNOS4210) += exynos4210-uart.o
+obj-$(CONFIG_MVEBU) += mvebu-uart.o
+obj-$(CONFIG_OMAP) += omap-uart.o
+obj-$(CONFIG_SCIF) += scif-uart.o
+obj-$(CONFIG_EHCI) += ehci-dbgp.o
obj-$(CONFIG_ARM) += arm-uart.o
obj-y += serial.o
obj-$(CONFIG_XEN_GUEST) += xen_pv_console.o
--
1.9.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 33+ messages in thread* Re: [PATCH v3 06/10] xen: remove HAS_ prefix from UART Kconfig options
2018-05-23 0:25 ` [PATCH v3 06/10] xen: remove HAS_ prefix from UART Kconfig options Stefano Stabellini
@ 2018-05-29 12:06 ` Jan Beulich
2018-05-30 20:33 ` Stefano Stabellini
0 siblings, 1 reply; 33+ messages in thread
From: Jan Beulich @ 2018-05-29 12:06 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Artem Mygaiev, Lars Kurth, Wei Liu, George Dunlap, Andrew Cooper,
Ian Jackson, xen-devel, Julien Grall, Tim Deegan, andrii_anisov,
Dario Faggioli
>>> On 23.05.18 at 02:25, <sstabellini@kernel.org> wrote:
> UART drivers are now selectable by the user. To mark the change, remove
> the HAS_ prefix.
I'm not sure we need to go this far at this point - for MEM_ACCESS this
looks reasonable, but here it looks more like clutter to me.
> Use HAS_* options to mark which options are available on which
> architecture. Use HAS_*_ALWAYS_ON options to mark which options are
> silent and always enabled on a given architecture.
>
> Make NS16550 and EHCI silent and always enabled on x86.
> Make all the others selectable on ARM, default on.
Is this last paragraph mostly stale now, with the previous patch
having most (and supposedly all) of this already?
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -20,6 +20,13 @@ config ARM
> select HAS_MEM_ACCESS
> select HAS_PASSTHROUGH
> select HAS_PDX
> + select HAS_NS16550
> + select HAS_CADENCE_UART
> + select HAS_MVEBU
> + select HAS_PL011
> + select HAS_EXYNOS4210
> + select HAS_OMAP
> + select HAS_SCIF
>
> config ARCH_DEFCONFIG
> string
> @@ -29,6 +36,27 @@ config ARCH_DEFCONFIG
> config HAS_MEM_ACCESS
> def_bool y
>
> +config HAS_NS16550
> + def_bool y
> +
> +config HAS_CADENCE_UART
> + def_bool y
> +
> +config HAS_MVEBU
> + def_bool y
> +
> +config HAS_PL011
> + def_bool y
> +
> +config HAS_EXYNOS4210
> + def_bool y
> +
> +config HAS_OMAP
> + def_bool y
> +
> +config HAS_SCIF
> + def_bool y
Either select plus just bool, or "def_bool y". But see my comment on
MEM_ACCESS - if others think this patch is worthwhile, I'd prefer if
things here were done that same way.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v3 06/10] xen: remove HAS_ prefix from UART Kconfig options
2018-05-29 12:06 ` Jan Beulich
@ 2018-05-30 20:33 ` Stefano Stabellini
0 siblings, 0 replies; 33+ messages in thread
From: Stefano Stabellini @ 2018-05-30 20:33 UTC (permalink / raw)
To: Jan Beulich
Cc: Artem Mygaiev, Lars Kurth, Stefano Stabellini, Wei Liu,
George Dunlap, Andrew Cooper, Ian Jackson, xen-devel,
Julien Grall, Tim Deegan, andrii_anisov, Dario Faggioli
On Tue, 29 May 2018, Jan Beulich wrote:
> >>> On 23.05.18 at 02:25, <sstabellini@kernel.org> wrote:
> > UART drivers are now selectable by the user. To mark the change, remove
> > the HAS_ prefix.
>
> I'm not sure we need to go this far at this point - for MEM_ACCESS this
> looks reasonable, but here it looks more like clutter to me.
Fair enough, I drop this patch.
> > Use HAS_* options to mark which options are available on which
> > architecture. Use HAS_*_ALWAYS_ON options to mark which options are
> > silent and always enabled on a given architecture.
> >
> > Make NS16550 and EHCI silent and always enabled on x86.
> > Make all the others selectable on ARM, default on.
>
> Is this last paragraph mostly stale now, with the previous patch
> having most (and supposedly all) of this already?
>
> > --- a/xen/arch/arm/Kconfig
> > +++ b/xen/arch/arm/Kconfig
> > @@ -20,6 +20,13 @@ config ARM
> > select HAS_MEM_ACCESS
> > select HAS_PASSTHROUGH
> > select HAS_PDX
> > + select HAS_NS16550
> > + select HAS_CADENCE_UART
> > + select HAS_MVEBU
> > + select HAS_PL011
> > + select HAS_EXYNOS4210
> > + select HAS_OMAP
> > + select HAS_SCIF
> >
> > config ARCH_DEFCONFIG
> > string
> > @@ -29,6 +36,27 @@ config ARCH_DEFCONFIG
> > config HAS_MEM_ACCESS
> > def_bool y
> >
> > +config HAS_NS16550
> > + def_bool y
> > +
> > +config HAS_CADENCE_UART
> > + def_bool y
> > +
> > +config HAS_MVEBU
> > + def_bool y
> > +
> > +config HAS_PL011
> > + def_bool y
> > +
> > +config HAS_EXYNOS4210
> > + def_bool y
> > +
> > +config HAS_OMAP
> > + def_bool y
> > +
> > +config HAS_SCIF
> > + def_bool y
>
> Either select plus just bool, or "def_bool y". But see my comment on
> MEM_ACCESS - if others think this patch is worthwhile, I'd prefer if
> things here were done that same way.
>
> Jan
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* [PATCH v3 07/10] arm: make it possible to disable the SMMU driver
2018-05-23 0:24 [PATCH v3 0/10] arm: more kconfig configurability and small default configs Stefano Stabellini
` (5 preceding siblings ...)
2018-05-23 0:25 ` [PATCH v3 06/10] xen: remove HAS_ prefix from UART Kconfig options Stefano Stabellini
@ 2018-05-23 0:25 ` Stefano Stabellini
2018-05-23 17:54 ` Andrii Anisov
` (2 more replies)
2018-05-23 0:25 ` [PATCH v3 08/10] arm: add a tiny kconfig configuration Stefano Stabellini
` (2 subsequent siblings)
9 siblings, 3 replies; 33+ messages in thread
From: Stefano Stabellini @ 2018-05-23 0:25 UTC (permalink / raw)
To: julien.grall
Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov, dfaggioli,
jbeulich, xen-devel
Introduce a Kconfig option for the ARM SMMUv1 and SMMUv2 driver.
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
CC: jbeulich@suse.com
---
Changes in v3:
- rename SMMUv2 to ARM_SMMU
- improve help message
- use if ARM
Changes in v2:
- rename HAS_SMMUv2 to SMMUv2
- move SMMUv2 to xen/drivers/passthrough/Kconfig
---
xen/drivers/passthrough/Kconfig | 12 ++++++++++++
xen/drivers/passthrough/arm/Makefile | 2 +-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/xen/drivers/passthrough/Kconfig b/xen/drivers/passthrough/Kconfig
index 8d90b67..a3c0649 100644
--- a/xen/drivers/passthrough/Kconfig
+++ b/xen/drivers/passthrough/Kconfig
@@ -1,3 +1,15 @@
config HAS_PASSTHROUGH
bool
+
+if ARM
+config ARM_SMMU
+ bool "ARM SMMUv1 and v2 driver"
+ default y
+ ---help---
+ Support for implementations of the ARM System MMU architecture
+ versions 1 and 2.
+
+ Say Y here if your SoC includes an IOMMU device implementing the
+ ARM SMMU architecture.
+endif
diff --git a/xen/drivers/passthrough/arm/Makefile b/xen/drivers/passthrough/arm/Makefile
index f4cd26e..0156431 100644
--- a/xen/drivers/passthrough/arm/Makefile
+++ b/xen/drivers/passthrough/arm/Makefile
@@ -1,2 +1,2 @@
obj-y += iommu.o
-obj-y += smmu.o
+obj-$(ARM_SMMU) += smmu.o
--
1.9.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 33+ messages in thread* Re: [PATCH v3 07/10] arm: make it possible to disable the SMMU driver
2018-05-23 0:25 ` [PATCH v3 07/10] arm: make it possible to disable the SMMU driver Stefano Stabellini
@ 2018-05-23 17:54 ` Andrii Anisov
2018-05-23 19:16 ` Stefano Stabellini
2018-05-29 12:07 ` Jan Beulich
2018-05-29 13:40 ` Julien Grall
2 siblings, 1 reply; 33+ messages in thread
From: Andrii Anisov @ 2018-05-23 17:54 UTC (permalink / raw)
To: Stefano Stabellini, julien.grall
Cc: artem_mygaiev, lars.kurth, dfaggioli, jbeulich, xen-devel
Hello Stefano,
On 23.05.18 03:25, Stefano Stabellini wrote:
> Introduce a Kconfig option for the ARM SMMUv1 and SMMUv2 driver.
>
> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
> CC: jbeulich@suse.com
>
> ---
> Changes in v3:
> - rename SMMUv2 to ARM_SMMU
> - improve help message
> - use if ARM
>
> Changes in v2:
> - rename HAS_SMMUv2 to SMMUv2
> - move SMMUv2 to xen/drivers/passthrough/Kconfig
> ---
> xen/drivers/passthrough/Kconfig | 12 ++++++++++++
> xen/drivers/passthrough/arm/Makefile | 2 +-
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/xen/drivers/passthrough/Kconfig b/xen/drivers/passthrough/Kconfig
> index 8d90b67..a3c0649 100644
> --- a/xen/drivers/passthrough/Kconfig
> +++ b/xen/drivers/passthrough/Kconfig
> @@ -1,3 +1,15 @@
>
> config HAS_PASSTHROUGH
> bool
> +
> +if ARM
> +config ARM_SMMU
> + bool "ARM SMMUv1 and v2 driver"
> + default y
Did you mean here "default n"? So in a platform selecting configs patch
you silently skipping it for QEMU and RCAR3, but enabling for MPSOC?
> + ---help---
> + Support for implementations of the ARM System MMU architecture
> + versions 1 and 2.
> +
> + Say Y here if your SoC includes an IOMMU device implementing the
> + ARM SMMU architecture.
> +endif
> diff --git a/xen/drivers/passthrough/arm/Makefile b/xen/drivers/passthrough/arm/Makefile
> index f4cd26e..0156431 100644
> --- a/xen/drivers/passthrough/arm/Makefile
> +++ b/xen/drivers/passthrough/arm/Makefile
> @@ -1,2 +1,2 @@
> obj-y += iommu.o
> -obj-y += smmu.o
> +obj-$(ARM_SMMU) += smmu.o
--
*Andrii Anisov*
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v3 07/10] arm: make it possible to disable the SMMU driver
2018-05-23 17:54 ` Andrii Anisov
@ 2018-05-23 19:16 ` Stefano Stabellini
2018-05-24 8:01 ` Andrii Anisov
0 siblings, 1 reply; 33+ messages in thread
From: Stefano Stabellini @ 2018-05-23 19:16 UTC (permalink / raw)
To: Andrii Anisov
Cc: artem_mygaiev, lars.kurth, Stefano Stabellini, dfaggioli,
julien.grall, jbeulich, xen-devel
On Wed, 23 May 2018, Andrii Anisov wrote:
> Hello Stefano,
>
>
> On 23.05.18 03:25, Stefano Stabellini wrote:
> > Introduce a Kconfig option for the ARM SMMUv1 and SMMUv2 driver.
> >
> > Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
> > CC: jbeulich@suse.com
> >
> > ---
> > Changes in v3:
> > - rename SMMUv2 to ARM_SMMU
> > - improve help message
> > - use if ARM
> >
> > Changes in v2:
> > - rename HAS_SMMUv2 to SMMUv2
> > - move SMMUv2 to xen/drivers/passthrough/Kconfig
> > ---
> > xen/drivers/passthrough/Kconfig | 12 ++++++++++++
> > xen/drivers/passthrough/arm/Makefile | 2 +-
> > 2 files changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/xen/drivers/passthrough/Kconfig
> > b/xen/drivers/passthrough/Kconfig
> > index 8d90b67..a3c0649 100644
> > --- a/xen/drivers/passthrough/Kconfig
> > +++ b/xen/drivers/passthrough/Kconfig
> > @@ -1,3 +1,15 @@
> > config HAS_PASSTHROUGH
> > bool
> > +
> > +if ARM
> > +config ARM_SMMU
> > + bool "ARM SMMUv1 and v2 driver"
> > + default y
> Did you mean here "default n"? So in a platform selecting configs patch you
> silently skipping it for QEMU and RCAR3, but enabling for MPSOC?
I meant "default y" because I am only trying to introduce the options
in this patch series, I am not trying to change the defaults (yet).
In any case, even with "default y" it works as intended if you start
from tiny.config.
1) cp arch/arm/configs/tiny.conf .config
2) make olddefconfig
3) make menuconfig -> select RCAR3
the results is that ARM_SMMU will be disabled because it is already
disabled in tiny.config and CONFIG_RCAR3 won't enable it.
> > + ---help---
> > + Support for implementations of the ARM System MMU architecture
> > + versions 1 and 2.
> > +
> > + Say Y here if your SoC includes an IOMMU device implementing the
> > + ARM SMMU architecture.
> > +endif
> > diff --git a/xen/drivers/passthrough/arm/Makefile
> > b/xen/drivers/passthrough/arm/Makefile
> > index f4cd26e..0156431 100644
> > --- a/xen/drivers/passthrough/arm/Makefile
> > +++ b/xen/drivers/passthrough/arm/Makefile
> > @@ -1,2 +1,2 @@
> > obj-y += iommu.o
> > -obj-y += smmu.o
> > +obj-$(ARM_SMMU) += smmu.o
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v3 07/10] arm: make it possible to disable the SMMU driver
2018-05-23 19:16 ` Stefano Stabellini
@ 2018-05-24 8:01 ` Andrii Anisov
0 siblings, 0 replies; 33+ messages in thread
From: Andrii Anisov @ 2018-05-24 8:01 UTC (permalink / raw)
To: Stefano Stabellini
Cc: artem_mygaiev, lars.kurth, xen-devel, julien.grall, jbeulich, dfaggioli
Hello Stefano,
On 23.05.18 22:16, Stefano Stabellini wrote:
> I meant "default y" because I am only trying to introduce the options
> in this patch series, I am not trying to change the defaults (yet).
>
> In any case, even with "default y" it works as intended if you start
> from tiny.config.
>
> 1) cp arch/arm/configs/tiny.conf .config
> 2) make olddefconfig
> 3) make menuconfig -> select RCAR3
>
> the results is that ARM_SMMU will be disabled because it is already
> disabled in tiny.config and CONFIG_RCAR3 won't enable it.
I've got the point.
Thank you.
--
*Andrii Anisov*
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v3 07/10] arm: make it possible to disable the SMMU driver
2018-05-23 0:25 ` [PATCH v3 07/10] arm: make it possible to disable the SMMU driver Stefano Stabellini
2018-05-23 17:54 ` Andrii Anisov
@ 2018-05-29 12:07 ` Jan Beulich
2018-05-29 13:40 ` Julien Grall
2 siblings, 0 replies; 33+ messages in thread
From: Jan Beulich @ 2018-05-29 12:07 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Artem Mygaiev, Lars Kurth, andrii_anisov, Dario Faggioli,
Julien Grall, xen-devel
>>> On 23.05.18 at 02:25, <sstabellini@kernel.org> wrote:
> Introduce a Kconfig option for the ARM SMMUv1 and SMMUv2 driver.
>
> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v3 07/10] arm: make it possible to disable the SMMU driver
2018-05-23 0:25 ` [PATCH v3 07/10] arm: make it possible to disable the SMMU driver Stefano Stabellini
2018-05-23 17:54 ` Andrii Anisov
2018-05-29 12:07 ` Jan Beulich
@ 2018-05-29 13:40 ` Julien Grall
2 siblings, 0 replies; 33+ messages in thread
From: Julien Grall @ 2018-05-29 13:40 UTC (permalink / raw)
To: Stefano Stabellini
Cc: artem_mygaiev, lars.kurth, andrii_anisov, dfaggioli, jbeulich, xen-devel
Hi Stefano,
On 23/05/18 01:25, Stefano Stabellini wrote:
> Introduce a Kconfig option for the ARM SMMUv1 and SMMUv2 driver.
>
> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Julien Grall <julien.grall@arm.com>
Cheers,
> CC: jbeulich@suse.com
>
> ---
> Changes in v3:
> - rename SMMUv2 to ARM_SMMU
> - improve help message
> - use if ARM
>
> Changes in v2:
> - rename HAS_SMMUv2 to SMMUv2
> - move SMMUv2 to xen/drivers/passthrough/Kconfig
> ---
> xen/drivers/passthrough/Kconfig | 12 ++++++++++++
> xen/drivers/passthrough/arm/Makefile | 2 +-
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/xen/drivers/passthrough/Kconfig b/xen/drivers/passthrough/Kconfig
> index 8d90b67..a3c0649 100644
> --- a/xen/drivers/passthrough/Kconfig
> +++ b/xen/drivers/passthrough/Kconfig
> @@ -1,3 +1,15 @@
>
> config HAS_PASSTHROUGH
> bool
> +
> +if ARM
> +config ARM_SMMU
> + bool "ARM SMMUv1 and v2 driver"
> + default y
> + ---help---
> + Support for implementations of the ARM System MMU architecture
> + versions 1 and 2.
> +
> + Say Y here if your SoC includes an IOMMU device implementing the
> + ARM SMMU architecture.
> +endif
> diff --git a/xen/drivers/passthrough/arm/Makefile b/xen/drivers/passthrough/arm/Makefile
> index f4cd26e..0156431 100644
> --- a/xen/drivers/passthrough/arm/Makefile
> +++ b/xen/drivers/passthrough/arm/Makefile
> @@ -1,2 +1,2 @@
> obj-y += iommu.o
> -obj-y += smmu.o
> +obj-$(ARM_SMMU) += smmu.o
>
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* [PATCH v3 08/10] arm: add a tiny kconfig configuration
2018-05-23 0:24 [PATCH v3 0/10] arm: more kconfig configurability and small default configs Stefano Stabellini
` (6 preceding siblings ...)
2018-05-23 0:25 ` [PATCH v3 07/10] arm: make it possible to disable the SMMU driver Stefano Stabellini
@ 2018-05-23 0:25 ` Stefano Stabellini
2018-05-23 0:25 ` [PATCH v3 09/10] arm: add QEMU, Rcar3 and MPSoC configs Stefano Stabellini
2018-05-23 0:25 ` [PATCH v3 10/10] xen: add cloc target Stefano Stabellini
9 siblings, 0 replies; 33+ messages in thread
From: Stefano Stabellini @ 2018-05-23 0:25 UTC (permalink / raw)
To: julien.grall
Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov, dfaggioli,
xen-devel
Add a tiny kconfig configuration. Enabled NULL and Credit schedulers.
Support only 4 cpus. It only carries non-default options (use make
olddefconfig to produce a complete .config file).
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
---
xen/arch/arm/configs/tiny.conf | 44 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
create mode 100644 xen/arch/arm/configs/tiny.conf
diff --git a/xen/arch/arm/configs/tiny.conf b/xen/arch/arm/configs/tiny.conf
new file mode 100644
index 0000000..13e67d2
--- /dev/null
+++ b/xen/arch/arm/configs/tiny.conf
@@ -0,0 +1,44 @@
+CONFIG_ARM_64=y
+CONFIG_ARM=y
+
+#
+# Architecture Features
+#
+CONFIG_NR_CPUS=4
+# CONFIG_GICV3 is not set
+# CONFIG_MEM_ACCESS is not set
+# CONFIG_SBSA_VUART_CONSOLE is not set
+
+#
+# Common Features
+#
+# CONFIG_TMEM is not set
+
+#
+# Schedulers
+#
+# CONFIG_SCHED_CREDIT2 is not set
+# CONFIG_SCHED_RTDS is not set
+# CONFIG_SCHED_ARINC653 is not set
+CONFIG_SCHED_NULL=y
+CONFIG_SCHED_NULL_DEFAULT=y
+CONFIG_SCHED_DEFAULT="null"
+# CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS is not set
+
+#
+# Device Drivers
+#
+# CONFIG_NS16550 is not set
+# CONFIG_CADENCE_UART is not set
+# CONFIG_MVEBU is not set
+# CONFIG_PL011 is not set
+# CONFIG_SCIF is not set
+# CONFIG_ARM_SMMU is not set
+
+#
+# Debugging Options
+#
+# CONFIG_DEBUG is not set
+# CONFIG_FRAME_POINTER is not set
+# CONFIG_VERBOSE_DEBUG is not set
+# CONFIG_SCRUB_DEBUG is not set
--
1.9.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 33+ messages in thread* [PATCH v3 09/10] arm: add QEMU, Rcar3 and MPSoC configs
2018-05-23 0:24 [PATCH v3 0/10] arm: more kconfig configurability and small default configs Stefano Stabellini
` (7 preceding siblings ...)
2018-05-23 0:25 ` [PATCH v3 08/10] arm: add a tiny kconfig configuration Stefano Stabellini
@ 2018-05-23 0:25 ` Stefano Stabellini
2018-05-29 14:07 ` Julien Grall
2018-05-23 0:25 ` [PATCH v3 10/10] xen: add cloc target Stefano Stabellini
9 siblings, 1 reply; 33+ messages in thread
From: Stefano Stabellini @ 2018-05-23 0:25 UTC (permalink / raw)
To: julien.grall
Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov, dfaggioli,
xen-devel, volodymyr_babchuk
Add a "Platform Support" menu with three umbrella kconfig options: QEMU,
RCAR3 and MPSOC. They enable the required options for their hardware
platform.
They are introduced for convience: the user will be able to simply open
the menu and enable the right config for her platform.
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
CC: artem_mygaiev@epam.com
CC: volodymyr_babchuk@epam.com
---
Note that this approach has a limitation: it is not possible to "select
a range". In other words, using tiny.config NR_CPUS is set to 4. It is
not possible to increase it to 8 from config RCAR3.
Suggestions are welcome.
---
xen/arch/arm/Kconfig | 2 ++
xen/arch/arm/platforms/Kconfig | 30 ++++++++++++++++++++++++++++++
2 files changed, 32 insertions(+)
create mode 100644 xen/arch/arm/platforms/Kconfig
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index a5a6943..b5ddd12 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -245,6 +245,8 @@ config ARM64_HARDEN_BRANCH_PREDICTOR
config ARM32_HARDEN_BRANCH_PREDICTOR
def_bool y if ARM_32 && HARDEN_BRANCH_PREDICTOR
+source "arch/arm/platforms/Kconfig"
+
source "common/Kconfig"
source "drivers/Kconfig"
diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig
new file mode 100644
index 0000000..0eafbef
--- /dev/null
+++ b/xen/arch/arm/platforms/Kconfig
@@ -0,0 +1,30 @@
+menu "Platform Support"
+
+config QEMU
+ bool "QEMU aarch virt machine support"
+ default n
+ depends on ARM_64
+ select GICv3
+ select PL011
+ ---help---
+ Enable all the required drivers for QEMU aarch64 virt emulated
+ machine.
+
+config RCAR3
+ bool "Renesas RCar3 support"
+ default n
+ depends on ARM_64
+ select SCIF
+ ---help---
+ Enable all the required drivers for Renesas RCar3
+
+config MPSOC
+ bool "Xilinx Ultrascale+ MPSoC support"
+ default n
+ depends on ARM_64
+ select CADENCE_UART
+ select ARM_SMMU
+ ---help---
+ Enable all the required drivers for Xilinx Ultrascale+ MPSoC
+
+endmenu
--
1.9.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 33+ messages in thread* Re: [PATCH v3 09/10] arm: add QEMU, Rcar3 and MPSoC configs
2018-05-23 0:25 ` [PATCH v3 09/10] arm: add QEMU, Rcar3 and MPSoC configs Stefano Stabellini
@ 2018-05-29 14:07 ` Julien Grall
2018-05-30 21:39 ` Stefano Stabellini
0 siblings, 1 reply; 33+ messages in thread
From: Julien Grall @ 2018-05-29 14:07 UTC (permalink / raw)
To: Stefano Stabellini
Cc: artem_mygaiev, lars.kurth, andrii_anisov, dfaggioli, xen-devel,
volodymyr_babchuk
Hi Stefano,
On 23/05/18 01:25, Stefano Stabellini wrote:
> Add a "Platform Support" menu with three umbrella kconfig options: QEMU,
> RCAR3 and MPSOC. They enable the required options for their hardware
> platform.
>
> They are introduced for convience: the user will be able to simply open
> the menu and enable the right config for her platform.
>
> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
> CC: artem_mygaiev@epam.com
> CC: volodymyr_babchuk@epam.com
>
> ---
> Note that this approach has a limitation: it is not possible to "select
> a range". In other words, using tiny.config NR_CPUS is set to 4. It is
> not possible to increase it to 8 from config RCAR3.
What you can do is:
config NR_CPUS
range ...
default "8" if (RCAR3)
default "x" if (QEMU)
default 64
This would imply to move NR_CPUS in arch/{arm,x86}/Kconfig.
This solution is not very nice, but at least would provide a better
experience to the user.
>
> Suggestions are welcome.
> ---
> xen/arch/arm/Kconfig | 2 ++
> xen/arch/arm/platforms/Kconfig | 30 ++++++++++++++++++++++++++++++
> 2 files changed, 32 insertions(+)
> create mode 100644 xen/arch/arm/platforms/Kconfig
>
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index a5a6943..b5ddd12 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -245,6 +245,8 @@ config ARM64_HARDEN_BRANCH_PREDICTOR
> config ARM32_HARDEN_BRANCH_PREDICTOR
> def_bool y if ARM_32 && HARDEN_BRANCH_PREDICTOR
>
> +source "arch/arm/platforms/Kconfig"
> +
> source "common/Kconfig"
>
> source "drivers/Kconfig"
> diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig
> new file mode 100644
> index 0000000..0eafbef
> --- /dev/null
> +++ b/xen/arch/arm/platforms/Kconfig
> @@ -0,0 +1,30 @@
> +menu "Platform Support"
> +
> +config QEMU
> + bool "QEMU aarch virt machine support"
> + default n
The default value is confusing here. The default .config will support
QEMU but not select that.
While I don't yet buy the argument, some users will also want to remove
platform specific code (Andrii suggest that). This would means by
default support for a specific platform will not be in Xen.
Furthermore, very likely, the end user will select either one board (e.g
automotive) or all of them (e.g distribution).
So I think it would be better to do a choice list:
- All -> Board support for all board added. Drivers selected by the user
- MPSOC -> Select board support for Xilinx + appropriate drivers
- RCAR3 -> Select board support for RCAR3 + appropriate drivers
The tiny.config would select ALL. This could then be refined by
selecting a specific platform.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: [PATCH v3 09/10] arm: add QEMU, Rcar3 and MPSoC configs
2018-05-29 14:07 ` Julien Grall
@ 2018-05-30 21:39 ` Stefano Stabellini
2018-05-30 22:38 ` Julien Grall
0 siblings, 1 reply; 33+ messages in thread
From: Stefano Stabellini @ 2018-05-30 21:39 UTC (permalink / raw)
To: Julien Grall
Cc: artem_mygaiev, lars.kurth, Stefano Stabellini, andrii_anisov,
dfaggioli, xen-devel, volodymyr_babchuk
On Tue, 29 May 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 23/05/18 01:25, Stefano Stabellini wrote:
> > Add a "Platform Support" menu with three umbrella kconfig options: QEMU,
> > RCAR3 and MPSOC. They enable the required options for their hardware
> > platform.
> >
> > They are introduced for convience: the user will be able to simply open
> > the menu and enable the right config for her platform.
> >
> > Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
> > CC: artem_mygaiev@epam.com
> > CC: volodymyr_babchuk@epam.com
> >
> > ---
> > Note that this approach has a limitation: it is not possible to "select
> > a range". In other words, using tiny.config NR_CPUS is set to 4. It is
> > not possible to increase it to 8 from config RCAR3.
>
> What you can do is:
>
> config NR_CPUS
> range ...
> default "8" if (RCAR3)
> default "x" if (QEMU)
> default 64
>
> This would imply to move NR_CPUS in arch/{arm,x86}/Kconfig.
>
> This solution is not very nice, but at least would provide a better experience
> to the user.
Unfortunately, make olddefconfig is executed automatically when make is
called, adding CONFIG_NR_CPUS=128. Thus, unless tiny.config has already
CONFIG_RCAR3 in it, the correct default won't be applied.
This suggestions only make sense if we introduce per-platform configs,
such as xen/arch/arm/configs/tiny-rcar3.config.
> > Suggestions are welcome.
> > ---
> > xen/arch/arm/Kconfig | 2 ++
> > xen/arch/arm/platforms/Kconfig | 30 ++++++++++++++++++++++++++++++
> > 2 files changed, 32 insertions(+)
> > create mode 100644 xen/arch/arm/platforms/Kconfig
> >
> > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> > index a5a6943..b5ddd12 100644
> > --- a/xen/arch/arm/Kconfig
> > +++ b/xen/arch/arm/Kconfig
> > @@ -245,6 +245,8 @@ config ARM64_HARDEN_BRANCH_PREDICTOR
> > config ARM32_HARDEN_BRANCH_PREDICTOR
> > def_bool y if ARM_32 && HARDEN_BRANCH_PREDICTOR
> > +source "arch/arm/platforms/Kconfig"
> > +
> > source "common/Kconfig"
> > source "drivers/Kconfig"
> > diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig
> > new file mode 100644
> > index 0000000..0eafbef
> > --- /dev/null
> > +++ b/xen/arch/arm/platforms/Kconfig
> > @@ -0,0 +1,30 @@
> > +menu "Platform Support"
> > +
> > +config QEMU
> > + bool "QEMU aarch virt machine support"
> > + default n
> The default value is confusing here. The default .config will support QEMU but
> not select that.
>
> While I don't yet buy the argument, some users will also want to remove
> platform specific code (Andrii suggest that). This would means by default
> support for a specific platform will not be in Xen.
>
> Furthermore, very likely, the end user will select either one board (e.g
> automotive) or all of them (e.g distribution).
>
> So I think it would be better to do a choice list:
> - All -> Board support for all board added. Drivers selected by the
> user
> - MPSOC -> Select board support for Xilinx + appropriate drivers
> - RCAR3 -> Select board support for RCAR3 + appropriate drivers
>
> The tiny.config would select ALL. This could then be refined by selecting a
> specific platform.
The idea of an "ALL" configuration is interesting, however, all the
options we would select under "ALL" already default to "Y". Effectively,
if we remove the following lines from tiny.config:
# CONFIG_GICV3 is not set
# CONFIG_MEM_ACCESS is not set
# CONFIG_SBSA_VUART_CONSOLE is not set
# CONFIG_HAS_NS16550 is not set
# CONFIG_HAS_CADENCE_UART is not set
# CONFIG_HAS_MVEBU is not set
# CONFIG_HAS_PL011 is not set
# CONFIG_HAS_SCIF is not set
# CONFIG_ARM_SMMU is not set
then, it would be as if tiny.config had CONFIG_ALL=y, because after
running `make olddefconfig' it would get all these options set to "Y".
Given that make olddefconfig is always executed automatically by make, I
cannot even remove the "is not set" options above from tiny.config
because otherwise they will all be automatically enabled always unless I
change all the defaults from Y to N.
In fact, the main issue is that it is not possible to deselect Kconfig
options using the Kconfig infrastructure. So, if a user has a
config with CONFIG_ALL in it, then she executes `make menuconfig'
to select RCAR3 and reduce the config size, the menu won't actually be
able to deselect any other option automatically. This is very
unfortunate. For instance, if the config has CADENCE_UART, and the user
selects CONFIG_RCAR3 from the menu, the resulting config will still have
CADENCE_UART, unless she goes to remove it by hand.
Given all this, I don't know if it is worth introducing CONFIG_ALL. I
could add something like:
+config ALL
+ bool "Support for all platforms"
+ default y
+ select GICv3
+ select HAS_NS16550
+ select HAS_CADENCE_UART
+ select HAS_PL011
+ select HAS_EXYNOS4210
+ select HAS_MVEBU
+ select HAS_OMAP
+ select HAS_SCIF
+ select ARM_SMMU
+ ---help---
+ Enable support for all platforms. Triggers the build of a larger Xen
+ binary but with more drivers.
+
+ If unsure, say Y.
but my preference would be to avoid it because it just duplicates the
default Y/N settings elsewhere.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: [PATCH v3 09/10] arm: add QEMU, Rcar3 and MPSoC configs
2018-05-30 21:39 ` Stefano Stabellini
@ 2018-05-30 22:38 ` Julien Grall
2018-05-31 21:38 ` Stefano Stabellini
0 siblings, 1 reply; 33+ messages in thread
From: Julien Grall @ 2018-05-30 22:38 UTC (permalink / raw)
To: Stefano Stabellini
Cc: artem_mygaiev, lars.kurth, xen-devel, andrii_anisov, dfaggioli,
nd, volodymyr_babchuk
On 30/05/2018 22:39, Stefano Stabellini wrote:
> On Tue, 29 May 2018, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 23/05/18 01:25, Stefano Stabellini wrote:
>>> Add a "Platform Support" menu with three umbrella kconfig options: QEMU,
>>> RCAR3 and MPSOC. They enable the required options for their hardware
>>> platform.
>>>
>>> They are introduced for convience: the user will be able to simply open
>>> the menu and enable the right config for her platform.
>>>
>>> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
>>> CC: artem_mygaiev@epam.com
>>> CC: volodymyr_babchuk@epam.com
>>>
>>> ---
>>> Note that this approach has a limitation: it is not possible to "select
>>> a range". In other words, using tiny.config NR_CPUS is set to 4. It is
>>> not possible to increase it to 8 from config RCAR3.
>>
>> What you can do is:
>>
>> config NR_CPUS
>> range ...
>> default "8" if (RCAR3)
>> default "x" if (QEMU)
>> default 64
>>
>> This would imply to move NR_CPUS in arch/{arm,x86}/Kconfig.
>>
>> This solution is not very nice, but at least would provide a better experience
>> to the user.
>
> Unfortunately, make olddefconfig is executed automatically when make is
> called, adding CONFIG_NR_CPUS=128. Thus, unless tiny.config has already
> CONFIG_RCAR3 in it, the correct default won't be applied.
>
> This suggestions only make sense if we introduce per-platform configs,
> such as xen/arch/arm/configs/tiny-rcar3.config.
The other solution is to introduce a new command (or script) that will
select the platform at the same time as olddefconfig.
This would avoid to create a config per board and still keeping only one
tiny config.
>
>
>>> Suggestions are welcome.
>>> ---
>>> xen/arch/arm/Kconfig | 2 ++
>>> xen/arch/arm/platforms/Kconfig | 30 ++++++++++++++++++++++++++++++
>>> 2 files changed, 32 insertions(+)
>>> create mode 100644 xen/arch/arm/platforms/Kconfig
>>>
>>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
>>> index a5a6943..b5ddd12 100644
>>> --- a/xen/arch/arm/Kconfig
>>> +++ b/xen/arch/arm/Kconfig
>>> @@ -245,6 +245,8 @@ config ARM64_HARDEN_BRANCH_PREDICTOR
>>> config ARM32_HARDEN_BRANCH_PREDICTOR
>>> def_bool y if ARM_32 && HARDEN_BRANCH_PREDICTOR
>>> +source "arch/arm/platforms/Kconfig"
>>> +
>>> source "common/Kconfig"
>>> source "drivers/Kconfig"
>>> diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig
>>> new file mode 100644
>>> index 0000000..0eafbef
>>> --- /dev/null
>>> +++ b/xen/arch/arm/platforms/Kconfig
>>> @@ -0,0 +1,30 @@
>>> +menu "Platform Support"
>>> +
>>> +config QEMU
>>> + bool "QEMU aarch virt machine support"
>>> + default n
>> The default value is confusing here. The default .config will support QEMU but
>> not select that.
>>
>> While I don't yet buy the argument, some users will also want to remove
>> platform specific code (Andrii suggest that). This would means by default
>> support for a specific platform will not be in Xen.
>>
>> Furthermore, very likely, the end user will select either one board (e.g
>> automotive) or all of them (e.g distribution).
>>
>> So I think it would be better to do a choice list:
>> - All -> Board support for all board added. Drivers selected by the
>> user
>> - MPSOC -> Select board support for Xilinx + appropriate drivers
>> - RCAR3 -> Select board support for RCAR3 + appropriate drivers
>>
>> The tiny.config would select ALL. This could then be refined by selecting a
>> specific platform.
>
> The idea of an "ALL" configuration is interesting, however, all the
> options we would select under "ALL" already default to "Y". Effectively,
> if we remove the following lines from tiny.config:
>
> # CONFIG_GICV3 is not set
> # CONFIG_MEM_ACCESS is not set
> # CONFIG_SBSA_VUART_CONSOLE is not set
> # CONFIG_HAS_NS16550 is not set
> # CONFIG_HAS_CADENCE_UART is not set
> # CONFIG_HAS_MVEBU is not set
> # CONFIG_HAS_PL011 is not set
> # CONFIG_HAS_SCIF is not set
> # CONFIG_ARM_SMMU is not set
>
> then, it would be as if tiny.config had CONFIG_ALL=y, because after
> running `make olddefconfig' it would get all these options set to "Y".
>
> Given that make olddefconfig is always executed automatically by make, I
> cannot even remove the "is not set" options above from tiny.config
> because otherwise they will all be automatically enabled always unless I
> change all the defaults from Y to N.
>
> In fact, the main issue is that it is not possible to deselect Kconfig
> options using the Kconfig infrastructure. So, if a user has a
> config with CONFIG_ALL in it, then she executes `make menuconfig'
> to select RCAR3 and reduce the config size, the menu won't actually be
> able to deselect any other option automatically. This is very
> unfortunate. For instance, if the config has CADENCE_UART, and the user
> selects CONFIG_RCAR3 from the menu, the resulting config will still have
> CADENCE_UART, unless she goes to remove it by hand.
>
> Given all this, I don't know if it is worth introducing CONFIG_ALL. I
> could add something like:
>
> +config ALL
> + bool "Support for all platforms"
> + default y
> + select GICv3
> + select HAS_NS16550
> + select HAS_CADENCE_UART
> + select HAS_PL011
> + select HAS_EXYNOS4210
> + select HAS_MVEBU
> + select HAS_OMAP
> + select HAS_SCIF
> + select ARM_SMMU
> + ---help---
> + Enable support for all platforms. Triggers the build of a larger Xen
> + binary but with more drivers.
> +
> + If unsure, say Y.
>
> but my preference would be to avoid it because it just duplicates the
> default Y/N settings elsewhere.
This is not what I suggested for all. What I suggested is the option All
will select all platforms/*.c file to build and does not select any
drivers. The user will have to chose the drivers. You can see it as a
"custom" option.
Also, by a list I meant:
config PLATFORM_RCAR3
...
choice
prompt "Machine"
default ....
config ALL
select PLATFORM_RCAR3
select PLATFORM_XILINX
config RCAR3
prompt "RCAR 3 support"
select PLATFORM_RCAR3
select HAS_PL011
select ...
endchoice.
The config PLATFORM_* would then be used in the Makefile
xen-$(CONFIG_PLATFORM_XILINX) += xilinx.o
...
I can also understand that there might be issue with the "All" option
hence why I suggested the "NONE" platform. This would select none of the
PLATFORM_*.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: [PATCH v3 09/10] arm: add QEMU, Rcar3 and MPSoC configs
2018-05-30 22:38 ` Julien Grall
@ 2018-05-31 21:38 ` Stefano Stabellini
2018-06-04 15:58 ` Julien Grall
0 siblings, 1 reply; 33+ messages in thread
From: Stefano Stabellini @ 2018-05-31 21:38 UTC (permalink / raw)
To: Julien Grall
Cc: artem_mygaiev, lars.kurth, nd, Stefano Stabellini, andrii_anisov,
dfaggioli, xen-devel, volodymyr_babchuk
On Wed, 30 May 2018, Julien Grall wrote:
> On 30/05/2018 22:39, Stefano Stabellini wrote:
> > On Tue, 29 May 2018, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 23/05/18 01:25, Stefano Stabellini wrote:
> > > > Add a "Platform Support" menu with three umbrella kconfig options: QEMU,
> > > > RCAR3 and MPSOC. They enable the required options for their hardware
> > > > platform.
> > > >
> > > > They are introduced for convience: the user will be able to simply open
> > > > the menu and enable the right config for her platform.
> > > >
> > > > Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
> > > > CC: artem_mygaiev@epam.com
> > > > CC: volodymyr_babchuk@epam.com
> > > >
> > > > ---
> > > > Note that this approach has a limitation: it is not possible to "select
> > > > a range". In other words, using tiny.config NR_CPUS is set to 4. It is
> > > > not possible to increase it to 8 from config RCAR3.
> > >
> > > What you can do is:
> > >
> > > config NR_CPUS
> > > range ...
> > > default "8" if (RCAR3)
> > > default "x" if (QEMU)
> > > default 64
> > >
> > > This would imply to move NR_CPUS in arch/{arm,x86}/Kconfig.
> > >
> > > This solution is not very nice, but at least would provide a better
> > > experience
> > > to the user.
> >
> > Unfortunately, make olddefconfig is executed automatically when make is
> > called, adding CONFIG_NR_CPUS=128. Thus, unless tiny.config has already
> > CONFIG_RCAR3 in it, the correct default won't be applied.
> >
> > This suggestions only make sense if we introduce per-platform configs,
> > such as xen/arch/arm/configs/tiny-rcar3.config.
>
> The other solution is to introduce a new command (or script) that will select
> the platform at the same time as olddefconfig.
>
> This would avoid to create a config per board and still keeping only one tiny
> config.
I am not looking forward to making changes to the kconfig commands, but
fortunately I was wrong on my previous reply: the issue was the order of
the defaults in the range! To fix the problem I just had to:
default "8" if ARM && RCAR3
default "4" if ARM && QEMU
default "4" if ARM && MPSOC
default "256" if X86
default "128" if ARM
> > > > Suggestions are welcome.
> > > > ---
> > > > xen/arch/arm/Kconfig | 2 ++
> > > > xen/arch/arm/platforms/Kconfig | 30 ++++++++++++++++++++++++++++++
> > > > 2 files changed, 32 insertions(+)
> > > > create mode 100644 xen/arch/arm/platforms/Kconfig
> > > >
> > > > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> > > > index a5a6943..b5ddd12 100644
> > > > --- a/xen/arch/arm/Kconfig
> > > > +++ b/xen/arch/arm/Kconfig
> > > > @@ -245,6 +245,8 @@ config ARM64_HARDEN_BRANCH_PREDICTOR
> > > > config ARM32_HARDEN_BRANCH_PREDICTOR
> > > > def_bool y if ARM_32 && HARDEN_BRANCH_PREDICTOR
> > > > +source "arch/arm/platforms/Kconfig"
> > > > +
> > > > source "common/Kconfig"
> > > > source "drivers/Kconfig"
> > > > diff --git a/xen/arch/arm/platforms/Kconfig
> > > > b/xen/arch/arm/platforms/Kconfig
> > > > new file mode 100644
> > > > index 0000000..0eafbef
> > > > --- /dev/null
> > > > +++ b/xen/arch/arm/platforms/Kconfig
> > > > @@ -0,0 +1,30 @@
> > > > +menu "Platform Support"
> > > > +
> > > > +config QEMU
> > > > + bool "QEMU aarch virt machine support"
> > > > + default n
> > > The default value is confusing here. The default .config will support QEMU
> > > but
> > > not select that.
> > >
> > > While I don't yet buy the argument, some users will also want to remove
> > > platform specific code (Andrii suggest that). This would means by default
> > > support for a specific platform will not be in Xen.
> > >
> > > Furthermore, very likely, the end user will select either one board (e.g
> > > automotive) or all of them (e.g distribution).
> > >
> > > So I think it would be better to do a choice list:
> > > - All -> Board support for all board added. Drivers selected by the
> > > user
> > > - MPSOC -> Select board support for Xilinx + appropriate drivers
> > > - RCAR3 -> Select board support for RCAR3 + appropriate drivers
> > >
> > > The tiny.config would select ALL. This could then be refined by selecting
> > > a
> > > specific platform.
> >
> > The idea of an "ALL" configuration is interesting, however, all the
> > options we would select under "ALL" already default to "Y". Effectively,
> > if we remove the following lines from tiny.config:
> >
> > # CONFIG_GICV3 is not set
> > # CONFIG_MEM_ACCESS is not set
> > # CONFIG_SBSA_VUART_CONSOLE is not set
> > # CONFIG_HAS_NS16550 is not set
> > # CONFIG_HAS_CADENCE_UART is not set
> > # CONFIG_HAS_MVEBU is not set
> > # CONFIG_HAS_PL011 is not set
> > # CONFIG_HAS_SCIF is not set
> > # CONFIG_ARM_SMMU is not set
> >
> > then, it would be as if tiny.config had CONFIG_ALL=y, because after
> > running `make olddefconfig' it would get all these options set to "Y".
> >
> > Given that make olddefconfig is always executed automatically by make, I
> > cannot even remove the "is not set" options above from tiny.config
> > because otherwise they will all be automatically enabled always unless I
> > change all the defaults from Y to N.
> >
> > In fact, the main issue is that it is not possible to deselect Kconfig
> > options using the Kconfig infrastructure. So, if a user has a
> > config with CONFIG_ALL in it, then she executes `make menuconfig'
> > to select RCAR3 and reduce the config size, the menu won't actually be
> > able to deselect any other option automatically. This is very
> > unfortunate. For instance, if the config has CADENCE_UART, and the user
> > selects CONFIG_RCAR3 from the menu, the resulting config will still have
> > CADENCE_UART, unless she goes to remove it by hand.
> >
> > Given all this, I don't know if it is worth introducing CONFIG_ALL. I
> > could add something like:
> >
> > +config ALL
> > + bool "Support for all platforms"
> > + default y
> > + select GICv3
> > + select HAS_NS16550
> > + select HAS_CADENCE_UART
> > + select HAS_PL011
> > + select HAS_EXYNOS4210
> > + select HAS_MVEBU
> > + select HAS_OMAP
> > + select HAS_SCIF
> > + select ARM_SMMU
> > + ---help---
> > + Enable support for all platforms. Triggers the build of a larger Xen
> > + binary but with more drivers.
> > +
> > + If unsure, say Y.
> >
> > but my preference would be to avoid it because it just duplicates the
> > default Y/N settings elsewhere.
>
> This is not what I suggested for all. What I suggested is the option All will
> select all platforms/*.c file to build and does not select any drivers. The
> user will have to chose the drivers. You can see it as a "custom" option.
>
> Also, by a list I meant:
>
> config PLATFORM_RCAR3
> ...
>
> choice
> prompt "Machine"
> default ....
>
> config ALL
> select PLATFORM_RCAR3
> select PLATFORM_XILINX
>
> config RCAR3
> prompt "RCAR 3 support"
> select PLATFORM_RCAR3
> select HAS_PL011
> select ...
>
> endchoice.
>
> The config PLATFORM_* would then be used in the Makefile
> xen-$(CONFIG_PLATFORM_XILINX) += xilinx.o
> ...
>
> I can also understand that there might be issue with the "All" option hence
> why I suggested the "NONE" platform. This would select none of the PLATFORM_*.
Unfortunately it doesn't seem possible to have an option under a choice
menu in kconfig that enables the other options. I get this error:
arch/arm/platforms/Kconfig:1:error: recursive dependency detected!
arch/arm/platforms/Kconfig:1: choice <choice> contains symbol ALL
arch/arm/platforms/Kconfig:9: symbol ALL depends on QEMU
arch/arm/platforms/Kconfig:18: symbol QEMU is part of choice <choice>
Given the lack of better alternatives, I'll stick with what I had
before: all platforms can be enabled manually by ticking all the three
boxes, however, I changed the default to y, so that they will all be
selected in the menu by default. If you have a better suggestion please
reply to the new patch series I'll send shortly.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: [PATCH v3 09/10] arm: add QEMU, Rcar3 and MPSoC configs
2018-05-31 21:38 ` Stefano Stabellini
@ 2018-06-04 15:58 ` Julien Grall
0 siblings, 0 replies; 33+ messages in thread
From: Julien Grall @ 2018-06-04 15:58 UTC (permalink / raw)
To: Stefano Stabellini
Cc: artem_mygaiev, lars.kurth, xen-devel, andrii_anisov, dfaggioli,
nd, volodymyr_babchuk
On 05/31/2018 10:38 PM, Stefano Stabellini wrote:
> On Wed, 30 May 2018, Julien Grall wrote:
>> On 30/05/2018 22:39, Stefano Stabellini wrote:
>>> On Tue, 29 May 2018, Julien Grall wrote:
>>>> Hi Stefano,
>>>>
>>>> On 23/05/18 01:25, Stefano Stabellini wrote:
>>>>> Add a "Platform Support" menu with three umbrella kconfig options: QEMU,
>>>>> RCAR3 and MPSOC. They enable the required options for their hardware
>>>>> platform.
>>>>>
>>>>> They are introduced for convience: the user will be able to simply open
>>>>> the menu and enable the right config for her platform.
>>>>>
>>>>> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
>>>>> CC: artem_mygaiev@epam.com
>>>>> CC: volodymyr_babchuk@epam.com
>>>>>
>>>>> ---
>>>>> Note that this approach has a limitation: it is not possible to "select
>>>>> a range". In other words, using tiny.config NR_CPUS is set to 4. It is
>>>>> not possible to increase it to 8 from config RCAR3.
>>>>
>>>> What you can do is:
>>>>
>>>> config NR_CPUS
>>>> range ...
>>>> default "8" if (RCAR3)
>>>> default "x" if (QEMU)
>>>> default 64
>>>>
>>>> This would imply to move NR_CPUS in arch/{arm,x86}/Kconfig.
>>>>
>>>> This solution is not very nice, but at least would provide a better
>>>> experience
>>>> to the user.
>>>
>>> Unfortunately, make olddefconfig is executed automatically when make is
>>> called, adding CONFIG_NR_CPUS=128. Thus, unless tiny.config has already
>>> CONFIG_RCAR3 in it, the correct default won't be applied.
>>>
>>> This suggestions only make sense if we introduce per-platform configs,
>>> such as xen/arch/arm/configs/tiny-rcar3.config.
>>
>> The other solution is to introduce a new command (or script) that will select
>> the platform at the same time as olddefconfig.
>>
>> This would avoid to create a config per board and still keeping only one tiny
>> config.
>
> I am not looking forward to making changes to the kconfig commands, but
> fortunately I was wrong on my previous reply: the issue was the order of
> the defaults in the range! To fix the problem I just had to:
>
> default "8" if ARM && RCAR3
> default "4" if ARM && QEMU
> default "4" if ARM && MPSOC
> default "256" if X86
> default "128" if ARM
>
>
>>>>> Suggestions are welcome.
>>>>> ---
>>>>> xen/arch/arm/Kconfig | 2 ++
>>>>> xen/arch/arm/platforms/Kconfig | 30 ++++++++++++++++++++++++++++++
>>>>> 2 files changed, 32 insertions(+)
>>>>> create mode 100644 xen/arch/arm/platforms/Kconfig
>>>>>
>>>>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
>>>>> index a5a6943..b5ddd12 100644
>>>>> --- a/xen/arch/arm/Kconfig
>>>>> +++ b/xen/arch/arm/Kconfig
>>>>> @@ -245,6 +245,8 @@ config ARM64_HARDEN_BRANCH_PREDICTOR
>>>>> config ARM32_HARDEN_BRANCH_PREDICTOR
>>>>> def_bool y if ARM_32 && HARDEN_BRANCH_PREDICTOR
>>>>> +source "arch/arm/platforms/Kconfig"
>>>>> +
>>>>> source "common/Kconfig"
>>>>> source "drivers/Kconfig"
>>>>> diff --git a/xen/arch/arm/platforms/Kconfig
>>>>> b/xen/arch/arm/platforms/Kconfig
>>>>> new file mode 100644
>>>>> index 0000000..0eafbef
>>>>> --- /dev/null
>>>>> +++ b/xen/arch/arm/platforms/Kconfig
>>>>> @@ -0,0 +1,30 @@
>>>>> +menu "Platform Support"
>>>>> +
>>>>> +config QEMU
>>>>> + bool "QEMU aarch virt machine support"
>>>>> + default n
>>>> The default value is confusing here. The default .config will support QEMU
>>>> but
>>>> not select that.
>>>>
>>>> While I don't yet buy the argument, some users will also want to remove
>>>> platform specific code (Andrii suggest that). This would means by default
>>>> support for a specific platform will not be in Xen.
>>>>
>>>> Furthermore, very likely, the end user will select either one board (e.g
>>>> automotive) or all of them (e.g distribution).
>>>>
>>>> So I think it would be better to do a choice list:
>>>> - All -> Board support for all board added. Drivers selected by the
>>>> user
>>>> - MPSOC -> Select board support for Xilinx + appropriate drivers
>>>> - RCAR3 -> Select board support for RCAR3 + appropriate drivers
>>>>
>>>> The tiny.config would select ALL. This could then be refined by selecting
>>>> a
>>>> specific platform.
>>>
>>> The idea of an "ALL" configuration is interesting, however, all the
>>> options we would select under "ALL" already default to "Y". Effectively,
>>> if we remove the following lines from tiny.config:
>>>
>>> # CONFIG_GICV3 is not set
>>> # CONFIG_MEM_ACCESS is not set
>>> # CONFIG_SBSA_VUART_CONSOLE is not set
>>> # CONFIG_HAS_NS16550 is not set
>>> # CONFIG_HAS_CADENCE_UART is not set
>>> # CONFIG_HAS_MVEBU is not set
>>> # CONFIG_HAS_PL011 is not set
>>> # CONFIG_HAS_SCIF is not set
>>> # CONFIG_ARM_SMMU is not set
>>>
>>> then, it would be as if tiny.config had CONFIG_ALL=y, because after
>>> running `make olddefconfig' it would get all these options set to "Y".
>>>
>>> Given that make olddefconfig is always executed automatically by make, I
>>> cannot even remove the "is not set" options above from tiny.config
>>> because otherwise they will all be automatically enabled always unless I
>>> change all the defaults from Y to N.
>>>
>>> In fact, the main issue is that it is not possible to deselect Kconfig
>>> options using the Kconfig infrastructure. So, if a user has a
>>> config with CONFIG_ALL in it, then she executes `make menuconfig'
>>> to select RCAR3 and reduce the config size, the menu won't actually be
>>> able to deselect any other option automatically. This is very
>>> unfortunate. For instance, if the config has CADENCE_UART, and the user
>>> selects CONFIG_RCAR3 from the menu, the resulting config will still have
>>> CADENCE_UART, unless she goes to remove it by hand.
>>>
>>> Given all this, I don't know if it is worth introducing CONFIG_ALL. I
>>> could add something like:
>>>
>>> +config ALL
>>> + bool "Support for all platforms"
>>> + default y
>>> + select GICv3
>>> + select HAS_NS16550
>>> + select HAS_CADENCE_UART
>>> + select HAS_PL011
>>> + select HAS_EXYNOS4210
>>> + select HAS_MVEBU
>>> + select HAS_OMAP
>>> + select HAS_SCIF
>>> + select ARM_SMMU
>>> + ---help---
>>> + Enable support for all platforms. Triggers the build of a larger Xen
>>> + binary but with more drivers.
>>> +
>>> + If unsure, say Y.
>>>
>>> but my preference would be to avoid it because it just duplicates the
>>> default Y/N settings elsewhere.
>>
>> This is not what I suggested for all. What I suggested is the option All will
>> select all platforms/*.c file to build and does not select any drivers. The
>> user will have to chose the drivers. You can see it as a "custom" option.
>>
>> Also, by a list I meant:
>>
>> config PLATFORM_RCAR3
>> ...
>>
>> choice
>> prompt "Machine"
>> default ....
>>
>> config ALL
>> select PLATFORM_RCAR3
>> select PLATFORM_XILINX
>>
>> config RCAR3
>> prompt "RCAR 3 support"
>> select PLATFORM_RCAR3
>> select HAS_PL011
>> select ...
>>
>> endchoice.
>>
>> The config PLATFORM_* would then be used in the Makefile
>> xen-$(CONFIG_PLATFORM_XILINX) += xilinx.o
>> ...
>>
>> I can also understand that there might be issue with the "All" option hence
>> why I suggested the "NONE" platform. This would select none of the PLATFORM_*.
>
> Unfortunately it doesn't seem possible to have an option under a choice
> menu in kconfig that enables the other options. I get this error:
>
> arch/arm/platforms/Kconfig:1:error: recursive dependency detected!
> arch/arm/platforms/Kconfig:1: choice <choice> contains symbol ALL
> arch/arm/platforms/Kconfig:9: symbol ALL depends on QEMU
> arch/arm/platforms/Kconfig:18: symbol QEMU is part of choice <choice>
>
> Given the lack of better alternatives, I'll stick with what I had
> before: all platforms can be enabled manually by ticking all the three
> boxes, however, I changed the default to y, so that they will all be
> selected in the menu by default. If you have a better suggestion please
> reply to the new patch series I'll send shortly.
Well, what you've implemented is not my suggestion. I never suggested
that all select RCAR3. Instead it selects PLATFORM_RCAR3.
RCAR3 would select all the drivers + enable PLATFORM_RCAR3.
PLATFORM_RCAR3 would only be used to gate any potential code in platforms.
I would appreciate if you have a look again at my suggestion and explain
why it would not work for you.
Cheers,
>
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* [PATCH v3 10/10] xen: add cloc target
2018-05-23 0:24 [PATCH v3 0/10] arm: more kconfig configurability and small default configs Stefano Stabellini
` (8 preceding siblings ...)
2018-05-23 0:25 ` [PATCH v3 09/10] arm: add QEMU, Rcar3 and MPSoC configs Stefano Stabellini
@ 2018-05-23 0:25 ` Stefano Stabellini
2018-05-29 12:15 ` Jan Beulich
9 siblings, 1 reply; 33+ messages in thread
From: Stefano Stabellini @ 2018-05-23 0:25 UTC (permalink / raw)
To: julien.grall
Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov,
andrew.cooper3, dfaggioli, jbeulich, xen-devel
Add a Xen build target to count the lines of code of the source files
built. Uses `cloc' to do the job.
With Xen on ARM taking off in embedded, IoT, and automotive, we are
seeing more and more uses of Xen in constrained environments. Users and
system integrators want the smallest Xen and Dom0 configurations. Some
of these deployments require certifications, where you definitely want
the smallest lines of code count. I provided this patch to give us the
lines of code count for that purpose.
Use the .o.d files to account for all the built source files. Generate a
list for the `cloc' utility and invoke `cloc'.
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
CC: jbeulich@suse.com
CC: andrew.cooper3@citrix.com
---
Changes in v3:
- remove build as dependecy for the cloc target
Changes in v2:
- change implementation to use .o.d to find built source files
---
xen/Makefile | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/xen/Makefile b/xen/Makefile
index 62d479c..ac6fe41 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -267,3 +267,14 @@ $(KCONFIG_CONFIG):
include/config/auto.conf.cmd: ;
-include $(BASEDIR)/include/config/auto.conf.cmd
+
+.PHONY: cloc
+cloc:
+ $(eval tmpfile := $(shell mktemp))
+ $(foreach f, $(shell find $(BASEDIR) -name *.o.d), \
+ $(eval path := $(dir $(f))) \
+ $(eval name := $(shell cat $(f) | head -1 | cut -d " " -f 2)) \
+ $(shell if test -f $(path)/$(name) ; then echo $(path)/$(name) >> $(tmpfile); fi;))
+ cloc --list-file=$(tmpfile)
+ rm $(tmpfile)
+
--
1.9.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 33+ messages in thread* Re: [PATCH v3 10/10] xen: add cloc target
2018-05-23 0:25 ` [PATCH v3 10/10] xen: add cloc target Stefano Stabellini
@ 2018-05-29 12:15 ` Jan Beulich
2018-05-30 0:50 ` Stefano Stabellini
0 siblings, 1 reply; 33+ messages in thread
From: Jan Beulich @ 2018-05-29 12:15 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Artem Mygaiev, Lars Kurth, andrii_anisov, Andrew Cooper,
xen-devel, Julien Grall, Dario Faggioli
>>> On 23.05.18 at 02:25, <sstabellini@kernel.org> wrote:
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -267,3 +267,14 @@ $(KCONFIG_CONFIG):
> include/config/auto.conf.cmd: ;
>
> -include $(BASEDIR)/include/config/auto.conf.cmd
> +
> +.PHONY: cloc
> +cloc:
> + $(eval tmpfile := $(shell mktemp))
> + $(foreach f, $(shell find $(BASEDIR) -name *.o.d), \
> + $(eval path := $(dir $(f))) \
> + $(eval name := $(shell cat $(f) | head -1 | cut -d " " -f 2)) \
> + $(shell if test -f $(path)/$(name) ; then echo $(path)/$(name) >> $(tmpfile); fi;))
> + cloc --list-file=$(tmpfile)
> + rm $(tmpfile)
I thought I had said so on v2 already, but it looks like I remember a mail I
had mostly finished when my mail frontend decided to kick me off. So I'm
sorry for mentioning this only now: xen/arch/x86/x86_64/.mm.o.d (just
to give an example has
x86_64/mm.o: x86_64/mm.c \
/build/xen/unstable-hg/2018-05-28-64bit/xen/include/xen/config.h \
...
/build/xen/unstable-hg/2018-05-28-64bit/xen/include/asm/mem_paging.h \
x86_64/compat/mm.c \
/build/xen/unstable-hg/2018-05-28-64bit/xen/include/xen/event.h \
/build/xen/unstable-hg/2018-05-28-64bit/xen/include/xen/softirq.h \
/build/xen/unstable-hg/2018-05-28-64bit/xen/include/asm/softirq.h \
/build/xen/unstable-hg/2018-05-28-64bit/xen/include/asm/event.h \
/build/xen/unstable-hg/2018-05-28-64bit/xen/include/compat/memory.h \
/build/xen/unstable-hg/2018-05-28-64bit/xen/include/compat/physdev.h \
/build/xen/unstable-hg/2018-05-28-64bit/xen/include/asm/pv/mm.h
I think you'd better count x86_64/compat/mm.c's lines too.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v3 10/10] xen: add cloc target
2018-05-29 12:15 ` Jan Beulich
@ 2018-05-30 0:50 ` Stefano Stabellini
0 siblings, 0 replies; 33+ messages in thread
From: Stefano Stabellini @ 2018-05-30 0:50 UTC (permalink / raw)
To: Jan Beulich
Cc: Artem Mygaiev, Lars Kurth, Stefano Stabellini, andrii_anisov,
Andrew Cooper, xen-devel, Julien Grall, Dario Faggioli
On Tue, 29 May 2018, Jan Beulich wrote:
> >>> On 23.05.18 at 02:25, <sstabellini@kernel.org> wrote:
> > --- a/xen/Makefile
> > +++ b/xen/Makefile
> > @@ -267,3 +267,14 @@ $(KCONFIG_CONFIG):
> > include/config/auto.conf.cmd: ;
> >
> > -include $(BASEDIR)/include/config/auto.conf.cmd
> > +
> > +.PHONY: cloc
> > +cloc:
> > + $(eval tmpfile := $(shell mktemp))
> > + $(foreach f, $(shell find $(BASEDIR) -name *.o.d), \
> > + $(eval path := $(dir $(f))) \
> > + $(eval name := $(shell cat $(f) | head -1 | cut -d " " -f 2)) \
> > + $(shell if test -f $(path)/$(name) ; then echo $(path)/$(name) >> $(tmpfile); fi;))
> > + cloc --list-file=$(tmpfile)
> > + rm $(tmpfile)
>
> I thought I had said so on v2 already, but it looks like I remember a mail I
> had mostly finished when my mail frontend decided to kick me off. So I'm
> sorry for mentioning this only now: xen/arch/x86/x86_64/.mm.o.d (just
> to give an example has
>
> x86_64/mm.o: x86_64/mm.c \
> /build/xen/unstable-hg/2018-05-28-64bit/xen/include/xen/config.h \
> ...
> /build/xen/unstable-hg/2018-05-28-64bit/xen/include/asm/mem_paging.h \
> x86_64/compat/mm.c \
> /build/xen/unstable-hg/2018-05-28-64bit/xen/include/xen/event.h \
> /build/xen/unstable-hg/2018-05-28-64bit/xen/include/xen/softirq.h \
> /build/xen/unstable-hg/2018-05-28-64bit/xen/include/asm/softirq.h \
> /build/xen/unstable-hg/2018-05-28-64bit/xen/include/asm/event.h \
> /build/xen/unstable-hg/2018-05-28-64bit/xen/include/compat/memory.h \
> /build/xen/unstable-hg/2018-05-28-64bit/xen/include/compat/physdev.h \
> /build/xen/unstable-hg/2018-05-28-64bit/xen/include/asm/pv/mm.h
>
> I think you'd better count x86_64/compat/mm.c's lines too.
Thank you for noticing this, I'll make sure to handle this case too
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 33+ messages in thread