* Re: [V6, 1/2] media: dt-bindings: media: i2c: Document DW9768 bindings
From: Rob Herring @ 2020-05-18 14:31 UTC (permalink / raw)
To: Tomasz Figa
Cc: Mark Rutland, linux-devicetree, Andy Shevchenko, srv_heupstream,
Linus Walleij, Shengnan Wang (王圣男),
Louis Kuo, Bartosz Golaszewski, Sj Huang, Nicolas Boichat,
moderated list:ARM/Mediatek SoC support, Dongchun Zhu,
Sakari Ailus, Matthias Brugger, Cao Bing Bu,
Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
In-Reply-To: <CAAFQd5Byvc8Fb0f3_81xSKsuyvsQJm-8g8y1Kx2aUcC=PwpS7w@mail.gmail.com>
On Mon, May 18, 2020 at 04:12:28PM +0200, Tomasz Figa wrote:
> Hi Dongchun,
>
> On Mon, May 18, 2020 at 3:29 PM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> >
> > Add DeviceTree binding documentation for Dongwoon Anatech DW9768 voice
> > coil actuator.
>
> Thanks for the patch. Please see my comments below.
>
> >
> > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > Reviewed-by: Rob Herring <robh@kernel.org>
>
> This version includes significant changes, so the reviewed-by tag
> shouldn't have been carried out.
>
> > ---
> > .../bindings/media/i2c/dongwoon,dw9768.yaml | 105 +++++++++++++++++++++
> > MAINTAINERS | 7 ++
> > 2 files changed, 112 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml
> > new file mode 100644
> > index 0000000..b909e83
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml
> > @@ -0,0 +1,105 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +# Copyright (c) 2020 MediaTek Inc.
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/media/i2c/dongwoon,dw9768.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Dongwoon Anatech DW9768 Voice Coil Motor (VCM) Lens Device Tree Bindings
> > +
> > +maintainers:
> > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > +
> > +description: |-
> > + The Dongwoon DW9768 is a single 10-bit digital-to-analog (DAC) converter
> > + with 100 mA output current sink capability. VCM current is controlled with
> > + a linear mode driver. The DAC is controlled via a 2-wire (I2C-compatible)
> > + serial interface that operates at clock rates up to 1MHz. This chip
> > + integrates Advanced Actuator Control (AAC) technology and is intended for
> > + driving voice coil lenses in camera modules.
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + # for DW9768 VCM
> > + - dongwoon,dw9768
> > + # for GT9769 VCM
> > + - giantec,gt9769
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + vin-supply:
> > + description:
> > + Definition of the regulator used as I2C I/O interface power supply.
> > +
> > + vdd-supply:
> > + description:
> > + Definition of the regulator used as VCM chip power supply.
> > +
> > + dongwoon,aac-mode:
> > + description:
> > + Indication of AAC mode select.
> > + allOf:
> > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > + - enum:
> > + - 0 # Direct (default)
Default can be expressed as 'default: 0'.
> > + - 1 # AAC2 (operation time# 0.48 x Tvib)
> > + - 2 # AAC3 (operation time# 0.70 x Tvib)
> > + - 3 # AAC4 (operation time# 0.75 x Tvib)
> > + - 4 # Reserved
> > + - 5 # AAC8 (operation time# 1.13 x Tvib)
> > + - 6 # Reserved
> > + - 7 # Reserved
>
> I'll ultimately leave it to DT maintainers, but is there any reason to
> define the reserved values?
No.
>
> > +
> > + dongwoon,aac-timing:
> > + description:
> > + Indication of AAC Timing count, unit of 0.1 milliseconds.
Why not just use standard units (-us)?
> > + Valid values vary from 0 to 63 (default 32).
Looks like constraints.
> > + allOf:
> > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > +
> > + dongwoon,clock-dividing-rate:
> > + description:
> > + Indication of VCM internal clock dividing rate select, as one multiple
> > + factor to calculate VCM ring periodic time Tvib.
> > + allOf:
> > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > + - enum:
> > + - 0 # Dividing Rate - 2
> > + - 1 # Dividing Rate - 1 (default)
> > + - 2 # Dividing Rate - 1/2
> > + - 3 # Dividing Rate - 1/4
> > + - 4 # Dividing Rate - 8
> > + - 5 # Dividing Rate - 4
> > + - 6 # Dividing Rate - Reserved
> > + - 7 # Dividing Rate - Reserved
>
> Ditto.
>
> Best regards,
> Tomasz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC] arm64: Enable perf events based hard lockup detector
From: Mark Rutland @ 2020-05-18 14:34 UTC (permalink / raw)
To: Sumit Garg
Cc: daniel.thompson, peterz, catalin.marinas, jolsa, dianders, acme,
alexander.shishkin, mingo, julien.thierry.kdev, namhyung, tglx,
will, linux-arm-kernel
In-Reply-To: <1589532593-16428-1-git-send-email-sumit.garg@linaro.org>
Hi Sumit,
On Fri, May 15, 2020 at 02:19:53PM +0530, Sumit Garg wrote:
> With the recent feature added to enable perf events to use pseudo NMIs
> as interrupts on platforms which support GICv3 or later, its now been
> possible to enable hard lockup detector (or NMI watchdog) on arm64
> platforms. So enable corresponding support.
Where/when do we expect to see this used?
I thought for server systems we'd expect to have the SBSA watchdog, so
why would we need this?
> One thing to note here is that normally lockup detector is initialized
> just after the early initcalls but PMU on arm64 comes up much later as
> device_initcall(). So we need to re-initialize lockup detection once
> PMU has been initialized.
>
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> ---
>
> This patch is dependent on perf NMI patch-set [1].
>
> [1] https://patchwork.kernel.org/cover/11047407/
>
> arch/arm64/Kconfig | 2 ++
> arch/arm64/kernel/perf_event.c | 32 ++++++++++++++++++++++++++++++--
> drivers/perf/arm_pmu.c | 11 +++++++++++
> include/linux/perf/arm_pmu.h | 2 ++
> 4 files changed, 45 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 40fb05d..36f75c2 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -160,6 +160,8 @@ config ARM64
> select HAVE_NMI
> select HAVE_PATA_PLATFORM
> select HAVE_PERF_EVENTS
> + select HAVE_PERF_EVENTS_NMI if ARM64_PSEUDO_NMI
> + select HAVE_HARDLOCKUP_DETECTOR_PERF if PERF_EVENTS && HAVE_PERF_EVENTS_NMI
> select HAVE_PERF_REGS
> select HAVE_PERF_USER_STACK_DUMP
> select HAVE_REGS_AND_STACK_ACCESS_API
> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
> index 3ad5c8f..df57360 100644
> --- a/arch/arm64/kernel/perf_event.c
> +++ b/arch/arm64/kernel/perf_event.c
> @@ -20,6 +20,8 @@
> #include <linux/perf/arm_pmu.h>
> #include <linux/platform_device.h>
> #include <linux/smp.h>
> +#include <linux/nmi.h>
> +#include <linux/cpufreq.h>
>
> /* ARMv8 Cortex-A53 specific event types. */
> #define ARMV8_A53_PERFCTR_PREF_LINEFILL 0xC2
> @@ -1190,10 +1192,21 @@ static struct platform_driver armv8_pmu_driver = {
>
> static int __init armv8_pmu_driver_init(void)
> {
> + int ret;
> +
> if (acpi_disabled)
> - return platform_driver_register(&armv8_pmu_driver);
> + ret = platform_driver_register(&armv8_pmu_driver);
> else
> - return arm_pmu_acpi_probe(armv8_pmuv3_init);
> + ret = arm_pmu_acpi_probe(armv8_pmuv3_init);
> +
> + /*
> + * Try to re-initialize lockup detector after PMU init in
> + * case PMU events are triggered via NMIs.
> + */
> + if (arm_pmu_irq_is_nmi())
> + lockup_detector_init();
> +
> + return ret;
> }
> device_initcall(armv8_pmu_driver_init)
>
> @@ -1225,3 +1238,18 @@ void arch_perf_update_userpage(struct perf_event *event,
> userpg->time_shift = (u16)shift;
> userpg->time_offset = -now;
> }
> +
> +#ifdef CONFIG_HARDLOCKUP_DETECTOR_PERF
> +#define SAFE_MAX_CPU_FREQ 4000000000UL // 4 GHz
Why is 4GHz "safe"?
There's no architectural requirement on max frequency, and it's
conceviable that there could be parts faster than this.
If the frequency is critical, then we should bail out when it is
unknown rather than guessing. If it is not cirital then we should
explain what the requirements are and why using a hard-coded value is
sane.
> +u64 hw_nmi_get_sample_period(int watchdog_thresh)
> +{
> + unsigned int cpu = smp_processor_id();
> + unsigned int max_cpu_freq;
> +
> + max_cpu_freq = cpufreq_get_hw_max_freq(cpu);
> + if (max_cpu_freq)
> + return (u64)max_cpu_freq * 1000 * watchdog_thresh;
> + else
> + return (u64)SAFE_MAX_CPU_FREQ * watchdog_thresh;
> +}
I take it this uses CPU cycles?
AFAIK those can be gated in idle/retention states (e.g. for WFI/WFE or
any other instruction that could block). So if the CPU were blocked on
one of those, the counter would never overflow and trigger the
interrupt.
i.e. this isn't going to detect a hard lockup of that sort.
> +#endif
> diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
> index f96cfc4..691dfc9 100644
> --- a/drivers/perf/arm_pmu.c
> +++ b/drivers/perf/arm_pmu.c
> @@ -718,6 +718,17 @@ static int armpmu_get_cpu_irq(struct arm_pmu *pmu, int cpu)
> return per_cpu(hw_events->irq, cpu);
> }
>
> +bool arm_pmu_irq_is_nmi(void)
> +{
> + const struct pmu_irq_ops *irq_ops;
> +
> + irq_ops = per_cpu(cpu_irq_ops, smp_processor_id());
> + if (irq_ops == &pmunmi_ops || irq_ops == &percpu_pmunmi_ops)
> + return true;
> + else
> + return false;
You can simplify:
| if (x)
| return true;
| else
| return false;
... to:
| return x;
Thanks,
Mark.
> +}
> +
> /*
> * PMU hardware loses all context when a CPU goes offline.
> * When a CPU is hotplugged back in, since some hardware registers are
> diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
> index d9b8b76..a71f029 100644
> --- a/include/linux/perf/arm_pmu.h
> +++ b/include/linux/perf/arm_pmu.h
> @@ -155,6 +155,8 @@ int arm_pmu_acpi_probe(armpmu_init_fn init_fn);
> static inline int arm_pmu_acpi_probe(armpmu_init_fn init_fn) { return 0; }
> #endif
>
> +bool arm_pmu_irq_is_nmi(void);
> +
> /* Internal functions only for core arm_pmu code */
> struct arm_pmu *armpmu_alloc(void);
> struct arm_pmu *armpmu_alloc_atomic(void);
> --
> 2.7.4
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 10/15] net: ethernet: mtk-eth-mac: new driver
From: Arnd Bergmann @ 2020-05-18 14:38 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Edwin Peer, DTML, Bartosz Golaszewski, Stephane Le Provost,
Jonathan Corbet, Networking, Sean Wang,
linux-kernel@vger.kernel.org, Pedro Tsai, Mark Lee, Fabien Parent,
Rob Herring, moderated list:ARM/Mediatek SoC..., Andrew Perepech,
John Crispin, Matthias Brugger, Jakub Kicinski, David S . Miller,
Linux ARM, Heiner Kallweit
In-Reply-To: <CAMRc=MeVyNzTWw_hk=J9kX1NE9reCE_O4P3wrNpMMc9z4xA_DA@mail.gmail.com>
On Mon, May 18, 2020 at 4:07 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> pt., 15 maj 2020 o 15:32 Arnd Bergmann <arnd@arndb.de> napisał(a):
> > I would get rid of the 'count' here, as it duplicates the information
> > that is already known from the difference between head and tail, and you
> > can't update it atomically without holding a lock around the access to
> > the ring. The way I'd do this is to have the head and tail pointers
> > in separate cache lines, and then use READ_ONCE/WRITE_ONCE
> > and smp barriers to access them, with each one updated on one
> > thread but read by the other.
> >
>
> Your previous solution seems much more reliable though. For instance
> in the above: when we're doing the TX cleanup (we got the TX ready
> irq, we're iterating over descriptors until we know there are no more
> packets scheduled (count == 0) or we encounter one that's still owned
> by DMA), a parallel TX path can schedule new packets to be sent and I
> don't see how we can atomically check the count (understood as a
> difference between tail and head) and run a new iteration (where we'd
> modify the head or tail) without risking the other path getting in the
> way. We'd have to always check the descriptor.
It should be enough to read both pointers once at the start of each
side, then do whatever work you want to do (cleaning, sending,
receiving, refilling) and finally updating the one pointer that changed.
If both sides do that, you minimize the cache line bouncing and
always do a useful amount of work that guarantees forward progress
and does not interfere with the other side.
> I experimented a bit with this and couldn't come up with anything that
> would pass any stress test.
>
> On the other hand: spin_lock_bh() works fine and I like your approach
> from the previous e-mail - except for the work for updating stats as
> we could potentially lose some stats when we're updating in process
> context with RX/TX paths running in parallel in napi context but that
> would be rare enough to overlook it.
>
> I hope v4 will be good enough even with spinlocks. :)
Yes, it should be fine. Avoiding all the locks is mainly an optimization
for the number of CPU cycles spent per packet, the other points
are more important to get right, in particular the flow control.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] dt-bindings: clock: Convert i.MX7D clock to json-schema
From: Fabio Estevam @ 2020-05-18 14:45 UTC (permalink / raw)
To: Anson Huang
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Frank Li, Stephen Boyd, Michael Turquette, linux-kernel,
linux-clk, Rob Herring, NXP Linux Team, Sascha Hauer, Shawn Guo,
Sascha Hauer,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <1589810819-19851-1-git-send-email-Anson.Huang@nxp.com>
On Mon, May 18, 2020 at 11:16 AM Anson Huang <Anson.Huang@nxp.com> wrote:
> +maintainers:
> + - Frank Li <Frank.Li@freescale.com>
The freescale.com e-mail domain is no longer valid for quite some time :-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC] arm64: Enable perf events based hard lockup detector
From: Daniel Thompson @ 2020-05-18 14:52 UTC (permalink / raw)
To: Mark Rutland
Cc: Sumit Garg, peterz, catalin.marinas, jolsa, dianders, acme,
alexander.shishkin, mingo, julien.thierry.kdev, namhyung, tglx,
will, linux-arm-kernel
In-Reply-To: <20200518143455.GB3164@C02TD0UTHF1T.local>
On Mon, May 18, 2020 at 03:34:55PM +0100, Mark Rutland wrote:
> Hi Sumit,
>
> On Fri, May 15, 2020 at 02:19:53PM +0530, Sumit Garg wrote:
> > With the recent feature added to enable perf events to use pseudo NMIs
> > as interrupts on platforms which support GICv3 or later, its now been
> > possible to enable hard lockup detector (or NMI watchdog) on arm64
> > platforms. So enable corresponding support.
>
> Where/when do we expect to see this used?
>
> I thought for server systems we'd expect to have the SBSA watchdog, so
> why would we need this?
I view the lockup detector as a debug tool rather than a traditional
watchdog.
Certainly kernel machinery that prints the stack trace of a CPU that
has got wedged in a manner where it cannot service interrupts should
have fairly obvious applications for debugging embedded systems.
Daniel.
>
> > One thing to note here is that normally lockup detector is initialized
> > just after the early initcalls but PMU on arm64 comes up much later as
> > device_initcall(). So we need to re-initialize lockup detection once
> > PMU has been initialized.
> >
> > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > ---
> >
> > This patch is dependent on perf NMI patch-set [1].
> >
> > [1] https://patchwork.kernel.org/cover/11047407/
> >
> > arch/arm64/Kconfig | 2 ++
> > arch/arm64/kernel/perf_event.c | 32 ++++++++++++++++++++++++++++++--
> > drivers/perf/arm_pmu.c | 11 +++++++++++
> > include/linux/perf/arm_pmu.h | 2 ++
> > 4 files changed, 45 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index 40fb05d..36f75c2 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -160,6 +160,8 @@ config ARM64
> > select HAVE_NMI
> > select HAVE_PATA_PLATFORM
> > select HAVE_PERF_EVENTS
> > + select HAVE_PERF_EVENTS_NMI if ARM64_PSEUDO_NMI
> > + select HAVE_HARDLOCKUP_DETECTOR_PERF if PERF_EVENTS && HAVE_PERF_EVENTS_NMI
> > select HAVE_PERF_REGS
> > select HAVE_PERF_USER_STACK_DUMP
> > select HAVE_REGS_AND_STACK_ACCESS_API
> > diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
> > index 3ad5c8f..df57360 100644
> > --- a/arch/arm64/kernel/perf_event.c
> > +++ b/arch/arm64/kernel/perf_event.c
> > @@ -20,6 +20,8 @@
> > #include <linux/perf/arm_pmu.h>
> > #include <linux/platform_device.h>
> > #include <linux/smp.h>
> > +#include <linux/nmi.h>
> > +#include <linux/cpufreq.h>
> >
> > /* ARMv8 Cortex-A53 specific event types. */
> > #define ARMV8_A53_PERFCTR_PREF_LINEFILL 0xC2
> > @@ -1190,10 +1192,21 @@ static struct platform_driver armv8_pmu_driver = {
> >
> > static int __init armv8_pmu_driver_init(void)
> > {
> > + int ret;
> > +
> > if (acpi_disabled)
> > - return platform_driver_register(&armv8_pmu_driver);
> > + ret = platform_driver_register(&armv8_pmu_driver);
> > else
> > - return arm_pmu_acpi_probe(armv8_pmuv3_init);
> > + ret = arm_pmu_acpi_probe(armv8_pmuv3_init);
> > +
> > + /*
> > + * Try to re-initialize lockup detector after PMU init in
> > + * case PMU events are triggered via NMIs.
> > + */
> > + if (arm_pmu_irq_is_nmi())
> > + lockup_detector_init();
> > +
> > + return ret;
> > }
> > device_initcall(armv8_pmu_driver_init)
> >
> > @@ -1225,3 +1238,18 @@ void arch_perf_update_userpage(struct perf_event *event,
> > userpg->time_shift = (u16)shift;
> > userpg->time_offset = -now;
> > }
> > +
> > +#ifdef CONFIG_HARDLOCKUP_DETECTOR_PERF
> > +#define SAFE_MAX_CPU_FREQ 4000000000UL // 4 GHz
>
> Why is 4GHz "safe"?
>
> There's no architectural requirement on max frequency, and it's
> conceviable that there could be parts faster than this.
>
> If the frequency is critical, then we should bail out when it is
> unknown rather than guessing. If it is not cirital then we should
> explain what the requirements are and why using a hard-coded value is
> sane.
>
> > +u64 hw_nmi_get_sample_period(int watchdog_thresh)
> > +{
> > + unsigned int cpu = smp_processor_id();
> > + unsigned int max_cpu_freq;
> > +
> > + max_cpu_freq = cpufreq_get_hw_max_freq(cpu);
> > + if (max_cpu_freq)
> > + return (u64)max_cpu_freq * 1000 * watchdog_thresh;
> > + else
> > + return (u64)SAFE_MAX_CPU_FREQ * watchdog_thresh;
> > +}
>
> I take it this uses CPU cycles?
>
> AFAIK those can be gated in idle/retention states (e.g. for WFI/WFE or
> any other instruction that could block). So if the CPU were blocked on
> one of those, the counter would never overflow and trigger the
> interrupt.
>
> i.e. this isn't going to detect a hard lockup of that sort.
>
> > +#endif
> > diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
> > index f96cfc4..691dfc9 100644
> > --- a/drivers/perf/arm_pmu.c
> > +++ b/drivers/perf/arm_pmu.c
> > @@ -718,6 +718,17 @@ static int armpmu_get_cpu_irq(struct arm_pmu *pmu, int cpu)
> > return per_cpu(hw_events->irq, cpu);
> > }
> >
> > +bool arm_pmu_irq_is_nmi(void)
> > +{
> > + const struct pmu_irq_ops *irq_ops;
> > +
> > + irq_ops = per_cpu(cpu_irq_ops, smp_processor_id());
> > + if (irq_ops == &pmunmi_ops || irq_ops == &percpu_pmunmi_ops)
> > + return true;
> > + else
> > + return false;
>
> You can simplify:
>
> | if (x)
> | return true;
> | else
> | return false;
>
> ... to:
>
> | return x;
>
> Thanks,
> Mark.
>
> > +}
> > +
> > /*
> > * PMU hardware loses all context when a CPU goes offline.
> > * When a CPU is hotplugged back in, since some hardware registers are
> > diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
> > index d9b8b76..a71f029 100644
> > --- a/include/linux/perf/arm_pmu.h
> > +++ b/include/linux/perf/arm_pmu.h
> > @@ -155,6 +155,8 @@ int arm_pmu_acpi_probe(armpmu_init_fn init_fn);
> > static inline int arm_pmu_acpi_probe(armpmu_init_fn init_fn) { return 0; }
> > #endif
> >
> > +bool arm_pmu_irq_is_nmi(void);
> > +
> > /* Internal functions only for core arm_pmu code */
> > struct arm_pmu *armpmu_alloc(void);
> > struct arm_pmu *armpmu_alloc_atomic(void);
> > --
> > 2.7.4
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/3] Covert i.MX GPT/TPM/SYSCTR timer binding to json-schema
From: Anson Huang @ 2020-05-18 14:47 UTC (permalink / raw)
To: daniel.lezcano, tglx, robh+dt, shawnguo, s.hauer, kernel,
festevam, ping.bai, aisheng.dong, linux-kernel, devicetree,
linux-arm-kernel
Cc: Linux-imx
This patch series converts i.MX GPT, TPM and system counter timer binding
to json-schema, test build passed.
Anson Huang (3):
dt-bindings: timer: Convert i.MX GPT to json-schema
dt-bindings: timer: Convert i.MX TPM to json-schema
dt-bindings: timer: Convert i.MX SYSCTR to json-schema
.../devicetree/bindings/timer/fsl,imxgpt.txt | 45 ---------
.../devicetree/bindings/timer/fsl,imxgpt.yaml | 109 +++++++++++++++++++++
.../devicetree/bindings/timer/nxp,sysctr-timer.txt | 25 -----
.../bindings/timer/nxp,sysctr-timer.yaml | 54 ++++++++++
.../devicetree/bindings/timer/nxp,tpm-timer.txt | 28 ------
.../devicetree/bindings/timer/nxp,tpm-timer.yaml | 63 ++++++++++++
6 files changed, 226 insertions(+), 98 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
create mode 100644 Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml
delete mode 100644 Documentation/devicetree/bindings/timer/nxp,sysctr-timer.txt
create mode 100644 Documentation/devicetree/bindings/timer/nxp,sysctr-timer.yaml
delete mode 100644 Documentation/devicetree/bindings/timer/nxp,tpm-timer.txt
create mode 100644 Documentation/devicetree/bindings/timer/nxp,tpm-timer.yaml
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/3] dt-bindings: timer: Convert i.MX GPT to json-schema
From: Anson Huang @ 2020-05-18 14:47 UTC (permalink / raw)
To: daniel.lezcano, tglx, robh+dt, shawnguo, s.hauer, kernel,
festevam, ping.bai, aisheng.dong, linux-kernel, devicetree,
linux-arm-kernel
Cc: Linux-imx
In-Reply-To: <1589813260-20036-1-git-send-email-Anson.Huang@nxp.com>
Convert the i.MX GPT binding to DT schema format using json-schema.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
.../devicetree/bindings/timer/fsl,imxgpt.txt | 45 ---------
.../devicetree/bindings/timer/fsl,imxgpt.yaml | 109 +++++++++++++++++++++
2 files changed, 109 insertions(+), 45 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
create mode 100644 Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml
diff --git a/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt b/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
deleted file mode 100644
index 5d8fd5b..0000000
--- a/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
+++ /dev/null
@@ -1,45 +0,0 @@
-Freescale i.MX General Purpose Timer (GPT)
-
-Required properties:
-
-- compatible : should be one of following:
- for i.MX1:
- - "fsl,imx1-gpt";
- for i.MX21:
- - "fsl,imx21-gpt";
- for i.MX27:
- - "fsl,imx27-gpt", "fsl,imx21-gpt";
- for i.MX31:
- - "fsl,imx31-gpt";
- for i.MX25:
- - "fsl,imx25-gpt", "fsl,imx31-gpt";
- for i.MX50:
- - "fsl,imx50-gpt", "fsl,imx31-gpt";
- for i.MX51:
- - "fsl,imx51-gpt", "fsl,imx31-gpt";
- for i.MX53:
- - "fsl,imx53-gpt", "fsl,imx31-gpt";
- for i.MX6Q:
- - "fsl,imx6q-gpt", "fsl,imx31-gpt";
- for i.MX6DL:
- - "fsl,imx6dl-gpt";
- for i.MX6SL:
- - "fsl,imx6sl-gpt", "fsl,imx6dl-gpt";
- for i.MX6SX:
- - "fsl,imx6sx-gpt", "fsl,imx6dl-gpt";
-- reg : specifies base physical address and size of the registers.
-- interrupts : should be the gpt interrupt.
-- clocks : the clocks provided by the SoC to drive the timer, must contain
- an entry for each entry in clock-names.
-- clock-names : must include "ipg" entry first, then "per" entry.
-
-Example:
-
-gpt1: timer@10003000 {
- compatible = "fsl,imx27-gpt", "fsl,imx21-gpt";
- reg = <0x10003000 0x1000>;
- interrupts = <26>;
- clocks = <&clks IMX27_CLK_GPT1_IPG_GATE>,
- <&clks IMX27_CLK_PER1_GATE>;
- clock-names = "ipg", "per";
-};
diff --git a/Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml b/Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml
new file mode 100644
index 0000000..5c7186b
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml
@@ -0,0 +1,109 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/fsl,imxgpt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX General Purpose Timer (GPT)
+
+maintainers:
+ - Sascha Hauer <s.hauer@pengutronix.de>
+
+properties:
+ compatible:
+ oneOf:
+ - description: on i.MX1 the following compatible must be specified
+ items:
+ - const: "fsl,imx1-gpt"
+
+ - description: on i.MX21 the following compatible must be specified
+ items:
+ - const: "fsl,imx21-gpt"
+
+ - description: on i.MX27 the following compatibles must be specified
+ items:
+ - const: "fsl,imx27-gpt"
+ - const: "fsl,imx21-gpt"
+
+ - description: on i.MX31 the following compatible must be specified
+ items:
+ - const: "fsl,imx31-gpt"
+
+ - description: on i.MX25 the following compatibles must be specified
+ items:
+ - const: "fsl,imx25-gpt"
+ - const: "fsl,imx31-gpt"
+
+ - description: on i.MX50 the following compatibles must be specified
+ items:
+ - const: "fsl,imx50-gpt"
+ - const: "fsl,imx31-gpt"
+
+ - description: on i.MX51 the following compatibles must be specified
+ items:
+ - const: "fsl,imx51-gpt"
+ - const: "fsl,imx31-gpt"
+
+ - description: on i.MX53 the following compatibles must be specified
+ items:
+ - const: "fsl,imx53-gpt"
+ - const: "fsl,imx31-gpt"
+
+ - description: on i.MX6Q the following compatibles must be specified
+ items:
+ - const: "fsl,imx6q-gpt"
+ - const: "fsl,imx31-gpt"
+
+ - description: on i.MX6DL the following compatible must be specified
+ items:
+ - const: "fsl,imx6dl-gpt"
+
+ - description: on i.MX6SL the following compatibles must be specified
+ items:
+ - const: "fsl,imx6sl-gpt"
+ - const: "fsl,imx6dl-gpt"
+
+ - description: on i.MX6SX the following compatibles must be specified
+ items:
+ - const: "fsl,imx6sx-gpt"
+ - const: "fsl,imx6dl-gpt"
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: SoC GPT ipg clock
+ - description: SoC GPT per clock
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: ipg
+ - const: per
+ maxItems: 2
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx27-clock.h>
+
+ timer@10003000 {
+ compatible = "fsl,imx27-gpt", "fsl,imx21-gpt";
+ reg = <0x10003000 0x1000>;
+ interrupts = <26>;
+ clocks = <&clks IMX27_CLK_GPT1_IPG_GATE>,
+ <&clks IMX27_CLK_PER1_GATE>;
+ clock-names = "ipg", "per";
+ };
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/3] dt-bindings: timer: Convert i.MX SYSCTR to json-schema
From: Anson Huang @ 2020-05-18 14:47 UTC (permalink / raw)
To: daniel.lezcano, tglx, robh+dt, shawnguo, s.hauer, kernel,
festevam, ping.bai, aisheng.dong, linux-kernel, devicetree,
linux-arm-kernel
Cc: Linux-imx
In-Reply-To: <1589813260-20036-1-git-send-email-Anson.Huang@nxp.com>
Convert the i.MX SYSCTR binding to DT schema format using json-schema.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
.../devicetree/bindings/timer/nxp,sysctr-timer.txt | 25 ----------
.../bindings/timer/nxp,sysctr-timer.yaml | 54 ++++++++++++++++++++++
2 files changed, 54 insertions(+), 25 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/timer/nxp,sysctr-timer.txt
create mode 100644 Documentation/devicetree/bindings/timer/nxp,sysctr-timer.yaml
diff --git a/Documentation/devicetree/bindings/timer/nxp,sysctr-timer.txt b/Documentation/devicetree/bindings/timer/nxp,sysctr-timer.txt
deleted file mode 100644
index d576599..0000000
--- a/Documentation/devicetree/bindings/timer/nxp,sysctr-timer.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-NXP System Counter Module(sys_ctr)
-
-The system counter(sys_ctr) is a programmable system counter which provides
-a shared time base to Cortex A15, A7, A53, A73, etc. it is intended for use in
-applications where the counter is always powered and support multiple,
-unrelated clocks. The compare frame inside can be used for timer purpose.
-
-Required properties:
-
-- compatible : should be "nxp,sysctr-timer"
-- reg : Specifies the base physical address and size of the comapre
- frame and the counter control, read & compare.
-- interrupts : should be the first compare frames' interrupt
-- clocks : Specifies the counter clock.
-- clock-names: Specifies the clock's name of this module
-
-Example:
-
- system_counter: timer@306a0000 {
- compatible = "nxp,sysctr-timer";
- reg = <0x306a0000 0x20000>;/* system-counter-rd & compare */
- clocks = <&clk_8m>;
- clock-names = "per";
- interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
- };
diff --git a/Documentation/devicetree/bindings/timer/nxp,sysctr-timer.yaml b/Documentation/devicetree/bindings/timer/nxp,sysctr-timer.yaml
new file mode 100644
index 0000000..830211c
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/nxp,sysctr-timer.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/nxp,sysctr-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP System Counter Module(sys_ctr)
+
+maintainers:
+ - Bai Ping <ping.bai@nxp.com>
+
+description: |
+ The system counter(sys_ctr) is a programmable system counter
+ which provides a shared time base to Cortex A15, A7, A53, A73,
+ etc. it is intended for use in applications where the counter
+ is always powered and support multiple, unrelated clocks. The
+ compare frame inside can be used for timer purpose.
+
+properties:
+ compatible:
+ const: nxp,sysctr-timer
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: per
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ timer@306a0000 {
+ compatible = "nxp,sysctr-timer";
+ reg = <0x306a0000 0x20000>;
+ clocks = <&clk_8m>;
+ clock-names = "per";
+ interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
+ };
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/3] dt-bindings: timer: Convert i.MX TPM to json-schema
From: Anson Huang @ 2020-05-18 14:47 UTC (permalink / raw)
To: daniel.lezcano, tglx, robh+dt, shawnguo, s.hauer, kernel,
festevam, ping.bai, aisheng.dong, linux-kernel, devicetree,
linux-arm-kernel
Cc: Linux-imx
In-Reply-To: <1589813260-20036-1-git-send-email-Anson.Huang@nxp.com>
Convert the i.MX TPM binding to DT schema format using json-schema.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
.../devicetree/bindings/timer/nxp,tpm-timer.txt | 28 ----------
.../devicetree/bindings/timer/nxp,tpm-timer.yaml | 63 ++++++++++++++++++++++
2 files changed, 63 insertions(+), 28 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/timer/nxp,tpm-timer.txt
create mode 100644 Documentation/devicetree/bindings/timer/nxp,tpm-timer.yaml
diff --git a/Documentation/devicetree/bindings/timer/nxp,tpm-timer.txt b/Documentation/devicetree/bindings/timer/nxp,tpm-timer.txt
deleted file mode 100644
index f82087b..0000000
--- a/Documentation/devicetree/bindings/timer/nxp,tpm-timer.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-NXP Low Power Timer/Pulse Width Modulation Module (TPM)
-
-The Timer/PWM Module (TPM) supports input capture, output compare,
-and the generation of PWM signals to control electric motor and power
-management applications. The counter, compare and capture registers
-are clocked by an asynchronous clock that can remain enabled in low
-power modes. TPM can support global counter bus where one TPM drives
-the counter bus for the others, provided bit width is the same.
-
-Required properties:
-
-- compatible : should be "fsl,imx7ulp-tpm"
-- reg : Specifies base physical address and size of the register sets
- for the clock event device and clock source device.
-- interrupts : Should be the clock event device interrupt.
-- clocks : The clocks provided by the SoC to drive the timer, must contain
- an entry for each entry in clock-names.
-- clock-names : Must include the following entries: "ipg" and "per".
-
-Example:
-tpm5: tpm@40260000 {
- compatible = "fsl,imx7ulp-tpm";
- reg = <0x40260000 0x1000>;
- interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clks IMX7ULP_CLK_NIC1_BUS_DIV>,
- <&clks IMX7ULP_CLK_LPTPM5>;
- clock-names = "ipg", "per";
-};
diff --git a/Documentation/devicetree/bindings/timer/nxp,tpm-timer.yaml b/Documentation/devicetree/bindings/timer/nxp,tpm-timer.yaml
new file mode 100644
index 0000000..0d34610
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/nxp,tpm-timer.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/nxp,tpm-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP Low Power Timer/Pulse Width Modulation Module (TPM)
+
+maintainers:
+ - Dong Aisheng <aisheng.dong@nxp.com>
+
+description: |
+ The Timer/PWM Module (TPM) supports input capture, output compare,
+ and the generation of PWM signals to control electric motor and power
+ management applications. The counter, compare and capture registers
+ are clocked by an asynchronous clock that can remain enabled in low
+ power modes. TPM can support global counter bus where one TPM drives
+ the counter bus for the others, provided bit width is the same.
+
+properties:
+ compatible:
+ const: fsl,imx7ulp-tpm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: SoC TPM ipg clock
+ - description: SoC TPM per clock
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: ipg
+ - const: per
+ maxItems: 2
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx7ulp-clock.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ timer@40260000 {
+ compatible = "fsl,imx7ulp-tpm";
+ reg = <0x40260000 0x1000>;
+ interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&scg1 IMX7ULP_CLK_NIC1_BUS_DIV>,
+ <&pcc2 IMX7ULP_CLK_LPTPM5>;
+ clock-names = "ipg", "per";
+ };
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 1/3] usb/ohci-platform: Fix a warning when hibernating
From: Qais Yousef @ 2020-05-18 14:57 UTC (permalink / raw)
To: Alan Stern
Cc: Oliver Neukum, Mathias Nyman, Greg Kroah-Hartman, linux-usb,
Rafael J . Wysocki, linux-kernel, Tony Prisk, linux-arm-kernel
In-Reply-To: <Pine.LNX.4.44L0.2004281459240.1555-100000@netrider.rowland.org>
On 04/28/20 15:00, Alan Stern wrote:
> On Fri, 24 Apr 2020, Qais Yousef wrote:
>
> > The following warning was observed when attempting to suspend to disk
> > using a USB flash as a swap device.
> >
> > [ 111.779649] ------------[ cut here ]------------
> > [ 111.788382] URB (____ptrval____) submitted while active
> > [ 111.796646] WARNING: CPU: 3 PID: 365 at drivers/usb/core/urb.c:363 usb_submit_urb+0x3d8/0x590
> > [ 111.805417] Modules linked in:
> > [ 111.808584] CPU: 3 PID: 365 Comm: kworker/3:2 Not tainted 5.6.0-rc6-00002-gdfd1731f9a3e-dirty #545
> > [ 111.817796] Hardware name: ARM Juno development board (r2) (DT)
> > [ 111.823896] Workqueue: usb_hub_wq hub_event
> > [ 111.828217] pstate: 60000005 (nZCv daif -PAN -UAO)
> > [ 111.833156] pc : usb_submit_urb+0x3d8/0x590
> > [ 111.837471] lr : usb_submit_urb+0x3d8/0x590
> > [ 111.841783] sp : ffff800018de38b0
> > [ 111.845205] x29: ffff800018de38b0 x28: 0000000000000003
> > [ 111.850682] x27: ffff000970530b20 x26: ffff8000133fd000
> > [ 111.856159] x25: ffff8000133fd000 x24: ffff800018de3b38
> > [ 111.861635] x23: 0000000000000004 x22: 0000000000000c00
> > [ 111.867112] x21: 0000000000000000 x20: 00000000fffffff0
> > [ 111.872589] x19: ffff0009704e7a00 x18: ffffffffffffffff
> > [ 111.878065] x17: 00000000a7c8f4bc x16: 000000002af33de8
> > [ 111.883542] x15: ffff8000133fda88 x14: 0720072007200720
> > [ 111.889019] x13: 0720072007200720 x12: 0720072007200720
> > [ 111.894496] x11: 0000000000000000 x10: 00000000a5286134
> > [ 111.899973] x9 : 0000000000000002 x8 : ffff000970c837a0
> > [ 111.905449] x7 : 0000000000000000 x6 : ffff800018de3570
> > [ 111.910926] x5 : 0000000000000001 x4 : 0000000000000003
> > [ 111.916401] x3 : 0000000000000000 x2 : ffff800013427118
> > [ 111.921879] x1 : 9d4e965b4b7d7c00 x0 : 0000000000000000
> > [ 111.927356] Call trace:
> > [ 111.929892] usb_submit_urb+0x3d8/0x590
> > [ 111.933852] hub_activate+0x108/0x7f0
> > [ 111.937633] hub_resume+0xac/0x148
> > [ 111.941149] usb_resume_interface.isra.10+0x60/0x138
> > [ 111.946265] usb_resume_both+0xe4/0x140
> > [ 111.950225] usb_runtime_resume+0x24/0x30
> > [ 111.954365] __rpm_callback+0xdc/0x138
> > [ 111.958236] rpm_callback+0x34/0x98
> > [ 111.961841] rpm_resume+0x4a8/0x720
> > [ 111.965445] rpm_resume+0x50c/0x720
> > [ 111.969049] __pm_runtime_resume+0x4c/0xb8
> > [ 111.973276] usb_autopm_get_interface+0x28/0x60
> > [ 111.977948] hub_event+0x80/0x16d8
> > [ 111.981466] process_one_work+0x2a4/0x748
> > [ 111.985604] worker_thread+0x48/0x498
> > [ 111.989387] kthread+0x13c/0x140
> > [ 111.992725] ret_from_fork+0x10/0x18
> > [ 111.996415] irq event stamp: 354
> > [ 111.999756] hardirqs last enabled at (353): [<ffff80001019ea1c>] console_unlock+0x504/0x5b8
> > [ 112.008441] hardirqs last disabled at (354): [<ffff8000100a95d0>] do_debug_exception+0x1a8/0x258
> > [ 112.017479] softirqs last enabled at (350): [<ffff8000100818a4>] __do_softirq+0x4bc/0x568
> > [ 112.025984] softirqs last disabled at (343): [<ffff8000101145a4>] irq_exit+0x144/0x150
> > [ 112.034129] ---[ end trace dc96030b9cf6c8a3 ]---
> >
> > The problem was tracked down to a missing call to
> > pm_runtime_set_active() on resume in ohci-platform.
> >
> > Link: https://lore.kernel.org/lkml/20200323143857.db5zphxhq4hz3hmd@e107158-lin.cambridge.arm.com/
> > Signed-off-by: Qais Yousef <qais.yousef@arm.com>
> > CC: Tony Prisk <linux@prisktech.co.nz>
> > CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > CC: Mathias Nyman <mathias.nyman@intel.com>
> > CC: Oliver Neukum <oneukum@suse.de>
> > CC: linux-arm-kernel@lists.infradead.org
> > CC: linux-usb@vger.kernel.org
> > CC: linux-kernel@vger.kernel.org
> > ---
> > drivers/usb/host/ohci-platform.c | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
> > index 7addfc2cbadc..4a8456f12a73 100644
> > --- a/drivers/usb/host/ohci-platform.c
> > +++ b/drivers/usb/host/ohci-platform.c
> > @@ -299,6 +299,11 @@ static int ohci_platform_resume(struct device *dev)
> > }
> >
> > ohci_resume(hcd, false);
> > +
> > + pm_runtime_disable(dev);
> > + pm_runtime_set_active(dev);
> > + pm_runtime_enable(dev);
> > +
> > return 0;
> > }
> > #endif /* CONFIG_PM_SLEEP */
>
> For both this patch and the 3/3 patch (ehci-platform):
>
> Acked-by: Alan Stern <stern@rowland.harvard.edu>
Thanks Alan. Did this make it through to any tree? I don't see it on next, nor
on Linus. But it could be queued somewhere else.
I have sent v2 to patch 2 (xhci) as a reply, so hopefully it wasn't missed.
I can resend the whole series if necessary.
Thanks
--
Qais Yousef
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/4] PCI: cadence: Deprecate inbound/outbound specific bindings
From: Lorenzo Pieralisi @ 2020-05-18 14:57 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: devicetree, linux-pci, linux-kernel, Tom Joseph, Rob Herring,
Bjorn Helgaas, Robin Murphy, linux-arm-kernel
In-Reply-To: <20200508130646.23939-1-kishon@ti.com>
On Fri, May 08, 2020 at 06:36:42PM +0530, Kishon Vijay Abraham I wrote:
> This series is a result of comments given by Rob Herring @ [1].
> Patch series changes the DT bindings and makes the corresponding driver
> changes.
>
> Changes from v2:
> 1) Changed the order of patches (no solid reason. Just save some
> rebasing effort for me)
> 2) Added Acked-by Tom and Rob except for the dma-ranges patch
> 3) Re-worked dma-ranges patch for it do decode multiple dma-ranges
> and configure BAR0, BAR1 and NO_BAR instead of just NO_BAR [2].
>
> Changes from v1:
> 1) Added Reviewed-by: Rob Herring <robh@kernel.org> for dt-binding patch
> 2) Fixed nitpick comments from Bjorn Helgaas
> 3) Added a patch to read 32-bit Vendor ID/Device ID property from DT
>
> [1] -> http://lore.kernel.org/r/20200219202700.GA21908@bogus
> [2] -> http://lore.kernel.org/r/eb1ffcb3-264f-5174-1f25-b5b2d3269840@ti.com
>
> Kishon Vijay Abraham I (4):
> dt-bindings: PCI: cadence: Deprecate inbound/outbound specific
> bindings
> PCI: cadence: Remove "cdns,max-outbound-regions" DT property
> PCI: cadence: Fix to read 32-bit Vendor ID/Device ID property from DT
> PCI: cadence: Use "dma-ranges" instead of "cdns,no-bar-match-nbits"
> property
>
> .../bindings/pci/cdns,cdns-pcie-ep.yaml | 2 +-
> .../bindings/pci/cdns,cdns-pcie-host.yaml | 3 +-
> .../devicetree/bindings/pci/cdns-pcie-ep.yaml | 25 +++
> .../bindings/pci/cdns-pcie-host.yaml | 10 ++
> .../devicetree/bindings/pci/cdns-pcie.yaml | 8 -
> .../controller/cadence/pcie-cadence-host.c | 151 +++++++++++++++---
> drivers/pci/controller/cadence/pcie-cadence.h | 23 ++-
> 7 files changed, 182 insertions(+), 40 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/pci/cdns-pcie-ep.yaml
I have applied patches 1-3 to pci/cadence (that I think are
self-contained), waiting for the dma-ranges discussion to wrap up on
patch 4.
Lorenzo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH] dt-bindings: clock: Convert i.MX7D clock to json-schema
From: Anson Huang @ 2020-05-18 14:58 UTC (permalink / raw)
To: Fabio Estevam
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Frank Li, Stephen Boyd, Michael Turquette, linux-kernel,
linux-clk, Rob Herring, dl-linux-imx, Sascha Hauer, Shawn Guo,
Sascha Hauer,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAOMZO5BeBcvmAwEJTUhHSn=_chx7OVkkxj2oB+50hGH-7H7SfA@mail.gmail.com>
Hi, Fabio
> Subject: Re: [PATCH] dt-bindings: clock: Convert i.MX7D clock to json-schema
>
> On Mon, May 18, 2020 at 11:16 AM Anson Huang <Anson.Huang@nxp.com>
> wrote:
>
> > +maintainers:
> > + - Frank Li <Frank.Li@freescale.com>
>
> The freescale.com e-mail domain is no longer valid for quite some time :-)
Thanks for reminder, I will use Frank's nxp e-mail address instead.
Anson
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 2/5] iommu/arm-smmu: Add support for TTBR1
From: Will Deacon @ 2020-05-18 14:59 UTC (permalink / raw)
To: Jordan Crouse
Cc: linux-arm-msm, Joerg Roedel, linux-kernel, iommu, robin.murphy,
linux-arm-kernel
In-Reply-To: <20200409233350.6343-3-jcrouse@codeaurora.org>
On Thu, Apr 09, 2020 at 05:33:47PM -0600, Jordan Crouse wrote:
> Add support to enable TTBR1 if the domain requests it via the
> DOMAIN_ATTR_SPLIT_TABLES attribute. If enabled by the hardware
> and pagetable configuration the driver will configure the TTBR1 region
> and program the domain pagetable on TTBR1. TTBR0 will be disabled.
>
> After attaching the device the value of he domain attribute can
> be queried to see if the split pagetables were successfully programmed.
> The domain geometry will be updated as well so that the caller can
> determine the active region for the pagetable that was programmed.
>
> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> ---
>
> drivers/iommu/arm-smmu.c | 48 ++++++++++++++++++++++++++++++++++------
> drivers/iommu/arm-smmu.h | 24 +++++++++++++++-----
> 2 files changed, 59 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index a6a5796e9c41..db6d503c1673 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -555,11 +555,16 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
> cb->ttbr[0] = pgtbl_cfg->arm_v7s_cfg.ttbr;
> cb->ttbr[1] = 0;
> } else {
> - cb->ttbr[0] = pgtbl_cfg->arm_lpae_s1_cfg.ttbr;
> - cb->ttbr[0] |= FIELD_PREP(ARM_SMMU_TTBRn_ASID,
> - cfg->asid);
> - cb->ttbr[1] = FIELD_PREP(ARM_SMMU_TTBRn_ASID,
> - cfg->asid);
> + cb->ttbr[0] = FIELD_PREP(ARM_SMMU_TTBRn_ASID,
> + cfg->asid);
> +
> + if (pgtbl_cfg->quirks & IO_PGTABLE_QUIRK_ARM_TTBR1) {
> + cb->ttbr[1] = pgtbl_cfg->arm_lpae_s1_cfg.ttbr;
> + } else {
> + cb->ttbr[0] |= pgtbl_cfg->arm_lpae_s1_cfg.ttbr;
> + cb->ttbr[1] = FIELD_PREP(ARM_SMMU_TTBRn_ASID,
> + cfg->asid);
> + }
This looks odd to me. As I mentioned before, the SMMU driver absolutely has
to manage the ASID space, so we should be setting it in both TTBRs here.
> diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h
> index 8d1cd54d82a6..5f6d0af7c8c8 100644
> --- a/drivers/iommu/arm-smmu.h
> +++ b/drivers/iommu/arm-smmu.h
> @@ -172,6 +172,7 @@ enum arm_smmu_cbar_type {
> #define ARM_SMMU_TCR_SH0 GENMASK(13, 12)
> #define ARM_SMMU_TCR_ORGN0 GENMASK(11, 10)
> #define ARM_SMMU_TCR_IRGN0 GENMASK(9, 8)
> +#define ARM_SMMU_TCR_EPD0 BIT(7)
> #define ARM_SMMU_TCR_T0SZ GENMASK(5, 0)
>
> #define ARM_SMMU_VTCR_RES1 BIT(31)
> @@ -343,16 +344,27 @@ struct arm_smmu_domain {
> struct mutex init_mutex; /* Protects smmu pointer */
> spinlock_t cb_lock; /* Serialises ATS1* ops and TLB syncs */
> struct iommu_domain domain;
> + bool split_pagetables;
> };
>
> static inline u32 arm_smmu_lpae_tcr(struct io_pgtable_cfg *cfg)
> {
> - return ARM_SMMU_TCR_EPD1 |
> - FIELD_PREP(ARM_SMMU_TCR_TG0, cfg->arm_lpae_s1_cfg.tcr.tg) |
> - FIELD_PREP(ARM_SMMU_TCR_SH0, cfg->arm_lpae_s1_cfg.tcr.sh) |
> - FIELD_PREP(ARM_SMMU_TCR_ORGN0, cfg->arm_lpae_s1_cfg.tcr.orgn) |
> - FIELD_PREP(ARM_SMMU_TCR_IRGN0, cfg->arm_lpae_s1_cfg.tcr.irgn) |
> - FIELD_PREP(ARM_SMMU_TCR_T0SZ, cfg->arm_lpae_s1_cfg.tcr.tsz);
> + u32 tcr = FIELD_PREP(ARM_SMMU_TCR_TG0, cfg->arm_lpae_s1_cfg.tcr.tg) |
> + FIELD_PREP(ARM_SMMU_TCR_SH0, cfg->arm_lpae_s1_cfg.tcr.sh) |
> + FIELD_PREP(ARM_SMMU_TCR_ORGN0, cfg->arm_lpae_s1_cfg.tcr.orgn) |
> + FIELD_PREP(ARM_SMMU_TCR_IRGN0, cfg->arm_lpae_s1_cfg.tcr.irgn) |
> + FIELD_PREP(ARM_SMMU_TCR_T0SZ, cfg->arm_lpae_s1_cfg.tcr.tsz);
> +
> + /*
> + * When TTBR1 is selected shift the TCR fields by 16 bits and disable
> + * translation in TTBR0
> + */
> + if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_TTBR1)
> + tcr = (tcr << 16) | ARM_SMMU_TCR_EPD0;
This looks reasonably dodgy to me, as you copy a RESERVED bit into the A1
field. Furthermore, for 32-bit context banks you've got the EAE bit to
contend with as well.
Perhaps we shouldn't expose DOMAIN_ATTR_SPLIT_TABLES for anything other than
the 64-bit page table format.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V2] dt-bindings: clock: Convert i.MX7D clock to json-schema
From: Anson Huang @ 2020-05-18 14:52 UTC (permalink / raw)
To: mturquette, sboyd, robh+dt, shawnguo, s.hauer, kernel, festevam,
Frank.Li, linux-clk, devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
Convert the i.MX7D clock binding to DT schema format using json-schema.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
Changes since V1:
- Update maintainer's e-mail address.
---
.../devicetree/bindings/clock/imx7d-clock.txt | 13 -----
.../devicetree/bindings/clock/imx7d-clock.yaml | 64 ++++++++++++++++++++++
2 files changed, 64 insertions(+), 13 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/clock/imx7d-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx7d-clock.yaml
diff --git a/Documentation/devicetree/bindings/clock/imx7d-clock.txt b/Documentation/devicetree/bindings/clock/imx7d-clock.txt
deleted file mode 100644
index 9d3026d..0000000
--- a/Documentation/devicetree/bindings/clock/imx7d-clock.txt
+++ /dev/null
@@ -1,13 +0,0 @@
-* Clock bindings for Freescale i.MX7 Dual
-
-Required properties:
-- compatible: Should be "fsl,imx7d-ccm"
-- reg: Address and length of the register set
-- #clock-cells: Should be <1>
-- clocks: list of clock specifiers, must contain an entry for each required
- entry in clock-names
-- clock-names: should include entries "ckil", "osc"
-
-The clock consumer should specify the desired clock by having the clock
-ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx7d-clock.h
-for the full list of i.MX7 Dual clock IDs.
diff --git a/Documentation/devicetree/bindings/clock/imx7d-clock.yaml b/Documentation/devicetree/bindings/clock/imx7d-clock.yaml
new file mode 100644
index 0000000..8cd0573
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/imx7d-clock.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/imx7d-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Clock bindings for Freescale i.MX7 Dual
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+ - Anson Huang <Anson.Huang@nxp.com>
+
+description: |
+ The clock consumer should specify the desired clock by having the clock
+ ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx7d-clock.h
+ for the full list of i.MX7 Dual clock IDs.
+
+properties:
+ compatible:
+ const: fsl,imx7d-ccm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: CCM interrupt request 1
+ - description: CCM interrupt request 2
+ maxItems: 2
+
+ '#clock-cells':
+ const: 1
+
+ clocks:
+ items:
+ - description: 32k osc
+ - description: 24m osc
+
+ clock-names:
+ items:
+ - const: ckil
+ - const: osc
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - '#clock-cells'
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ clock-controller@30380000 {
+ compatible = "fsl,imx7d-ccm";
+ reg = <0x30380000 0x10000>;
+ interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
+ #clock-cells = <1>;
+ clocks = <&ckil>, <&osc>;
+ clock-names = "ckil", "osc";
+ };
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PING] [PATCH v2] arm: ptrace: Fix mask for thumb breakpoint hook
From: Fredrik Strupe @ 2020-05-18 15:02 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: linux-kernel, linux-arm-kernel, Oleg Nesterov
In-Reply-To: <20200518141858.GV1551@shell.armlinux.org.uk>
On 18.05.2020 16:18, Russell King - ARM Linux admin wrote:
> On Mon, May 18, 2020 at 03:12:06PM +0200, Fredrik Strupe wrote:
>> call_undef_hook() in traps.c applies the same instr_mask for both 16-bit
>> and 32-bit thumb instructions. If instr_mask then is only 16 bits wide
>> (0xffff as opposed to 0xffffffff), the first half-word of 32-bit thumb
>> instructions will be masked out. This makes the function match 32-bit
>> thumb instructions where the second half-word is equal to instr_val,
>> regardless of the first half-word.
>>
>> The result in this case is that all undefined 32-bit thumb instructions
>> with the second half-word equal to de01 (udf #1) work as breakpoints
>> and will raise a SIGTRAP instead of a SIGILL, instead of just the one
>> intended 16-bit instruction. An example of such an instruction is
>> eaa0b650, which is unallocated according to Arm ARM and should raise a
>> SIGILL, but instead raises a SIGTRAP.
>
> How can 0xeaa0b650 match 0xde01 when masked with 0xffff ?
>
Sorry, that is a typo; it should say 0xeaa0de01.
For reference, this is similar to the problem with SETEND emulation that
was fixed in commit fc2266011acc in the mainline kernel
(or as discussed here: https://lkml.org/lkml/2020/4/8/274).
Fredrik
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/4] arm64: Extract kprobes_save_local_irqflag() and kprobes_restore_local_irqflag()
From: Masami Hiramatsu @ 2020-05-18 15:14 UTC (permalink / raw)
To: Doug Anderson
Cc: Mark Rutland, Daniel Thompson, Catalin Marinas, Will Deacon,
Marc Zyngier, LKML, liwei1412, Masami Hiramatsu, Jason Wessel,
liwei (GF), David Miller, Linux ARM
In-Reply-To: <CAD=FV=XMSsMFpPzBckkWhP6iDR4WM+qdV7J=aQCBbbBit_rDwg@mail.gmail.com>
On Sat, 16 May 2020 09:17:21 -0700
Doug Anderson <dianders@chromium.org> wrote:
> Hi,
>
> On Sat, May 16, 2020 at 1:47 AM liwei (GF) <liwei391@huawei.com> wrote:
> >
> > >> - kprobes_save_local_irqflag(kcb, regs);
> > >> + kernel_prepare_single_step(&kcb->saved_irqflag, regs);
> > >
> > > Is there some reason to have two functions? It seems like every time
> > > you call kernel_enable_single_step() you'd want to call
> > > kernel_prepare_single_step(). ...and every time you call
> > > kernel_disable_single_step() you'd want to call
> > > kernel_cleanup_single_step().
> > >
> > > Maybe you can just add the flags parameter to
> > > kernel_enable_single_step() / kernel_disable_single_step() and put the
> > > code in there?
> > >
> >
> > As kernel_enable_single_step() / kernel_disable_single_step() are also called in
> > breakpoint_handler() and watchpoint_handler(), i am not sure it's a right thing
> > to put the daif flag prepare/cleanup into them, especially we don't have a context
> > to save the flags.
>
> I think you misunderstood what I was suggesting. Maybe better with
> examples? I was suggesting doing this:
>
> kcb->saved_irqflag = kernel_enable_single_step(regs);
> ...
> kernel_disable_single_step(kcb->saved_irqflag, regs);
>
> To me that seems better than what you have now:
>
> kcb->saved_irqflag = kernel_prepare_single_step(regs);
> kernel_enable_single_step(regs);
> ...
> kernel_cleanup_single_step(kcb->saved_irqflag, regs);
> kernel_disable_single_step();
>
> ...or am I confused?
+1, this sounds good to me. Currently arch/arm64/kernel/probes/kprobes.c
has a code which sololy use kernel_disable_single_step() without regs
restoring, but it looks like a bug there. So maybe you need following patch.
Thank you,
-----
From: Masami Hiramatsu <mhiramat@kernel.org>
Date: Mon, 18 May 2020 23:08:28 +0900
Subject: [PATCH] arm64: kprobes: Restore saved interrupt flag before disabling
single step
Restore the saved interrupt flag in kprobe_ctlblk to regs->pstate
when a page fault happens on single-stepping instruction.
Without this fix, we will lose the flag if it happens because
kcb->saved_irqflag only knows the previous flag.
Fixes: 2dd0e8d2d2a1 ("arm64: Kprobes with single stepping support")
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: stable@vger.kernel.org
---
arch/arm64/kernel/probes/kprobes.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index d1c95dcf1d78..73fb99770f69 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -308,6 +308,7 @@ int __kprobes kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr)
if (!instruction_pointer(regs))
BUG();
+ kprobes_restore_local_irqflag(kcb, regs);
kernel_disable_single_step();
if (kcb->kprobe_status == KPROBE_REENTER)
--
2.25.1
--
Masami Hiramatsu <mhiramat@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v1 2/6] arm/smmu: Add auxiliary domain support for arm-smmuv2
From: Will Deacon @ 2020-05-18 15:18 UTC (permalink / raw)
To: Rob Clark
Cc: linux-arm-msm, Linux Kernel Mailing List,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
Jordan Crouse, Robin Murphy,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAF6AEGu-hj6=3rsCe5XeBq_ffoq9VFmL+ycrQ8N=iv89DZf=8Q@mail.gmail.com>
On Wed, Mar 18, 2020 at 04:43:07PM -0700, Rob Clark wrote:
> On Wed, Mar 18, 2020 at 3:48 PM Will Deacon <will@kernel.org> wrote:
> > On Tue, Jan 28, 2020 at 03:16:06PM -0700, Jordan Crouse wrote:
> > > Support auxiliary domains for arm-smmu-v2 to initialize and support
> > > multiple pagetables for a single SMMU context bank. Since the smmu-v2
> > > hardware doesn't have any built in support for switching the pagetable
> > > base it is left as an exercise to the caller to actually use the pagetable.
> > >
> > > Aux domains are supported if split pagetable (TTBR1) support has been
> > > enabled on the master domain. Each auxiliary domain will reuse the
> > > configuration of the master domain. By default the a domain with TTBR1
> > > support will have the TTBR0 region disabled so the first attached aux
> > > domain will enable the TTBR0 region in the hardware and conversely the
> > > last domain to be detached will disable TTBR0 translations. All subsequent
> > > auxiliary domains create a pagetable but not touch the hardware.
> > >
> > > The leaf driver will be able to query the physical address of the
> > > pagetable with the DOMAIN_ATTR_PTBASE attribute so that it can use the
> > > address with whatever means it has to switch the pagetable base.
> > >
> > > Following is a pseudo code example of how a domain can be created
> > >
> > > /* Check to see if aux domains are supported */
> > > if (iommu_dev_has_feature(dev, IOMMU_DEV_FEAT_AUX)) {
> > > iommu = iommu_domain_alloc(...);
> > >
> > > if (iommu_aux_attach_device(domain, dev))
> > > return FAIL;
> > >
> > > /* Save the base address of the pagetable for use by the driver
> > > iommu_domain_get_attr(domain, DOMAIN_ATTR_PTBASE, &ptbase);
> > > }
> >
> > I'm not really understanding what the pagetable base gets used for here and,
> > to be honest with you, the whole thing feels like a huge layering violation
> > with the way things are structured today. Why doesn't the caller just
> > interface with io-pgtable directly?
> >
> > Finally, if we need to support context-switching TTBR0 for a live domain
> > then that code really needs to live inside the SMMU driver because the
> > ASID and TLB management necessary to do that safely doesn't belong anywhere
> > else.
>
> We do in fact need live domain switching, that is really the whole
> point. The GPU CP (command processor/parser) is directly updating
> TTBR0 and triggering TLB flush, asynchronously from the CPU.
>
> And I think the answer about ASID is easy (on current hw).. it must be zero[*].
Using ASID zero is really bad, because it means that you will end up sharing
TLB entries with whichever device is using context bank 0.
Is the SMMU only used by the GPU in your SoC?
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] usb/ohci-platform: Fix a warning when hibernating
From: Alan Stern @ 2020-05-18 15:19 UTC (permalink / raw)
To: Qais Yousef, Greg Kroah-Hartman
Cc: Oliver Neukum, Mathias Nyman, linux-usb, Rafael J . Wysocki,
linux-kernel, Tony Prisk, linux-arm-kernel
In-Reply-To: <20200518145748.puvxkcmyrxc7eqt7@e107158-lin.cambridge.arm.com>
On Mon, May 18, 2020 at 03:57:49PM +0100, Qais Yousef wrote:
> > For both this patch and the 3/3 patch (ehci-platform):
> >
> > Acked-by: Alan Stern <stern@rowland.harvard.edu>
>
> Thanks Alan. Did this make it through to any tree? I don't see it on next, nor
> on Linus. But it could be queued somewhere else.
>
> I have sent v2 to patch 2 (xhci) as a reply, so hopefully it wasn't missed.
> I can resend the whole series if necessary.
Greg, what happened to this series? Did it just fall through the
cracks?
Alan Stern
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] drm/mediatek: Delete not used of_device_get_match_data
From: Chun-Kuang Hu @ 2020-05-18 15:23 UTC (permalink / raw)
To: matthias.bgg
Cc: Chun-Kuang Hu, Philipp Zabel, David Airlie, linux-kernel,
DRI Development, Matthias Brugger,
moderated list:ARM/Mediatek SoC support, Daniel Vetter,
Enric Balletbo i Serra, Linux ARM
In-Reply-To: <20200518112254.23692-1-matthias.bgg@kernel.org>
Hi, Matthias:
<matthias.bgg@kernel.org> 於 2020年5月18日 週一 下午7:23寫道：
>
> From: Matthias Brugger <matthias.bgg@gmail.com>
>
> The driver will be loaded by via a platform device. So we
> will need to get the device_node from the parent device.
> Depending on this we will set the driver data.
> As all this is done later already, just delete the call to
> of_device_get_match_data.
>
Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index e2bb0d19ef99..63ec92ba0e92 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -447,7 +447,6 @@ static int mtk_drm_probe(struct platform_device *pdev)
> if (!private)
> return -ENOMEM;
>
> - private->data = of_device_get_match_data(dev);
> private->mmsys_dev = dev->parent;
> if (!private->mmsys_dev) {
> dev_err(dev, "Failed to get MMSYS device\n");
> --
> 2.26.2
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 07/14] arm64: kvm: Split hyp/switch.c to VHE/nVHE
From: Andrew Scull @ 2020-05-18 15:28 UTC (permalink / raw)
To: David Brazdil
Cc: Suzuki K Poulose, Catalin Marinas, linux-kernel, James Morse,
linux-arm-kernel, Marc Zyngier, Will Deacon, kvmarm,
Julien Thierry
In-Reply-To: <20200515105841.73532-8-dbrazdil@google.com>
On Fri, May 15, 2020 at 11:58:34AM +0100, David Brazdil wrote:
> +__kvm_nvhe_sve_load_state = sve_load_state;
> +__kvm_nvhe_sve_save_state = sve_save_state;
Building without CONFIG_ARM64_VHE leads to a linker error due to the SVE
functions being referenced in this list. This is caused by
CONFIG_ARM64_VHE disabling CONFIG_ARM64_SVE and, in turn, preventing the
generation of those symbols. There aren't any references from code, just
this file.
It can be resolved by having the SVE symbol aliases depend on
CONFIG_ARM64_SVE.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/4] clk/soc: mediatek: mt8183: Bind clock driver from platform device
From: Chun-Kuang Hu @ 2020-05-18 15:30 UTC (permalink / raw)
To: matthias.bgg
Cc: Kate Stewart, devicetree, Stephen Boyd, Greg Kroah-Hartman,
Michael Turquette, linux-kernel, Rob Herring,
moderated list:ARM/Mediatek SoC support, Allison Randal,
Matthias Brugger, mtk01761, Thomas Gleixner, linux-clk, Linux ARM
In-Reply-To: <20200518113156.25009-1-matthias.bgg@kernel.org>
Hi, Matthias:
<matthias.bgg@kernel.org> 於 2020年5月18日 週一 下午7:32寫道：
>
> From: Matthias Brugger <matthias.bgg@gmail.com>
>
> The mmsys driver is now the top level entry point for the multimedia
> system (mmsys), we bind the clock driver by creating a platform device.
> We also bind the MediaTek DRM driver which is not yet implement and
> therefor will errror out for now.
You may need to let CONFIG_MTK_MMSYS depends on
CONFIG_COMMON_CLK_MT8173_MMSYS || CONFIG_COMMON_CLK_MT8183_MMSYS
Regards,
Chun-Kuang.
>
> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
>
> drivers/clk/mediatek/clk-mt8183-mm.c | 9 ++-------
> drivers/soc/mediatek/mtk-mmsys.c | 8 ++++++++
> 2 files changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/clk/mediatek/clk-mt8183-mm.c b/drivers/clk/mediatek/clk-mt8183-mm.c
> index 720c696b506d..9d60e09619c1 100644
> --- a/drivers/clk/mediatek/clk-mt8183-mm.c
> +++ b/drivers/clk/mediatek/clk-mt8183-mm.c
> @@ -84,8 +84,9 @@ static const struct mtk_gate mm_clks[] = {
>
> static int clk_mt8183_mm_probe(struct platform_device *pdev)
> {
> + struct device *dev = &pdev->dev;
> + struct device_node *node = dev->parent->of_node;
> struct clk_onecell_data *clk_data;
> - struct device_node *node = pdev->dev.of_node;
>
> clk_data = mtk_alloc_clk_data(CLK_MM_NR_CLK);
>
> @@ -95,16 +96,10 @@ static int clk_mt8183_mm_probe(struct platform_device *pdev)
> return of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
> }
>
> -static const struct of_device_id of_match_clk_mt8183_mm[] = {
> - { .compatible = "mediatek,mt8183-mmsys", },
> - {}
> -};
> -
> static struct platform_driver clk_mt8183_mm_drv = {
> .probe = clk_mt8183_mm_probe,
> .driver = {
> .name = "clk-mt8183-mm",
> - .of_match_table = of_match_clk_mt8183_mm,
> },
> };
>
> diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
> index cacafe23c823..783c3dd008b2 100644
> --- a/drivers/soc/mediatek/mtk-mmsys.c
> +++ b/drivers/soc/mediatek/mtk-mmsys.c
> @@ -92,6 +92,10 @@ static const struct mtk_mmsys_driver_data mt8173_mmsys_driver_data = {
> .clk_driver = "clk-mt8173-mm",
> };
>
> +static const struct mtk_mmsys_driver_data mt8183_mmsys_driver_data = {
> + .clk_driver = "clk-mt8183-mm",
> +};
> +
> static unsigned int mtk_mmsys_ddp_mout_en(enum mtk_ddp_comp_id cur,
> enum mtk_ddp_comp_id next,
> unsigned int *addr)
> @@ -339,6 +343,10 @@ static const struct of_device_id of_match_mtk_mmsys[] = {
> .compatible = "mediatek,mt8173-mmsys",
> .data = &mt8173_mmsys_driver_data,
> },
> + {
> + .compatible = "mediatek,mt8183-mmsys",
> + .data = &mt8183_mmsys_driver_data,
> + },
> { }
> };
>
> --
> 2.26.2
>
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/6] scs: Move scs_overflow_check() out of architecture code
From: Kees Cook @ 2020-05-18 15:31 UTC (permalink / raw)
To: Mark Rutland
Cc: kernel-team, Jann Horn, Peter Zijlstra, Catalin Marinas,
linux-kernel, Mark Rutland, Sami Tolvanen, Will Deacon,
Ard Biesheuvel, linux-arm-kernel
In-Reply-To: <20200518133231.GC2787@C02TD0UTHF1T.local>
On Mon, May 18, 2020 at 02:32:31PM +0100, Mark Rutland wrote:
> On Mon, May 18, 2020 at 02:23:47PM +0100, Will Deacon wrote:
> > On Mon, May 18, 2020 at 01:12:10PM +0100, Mark Rutland wrote:
> > > On Fri, May 15, 2020 at 06:27:54PM +0100, Will Deacon wrote:
> > > > There is nothing architecture-specific about scs_overflow_check() as
> > > > it's just a trivial wrapper around scs_corrupted().
> > > >
> > > > For parity with task_stack_end_corrupted(), rename scs_corrupted() to
> > > > task_scs_end_corrupted() and call it from schedule_debug() when
> > > > CONFIG_SCHED_STACK_END_CHECK_is enabled. Finally, remove the unused
> > > > scs_overflow_check() function entirely.
> > > >
> > > > This has absolutely no impact on architectures that do not support SCS
> > > > (currently arm64 only).
> > > >
> > > > Signed-off-by: Will Deacon <will@kernel.org>
> > >
> > > Pulling this out of arch code seems sane to me, and the arch-specific
> > > chanes look sound. However, I have a concern with the changes within the
> > > scheduler context-switch.
> > >
> > > > diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> > > > index a35d3318492c..56be4cbf771f 100644
> > > > --- a/arch/arm64/kernel/process.c
> > > > +++ b/arch/arm64/kernel/process.c
> > > > @@ -52,7 +52,6 @@
> > > > #include <asm/mmu_context.h>
> > > > #include <asm/processor.h>
> > > > #include <asm/pointer_auth.h>
> > > > -#include <asm/scs.h>
> > > > #include <asm/stacktrace.h>
> > > >
> > > > #if defined(CONFIG_STACKPROTECTOR) && !defined(CONFIG_STACKPROTECTOR_PER_TASK)
> > > > @@ -516,7 +515,6 @@ __notrace_funcgraph struct task_struct *__switch_to(struct task_struct *prev,
> > > > entry_task_switch(next);
> > > > uao_thread_switch(next);
> > > > ssbs_thread_switch(next);
> > > > - scs_overflow_check(next);
> > >
> > > Prior to this patch, we'd never switch to a task whose SCS had already
> > > been corrupted.
> > >
> > > With this patch, we only check that when switching away from a task, and
> > > only when CONFIG_SCHED_STACK_END_CHECK is selected, which at first
> > > glance seems to weaken that.
> >
> > Yes, ignoring vmap'd stacks, this patch brings the SCS checking in-line with
> > the main stack checking when CONFIG_SCHED_STACK_END_CHECK=y.
> >
> > > Arguably:
> > >
> > > * If the next task's SCS was corrupted by that task while it was
> > > running, we had already lost at that point.
> >
> > With this change, we'll at least catch this one sooner, and that might be
> > useful if a bug has caused us to overflow the SCS but not the main stack.
>
> Sure, but only if CONFIG_SCHED_STACK_END_CHECK is selected.
>
> > > * If the next task's SCS was corrupted by another task, then that could
> > > also happen immediately after the check (though timing to avoid the
> > > check but affect the process could be harder).
> >
> > We're only checking the magic end value, so the cross-task case is basically
> > if you overrun your own SCS as above, but then continue to overrun entire
> > SCSs for other tasks as well. It's probably not very useful in that case.
> >
> > > ... and a VMAP'd SCS would be much nicer in this regard.
> > >
> > > Do we think this is weakening the check, or do we think it wasn't all
> > > that helpful to begin with?
> >
> > I see it as a debug check to catch SCS overflow, rather than a hardening
> > feature, and I agree that using something like vmap stack for the SCS would
> > be better because we could have a guard page instead.
>
> Fair enough. Could we put something into the commit message that more
> explicitly calls out debug-not-hardening? I agree that under that model
> this patch looks fine, and with something to that effect:
>
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
>
> Mark.
>
> > This is something I would like to revisit, but we need more
> > information from Sami about why Android rejected the larger allocation
> > size, since I don't think there's an awful lot of point merging this
> > series if Android doesn't pick it up.
>
> Indeed. I'd certainly prefer the robustness of a VMAP'd SCS if we can do
> that.
For smaller devices, the memory overhead was too high. (i.e. 4x more
memory allocated to kernel stacks -- 4k vs 1k per thread.) The series
is much more than just a stack exhaustion defense, so I don't think that
detail needs to block the entire series. FWIW, I'd like to have both modes
(contiguous and vmap) available so that system builders can choose their
trade-off. Both will gain return address corruption defense, but the
vmap case will protect against neighboring SCS corruption in the face
of very-unlikely-but-technically-possible stack exhaustion (remember
that with the elimination of VLAs, the stack depth compile time
checking, and the regular stack VMAP guard page, it will be quite
difficult to exhaust the SCS -- either because there is no code path to
accomplish it, or because it would trip the regular stack guard page
first).
--
Kees Cook
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] usb/ohci-platform: Fix a warning when hibernating
From: Greg Kroah-Hartman @ 2020-05-18 15:33 UTC (permalink / raw)
To: Alan Stern
Cc: Oliver Neukum, Mathias Nyman, linux-usb, Rafael J . Wysocki,
linux-kernel, Tony Prisk, Qais Yousef, linux-arm-kernel
In-Reply-To: <20200518151940.GC15479@rowland.harvard.edu>
On Mon, May 18, 2020 at 11:19:40AM -0400, Alan Stern wrote:
> On Mon, May 18, 2020 at 03:57:49PM +0100, Qais Yousef wrote:
> > > For both this patch and the 3/3 patch (ehci-platform):
> > >
> > > Acked-by: Alan Stern <stern@rowland.harvard.edu>
> >
> > Thanks Alan. Did this make it through to any tree? I don't see it on next, nor
> > on Linus. But it could be queued somewhere else.
> >
> > I have sent v2 to patch 2 (xhci) as a reply, so hopefully it wasn't missed.
> > I can resend the whole series if necessary.
>
> Greg, what happened to this series? Did it just fall through the
> cracks?
No idea, it's not in my to-review queue, so maybe it got merged
somewhere? If not, can someone resend it please?
thanks,
greg k-h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/4] iommu/arm-smmu-v3: Use pci_ats_supported()
From: Will Deacon @ 2020-05-18 15:37 UTC (permalink / raw)
To: Jean-Philippe Brucker
Cc: ashok.raj, linux-pci, joro, alex.williamson, iommu, bhelgaas,
robin.murphy, dwmw2, linux-arm-kernel, baolu.lu
In-Reply-To: <20200515104359.1178606-4-jean-philippe@linaro.org>
On Fri, May 15, 2020 at 12:44:01PM +0200, Jean-Philippe Brucker wrote:
> The new pci_ats_supported() function checks if a device supports ATS and
> is allowed to use it.
>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> ---
> I dropped the Ack because I slightly changed the patch to keep the
> fwspec check, since last version:
> https://lore.kernel.org/linux-iommu/20200311124506.208376-8-jean-philippe@linaro.org/
> ---
> drivers/iommu/arm-smmu-v3.c | 20 +++++---------------
> 1 file changed, 5 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index 82508730feb7a1..39b935e86ab203 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -2652,26 +2652,16 @@ static void arm_smmu_install_ste_for_dev(struct arm_smmu_master *master)
> }
> }
>
> -#ifdef CONFIG_PCI_ATS
> static bool arm_smmu_ats_supported(struct arm_smmu_master *master)
> {
> - struct pci_dev *pdev;
> + struct device *dev = master->dev;
> struct arm_smmu_device *smmu = master->smmu;
> - struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(master->dev);
> -
> - if (!(smmu->features & ARM_SMMU_FEAT_ATS) || !dev_is_pci(master->dev) ||
> - !(fwspec->flags & IOMMU_FWSPEC_PCI_RC_ATS) || pci_ats_disabled())
> - return false;
> + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
>
> - pdev = to_pci_dev(master->dev);
> - return !pdev->untrusted && pdev->ats_cap;
> + return (smmu->features & ARM_SMMU_FEAT_ATS) &&
> + !(fwspec->flags & IOMMU_FWSPEC_PCI_RC_ATS) &&
> + dev_is_pci(dev) && pci_ats_supported(to_pci_dev(dev));
nit, but I think this is clearer if you leave it split up (untested diff
below).
Will
--->8
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 82508730feb7..c5730557dbe3 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -2652,26 +2652,20 @@ static void arm_smmu_install_ste_for_dev(struct arm_smmu_master *master)
}
}
-#ifdef CONFIG_PCI_ATS
static bool arm_smmu_ats_supported(struct arm_smmu_master *master)
{
- struct pci_dev *pdev;
+ struct device *dev = master->dev;
struct arm_smmu_device *smmu = master->smmu;
- struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(master->dev);
+ struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
- if (!(smmu->features & ARM_SMMU_FEAT_ATS) || !dev_is_pci(master->dev) ||
- !(fwspec->flags & IOMMU_FWSPEC_PCI_RC_ATS) || pci_ats_disabled())
+ if (!(smmu->features & ARM_SMMU_FEAT_ATS))
return false;
- pdev = to_pci_dev(master->dev);
- return !pdev->untrusted && pdev->ats_cap;
-}
-#else
-static bool arm_smmu_ats_supported(struct arm_smmu_master *master)
-{
- return false;
+ if (!(fwspec->flags & IOMMU_FWSPEC_PCI_RC_ATS))
+ return false;
+
+ return dev_is_pci(dev) && pci_ats_supported(to_pci_dev(dev));
}
-#endif
static void arm_smmu_enable_ats(struct arm_smmu_master *master)
{
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 0/6] Clean up Shadow Call Stack patches for 5.8
From: Sami Tolvanen @ 2020-05-18 15:43 UTC (permalink / raw)
To: Will Deacon
Cc: Kees Cook, Jann Horn, Peter Zijlstra, Catalin Marinas, LKML,
Mark Rutland, kernel-team, Ard Biesheuvel, linux-arm-kernel
In-Reply-To: <20200518135228.GI32394@willie-the-truck>
On Mon, May 18, 2020 at 6:52 AM Will Deacon <will@kernel.org> wrote:
>
> On Fri, May 15, 2020 at 01:42:40PM -0700, Sami Tolvanen wrote:
> > On Fri, May 15, 2020 at 10:28 AM Will Deacon <will@kernel.org> wrote:
> > > Will Deacon (6):
> > > arm64: scs: Store absolute SCS stack pointer value in thread_info
> > > scs: Move accounting into alloc/free functions
> > > arm64: scs: Use 'scs_sp' register alias for x18
> > > scs: Move scs_overflow_check() out of architecture code
> > > scs: Remove references to asm/scs.h from core code
> > > scs: Move DEFINE_SCS macro into core code
> > >
> > > arch/Kconfig | 4 +--
> > > arch/arm64/include/asm/scs.h | 29 ++++------------
> > > arch/arm64/include/asm/thread_info.h | 4 +--
> > > arch/arm64/kernel/asm-offsets.c | 2 +-
> > > arch/arm64/kernel/entry.S | 10 +++---
> > > arch/arm64/kernel/head.S | 2 +-
> > > arch/arm64/kernel/process.c | 2 --
> > > arch/arm64/kernel/scs.c | 6 +---
> > > include/linux/scs.h | 16 +++++----
> > > kernel/sched/core.c | 3 ++
> > > kernel/scs.c | 52 +++++++++++++---------------
> > > 11 files changed, 55 insertions(+), 75 deletions(-)
> > >
> > > --
> > > 2.26.2.761.g0e0b3e54be-goog
> >
> > Thanks, Will. I tested these on my SCS tree and didn't run into any
> > issues. Looks good to me.
>
> Cheers, Sami. Can I add your 'Tested-by' to the patches, please?
Sure, please feel free to add Tested-by tags.
Sami
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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