* Re: [RFC v1 2/2] rcu/tree: Remove dynticks_nmi_nesting counter
From: Joel Fernandes @ 2019-08-29 13:59 UTC (permalink / raw)
To: Paul E. McKenney
Cc: linux-kernel, Frederic Weisbecker, Jonathan Corbet, Josh Triplett,
kernel-team, Lai Jiangshan, linux-doc, Mathieu Desnoyers,
Mauro Carvalho Chehab, rcu, Steven Rostedt
In-Reply-To: <20190829034336.GD4125@linux.ibm.com>
On Wed, Aug 28, 2019 at 08:43:36PM -0700, Paul E. McKenney wrote:
[snip]
> On the tracing patch... That patch might be a good idea regardless,
> but I bet that the reason that you felt the sudden need for it was due
> to the loss of information in your eventual ->dynticks_nesting field.
> After all, the value 0x1 might be an interrupt from idle, or it might
> just as easily be a task running in the kernel at process level.
True, however what really triggered me to do it was the existing code which
does not distinguish between entry/exit from USER and IDLE.
> The reason the patch might nevertheless be a good idea is that redundant
> information can be helpful when debugging. Especially when debugging
> new architecture-specific code, which is when RCU's dyntick-idle warnings
> tend to find bugs.
Sure, and also that it is more readable to ordinary human beings than "++="
and "--=" :-D.
thanks,
- Joel
^ permalink raw reply
* [PATCH 7/9] gpio: htc-egpio: use devm_platform_ioremap_resource_nocache()
From: Bartosz Golaszewski @ 2019-08-29 14:37 UTC (permalink / raw)
To: Jonathan Corbet, Greg Kroah-Hartman, Rafael J . Wysocki,
Alban Bedel, Linus Walleij, Arnd Bergmann, Geert Uytterhoeven
Cc: linux-doc, linux-kernel, linux-gpio, Julia Lawall,
Bartosz Golaszewski
In-Reply-To: <20190829143742.24726-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Use the new devm_platform_ioremap_resource_nocache() helper for memory
range mapping instead of devm_ioremap_nocache() combined with a call to
platform_get_resource().
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
drivers/gpio/gpio-htc-egpio.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpio/gpio-htc-egpio.c b/drivers/gpio/gpio-htc-egpio.c
index 9d3ac51a765c..7d8548e03226 100644
--- a/drivers/gpio/gpio-htc-egpio.c
+++ b/drivers/gpio/gpio-htc-egpio.c
@@ -295,14 +295,13 @@ static int __init egpio_probe(struct platform_device *pdev)
ei->chained_irq = res->start;
/* Map egpio chip into virtual address space. */
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res)
+ ei->base_addr = devm_platform_ioremap_resource_nocache(pdev, 0);
+ if (IS_ERR(ei->base_addr)) {
+ ret = PTR_ERR(ei->base_addr);
goto fail;
- ei->base_addr = devm_ioremap_nocache(&pdev->dev, res->start,
- resource_size(res));
- if (!ei->base_addr)
- goto fail;
- pr_debug("EGPIO phys=%08x virt=%p\n", (u32)res->start, ei->base_addr);
+ }
+ pr_debug("EGPIO phys=%08x virt=%p\n",
+ virt_to_phys(ei->base_addr), ei->base_addr);
if ((pdata->bus_width != 16) && (pdata->bus_width != 32))
goto fail;
--
2.21.0
^ permalink raw reply related
* [PATCH 9/9] misc: sram: use devm_platform_ioremap_resource_wc()
From: Bartosz Golaszewski @ 2019-08-29 14:37 UTC (permalink / raw)
To: Jonathan Corbet, Greg Kroah-Hartman, Rafael J . Wysocki,
Alban Bedel, Linus Walleij, Arnd Bergmann, Geert Uytterhoeven
Cc: linux-doc, linux-kernel, linux-gpio, Julia Lawall,
Bartosz Golaszewski
In-Reply-To: <20190829143742.24726-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Use the new devm_platform_ioremap_resource_wc() helper instead of
devm_ioremap_wc() combinded with a call to platform_get_resource().
Also use devm_platform_ioremap_resource() where applicable.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
drivers/misc/sram.c | 28 ++++++++--------------------
1 file changed, 8 insertions(+), 20 deletions(-)
diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
index f30448bf3a63..6c1a23cb3e8c 100644
--- a/drivers/misc/sram.c
+++ b/drivers/misc/sram.c
@@ -340,8 +340,6 @@ static const struct of_device_id sram_dt_ids[] = {
static int sram_probe(struct platform_device *pdev)
{
struct sram_dev *sram;
- struct resource *res;
- size_t size;
int ret;
int (*init_func)(void);
@@ -351,25 +349,14 @@ static int sram_probe(struct platform_device *pdev)
sram->dev = &pdev->dev;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(sram->dev, "found no memory resource\n");
- return -EINVAL;
- }
-
- size = resource_size(res);
-
- if (!devm_request_mem_region(sram->dev, res->start, size, pdev->name)) {
- dev_err(sram->dev, "could not request region for resource\n");
- return -EBUSY;
- }
-
if (of_property_read_bool(pdev->dev.of_node, "no-memory-wc"))
- sram->virt_base = devm_ioremap(sram->dev, res->start, size);
+ sram->virt_base = devm_platform_ioremap_resource(pdev, 0);
else
- sram->virt_base = devm_ioremap_wc(sram->dev, res->start, size);
- if (!sram->virt_base)
- return -ENOMEM;
+ sram->virt_base = devm_platform_ioremap_resource_wc(pdev, 0);
+ if (IS_ERR(sram->virt_base)) {
+ dev_err(&pdev->dev, "could not map SRAM registers\n");
+ return PTR_ERR(sram->virt_base);
+ }
sram->pool = devm_gen_pool_create(sram->dev, ilog2(SRAM_GRANULARITY),
NUMA_NO_NODE, NULL);
@@ -382,7 +369,8 @@ static int sram_probe(struct platform_device *pdev)
else
clk_prepare_enable(sram->clk);
- ret = sram_reserve_regions(sram, res);
+ ret = sram_reserve_regions(sram,
+ platform_get_resource(pdev, IORESOURCE_MEM, 0));
if (ret)
goto err_disable_clk;
--
2.21.0
^ permalink raw reply related
* [PATCH 8/9] gpio: xgene: use devm_platform_ioremap_resource_nocache()
From: Bartosz Golaszewski @ 2019-08-29 14:37 UTC (permalink / raw)
To: Jonathan Corbet, Greg Kroah-Hartman, Rafael J . Wysocki,
Alban Bedel, Linus Walleij, Arnd Bergmann, Geert Uytterhoeven
Cc: linux-doc, linux-kernel, linux-gpio, Julia Lawall,
Bartosz Golaszewski
In-Reply-To: <20190829143742.24726-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Use the new devm_platform_ioremap_resource_nocache() helper for memory
range mapping instead of devm_ioremap_nocache() combined with a call to
platform_get_resource().
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
drivers/gpio/gpio-xgene.c | 14 +++-----------
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/gpio/gpio-xgene.c b/drivers/gpio/gpio-xgene.c
index 2918363884de..559b8e53c2e0 100644
--- a/drivers/gpio/gpio-xgene.c
+++ b/drivers/gpio/gpio-xgene.c
@@ -155,7 +155,6 @@ static SIMPLE_DEV_PM_OPS(xgene_gpio_pm, xgene_gpio_suspend, xgene_gpio_resume);
static int xgene_gpio_probe(struct platform_device *pdev)
{
- struct resource *res;
struct xgene_gpio *gpio;
int err = 0;
@@ -165,16 +164,9 @@ static int xgene_gpio_probe(struct platform_device *pdev)
goto err;
}
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- err = -EINVAL;
- goto err;
- }
-
- gpio->base = devm_ioremap_nocache(&pdev->dev, res->start,
- resource_size(res));
- if (!gpio->base) {
- err = -ENOMEM;
+ gpio->base = devm_platform_ioremap_resource_nocache(pdev, 0);
+ if (IS_ERR(gpio->base)) {
+ err = PTR_ERR(gpio->base);
goto err;
}
--
2.21.0
^ permalink raw reply related
* [PATCH 6/9] gpio: ath79: use devm_platform_ioremap_resource_nocache()
From: Bartosz Golaszewski @ 2019-08-29 14:37 UTC (permalink / raw)
To: Jonathan Corbet, Greg Kroah-Hartman, Rafael J . Wysocki,
Alban Bedel, Linus Walleij, Arnd Bergmann, Geert Uytterhoeven
Cc: linux-doc, linux-kernel, linux-gpio, Julia Lawall,
Bartosz Golaszewski
In-Reply-To: <20190829143742.24726-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Use the new devm_platform_ioremap_resource_nocache() helper for memory
range mapping instead of devm_ioremap_nocache() combined with a call to
platform_get_resource().
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
drivers/gpio/gpio-ath79.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpio/gpio-ath79.c b/drivers/gpio/gpio-ath79.c
index f1a5ea9b3de2..c2c5d7dd2575 100644
--- a/drivers/gpio/gpio-ath79.c
+++ b/drivers/gpio/gpio-ath79.c
@@ -226,7 +226,6 @@ static int ath79_gpio_probe(struct platform_device *pdev)
struct device_node *np = dev->of_node;
struct ath79_gpio_ctrl *ctrl;
struct gpio_irq_chip *girq;
- struct resource *res;
u32 ath79_gpio_count;
bool oe_inverted;
int err;
@@ -256,12 +255,9 @@ static int ath79_gpio_probe(struct platform_device *pdev)
return -EINVAL;
}
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res)
- return -EINVAL;
- ctrl->base = devm_ioremap_nocache(dev, res->start, resource_size(res));
- if (!ctrl->base)
- return -ENOMEM;
+ ctrl->base = devm_platform_ioremap_resource_nocache(pdev, 0);
+ if (IS_ERR(ctrl->base))
+ return PTR_ERR(ctrl->base);
raw_spin_lock_init(&ctrl->lock);
err = bgpio_init(&ctrl->gc, dev, 4,
--
2.21.0
^ permalink raw reply related
* [PATCH 5/9] gpio: em: use devm_platform_ioremap_resource_nocache()
From: Bartosz Golaszewski @ 2019-08-29 14:37 UTC (permalink / raw)
To: Jonathan Corbet, Greg Kroah-Hartman, Rafael J . Wysocki,
Alban Bedel, Linus Walleij, Arnd Bergmann, Geert Uytterhoeven
Cc: linux-doc, linux-kernel, linux-gpio, Julia Lawall,
Bartosz Golaszewski
In-Reply-To: <20190829143742.24726-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Use the new devm_platform_ioremap_resource_nocache() helper for memory
range mapping instead of devm_ioremap_nocache() combined with a call to
platform_get_resource().
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
drivers/gpio/gpio-em.c | 22 +++++++++-------------
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/gpio/gpio-em.c b/drivers/gpio/gpio-em.c
index a87951293aaa..0f4f5e11278a 100644
--- a/drivers/gpio/gpio-em.c
+++ b/drivers/gpio/gpio-em.c
@@ -269,7 +269,7 @@ static void em_gio_irq_domain_remove(void *data)
static int em_gio_probe(struct platform_device *pdev)
{
struct em_gio_priv *p;
- struct resource *io[2], *irq[2];
+ struct resource *irq[2];
struct gpio_chip *gpio_chip;
struct irq_chip *irq_chip;
const char *name = dev_name(&pdev->dev);
@@ -284,25 +284,21 @@ static int em_gio_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, p);
spin_lock_init(&p->sense_lock);
- io[0] = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- io[1] = platform_get_resource(pdev, IORESOURCE_MEM, 1);
irq[0] = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
irq[1] = platform_get_resource(pdev, IORESOURCE_IRQ, 1);
- if (!io[0] || !io[1] || !irq[0] || !irq[1]) {
- dev_err(&pdev->dev, "missing IRQ or IOMEM\n");
+ if (!irq[0] || !irq[1]) {
+ dev_err(&pdev->dev, "missing IRQ resources\n");
return -EINVAL;
}
- p->base0 = devm_ioremap_nocache(&pdev->dev, io[0]->start,
- resource_size(io[0]));
- if (!p->base0)
- return -ENOMEM;
+ p->base0 = devm_platform_ioremap_resource_nocache(pdev, 0);
+ if (IS_ERR(p->base0))
+ return PTR_ERR(p->base0);
- p->base1 = devm_ioremap_nocache(&pdev->dev, io[1]->start,
- resource_size(io[1]));
- if (!p->base1)
- return -ENOMEM;
+ p->base1 = devm_platform_ioremap_resource_nocache(pdev, 1);
+ if (IS_ERR(p->base1))
+ return PTR_ERR(p->base1);
if (of_property_read_u32(pdev->dev.of_node, "ngpios", &ngpios)) {
dev_err(&pdev->dev, "Missing ngpios OF property\n");
--
2.21.0
^ permalink raw reply related
* [PATCH 2/9] lib: devres: prepare devm_ioremap_resource() for more variants
From: Bartosz Golaszewski @ 2019-08-29 14:37 UTC (permalink / raw)
To: Jonathan Corbet, Greg Kroah-Hartman, Rafael J . Wysocki,
Alban Bedel, Linus Walleij, Arnd Bergmann, Geert Uytterhoeven
Cc: linux-doc, linux-kernel, linux-gpio, Julia Lawall,
Bartosz Golaszewski
In-Reply-To: <20190829143742.24726-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
We want to add the nocache and write-combined variants of
devm_ioremap_resource(). Let's first implement __devm_ioremap_resource()
which takes an additional argument type. The types are the same as
for __devm_ioremap(). The existing devm_ioremap_resource() now simply
calls __devm_ioremap_resource() with regular DEVM_IOREMAP type.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
lib/devres.c | 47 +++++++++++++++++++++++++++--------------------
1 file changed, 27 insertions(+), 20 deletions(-)
diff --git a/lib/devres.c b/lib/devres.c
index 6a0e9bd6524a..a14c727128c1 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -114,25 +114,9 @@ void devm_iounmap(struct device *dev, void __iomem *addr)
}
EXPORT_SYMBOL(devm_iounmap);
-/**
- * devm_ioremap_resource() - check, request region, and ioremap resource
- * @dev: generic device to handle the resource for
- * @res: resource to be handled
- *
- * Checks that a resource is a valid memory region, requests the memory
- * region and ioremaps it. All operations are managed and will be undone
- * on driver detach.
- *
- * Returns a pointer to the remapped memory or an ERR_PTR() encoded error code
- * on failure. Usage example:
- *
- * res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- * base = devm_ioremap_resource(&pdev->dev, res);
- * if (IS_ERR(base))
- * return PTR_ERR(base);
- */
-void __iomem *devm_ioremap_resource(struct device *dev,
- const struct resource *res)
+static void __iomem *
+__devm_ioremap_resource(struct device *dev, const struct resource *res,
+ enum devm_ioremap_type type)
{
resource_size_t size;
void __iomem *dest_ptr;
@@ -151,7 +135,7 @@ void __iomem *devm_ioremap_resource(struct device *dev,
return IOMEM_ERR_PTR(-EBUSY);
}
- dest_ptr = devm_ioremap(dev, res->start, size);
+ dest_ptr = __devm_ioremap(dev, res->start, size, type);
if (!dest_ptr) {
dev_err(dev, "ioremap failed for resource %pR\n", res);
devm_release_mem_region(dev, res->start, size);
@@ -160,6 +144,29 @@ void __iomem *devm_ioremap_resource(struct device *dev,
return dest_ptr;
}
+
+/**
+ * devm_ioremap_resource() - check, request region, and ioremap resource
+ * @dev: generic device to handle the resource for
+ * @res: resource to be handled
+ *
+ * Checks that a resource is a valid memory region, requests the memory
+ * region and ioremaps it. All operations are managed and will be undone
+ * on driver detach.
+ *
+ * Returns a pointer to the remapped memory or an ERR_PTR() encoded error code
+ * on failure. Usage example:
+ *
+ * res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ * base = devm_ioremap_resource(&pdev->dev, res);
+ * if (IS_ERR(base))
+ * return PTR_ERR(base);
+ */
+void __iomem *devm_ioremap_resource(struct device *dev,
+ const struct resource *res)
+{
+ return __devm_ioremap_resource(dev, res, DEVM_IOREMAP);
+}
EXPORT_SYMBOL(devm_ioremap_resource);
/*
--
2.21.0
^ permalink raw reply related
* [PATCH 4/9] drivers: provide new variants of devm_platform_ioremap_resource()
From: Bartosz Golaszewski @ 2019-08-29 14:37 UTC (permalink / raw)
To: Jonathan Corbet, Greg Kroah-Hartman, Rafael J . Wysocki,
Alban Bedel, Linus Walleij, Arnd Bergmann, Geert Uytterhoeven
Cc: linux-doc, linux-kernel, linux-gpio, Julia Lawall,
Bartosz Golaszewski
In-Reply-To: <20190829143742.24726-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Provide two new variants of devm_platform_ioremap_resource() - one for
nocache and one for write-combined ioremap.
Move the core functionality into a separate static function -
__devm_platform_ioremap_resource() - that takes an additional type
argument.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
.../driver-api/driver-model/devres.rst | 2 +
drivers/base/platform.c | 70 +++++++++++++++++--
include/linux/platform_device.h | 6 ++
3 files changed, 73 insertions(+), 5 deletions(-)
diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst
index 20c4be0389ab..37d10e5cc44c 100644
--- a/Documentation/driver-api/driver-model/devres.rst
+++ b/Documentation/driver-api/driver-model/devres.rst
@@ -319,6 +319,8 @@ IOMAP
devm_ioremap_resource_nocache()
devm_ioremap_resource_wc()
devm_platform_ioremap_resource() : calls devm_ioremap_resource() for platform device
+ devm_platform_ioremap_resource_nocache()
+ devm_platform_ioremap_resource_wc()
devm_iounmap()
pcim_iomap()
pcim_iomap_regions() : do request_region() and iomap() on multiple BARs
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index ec974ba9c0c4..4191e776ebae 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -79,6 +79,37 @@ struct resource *platform_get_resource(struct platform_device *dev,
}
EXPORT_SYMBOL_GPL(platform_get_resource);
+#ifdef CONFIG_HAS_IOMEM
+enum {
+ IOREMAP_TYPE_NONE,
+ IOREMAP_TYPE_NOCACHE,
+ IOREMAP_TYPE_WC,
+};
+
+static void __iomem *
+__devm_platform_ioremap_resource(struct platform_device *pdev,
+ unsigned int index, int type)
+{
+ struct resource *res = platform_get_resource(pdev,
+ IORESOURCE_MEM, index);
+ struct device *dev = &pdev->dev;
+ void __iomem *addr = NULL;
+
+ switch (type) {
+ case IOREMAP_TYPE_NONE:
+ addr = devm_ioremap_resource(dev, res);
+ break;
+ case IOREMAP_TYPE_NOCACHE:
+ addr = devm_ioremap_resource_nocache(dev, res);
+ break;
+ case IOREMAP_TYPE_WC:
+ addr = devm_ioremap_resource_wc(dev, res);
+ break;
+ }
+
+ return addr;
+}
+
/**
* devm_platform_ioremap_resource - call devm_ioremap_resource() for a platform
* device
@@ -87,16 +118,45 @@ EXPORT_SYMBOL_GPL(platform_get_resource);
* resource management
* @index: resource index
*/
-#ifdef CONFIG_HAS_IOMEM
void __iomem *devm_platform_ioremap_resource(struct platform_device *pdev,
unsigned int index)
{
- struct resource *res;
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, index);
- return devm_ioremap_resource(&pdev->dev, res);
+ return __devm_platform_ioremap_resource(pdev, index, IOREMAP_TYPE_NONE);
}
EXPORT_SYMBOL_GPL(devm_platform_ioremap_resource);
+
+/**
+ * devm_platform_ioremap_resource_nocache - nocache variant of
+ * devm_platform_ioremap_resource()
+ *
+ * @pdev: platform device to use both for memory resource lookup as well as
+ * resource management
+ * @index: resource index
+ */
+void __iomem *
+devm_platform_ioremap_resource_nocache(struct platform_device *pdev,
+ unsigned int index)
+{
+ return __devm_platform_ioremap_resource(pdev, index,
+ IOREMAP_TYPE_NOCACHE);
+}
+EXPORT_SYMBOL_GPL(devm_platform_ioremap_resource_nocache);
+
+/**
+ * devm_platform_ioremap_resource_wc - write-combined variant of
+ * devm_platform_ioremap_resource()
+ *
+ * @pdev: platform device to use both for memory resource lookup as well as
+ * resource management
+ * @index: resource index
+ */
+void __iomem *devm_platform_ioremap_resource_wc(struct platform_device *pdev,
+ unsigned int index)
+{
+ return __devm_platform_ioremap_resource(pdev, index, IOREMAP_TYPE_WC);
+}
+EXPORT_SYMBOL_GPL(devm_platform_ioremap_resource_wc);
+
#endif /* CONFIG_HAS_IOMEM */
/**
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index 9bc36b589827..00ae0679396e 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -54,6 +54,12 @@ extern struct resource *platform_get_resource(struct platform_device *,
extern void __iomem *
devm_platform_ioremap_resource(struct platform_device *pdev,
unsigned int index);
+extern void __iomem *
+devm_platform_ioremap_resource_nocache(struct platform_device *pdev,
+ unsigned int index);
+extern void __iomem *
+devm_platform_ioremap_resource_wc(struct platform_device *pdev,
+ unsigned int index);
extern int platform_get_irq(struct platform_device *, unsigned int);
extern int platform_irq_count(struct platform_device *);
extern struct resource *platform_get_resource_byname(struct platform_device *,
--
2.21.0
^ permalink raw reply related
* [PATCH 3/9] lib: devres: provide new variants for devm_ioremap_resource()
From: Bartosz Golaszewski @ 2019-08-29 14:37 UTC (permalink / raw)
To: Jonathan Corbet, Greg Kroah-Hartman, Rafael J . Wysocki,
Alban Bedel, Linus Walleij, Arnd Bergmann, Geert Uytterhoeven
Cc: linux-doc, linux-kernel, linux-gpio, Julia Lawall,
Bartosz Golaszewski
In-Reply-To: <20190829143742.24726-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Provide two new variants of devm_ioremap_resource() - one for nocache
and one for write-combined ioremap.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
.../driver-api/driver-model/devres.rst | 2 ++
include/linux/device.h | 4 +++
lib/devres.c | 29 +++++++++++++++++++
3 files changed, 35 insertions(+)
diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst
index 8e3087662daf..20c4be0389ab 100644
--- a/Documentation/driver-api/driver-model/devres.rst
+++ b/Documentation/driver-api/driver-model/devres.rst
@@ -316,6 +316,8 @@ IOMAP
devm_ioremap_nocache()
devm_ioremap_wc()
devm_ioremap_resource() : checks resource, requests memory region, ioremaps
+ devm_ioremap_resource_nocache()
+ devm_ioremap_resource_wc()
devm_platform_ioremap_resource() : calls devm_ioremap_resource() for platform device
devm_iounmap()
pcim_iomap()
diff --git a/include/linux/device.h b/include/linux/device.h
index 6717adee33f0..e8aa916e8eb2 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -710,6 +710,10 @@ extern void devm_free_pages(struct device *dev, unsigned long addr);
void __iomem *devm_ioremap_resource(struct device *dev,
const struct resource *res);
+void __iomem *devm_ioremap_resource_nocache(struct device *dev,
+ const struct resource *res);
+void __iomem *devm_ioremap_resource_wc(struct device *dev,
+ const struct resource *res);
void __iomem *devm_of_iomap(struct device *dev,
struct device_node *node, int index,
diff --git a/lib/devres.c b/lib/devres.c
index a14c727128c1..f1297bcc8891 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -169,6 +169,35 @@ void __iomem *devm_ioremap_resource(struct device *dev,
}
EXPORT_SYMBOL(devm_ioremap_resource);
+/**
+ * devm_ioremap_resource_nocache() - nocache variant of devm_ioremap_resource()
+ * @dev: generic device to handle the resource for
+ * @res: resource to be handled
+ *
+ * Returns a pointer to the remapped memory or an ERR_PTR() encoded error code
+ * on failure. Usage example:
+ */
+void __iomem *devm_ioremap_resource_nocache(struct device *dev,
+ const struct resource *res)
+{
+ return __devm_ioremap_resource(dev, res, DEVM_IOREMAP_NC);
+}
+
+/**
+ * devm_ioremap_resource_wc() - write-combined variant of
+ * devm_ioremap_resource()
+ * @dev: generic device to handle the resource for
+ * @res: resource to be handled
+ *
+ * Returns a pointer to the remapped memory or an ERR_PTR() encoded error code
+ * on failure. Usage example:
+ */
+void __iomem *devm_ioremap_resource_wc(struct device *dev,
+ const struct resource *res)
+{
+ return __devm_ioremap_resource(dev, res, DEVM_IOREMAP_WC);
+}
+
/*
* devm_of_iomap - Requests a resource and maps the memory mapped IO
* for a given device_node managed by a given device
--
2.21.0
^ permalink raw reply related
* [PATCH 1/9] Documentation: devres: add missing entry for devm_platform_ioremap_resource()
From: Bartosz Golaszewski @ 2019-08-29 14:37 UTC (permalink / raw)
To: Jonathan Corbet, Greg Kroah-Hartman, Rafael J . Wysocki,
Alban Bedel, Linus Walleij, Arnd Bergmann, Geert Uytterhoeven
Cc: linux-doc, linux-kernel, linux-gpio, Julia Lawall,
Bartosz Golaszewski
In-Reply-To: <20190829143742.24726-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
devm_platform_ioremap_resource() should be documented in devres.rst.
Add the missing entry.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
Documentation/driver-api/driver-model/devres.rst | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst
index a100bef54952..8e3087662daf 100644
--- a/Documentation/driver-api/driver-model/devres.rst
+++ b/Documentation/driver-api/driver-model/devres.rst
@@ -316,6 +316,7 @@ IOMAP
devm_ioremap_nocache()
devm_ioremap_wc()
devm_ioremap_resource() : checks resource, requests memory region, ioremaps
+ devm_platform_ioremap_resource() : calls devm_ioremap_resource() for platform device
devm_iounmap()
pcim_iomap()
pcim_iomap_regions() : do request_region() and iomap() on multiple BARs
--
2.21.0
^ permalink raw reply related
* [PATCH 0/9] drivers: add new variants of devm_platform_ioremap_resource()
From: Bartosz Golaszewski @ 2019-08-29 14:37 UTC (permalink / raw)
To: Jonathan Corbet, Greg Kroah-Hartman, Rafael J . Wysocki,
Alban Bedel, Linus Walleij, Arnd Bergmann, Geert Uytterhoeven
Cc: linux-doc, linux-kernel, linux-gpio, Julia Lawall,
Bartosz Golaszewski
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
The new devm_platform_ioremap_resource() helper has now been widely
adopted and used in many drivers. Users of nocache and write-combined
ioremap() variants could profit from the same code shrinkage. This
series provides two new versions of devm_platform_ioremap_resource()
and uses it in a few example drivers with the assumption that - just
like was the case previously - a coccinelle script will be developed
to ease the transition for others.
Bartosz Golaszewski (9):
Documentation: devres: add missing entry for
devm_platform_ioremap_resource()
lib: devres: prepare devm_ioremap_resource() for more variants
lib: devres: provide new variants for devm_ioremap_resource()
drivers: provide new variants of devm_platform_ioremap_resource()
gpio: em: use devm_platform_ioremap_resource_nocache()
gpio: ath79: use devm_platform_ioremap_resource_nocache()
gpio: htc-egpio: use devm_platform_ioremap_resource_nocache()
gpio: xgene: use devm_platform_ioremap_resource_nocache()
misc: sram: use devm_platform_ioremap_resource_wc()
.../driver-api/driver-model/devres.rst | 5 ++
drivers/base/platform.c | 70 +++++++++++++++--
drivers/gpio/gpio-ath79.c | 10 +--
drivers/gpio/gpio-em.c | 22 +++---
drivers/gpio/gpio-htc-egpio.c | 13 ++--
drivers/gpio/gpio-xgene.c | 14 +---
drivers/misc/sram.c | 28 ++-----
include/linux/device.h | 4 +
include/linux/platform_device.h | 6 ++
lib/devres.c | 76 ++++++++++++++-----
10 files changed, 165 insertions(+), 83 deletions(-)
--
2.21.0
^ permalink raw reply
* Re: [RFC v1 2/2] rcu/tree: Remove dynticks_nmi_nesting counter
From: Joel Fernandes @ 2019-08-29 14:43 UTC (permalink / raw)
To: Paul E. McKenney
Cc: linux-kernel, Frederic Weisbecker, Jonathan Corbet, Josh Triplett,
kernel-team, Lai Jiangshan, linux-doc, Mathieu Desnoyers,
Mauro Carvalho Chehab, rcu, Steven Rostedt
In-Reply-To: <20190829034336.GD4125@linux.ibm.com>
On Wed, Aug 28, 2019 at 08:43:36PM -0700, Paul E. McKenney wrote:
[snip]
> > > > > This change is not fixing a bug, so there is no need for an emergency fix,
> > > > > and thus no point in additional churn. I understand that it is a bit
> > > > > annoying to code and test something and have your friendly maintainer say
> > > > > "sorry, wrong rocks", and the reason that I understand this is that I do
> > > > > that to myself rather often.
> > > >
> > > > The motivation for me for this change is to avoid future bugs such as with
> > > > the following patch where "== 2" did not take the force write of
> > > > DYNTICK_IRQ_NONIDLE into account:
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git/commit/?h=dev&id=13c4b07593977d9288e5d0c21c89d9ba27e2ea1f
> > >
> > > Yes, the current code does need some simplification.
> > >
> > > > I still don't see it as pointless churn, it is also a maintenance cost in its
> > > > current form and the simplification is worth it IMHO both from a readability,
> > > > and maintenance stand point.
> > > >
> > > > I still don't see what's technically wrong with the patch. I could perhaps
> > > > add the above "== 2" point in the patch?
> > >
> > > I don't know of a crash or splat your patch would cause, if that is
> > > your question. But that is also true of the current code, so the point
> > > is simplification, not bug fixing. And from what I can see, there is an
> > > opportunity to simplify quite a bit further. And with something like
> > > RCU, further simplification is worth -serious- consideration.
> > >
> > > > We could also discuss f2f at LPC to see if we can agree about it?
> > >
> > > That might make a lot of sense.
> >
> > Sure. I am up for a further redesign / simplification. I will think more
> > about your suggestions and can also further discuss at LPC.
>
> One question that might (or might not) help: Given the compound counter,
> where the low-order hex digit indicates whether the corresponding CPU
> is running in a non-idle kernel task and the rest of the hex digits
> indicate the NMI-style nesting counter shifted up by four bits, what
> could rcu_is_cpu_rrupt_from_idle() be reduced to?
>
> > And this patch is on LKML archives and is not going anywhere so there's no
> > rush I guess ;-)
>
> True enough! ;-)
Paul, do we also nuke rcu_eqs_special_set()? Currently I don't see anyone
using it. And also remove the bottom most bit of dynticks?
Also what happens if a TLB flush broadcast is needed? Do we IPI nohz or idle
CPUs are the moment?
All of this was introduced in:
b8c17e6664c4 ("rcu: Maintain special bits at bottom of ->dynticks counter")
thanks,
- Joel
^ permalink raw reply
* Re: [PATCH 0/9] drivers: add new variants of devm_platform_ioremap_resource()
From: Geert Uytterhoeven @ 2019-08-29 14:48 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Jonathan Corbet, Greg Kroah-Hartman, Rafael J . Wysocki,
Alban Bedel, Linus Walleij, Arnd Bergmann, Geert Uytterhoeven,
open list:DOCUMENTATION, Linux Kernel Mailing List,
open list:GPIO SUBSYSTEM, Julia Lawall, Bartosz Golaszewski,
Christoph Hellwig
In-Reply-To: <20190829143742.24726-1-brgl@bgdev.pl>
Hi Bartosz,
On Thu, Aug 29, 2019 at 4:38 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> The new devm_platform_ioremap_resource() helper has now been widely
> adopted and used in many drivers. Users of nocache and write-combined
> ioremap() variants could profit from the same code shrinkage. This
> series provides two new versions of devm_platform_ioremap_resource()
> and uses it in a few example drivers with the assumption that - just
> like was the case previously - a coccinelle script will be developed
> to ease the transition for others.
Please be aware that the number of ioremap() variants is being
reduced, as some of them are redundant (e.g. ioremap() already creates
an uncached mapping, so ioremap_nocache() is not needed).
So less is better than more ;-)
https://lore.kernel.org/lkml/20190817073253.27819-1-hch@lst.de/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] ALSA: doc: Fix PCM interface section typos
From: Miquel Raynal @ 2019-08-29 14:55 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: linux-doc, Miquel Raynal
Fix two mistakes in the PCM interface section:
1/ Members of the snd_pcm_hardware structure are channels_{min,max}
and not channel_{min,max} (mind the 's').
2/ Another sentence is incomplete as the reference to one structure
member (period_bytes_max) is missing.
There is no relevant 'Fixes:' tag to apply as both typos predate the
Git era.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
.../sound/kernel-api/writing-an-alsa-driver.rst | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst
index 6b154dbb02cc..3488b8be5bd5 100644
--- a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst
+++ b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst
@@ -1715,16 +1715,16 @@ Typically, you'll have a hardware descriptor as below:
- ``rate_min`` and ``rate_max`` define the minimum and maximum sample
rate. This should correspond somehow to ``rates`` bits.
-- ``channel_min`` and ``channel_max`` define, as you might already
+- ``channels_min`` and ``channels_max`` define, as you might already
expected, the minimum and maximum number of channels.
- ``buffer_bytes_max`` defines the maximum buffer size in
bytes. There is no ``buffer_bytes_min`` field, since it can be
calculated from the minimum period size and the minimum number of
- periods. Meanwhile, ``period_bytes_min`` and define the minimum and
- maximum size of the period in bytes. ``periods_max`` and
- ``periods_min`` define the maximum and minimum number of periods in
- the buffer.
+ periods. Meanwhile, ``period_bytes_min`` and ``period_bytes_max``
+ define the minimum and maximum size of the period in bytes.
+ ``periods_max`` and ``periods_min`` define the maximum and minimum
+ number of periods in the buffer.
The “period” is a term that corresponds to a fragment in the OSS
world. The period defines the size at which a PCM interrupt is
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 3/9] lib: devres: provide new variants for devm_ioremap_resource()
From: Arnd Bergmann @ 2019-08-29 15:09 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Jonathan Corbet, Greg Kroah-Hartman, Rafael J . Wysocki,
Alban Bedel, Linus Walleij, Geert Uytterhoeven,
open list:DOCUMENTATION, Linux Kernel Mailing List,
open list:GPIO SUBSYSTEM, Julia Lawall, Bartosz Golaszewski
In-Reply-To: <20190829143742.24726-4-brgl@bgdev.pl>
On Thu, Aug 29, 2019 at 4:38 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> @@ -710,6 +710,10 @@ extern void devm_free_pages(struct device *dev, unsigned long addr);
>
> void __iomem *devm_ioremap_resource(struct device *dev,
> const struct resource *res);
> +void __iomem *devm_ioremap_resource_nocache(struct device *dev,
> + const struct resource *res);
> +void __iomem *devm_ioremap_resource_wc(struct device *dev,
> + const struct resource *res);
>
> void __iomem *devm_of_iomap(struct device *dev,
> struct device_node *node, int index,
> diff --git a/lib/devres.c b/lib/devres.c
I think adding devm_ioremap_resource_wc() and
devm_platform_ioremap_resource_wc() makes sense, but I think we're
better off without devm_ioremap_resource_nocache() and
devm_ioremap_resource_cache().
The only architecture that actually has a difference between
ioremap() and ioremap_nocache() seems to be ia64. I would
generally assume that any driver using ioremap_nocache()
that is not ia64 specific should just use ioremap().
The ia64 version of ioremap() tries to guess whether it needs
a cached or uncached mapping, everyone else always
gets uncached these days.
Arnd
^ permalink raw reply
* Re: [RFC v1 2/2] rcu/tree: Remove dynticks_nmi_nesting counter
From: Joel Fernandes @ 2019-08-29 15:13 UTC (permalink / raw)
To: Paul E. McKenney
Cc: linux-kernel, Frederic Weisbecker, Jonathan Corbet, Josh Triplett,
kernel-team, Lai Jiangshan, linux-doc, Mathieu Desnoyers,
Mauro Carvalho Chehab, rcu, Steven Rostedt
In-Reply-To: <20190829144355.GE63638@google.com>
On Thu, Aug 29, 2019 at 10:43:55AM -0400, Joel Fernandes wrote:
> On Wed, Aug 28, 2019 at 08:43:36PM -0700, Paul E. McKenney wrote:
> [snip]
> > > > > > This change is not fixing a bug, so there is no need for an emergency fix,
> > > > > > and thus no point in additional churn. I understand that it is a bit
> > > > > > annoying to code and test something and have your friendly maintainer say
> > > > > > "sorry, wrong rocks", and the reason that I understand this is that I do
> > > > > > that to myself rather often.
> > > > >
> > > > > The motivation for me for this change is to avoid future bugs such as with
> > > > > the following patch where "== 2" did not take the force write of
> > > > > DYNTICK_IRQ_NONIDLE into account:
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git/commit/?h=dev&id=13c4b07593977d9288e5d0c21c89d9ba27e2ea1f
> > > >
> > > > Yes, the current code does need some simplification.
> > > >
> > > > > I still don't see it as pointless churn, it is also a maintenance cost in its
> > > > > current form and the simplification is worth it IMHO both from a readability,
> > > > > and maintenance stand point.
> > > > >
> > > > > I still don't see what's technically wrong with the patch. I could perhaps
> > > > > add the above "== 2" point in the patch?
> > > >
> > > > I don't know of a crash or splat your patch would cause, if that is
> > > > your question. But that is also true of the current code, so the point
> > > > is simplification, not bug fixing. And from what I can see, there is an
> > > > opportunity to simplify quite a bit further. And with something like
> > > > RCU, further simplification is worth -serious- consideration.
> > > >
> > > > > We could also discuss f2f at LPC to see if we can agree about it?
> > > >
> > > > That might make a lot of sense.
> > >
> > > Sure. I am up for a further redesign / simplification. I will think more
> > > about your suggestions and can also further discuss at LPC.
> >
> > One question that might (or might not) help: Given the compound counter,
> > where the low-order hex digit indicates whether the corresponding CPU
> > is running in a non-idle kernel task and the rest of the hex digits
> > indicate the NMI-style nesting counter shifted up by four bits, what
> > could rcu_is_cpu_rrupt_from_idle() be reduced to?
> >
> > > And this patch is on LKML archives and is not going anywhere so there's no
> > > rush I guess ;-)
> >
> > True enough! ;-)
>
> Paul, do we also nuke rcu_eqs_special_set()? Currently I don't see anyone
> using it. And also remove the bottom most bit of dynticks?
>
> Also what happens if a TLB flush broadcast is needed? Do we IPI nohz or idle
> CPUs are the moment?
>
> All of this was introduced in:
> b8c17e6664c4 ("rcu: Maintain special bits at bottom of ->dynticks counter")
Paul, also what what happens in the following scenario:
CPU0 CPU1
A syscall causes rcu_eqs_exit()
rcu_read_lock();
---> FQS loop waiting on
dyntick_snap
usermode-upcall entry -->causes rcu_eqs_enter();
usermode-upcall exit -->causes rcu_eqs_exit();
---> FQS loop sees
dyntick snap
increment and
declares CPU0 is
in a QS state
before the
rcu_read_unlock!
rcu_read_unlock();
---
Does the context tracking not call rcu_user_enter() in this case, or did I
really miss something?
thanks,
- Joel
^ permalink raw reply
* Re: [PATCH v3 01/10] KVM: arm64: Document PV-time interface
From: Steven Price @ 2019-08-29 15:21 UTC (permalink / raw)
To: Christoffer Dall
Cc: kvm, linux-doc, Marc Zyngier, linux-kernel, Russell King,
Catalin Marinas, Paolo Bonzini, Will Deacon, kvmarm,
linux-arm-kernel
In-Reply-To: <20190828134900.GA2113@lvm>
On 28/08/2019 14:49, Christoffer Dall wrote:
> On Tue, Aug 27, 2019 at 10:57:06AM +0200, Christoffer Dall wrote:
>> On Wed, Aug 21, 2019 at 04:36:47PM +0100, Steven Price wrote:
>>> Introduce a paravirtualization interface for KVM/arm64 based on the
>>> "Arm Paravirtualized Time for Arm-Base Systems" specification DEN 0057A.
>>>
>>> This only adds the details about "Stolen Time" as the details of "Live
>>> Physical Time" have not been fully agreed.
>>>
>>> User space can specify a reserved area of memory for the guest and
>>> inform KVM to populate the memory with information on time that the host
>>> kernel has stolen from the guest.
>>>
>>> A hypercall interface is provided for the guest to interrogate the
>>> hypervisor's support for this interface and the location of the shared
>>> memory structures.
>>>
>>> Signed-off-by: Steven Price <steven.price@arm.com>
>>> ---
>>> Documentation/virt/kvm/arm/pvtime.txt | 100 ++++++++++++++++++++++++++
>>> 1 file changed, 100 insertions(+)
>>> create mode 100644 Documentation/virt/kvm/arm/pvtime.txt
>>>
>>> diff --git a/Documentation/virt/kvm/arm/pvtime.txt b/Documentation/virt/kvm/arm/pvtime.txt
>>> new file mode 100644
>>> index 000000000000..1ceb118694e7
>>> --- /dev/null
>>> +++ b/Documentation/virt/kvm/arm/pvtime.txt
>>> @@ -0,0 +1,100 @@
>>> +Paravirtualized time support for arm64
>>> +======================================
>>> +
>>> +Arm specification DEN0057/A defined a standard for paravirtualised time
>>> +support for AArch64 guests:
>>> +
>>> +https://developer.arm.com/docs/den0057/a
>>> +
>>> +KVM/arm64 implements the stolen time part of this specification by providing
>>> +some hypervisor service calls to support a paravirtualized guest obtaining a
>>> +view of the amount of time stolen from its execution.
>>> +
>>> +Two new SMCCC compatible hypercalls are defined:
>>> +
>>> +PV_FEATURES 0xC5000020
>>> +PV_TIME_ST 0xC5000022
>>> +
>>> +These are only available in the SMC64/HVC64 calling convention as
>>> +paravirtualized time is not available to 32 bit Arm guests. The existence of
>>> +the PV_FEATURES hypercall should be probed using the SMCCC 1.1 ARCH_FEATURES
>>> +mechanism before calling it.
>>> +
>>> +PV_FEATURES
>>> + Function ID: (uint32) : 0xC5000020
>>> + PV_func_id: (uint32) : Either PV_TIME_LPT or PV_TIME_ST
>>> + Return value: (int32) : NOT_SUPPORTED (-1) or SUCCESS (0) if the relevant
>>> + PV-time feature is supported by the hypervisor.
>>> +
>>> +PV_TIME_ST
>>> + Function ID: (uint32) : 0xC5000022
>>> + Return value: (int64) : IPA of the stolen time data structure for this
>>> + (V)CPU. On failure:
>>> + NOT_SUPPORTED (-1)
>>> +
>>> +The IPA returned by PV_TIME_ST should be mapped by the guest as normal memory
>>> +with inner and outer write back caching attributes, in the inner shareable
>>> +domain. A total of 16 bytes from the IPA returned are guaranteed to be
>>> +meaningfully filled by the hypervisor (see structure below).
>>> +
>>> +PV_TIME_ST returns the structure for the calling VCPU.
>>> +
>>> +Stolen Time
>>> +-----------
>>> +
>>> +The structure pointed to by the PV_TIME_ST hypercall is as follows:
>>> +
>>> + Field | Byte Length | Byte Offset | Description
>>> + ----------- | ----------- | ----------- | --------------------------
>>> + Revision | 4 | 0 | Must be 0 for version 0.1
>>> + Attributes | 4 | 4 | Must be 0
>>> + Stolen time | 8 | 8 | Stolen time in unsigned
>>> + | | | nanoseconds indicating how
>>> + | | | much time this VCPU thread
>>> + | | | was involuntarily not
>>> + | | | running on a physical CPU.
>>> +
>>> +The structure will be updated by the hypervisor prior to scheduling a VCPU. It
>>> +will be present within a reserved region of the normal memory given to the
>>> +guest. The guest should not attempt to write into this memory. There is a
>>> +structure per VCPU of the guest.
>>> +
>>> +User space interface
>>> +====================
>>> +
>>> +User space can request that KVM provide the paravirtualized time interface to
>>> +a guest by creating a KVM_DEV_TYPE_ARM_PV_TIME device, for example:
>>> +
>>> + struct kvm_create_device pvtime_device = {
>>> + .type = KVM_DEV_TYPE_ARM_PV_TIME,
>>> + .attr = 0,
>>> + .flags = 0,
>>> + };
>>> +
>>> + pvtime_fd = ioctl(vm_fd, KVM_CREATE_DEVICE, &pvtime_device);
>>> +
>>> +Creation of the device should be done after creating the vCPUs of the virtual
>>> +machine.
>>> +
>>> +The IPA of the structures must be given to KVM. This is the base address
>>> +of an array of stolen time structures (one for each VCPU). The base address
>>> +must be page aligned. The size must be at least 64 * number of VCPUs and be a
>>> +multiple of PAGE_SIZE.
>>> +
>>> +The memory for these structures should be added to the guest in the usual
>>> +manner (e.g. using KVM_SET_USER_MEMORY_REGION).
>>> +
>>> +For example:
>>> +
>>> + struct kvm_dev_arm_st_region region = {
>>> + .gpa = <IPA of guest base address>,
>>> + .size = <size in bytes>
>>> + };
>>
>> This feel fragile; how are you handling userspace creating VCPUs after
>> setting this up, the GPA overlapping guest memory, etc. Is the
>> philosophy here that the VMM can mess up the VM if it wants, but that
>> this should never lead attacks on the host (we better hope not) and so
>> we don't care?
>>
>> It seems to me setting the IPA per vcpu throught the VCPU device would
>> avoid a lot of these issues. See
>> Documentation/virt/kvm/devices/vcpu.txt.
>>
>>
> I discussed this with Marc the other day, and we realized that if we
> make the configuration of the IPA per-PE, then a VMM can construct a VM
> where these data structures are distributed within the IPA space of a
> VM, which could lead to a lower TLB pressure for some
> configurations/workloads.
Ok, I'm dubious it will make much difference in terms of TLB pressure,
but I've done the refactoring and I think it actually simplifies the
code. So I'll post a new version where the base address is set via the
VCPU device.
Thanks for the review,
Steve
^ permalink raw reply
* Re: [PATCH] Documentation: add link to stm32mp157 docs
From: Jonathan Corbet @ 2019-08-29 15:44 UTC (permalink / raw)
To: Alexandre Torgue
Cc: Gerald BAEZA, mcoquelin.stm32@gmail.com,
linux-doc@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <5257eff7-418b-8e94-1ced-30718dd3f5dc@st.com>
On Tue, 27 Aug 2019 17:23:30 +0200
Alexandre Torgue <alexandre.torgue@st.com> wrote:
> >> +Datasheet and reference manual are publicly available on ST website:
> >> +.. _STM32MP157: https://www.st.com/en/microcontrollers-microprocessors/stm32mp157.html
> >> +
> >
> > Adding the URL is a fine idea. But you don't need the extra syntax to
> > create a link if you're not going to actually make a link out of it. So
> > I'd take the ".. _STM32MP157:" part out and life will be good.
> >
>
> We also did it for older stm32 product. Idea was to not have the "full"
> address but just a shortcut of the link when html file is read. It maybe
> makes no sens ? (if yes we will have to update older stm32 overview :))
Did you actually run it through Sphinx to see what you get? If I
understand the effect you're after, you want something like this:
The datasheet and reference manual are publicly available on
STM32MP157_.
.. _STM32MP157: https://www.st.com/en/microcontrollers-microprocessors/stm32mp157.html
IOW you have to actually *use* the label you are setting up. That's a fine
way to do it, I guess, though I'm not really convinced it's better than
just putting the URL in directly.
Thanks,
jon
^ permalink raw reply
* Re: [RFC v1 2/2] rcu/tree: Remove dynticks_nmi_nesting counter
From: Paul E. McKenney @ 2019-08-29 16:09 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Frederic Weisbecker, Jonathan Corbet, Josh Triplett,
kernel-team, Lai Jiangshan, linux-doc, Mathieu Desnoyers,
Mauro Carvalho Chehab, rcu, Steven Rostedt, luto
In-Reply-To: <20190829144355.GE63638@google.com>
On Thu, Aug 29, 2019 at 10:43:55AM -0400, Joel Fernandes wrote:
[ . . . ]
> Paul, do we also nuke rcu_eqs_special_set()? Currently I don't see anyone
> using it. And also remove the bottom most bit of dynticks?
>
> Also what happens if a TLB flush broadcast is needed? Do we IPI nohz or idle
> CPUs are the moment?
>
> All of this was introduced in:
> b8c17e6664c4 ("rcu: Maintain special bits at bottom of ->dynticks counter")
Adding Andy Lutomirski on CC.
Andy, is this going to be used in the near term, or should we just get
rid of it?
Thanx, Paul
^ permalink raw reply
* Re: [RFC v1 2/2] rcu/tree: Remove dynticks_nmi_nesting counter
From: Paul E. McKenney @ 2019-08-29 16:13 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Frederic Weisbecker, Jonathan Corbet, Josh Triplett,
kernel-team, Lai Jiangshan, linux-doc, Mathieu Desnoyers,
Mauro Carvalho Chehab, rcu, Steven Rostedt
In-Reply-To: <20190829151325.GF63638@google.com>
On Thu, Aug 29, 2019 at 11:13:25AM -0400, Joel Fernandes wrote:
> On Thu, Aug 29, 2019 at 10:43:55AM -0400, Joel Fernandes wrote:
> > On Wed, Aug 28, 2019 at 08:43:36PM -0700, Paul E. McKenney wrote:
> > [snip]
> > > > > > > This change is not fixing a bug, so there is no need for an emergency fix,
> > > > > > > and thus no point in additional churn. I understand that it is a bit
> > > > > > > annoying to code and test something and have your friendly maintainer say
> > > > > > > "sorry, wrong rocks", and the reason that I understand this is that I do
> > > > > > > that to myself rather often.
> > > > > >
> > > > > > The motivation for me for this change is to avoid future bugs such as with
> > > > > > the following patch where "== 2" did not take the force write of
> > > > > > DYNTICK_IRQ_NONIDLE into account:
> > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git/commit/?h=dev&id=13c4b07593977d9288e5d0c21c89d9ba27e2ea1f
> > > > >
> > > > > Yes, the current code does need some simplification.
> > > > >
> > > > > > I still don't see it as pointless churn, it is also a maintenance cost in its
> > > > > > current form and the simplification is worth it IMHO both from a readability,
> > > > > > and maintenance stand point.
> > > > > >
> > > > > > I still don't see what's technically wrong with the patch. I could perhaps
> > > > > > add the above "== 2" point in the patch?
> > > > >
> > > > > I don't know of a crash or splat your patch would cause, if that is
> > > > > your question. But that is also true of the current code, so the point
> > > > > is simplification, not bug fixing. And from what I can see, there is an
> > > > > opportunity to simplify quite a bit further. And with something like
> > > > > RCU, further simplification is worth -serious- consideration.
> > > > >
> > > > > > We could also discuss f2f at LPC to see if we can agree about it?
> > > > >
> > > > > That might make a lot of sense.
> > > >
> > > > Sure. I am up for a further redesign / simplification. I will think more
> > > > about your suggestions and can also further discuss at LPC.
> > >
> > > One question that might (or might not) help: Given the compound counter,
> > > where the low-order hex digit indicates whether the corresponding CPU
> > > is running in a non-idle kernel task and the rest of the hex digits
> > > indicate the NMI-style nesting counter shifted up by four bits, what
> > > could rcu_is_cpu_rrupt_from_idle() be reduced to?
> > >
> > > > And this patch is on LKML archives and is not going anywhere so there's no
> > > > rush I guess ;-)
> > >
> > > True enough! ;-)
> >
> > Paul, do we also nuke rcu_eqs_special_set()? Currently I don't see anyone
> > using it. And also remove the bottom most bit of dynticks?
> >
> > Also what happens if a TLB flush broadcast is needed? Do we IPI nohz or idle
> > CPUs are the moment?
> >
> > All of this was introduced in:
> > b8c17e6664c4 ("rcu: Maintain special bits at bottom of ->dynticks counter")
>
>
> Paul, also what what happens in the following scenario:
>
> CPU0 CPU1
>
> A syscall causes rcu_eqs_exit()
> rcu_read_lock();
> ---> FQS loop waiting on
> dyntick_snap
> usermode-upcall entry -->causes rcu_eqs_enter();
>
> usermode-upcall exit -->causes rcu_eqs_exit();
>
> ---> FQS loop sees
> dyntick snap
> increment and
> declares CPU0 is
> in a QS state
> before the
> rcu_read_unlock!
>
> rcu_read_unlock();
> ---
>
> Does the context tracking not call rcu_user_enter() in this case, or did I
> really miss something?
Holding rcu_read_lock() across usermode execution (in this case,
the usermode upcall) is a bad idea. Why is CPU 0 doing that?
Thanx, Paul
^ permalink raw reply
* Re: [RFC v1 2/2] rcu/tree: Remove dynticks_nmi_nesting counter
From: Andy Lutomirski @ 2019-08-29 16:21 UTC (permalink / raw)
To: paulmck
Cc: Joel Fernandes, LKML, Frederic Weisbecker, Jonathan Corbet,
Josh Triplett, Android Kernel Team, Lai Jiangshan,
open list:DOCUMENTATION, Mathieu Desnoyers, Mauro Carvalho Chehab,
rcu, Steven Rostedt, Andrew Lutomirski
In-Reply-To: <20190829160946.GP4125@linux.ibm.com>
On Thu, Aug 29, 2019 at 9:10 AM Paul E. McKenney <paulmck@kernel.org> wrote:
>
> On Thu, Aug 29, 2019 at 10:43:55AM -0400, Joel Fernandes wrote:
>
> [ . . . ]
>
> > Paul, do we also nuke rcu_eqs_special_set()? Currently I don't see anyone
> > using it. And also remove the bottom most bit of dynticks?
> >
> > Also what happens if a TLB flush broadcast is needed? Do we IPI nohz or idle
> > CPUs are the moment?
> >
> > All of this was introduced in:
> > b8c17e6664c4 ("rcu: Maintain special bits at bottom of ->dynticks counter")
>
> Adding Andy Lutomirski on CC.
>
> Andy, is this going to be used in the near term, or should we just get
> rid of it?
>
Let's get rid of it. I'm not actually convinced it *can* be used as designed.
For those who forgot the history or weren't cc'd on all of it: I had
this clever idea about how we could reduce TLB flushes. I implemented
some of it (but not the part that would have used this RCU feature),
and it exploded in nasty and subtle ways. This caused me to learn
that speculative TLB fills were a problem that I had entirely failed
to account for. Then PTI happened and thoroughly muddied the water.
So I think we should just drop this :(
^ permalink raw reply
* Re: [RFC v1 2/2] rcu/tree: Remove dynticks_nmi_nesting counter
From: Paul E. McKenney @ 2019-08-29 16:32 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Frederic Weisbecker, Jonathan Corbet, Josh Triplett,
kernel-team, Lai Jiangshan, linux-doc, Mathieu Desnoyers,
Mauro Carvalho Chehab, rcu, Steven Rostedt
In-Reply-To: <20190829135907.GC63638@google.com>
On Thu, Aug 29, 2019 at 09:59:07AM -0400, Joel Fernandes wrote:
> On Wed, Aug 28, 2019 at 08:43:36PM -0700, Paul E. McKenney wrote:
> [snip]
> > On the tracing patch... That patch might be a good idea regardless,
> > but I bet that the reason that you felt the sudden need for it was due
> > to the loss of information in your eventual ->dynticks_nesting field.
> > After all, the value 0x1 might be an interrupt from idle, or it might
> > just as easily be a task running in the kernel at process level.
>
> True, however what really triggered me to do it was the existing code which
> does not distinguish between entry/exit from USER and IDLE.
>
> > The reason the patch might nevertheless be a good idea is that redundant
> > information can be helpful when debugging. Especially when debugging
> > new architecture-specific code, which is when RCU's dyntick-idle warnings
> > tend to find bugs.
>
> Sure, and also that it is more readable to ordinary human beings than "++="
> and "--=" :-D.
And those considerations did figure into my deciding that the tracing
change was likely a good thing in any case. ;-)
Thanx, Paul
^ permalink raw reply
* Re: [PATCH v10 0/7] Solve postboot supplier cleanup and optimize probe ordering
From: Rob Herring @ 2019-08-29 16:43 UTC (permalink / raw)
To: Saravana Kannan
Cc: Mark Rutland, Greg Kroah-Hartman, Rafael J. Wysocki, Frank Rowand,
Jonathan Corbet, Len Brown, devicetree,
linux-kernel@vger.kernel.org, Linux Doc Mailing List, linux-acpi,
clang-built-linux, David Collins, Android Kernel Team
In-Reply-To: <20190829074603.70424-1-saravanak@google.com>
On Thu, Aug 29, 2019 at 2:46 AM Saravana Kannan <saravanak@google.com> wrote:
>
> Add device-links to track functional dependencies between devices
> after they are created (but before they are probed) by looking at
> their common DT bindings like clocks, interconnects, etc.
>
> Having functional dependencies automatically added before the devices
> are probed, provides the following benefits:
>
> - Optimizes device probe order and avoids the useless work of
> attempting probes of devices that will not probe successfully
> (because their suppliers aren't present or haven't probed yet).
>
> For example, in a commonly available mobile SoC, registering just
> one consumer device's driver at an initcall level earlier than the
> supplier device's driver causes 11 failed probe attempts before the
> consumer device probes successfully. This was with a kernel with all
> the drivers statically compiled in. This problem gets a lot worse if
> all the drivers are loaded as modules without direct symbol
> dependencies.
>
> - Supplier devices like clock providers, interconnect providers, etc
> need to keep the resources they provide active and at a particular
> state(s) during boot up even if their current set of consumers don't
> request the resource to be active. This is because the rest of the
> consumers might not have probed yet and turning off the resource
> before all the consumers have probed could lead to a hang or
> undesired user experience.
>
> Some frameworks (Eg: regulator) handle this today by turning off
> "unused" resources at late_initcall_sync and hoping all the devices
> have probed by then. This is not a valid assumption for systems with
> loadable modules. Other frameworks (Eg: clock) just don't handle
> this due to the lack of a clear signal for when they can turn off
> resources. This leads to downstream hacks to handle cases like this
> that can easily be solved in the upstream kernel.
>
> By linking devices before they are probed, we give suppliers a clear
> count of the number of dependent consumers. Once all of the
> consumers are active, the suppliers can turn off the unused
> resources without making assumptions about the number of consumers.
>
> By default we just add device-links to track "driver presence" (probe
> succeeded) of the supplier device. If any other functionality provided
> by device-links are needed, it is left to the consumer/supplier
> devices to change the link when they probe.
>
> v1 -> v2:
> - Drop patch to speed up of_find_device_by_node()
> - Drop depends-on property and use existing bindings
>
> v2 -> v3:
> - Refactor the code to have driver core initiate the linking of devs
> - Have driver core link consumers to supplier before it's probed
> - Add support for drivers to edit the device links before probing
>
> v3 -> v4:
> - Tested edit_links() on system with cyclic dependency. Works.
> - Added some checks to make sure device link isn't attempted from
> parent device node to child device node.
> - Added way to pause/resume sync_state callbacks across
> of_platform_populate().
> - Recursively parse DT node to create device links from parent to
> suppliers of parent and all child nodes.
>
> v4 -> v5:
> - Fixed copy-pasta bugs with linked list handling
> - Walk up the phandle reference till I find an actual device (needed
> for regulators to work)
> - Added support for linking devices from regulator DT bindings
> - Tested the whole series again to make sure cyclic dependencies are
> broken with edit_links() and regulator links are created properly.
>
> v5 -> v6:
> - Split, squashed and reordered some of the patches.
> - Refactored the device linking code to follow the same code pattern for
> any property.
>
> v6 -> v7:
> - No functional changes.
> - Renamed i to index
> - Added comment to clarify not having to check property name for every
> index
> - Added "matched" variable to clarify code. No functional change.
> - Added comments to include/linux/device.h for add_links()
>
> v7 -> v8:
> - Rebased on top of linux-next to handle device link changes in [1]
>
> v8 -> v9:
> - Fixed kbuild test bot reported errors (docs and const)
>
> v9->v10:
> - Changes made based on reviews on LKML [2] and discussions at ELC [3]
> - Dropped the edit_links() patch
> - Dropped the patch that skips linking for default bus nodes
> - 1/7: Changed from bus.add_links() to fwnode.ops.add_links()
> - 1/7: Update device link doc
> - 1/7: Lots of comments/fn doc updates
> - 1/7: Renamed device_link_check_waiting_consumers() to
> device_link_add_missing_supplier_links()
> - 2/7: Moved DT parsing/linking code from of/platform.c to of/property.c
Why? You'll notice that of/property.c doesn't know anything about
platform_device (and struct device):
$ git grep platform_device -- drivers/of/property.c
$
Everything related to platform_device goes in of/platform.c.
Everything related to struct device only goes in of/device.c. I'd be
okay with a new file for this too.
Rob
^ permalink raw reply
* Re: [PATCH v10 2/7] of: property: Add functional dependency link from DT bindings
From: Rob Herring @ 2019-08-29 16:51 UTC (permalink / raw)
To: Saravana Kannan
Cc: Mark Rutland, Greg Kroah-Hartman, Rafael J. Wysocki, Frank Rowand,
Jonathan Corbet, Len Brown, devicetree,
linux-kernel@vger.kernel.org, Linux Doc Mailing List, linux-acpi,
clang-built-linux, David Collins, Android Kernel Team,
kbuild test robot
In-Reply-To: <20190829074603.70424-3-saravanak@google.com>
On Thu, Aug 29, 2019 at 2:46 AM Saravana Kannan <saravanak@google.com> wrote:
>
> Add device links after the devices are created (but before they are
> probed) by looking at common DT bindings like clocks and
> interconnects.
>
> Automatically adding device links for functional dependencies at the
> framework level provides the following benefits:
>
> - Optimizes device probe order and avoids the useless work of
> attempting probes of devices that will not probe successfully
> (because their suppliers aren't present or haven't probed yet).
>
> For example, in a commonly available mobile SoC, registering just
> one consumer device's driver at an initcall level earlier than the
> supplier device's driver causes 11 failed probe attempts before the
> consumer device probes successfully. This was with a kernel with all
> the drivers statically compiled in. This problem gets a lot worse if
> all the drivers are loaded as modules without direct symbol
> dependencies.
>
> - Supplier devices like clock providers, interconnect providers, etc
> need to keep the resources they provide active and at a particular
> state(s) during boot up even if their current set of consumers don't
> request the resource to be active. This is because the rest of the
> consumers might not have probed yet and turning off the resource
> before all the consumers have probed could lead to a hang or
> undesired user experience.
>
> Some frameworks (Eg: regulator) handle this today by turning off
> "unused" resources at late_initcall_sync and hoping all the devices
> have probed by then. This is not a valid assumption for systems with
> loadable modules. Other frameworks (Eg: clock) just don't handle
> this due to the lack of a clear signal for when they can turn off
> resources. This leads to downstream hacks to handle cases like this
> that can easily be solved in the upstream kernel.
>
> By linking devices before they are probed, we give suppliers a clear
> count of the number of dependent consumers. Once all of the
> consumers are active, the suppliers can turn off the unused
> resources without making assumptions about the number of consumers.
>
> By default we just add device-links to track "driver presence" (probe
> succeeded) of the supplier device. If any other functionality provided
> by device-links are needed, it is left to the consumer/supplier
> devices to change the link when they probe.
>
> kbuild test robot reported clang error about missing const
> Reported-by: kbuild test robot <lkp@intel.com>
> Signed-off-by: Saravana Kannan <saravanak@google.com>
> ---
> .../admin-guide/kernel-parameters.rst | 1 +
> .../admin-guide/kernel-parameters.txt | 6 +
> drivers/of/property.c | 241 ++++++++++++++++++
> 3 files changed, 248 insertions(+)
> +static int of_link_to_phandle(struct device *dev, struct device_node *sup_np)
> +{
> + struct platform_device *sup_dev;
> + u32 dl_flags = DL_FLAG_AUTOPROBE_CONSUMER;
> + int ret = 0;
> + struct device_node *tmp_np = sup_np;
> +
> + of_node_get(sup_np);
> + /*
> + * Find the device node that contains the supplier phandle. It may be
> + * @sup_np or it may be an ancestor of @sup_np.
> + */
> + while (sup_np && !of_find_property(sup_np, "compatible", NULL))
> + sup_np = of_get_next_parent(sup_np);
> + if (!sup_np) {
> + dev_dbg(dev, "Not linking to %pOFP - No device\n", tmp_np);
> + return -ENODEV;
> + }
> +
> + /*
> + * Don't allow linking a device node as a consumer of one of its
> + * descendant nodes. By definition, a child node can't be a functional
> + * dependency for the parent node.
> + */
> + if (!of_is_ancestor_of(dev->of_node, sup_np)) {
> + dev_dbg(dev, "Not linking to %pOFP - is descendant\n", sup_np);
> + of_node_put(sup_np);
> + return -EINVAL;
> + }
> + sup_dev = of_find_device_by_node(sup_np);
What if the supplier isn't a platform_device? A regulator supply is
quite likely not.
Rob
^ permalink raw reply
* Re: [RFC v1 2/2] rcu/tree: Remove dynticks_nmi_nesting counter
From: Paul E. McKenney @ 2019-08-29 16:54 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Joel Fernandes, LKML, Frederic Weisbecker, Jonathan Corbet,
Josh Triplett, Android Kernel Team, Lai Jiangshan,
open list:DOCUMENTATION, Mathieu Desnoyers, Mauro Carvalho Chehab,
rcu, Steven Rostedt
In-Reply-To: <CALCETrWNPOOdTrFabTDd=H7+wc6xJ9rJceg6OL1S0rTV5pfSsA@mail.gmail.com>
On Thu, Aug 29, 2019 at 09:21:46AM -0700, Andy Lutomirski wrote:
> On Thu, Aug 29, 2019 at 9:10 AM Paul E. McKenney <paulmck@kernel.org> wrote:
> >
> > On Thu, Aug 29, 2019 at 10:43:55AM -0400, Joel Fernandes wrote:
> >
> > [ . . . ]
> >
> > > Paul, do we also nuke rcu_eqs_special_set()? Currently I don't see anyone
> > > using it. And also remove the bottom most bit of dynticks?
> > >
> > > Also what happens if a TLB flush broadcast is needed? Do we IPI nohz or idle
> > > CPUs are the moment?
> > >
> > > All of this was introduced in:
> > > b8c17e6664c4 ("rcu: Maintain special bits at bottom of ->dynticks counter")
> >
> > Adding Andy Lutomirski on CC.
> >
> > Andy, is this going to be used in the near term, or should we just get
> > rid of it?
>
> Let's get rid of it. I'm not actually convinced it *can* be used as designed.
>
> For those who forgot the history or weren't cc'd on all of it: I had
> this clever idea about how we could reduce TLB flushes. I implemented
> some of it (but not the part that would have used this RCU feature),
> and it exploded in nasty and subtle ways. This caused me to learn
> that speculative TLB fills were a problem that I had entirely failed
> to account for. Then PTI happened and thoroughly muddied the water.
Yeah, PTI was quite annoying. Still is, from what I can see. :-/
> So I think we should just drop this :(
OK, thank you! I will put a tag into -rcu marking its removal in case
it should prove useful whenever for whatever.
Joel, would you like to remove this, or would you rather that I did?
It is in code you are working with right now, so if I do it, I need to
wait until yours is finalized. Which wouldn't be a problem.
Thanx, Paul
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox