* [PATCH v3 4/6] bus: ti-sysc: Add support for software reset
From: Faiz Abbas @ 2018-06-06 6:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180606060826.14671-1-faiz_abbas@ti.com>
Add support for the software reset of a target interconnect
module using its sysconfig and sysstatus registers.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
drivers/bus/ti-sysc.c | 40 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
index 4a2244419b9b..74d716a7bd6e 100644
--- a/drivers/bus/ti-sysc.c
+++ b/drivers/bus/ti-sysc.c
@@ -22,11 +22,14 @@
#include <linux/of_address.h>
#include <linux/of_platform.h>
#include <linux/slab.h>
+#include <linux/iopoll.h>
#include <linux/platform_data/ti-sysc.h>
#include <dt-bindings/bus/ti-sysc.h>
+#define MAX_MODULE_SOFTRESET_WAIT 10000
+
static const char * const reg_names[] = { "rev", "sysc", "syss", };
enum sysc_clocks {
@@ -74,6 +77,11 @@ struct sysc {
struct delayed_work idle_work;
};
+void sysc_write(struct sysc *ddata, int offset, u32 value)
+{
+ writel_relaxed(value, ddata->module_va + offset);
+}
+
static u32 sysc_read(struct sysc *ddata, int offset)
{
if (ddata->cfg.quirks & SYSC_QUIRK_16BIT) {
@@ -700,6 +708,26 @@ static void sysc_init_revision_quirks(struct sysc *ddata)
}
}
+static int sysc_reset(struct sysc *ddata)
+{
+ int offset = ddata->offsets[SYSC_SYSCONFIG];
+ int val = sysc_read(ddata, offset);
+
+ val |= (0x1 << ddata->cap->regbits->srst_shift);
+ sysc_write(ddata, offset, val);
+
+ /* Poll on reset status */
+ if (ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS) {
+ offset = ddata->offsets[SYSC_SYSSTATUS];
+
+ return readl_poll_timeout(ddata->module_va + offset, val,
+ (val & ddata->cfg.syss_mask) == 0x0,
+ 100, MAX_MODULE_SOFTRESET_WAIT);
+ }
+
+ return 0;
+}
+
/* At this point the module is configured enough to read the revision */
static int sysc_init_module(struct sysc *ddata)
{
@@ -716,6 +744,18 @@ static int sysc_init_module(struct sysc *ddata)
return 0;
}
+
+ if (!(ddata->cfg.quirks & SYSC_QUIRK_NO_RESET_ON_INIT) &&
+ !ddata->legacy_mode) {
+ error = sysc_reset(ddata);
+ if (error) {
+ dev_err(ddata->dev, "Reset failed with %d\n", error);
+ pm_runtime_put_sync(ddata->dev);
+
+ return error;
+ }
+ }
+
ddata->revision = sysc_read_revision(ddata);
pm_runtime_put_sync(ddata->dev);
--
2.17.0
^ permalink raw reply related
* [PATCH v3 5/6] ARM: dts: Add generic interconnect target module node for MCAN
From: Faiz Abbas @ 2018-06-06 6:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180606060826.14671-1-faiz_abbas@ti.com>
The ti-sysc driver provides support for manipulating the idle modes
and interconnect level resets.
Add the generic interconnect target module node for MCAN to support
the same.
CC: Tony Lindgren <tony@atomide.com>
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
arch/arm/boot/dts/dra76x.dtsi | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/dra76x.dtsi b/arch/arm/boot/dts/dra76x.dtsi
index bfc82636999c..5157cc431574 100644
--- a/arch/arm/boot/dts/dra76x.dtsi
+++ b/arch/arm/boot/dts/dra76x.dtsi
@@ -11,6 +11,24 @@
/ {
compatible = "ti,dra762", "ti,dra7";
+ ocp {
+ target-module at 42c01900 {
+ compatible = "ti,sysc-dra7-mcan", "ti,sysc";
+ ranges = <0x0 0x42c00000 0x2000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x42c01900 0x4>,
+ <0x42c01904 0x4>,
+ <0x42c01908 0x4>;
+ reg-names = "rev", "sysc", "syss";
+ ti,sysc-mask = <(SYSC_OMAP4_SOFTRESET |
+ SYSC_DRA7_MCAN_ENAWAKEUP)>;
+ ti,syss-mask = <1>;
+ clocks = <&wkupaon_clkctrl DRA7_ADC_CLKCTRL 0>;
+ clock-names = "fck";
+ };
+ };
+
};
/* MCAN interrupts are hard-wired to irqs 67, 68 */
--
2.17.0
^ permalink raw reply related
* [PATCH v3 6/6] ARM: dts: dra76x: Add MCAN node
From: Faiz Abbas @ 2018-06-06 6:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180606060826.14671-1-faiz_abbas@ti.com>
From: Franklin S Cooper Jr <fcooper@ti.com>
Add support for the MCAN peripheral which supports both classic
CAN messages along with the new CAN-FD message.
Add MCAN node to evm and enable it with a maximum datarate of 5 mbps
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
arch/arm/boot/dts/dra76-evm.dts | 6 ++++++
arch/arm/boot/dts/dra76x.dtsi | 13 +++++++++++++
2 files changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/dra76-evm.dts b/arch/arm/boot/dts/dra76-evm.dts
index 2deb96405d06..b6ac2b6ffc6e 100644
--- a/arch/arm/boot/dts/dra76-evm.dts
+++ b/arch/arm/boot/dts/dra76-evm.dts
@@ -404,3 +404,9 @@
phys = <&pcie1_phy>, <&pcie2_phy>;
phy-names = "pcie-phy0", "pcie-phy1";
};
+
+&m_can0 {
+ can-transceiver {
+ max-bitrate = <5000000>;
+ };
+};
diff --git a/arch/arm/boot/dts/dra76x.dtsi b/arch/arm/boot/dts/dra76x.dtsi
index 5157cc431574..613e4dc0ed3e 100644
--- a/arch/arm/boot/dts/dra76x.dtsi
+++ b/arch/arm/boot/dts/dra76x.dtsi
@@ -26,6 +26,19 @@
ti,syss-mask = <1>;
clocks = <&wkupaon_clkctrl DRA7_ADC_CLKCTRL 0>;
clock-names = "fck";
+
+ m_can0: mcan at 1a00 {
+ compatible = "bosch,m_can";
+ reg = <0x1a00 0x4000>, <0x0 0x18FC>;
+ reg-names = "m_can", "message_ram";
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "int0", "int1";
+ clocks = <&mcan_clk>, <&l3_iclk_div>;
+ clock-names = "cclk", "hclk";
+ bosch,mram-cfg = <0x0 0 0 32 0 0 1 1>;
+ };
};
};
--
2.17.0
^ permalink raw reply related
* [PATCH v4 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Michel Pollet @ 2018-06-06 6:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0481173f-6384-98d6-707c-89dc5ef103f0@gmail.com>
Hi Frank,
On 05 June 2018 18:34, Frank wrote:
> On 06/05/18 04:28, Michel Pollet wrote:
> > The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot time,
> > it requires a special enable method to get it started.
> >
> > Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
> > ---
> > arch/arm/mach-shmobile/Makefile | 1 +
> > arch/arm/mach-shmobile/smp-r9a06g032.c | 79
> > ++++++++++++++++++++++++++++++++++
> > 2 files changed, 80 insertions(+)
> > create mode 100644 arch/arm/mach-shmobile/smp-r9a06g032.c
> >
> > diff --git a/arch/arm/mach-shmobile/Makefile
> > b/arch/arm/mach-shmobile/Makefile index 1939f52..d7fc98f 100644
> > --- a/arch/arm/mach-shmobile/Makefile
> > +++ b/arch/arm/mach-shmobile/Makefile
> > @@ -34,6 +34,7 @@ smp-$(CONFIG_ARCH_SH73A0)+= smp-sh73a0.o
> headsmp-scu.o platsmp-scu.o
> > smp-$(CONFIG_ARCH_R8A7779)+= smp-r8a7779.o headsmp-scu.o
> platsmp-scu.o
> > smp-$(CONFIG_ARCH_R8A7790)+= smp-r8a7790.o
> > smp-$(CONFIG_ARCH_R8A7791)+= smp-r8a7791.o
> > +smp-$(CONFIG_ARCH_R9A06G032)+= smp-r9a06g032.o
> > smp-$(CONFIG_ARCH_EMEV2)+= smp-emev2.o headsmp-scu.o
> platsmp-scu.o
> >
> > # PM objects
> > diff --git a/arch/arm/mach-shmobile/smp-r9a06g032.c
> > b/arch/arm/mach-shmobile/smp-r9a06g032.c
> > new file mode 100644
> > index 0000000..cd40e6e
> > --- /dev/null
> > +++ b/arch/arm/mach-shmobile/smp-r9a06g032.c
> > @@ -0,0 +1,79 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * R9A06G032 Second CA7 enabler.
> > + *
> > + * Copyright (C) 2018 Renesas Electronics Europe Limited
> > + *
> > + * Michel Pollet <michel.pollet@bp.renesas.com>,
> <buserror@gmail.com>
> > + * Derived from action,s500-smp
> > + */
> > +
> > +#include <linux/io.h>
> > +#include <linux/of.h>
> > +#include <linux/of_address.h>
> > +#include <linux/smp.h>
> > +
> > +/*
> > + * The second CPU is parked in ROM at boot time. It requires waking
> > +it after
> > + * writing an address into the BOOTADDR register of sysctrl.
> > + *
> > + * So the default value of the "cpu-release-addr" corresponds to
> BOOTADDR...
> > + *
> > + * *However* the BOOTADDR register is not available when the kernel
> > + * starts in NONSEC mode.
> > + *
> > + * So for NONSEC mode, the bootloader re-parks the second CPU into a
> > +pen
> > + * in SRAM, and changes the "cpu-release-addr" of linux's DT to a
> > +SRAM address,
> > + * which is not restricted.
>
> The binding document for cpu-release-addr does not have a definition for 32
> bit arm. The existing definition is only 64 bit arm. Please add the definition
> for 32 bit arm to patch 1.
Hmmm I do find a definition in
Documentation/devicetree/bindings/arm/cpus.txt -- just under where I
added my 'enable-method' -- And it is already used as 32 bits in at least
arch/arm/boot/dts/stih407-family.dtsi.
What do you want me to add to this exactly? Do you want me to just
change "required for systems that have an "enable-method" property
value of "spin-table" to also specify renesas,r9a06g032 ?
Thanks!
Michel
>
> -Frank
>
>
> > + */
> > +
> > +static void __iomem *cpu_bootaddr;
> > +
> > +static DEFINE_SPINLOCK(cpu_lock);
> > +
> > +static int r9a06g032_smp_boot_secondary(unsigned int cpu, struct
> > +task_struct *idle) {
> > +if (!cpu_bootaddr)
> > +return -ENODEV;
> > +
> > +spin_lock(&cpu_lock);
> > +
> > +writel(__pa_symbol(secondary_startup), cpu_bootaddr);
> > +arch_send_wakeup_ipi_mask(cpumask_of(cpu));
> > +
> > +spin_unlock(&cpu_lock);
> > +
> > +return 0;
> > +}
> > +
> > +static void __init r9a06g032_smp_prepare_cpus(unsigned int max_cpus)
> > +{
> > +struct device_node *dn;
> > +int ret;
> > +u32 bootaddr;
> > +
> > +dn = of_get_cpu_node(1, NULL);
> > +if (!dn) {
> > +pr_err("CPU#1: missing device tree node\n");
> > +return;
> > +}
> > +/*
> > + * Determine the address from which the CPU is polling.
> > + * The bootloader *does* change this property
> > + */
> > +ret = of_property_read_u32(dn, "cpu-release-addr", &bootaddr);
> > +of_node_put(dn);
> > +if (ret) {
> > +pr_err("CPU#1: invalid cpu-release-addr property\n");
> > +return;
> > +}
> > +pr_info("CPU#1: cpu-release-addr %08x\n", bootaddr);
> > +
> > +cpu_bootaddr = ioremap(bootaddr, sizeof(bootaddr)); }
> > +
> > +static const struct smp_operations r9a06g032_smp_ops __initconst = {
> > +.smp_prepare_cpus = r9a06g032_smp_prepare_cpus,
> > +.smp_boot_secondary = r9a06g032_smp_boot_secondary, };
> > +CPU_METHOD_OF_DECLARE(r9a06g032_smp, "renesas,r9a06g032-smp",
> > +&r9a06g032_smp_ops);
> >
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
^ permalink raw reply
* [PATCH 01/20] coresight: Fix memory leak in coresight_register
From: Arvind Yadav @ 2018-06-06 6:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528235011-30691-2-git-send-email-suzuki.poulose@arm.com>
Hi Suzuki,
On Wednesday 06 June 2018 03:13 AM, Suzuki K Poulose wrote:
> commit 6403587a930c ("coresight: use put_device() instead of kfree()")
> introduced a memory leak where, if we fail to register the device
> for coresight_device, we don't free the "coresight_device" object,
> which was allocated via kzalloc(). Fix this by jumping to the
> appropriate error path.
put_device() will decrement the last reference and then
free the memory by calling dev->release. Internally
put_device() -> kobject_put() -> kobject_cleanup() which is
responsible to call 'dev -> release' and also free other kobject
resources. If you will see the coresight_device_release. There
we are releasing all allocated memory. Still if you call kfree() again
then it'll be redundancy.
~arvind
>
> Fixes: commit 6403587a930c ("coresight: use put_device() instead of kfree()")
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Cc: Arvind Yadav <arvind.yadav.cs@gmail.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> drivers/hwtracing/coresight/coresight.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
> index 4969b32..2893cfe 100644
> --- a/drivers/hwtracing/coresight/coresight.c
> +++ b/drivers/hwtracing/coresight/coresight.c
> @@ -1020,7 +1020,7 @@ struct coresight_device *coresight_register(struct coresight_desc *desc)
> ret = device_register(&csdev->dev);
> if (ret) {
> put_device(&csdev->dev);
> - goto err_kzalloc_csdev;
> + goto err_kzalloc_refcnts;
> }
>
> mutex_lock(&coresight_mutex);
^ permalink raw reply
* [PATCH V2 2/2] arm: dts: sunxi: Add missing cooling device properties for CPUs
From: Maxime Ripard @ 2018-06-06 6:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v65EX2RwKjxPw+EK4i6rkfgOJoCU2amuFkF-tHQT40isxw@mail.gmail.com>
On Wed, Jun 06, 2018 at 12:02:20AM +0800, Chen-Yu Tsai wrote:
> On Tue, Jun 5, 2018 at 3:11 PM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > On Tue, Jun 05, 2018 at 10:17:49AM +0530, Viresh Kumar wrote:
> >> The cooling device properties, like "#cooling-cells" and
> >> "dynamic-power-coefficient", should either be present for all the CPUs
> >> of a cluster or none. If these are present only for a subset of CPUs of
> >> a cluster then things will start falling apart as soon as the CPUs are
> >> brought online in a different order. For example, this will happen
> >> because the operating system looks for such properties in the CPU node
> >> it is trying to bring up, so that it can register a cooling device.
> >>
> >> Add such missing properties.
> >>
> >> Fix other missing properties (clocks, OPP, clock latency) as well to
> >> make it all work.
> >>
> >> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> >
> > Applied both, thanks!
>
> Please fix the "ARM" prefix when applying. :)
Done, thanks for the reminder :)
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180606/7503a1f4/attachment-0001.sig>
^ permalink raw reply
* [PATCH v13 0/3] Fix issues with huge mapping in ioremap for ARM64
From: Chintan Pandya @ 2018-06-06 7:01 UTC (permalink / raw)
To: linux-arm-kernel
This series of patches re-bring huge vmap back for arm64.
Patch 1/3 has been taken by Toshi in his series of patches
by name "[PATCH v3 0/3] fix free pmd/pte page handlings on x86"
to avoid merge conflict with this series.
These patches are tested on 4.16 kernel with Cortex-A75 based SoC.
The test used for verifying these patches is a stress test on
ioremap/unmap which tries to re-use same io-address but changes
size of mapping randomly i.e. 4K to 2M to 1G etc. The same test
used to reproduce 3rd level translation fault without these fixes
(and also of course with Revert "arm64: Enforce BBM for huge IO/VMAP
mappings" being part of the tree).
These patches can also go into '-stable' branch (if accepted)
for 4.6 onwards.
>From V12->V13:
- Dropped v12 3/5 and v12 5/5
- Using existing APIs like pte_offset_kernel and pmd_offset
instead of pmd_page_vaddr & pud_page_vaddr
- Updated commit log message for 3/3
- Some other cosmetic corrections in 3/3
>From V11->V12:
- Introduced p*d_page_vaddr helper macros and using them
- Rebased over current tip
>From V10->V11:
- Updated pud_free_pmd_page & pmd_free_pte_page to use consistent
conding style
- Fixed few bugs by using pmd_page_paddr & pud_page_paddr
>From V9->V10:
- Updated commit log for patch 1/4 by Toshi
- Addressed review comments by Will on patch 3/4
>From V8->V9:
- Used __TLBI_VADDR macros in new TLB flush API
>From V7->V8:
- Properly fixed compilation issue in x86 file
>From V6->V7:
- Fixed compilation issue in x86 case
- V6 patches were not properly enumarated
>From V5->V6:
- Use __flush_tlb_kernel_pgtable() for both PUD and PMD. Remove
"bool tlb_inv" based variance as it is not need now
- Re-naming for consistency
>From V4->V5:
- Add new API __flush_tlb_kernel_pgtable(unsigned long addr)
for kernel addresses
>From V3->V4:
- Add header for 'addr' in x86 implementation
- Re-order pmd/pud clear and table free
- Avoid redundant TLB invalidatation in one perticular case
>From V2->V3:
- Use the exisiting page table free interface to do arm64
specific things
>From V1->V2:
- Rebased my patches on top of "[PATCH v2 1/2] mm/vmalloc:
Add interfaces to free unmapped page table"
- Honored BBM for ARM64
Chintan Pandya (3):
ioremap: Update pgtable free interfaces with addr
arm64: tlbflush: Introduce __flush_tlb_kernel_pgtable
arm64: Implement page table free interfaces
arch/arm64/include/asm/tlbflush.h | 7 ++++++
arch/arm64/mm/mmu.c | 48 +++++++++++++++++++++++++++++++++++----
arch/x86/mm/pgtable.c | 8 ++++---
include/asm-generic/pgtable.h | 8 +++----
lib/ioremap.c | 4 ++--
5 files changed, 62 insertions(+), 13 deletions(-)
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation
Center, Inc., is a member of Code Aurora Forum, a Linux Foundation
Collaborative Project
^ permalink raw reply
* [PATCH v13 1/3] ioremap: Update pgtable free interfaces with addr
From: Chintan Pandya @ 2018-06-06 7:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528268481-19299-1-git-send-email-cpandya@codeaurora.org>
From: Chintan Pandya <cpandya@codeaurora.org>
The following kernel panic was observed on ARM64 platform due to a stale
TLB entry.
1. ioremap with 4K size, a valid pte page table is set.
2. iounmap it, its pte entry is set to 0.
3. ioremap the same address with 2M size, update its pmd entry with
a new value.
4. CPU may hit an exception because the old pmd entry is still in TLB,
which leads to a kernel panic.
Commit b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page
table") has addressed this panic by falling to pte mappings in the above
case on ARM64.
To support pmd mappings in all cases, TLB purge needs to be performed
in this case on ARM64.
Add a new arg, 'addr', to pud_free_pmd_page() and pmd_free_pte_page()
so that TLB purge can be added later in seprate patches.
[toshi at hpe.com: merge changes, rewrite patch description]
Fixes: 28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces")
Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: <stable@vger.kernel.org>
---
arch/arm64/mm/mmu.c | 4 ++--
arch/x86/mm/pgtable.c | 8 +++++---
include/asm-generic/pgtable.h | 8 ++++----
lib/ioremap.c | 4 ++--
4 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 493ff75..8ae5d7a 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -977,12 +977,12 @@ int pmd_clear_huge(pmd_t *pmdp)
return 1;
}
-int pud_free_pmd_page(pud_t *pud)
+int pud_free_pmd_page(pud_t *pud, unsigned long addr)
{
return pud_none(*pud);
}
-int pmd_free_pte_page(pmd_t *pmd)
+int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
{
return pmd_none(*pmd);
}
diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
index ffc8c13..37e3cba 100644
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -718,11 +718,12 @@ int pmd_clear_huge(pmd_t *pmd)
/**
* pud_free_pmd_page - Clear pud entry and free pmd page.
* @pud: Pointer to a PUD.
+ * @addr: Virtual address associated with pud.
*
* Context: The pud range has been unmaped and TLB purged.
* Return: 1 if clearing the entry succeeded. 0 otherwise.
*/
-int pud_free_pmd_page(pud_t *pud)
+int pud_free_pmd_page(pud_t *pud, unsigned long addr)
{
pmd_t *pmd;
int i;
@@ -733,7 +734,7 @@ int pud_free_pmd_page(pud_t *pud)
pmd = (pmd_t *)pud_page_vaddr(*pud);
for (i = 0; i < PTRS_PER_PMD; i++)
- if (!pmd_free_pte_page(&pmd[i]))
+ if (!pmd_free_pte_page(&pmd[i], addr + (i * PMD_SIZE)))
return 0;
pud_clear(pud);
@@ -745,11 +746,12 @@ int pud_free_pmd_page(pud_t *pud)
/**
* pmd_free_pte_page - Clear pmd entry and free pte page.
* @pmd: Pointer to a PMD.
+ * @addr: Virtual address associated with pmd.
*
* Context: The pmd range has been unmaped and TLB purged.
* Return: 1 if clearing the entry succeeded. 0 otherwise.
*/
-int pmd_free_pte_page(pmd_t *pmd)
+int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
{
pte_t *pte;
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index f59639a..b081794 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -1019,8 +1019,8 @@ static inline int p4d_clear_huge(p4d_t *p4d)
int pmd_set_huge(pmd_t *pmd, phys_addr_t addr, pgprot_t prot);
int pud_clear_huge(pud_t *pud);
int pmd_clear_huge(pmd_t *pmd);
-int pud_free_pmd_page(pud_t *pud);
-int pmd_free_pte_page(pmd_t *pmd);
+int pud_free_pmd_page(pud_t *pud, unsigned long addr);
+int pmd_free_pte_page(pmd_t *pmd, unsigned long addr);
#else /* !CONFIG_HAVE_ARCH_HUGE_VMAP */
static inline int p4d_set_huge(p4d_t *p4d, phys_addr_t addr, pgprot_t prot)
{
@@ -1046,11 +1046,11 @@ static inline int pmd_clear_huge(pmd_t *pmd)
{
return 0;
}
-static inline int pud_free_pmd_page(pud_t *pud)
+static inline int pud_free_pmd_page(pud_t *pud, unsigned long addr)
{
return 0;
}
-static inline int pmd_free_pte_page(pmd_t *pmd)
+static inline int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
{
return 0;
}
diff --git a/lib/ioremap.c b/lib/ioremap.c
index 54e5bba..517f585 100644
--- a/lib/ioremap.c
+++ b/lib/ioremap.c
@@ -92,7 +92,7 @@ static inline int ioremap_pmd_range(pud_t *pud, unsigned long addr,
if (ioremap_pmd_enabled() &&
((next - addr) == PMD_SIZE) &&
IS_ALIGNED(phys_addr + addr, PMD_SIZE) &&
- pmd_free_pte_page(pmd)) {
+ pmd_free_pte_page(pmd, addr)) {
if (pmd_set_huge(pmd, phys_addr + addr, prot))
continue;
}
@@ -119,7 +119,7 @@ static inline int ioremap_pud_range(p4d_t *p4d, unsigned long addr,
if (ioremap_pud_enabled() &&
((next - addr) == PUD_SIZE) &&
IS_ALIGNED(phys_addr + addr, PUD_SIZE) &&
- pud_free_pmd_page(pud)) {
+ pud_free_pmd_page(pud, addr)) {
if (pud_set_huge(pud, phys_addr + addr, prot))
continue;
}
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation
Center, Inc., is a member of Code Aurora Forum, a Linux Foundation
Collaborative Project
^ permalink raw reply related
* [PATCH v13 2/3] arm64: tlbflush: Introduce __flush_tlb_kernel_pgtable
From: Chintan Pandya @ 2018-06-06 7:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528268481-19299-1-git-send-email-cpandya@codeaurora.org>
Add an interface to invalidate intermediate page tables
from TLB for kernel.
Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>
---
arch/arm64/include/asm/tlbflush.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
index dfc61d7..a4a1901 100644
--- a/arch/arm64/include/asm/tlbflush.h
+++ b/arch/arm64/include/asm/tlbflush.h
@@ -218,6 +218,13 @@ static inline void __flush_tlb_pgtable(struct mm_struct *mm,
dsb(ish);
}
+static inline void __flush_tlb_kernel_pgtable(unsigned long kaddr)
+{
+ unsigned long addr = __TLBI_VADDR(kaddr, 0);
+
+ __tlbi(vaae1is, addr);
+ dsb(ish);
+}
#endif
#endif
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation
Center, Inc., is a member of Code Aurora Forum, a Linux Foundation
Collaborative Project
^ permalink raw reply related
* [PATCH v13 3/3] arm64: Implement page table free interfaces
From: Chintan Pandya @ 2018-06-06 7:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528268481-19299-1-git-send-email-cpandya@codeaurora.org>
arm64 requires break-before-make. Originally, before
setting up new pmd/pud entry for huge mapping, in few
cases, the modifying pmd/pud entry was still valid
and pointing to next level page table as we only
clear off leaf PTE in unmap leg.
a) This was resulting into stale entry in TLBs (as few
TLBs also cache intermediate mapping for performance
reasons)
b) Also, modifying pmd/pud was the only reference to
next level page table and it was getting lost without
freeing it. So, page leaks were happening.
Implement pud_free_pmd_page() and pmd_free_pte_page() to
enforce BBM and also free the leaking page tables.
Implementation requires,
1) Clearing off the current pud/pmd entry
2) Invalidation of TLB
3) Freeing of the un-used next level page tables
Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>
---
arch/arm64/mm/mmu.c | 48 ++++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 44 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 8ae5d7a..65f8627 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -45,6 +45,7 @@
#include <asm/memblock.h>
#include <asm/mmu_context.h>
#include <asm/ptdump.h>
+#include <asm/tlbflush.h>
#define NO_BLOCK_MAPPINGS BIT(0)
#define NO_CONT_MAPPINGS BIT(1)
@@ -977,12 +978,51 @@ int pmd_clear_huge(pmd_t *pmdp)
return 1;
}
-int pud_free_pmd_page(pud_t *pud, unsigned long addr)
+int pmd_free_pte_page(pmd_t *pmdp, unsigned long addr)
{
- return pud_none(*pud);
+ pte_t *table;
+ pmd_t pmd;
+
+ pmd = READ_ONCE(*pmdp);
+
+ /* No-op for empty entry and WARN_ON for valid entry */
+ if (!pmd_present(pmd) || !pmd_table(pmd)) {
+ VM_WARN_ON(!pmd_table(pmd));
+ return 1;
+ }
+
+ table = pte_offset_kernel(pmdp, addr);
+ pmd_clear(pmdp);
+ __flush_tlb_kernel_pgtable(addr);
+ pte_free_kernel(NULL, table);
+ return 1;
}
-int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
+int pud_free_pmd_page(pud_t *pudp, unsigned long addr)
{
- return pmd_none(*pmd);
+ pmd_t *table;
+ pmd_t *pmdp;
+ pud_t pud;
+ unsigned long next, end;
+
+ pud = READ_ONCE(*pudp);
+
+ /* No-op for empty entry and WARN_ON for valid entry */
+ if (!pud_present(pud) || !pud_table(pud)) {
+ VM_WARN_ON(!pud_table(pud));
+ return 1;
+ }
+
+ table = pmd_offset(pudp, addr);
+ pmdp = table;
+ next = addr;
+ end = addr + PUD_SIZE;
+ do {
+ pmd_free_pte_page(pmdp, next);
+ } while (pmdp++, next += PMD_SIZE, next != end);
+
+ pud_clear(pudp);
+ __flush_tlb_kernel_pgtable(addr);
+ pmd_free(NULL, table);
+ return 1;
}
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation
Center, Inc., is a member of Code Aurora Forum, a Linux Foundation
Collaborative Project
^ permalink raw reply related
* panic kexec broken on ARM64?
From: Stefan Wahren @ 2018-06-06 7:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8028219f-0d14-eafd-86b7-359ee927bcd3@arm.com>
Hi Petr,
Am 05.06.2018 um 19:46 schrieb James Morse:
> Hi Petr,
>
> (CC: +Akashi, Marc)
>
> On 05/06/18 09:01, Petr Tesarik wrote:
>> I have observed hangs after crash on a Raspberry Pi 3 Model B+ board
>> when a panic kernel is loaded.
> kdump is a best-effort thing, it looks like this is a case where the
> crashed-kernel can't tear itself down.
>
> Do you have the rest of the stack trace? Was it handling an irq when it decided
> to panic?:
> https://lkml.org/lkml/2018/3/13/1134
the Raspberry Pi 3 B+ support is very fresh (linux-next). Since i didn't
see a version, i need to doublecheck.
You are actually using linux-next and not the downstream kernel?
>
>> I attached a hardware debugger and found
>> out that all CPU cores were stopped except one which was stuck in the
>> idle thread. It seems that irq_set_irqchip_state() may sleep, which is
>> definitely not safe after a kernel panic.
> I don't know much about irqchip stuff, but __irq_get_desc_lock() takes a
> raw_spin_lock(), and calls gic_irq_get_irqchip_state() which is just poking
> around in mmio registers, this should all be safe unless you re-entered the same
> code.
>
>
>> If I'm right, then this is broken in general, but I have only ever seen
>> it on RPi 3 Model B+ (even RPi3 Model B works fine), so the issue may
>> be more subtle.
> Is there a hardware difference around the interrupt controller on these?
@James:
No, but the RPi 3 B has a different USB network chip on board (smsc95xx,
Fast ethernet) instead of lan78xx (Gigabit ethernet).
Stefan
^ permalink raw reply
* [PATCH 2/2] arm64: dts: renesas: condor: add I2C0 support
From: Geert Uytterhoeven @ 2018-06-06 7:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <61f6f4a4-e55c-06e0-cba1-7d90a556950a@cogentembedded.com>
Hi Sergei,
On Mon, May 28, 2018 at 10:14 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Define the Condor board dependent part of the I2C0 device node.
>
> The I2C0 bus is populated by 2 ON Semiconductor PCA9654 I/O expanders
> and Analog Devices ADV7511W HDMI transmitter (but we're only describing
> the former chips now).
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Suggestion for future improvement below.
> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
> @@ -80,6 +80,28 @@
> clock-frequency = <32768>;
> };
>
> +&i2c0 {
> + pinctrl-0 = <&i2c0_pins>;
> + pinctrl-names = "default";
> +
> + status = "okay";
> + clock-frequency = <400000>;
> +
> + io_expander0: gpio at 20 {
> + compatible = "onnn,pca9654";
> + reg = <0x20>;
> + gpio-controller;
> + #gpio-cells = <2>;
The bindings don't mention this (the example does have it) the optional
interrupts prototype. As this is wired to INTC-EX IRQ4, you may want to
add that. Perhaps later, as r8a77980.dtsi doesn't have INTC-EX yet.
> + };
> +
> + io_expander1: gpio at 21 {
> + compatible = "onnn,pca9654";
> + reg = <0x21>;
> + gpio-controller;
> + #gpio-cells = <2>;
Same for IRQ5.
> + };
> +};
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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 2/2] arm64: dts: renesas: initial V3HSK board device tree
From: Geert Uytterhoeven @ 2018-06-06 7:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50de037c-7560-c261-f96a-f86065674c9b@cogentembedded.com>
On Thu, May 10, 2018 at 8:12 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Add the initial device tree for the V3H Starter Kit board.
> The board has 1 debug serial port (SCIF0); include support for it,
> so that the serial console can work.
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
FTR:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> --- /dev/null
> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
> +&pfc {
> + scif0_pins: scif0 {
> + groups = "scif0_data";
> + function = "scif0";
> + };
JFYI, hscif0 can be routed to the same pins, if higher performance is needed.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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
* panic kexec broken on ARM64?
From: Petr Tesarik @ 2018-06-06 7:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACi5LpMJ9whXxpMvQDw4_4kRNaATGGq4fWt7nRRJTMrdN_q_nQ@mail.gmail.com>
On Wed, 6 Jun 2018 11:06:28 +0530
Bhupesh Sharma <bhsharma@redhat.com> wrote:
> Hello Petr,
>
> On Tue, Jun 5, 2018 at 1:31 PM, Petr Tesarik <ptesarik@suse.cz> wrote:
> > Hi all,
> >
> > I have observed hangs after crash on a Raspberry Pi 3 Model B+ board
> > when a panic kernel is loaded. I attached a hardware debugger and found
> > out that all CPU cores were stopped except one which was stuck in the
> > idle thread. It seems that irq_set_irqchip_state() may sleep, which is
> > definitely not safe after a kernel panic.
>[...]
> Also do you get any console output from the crash kernel (you can try
> passing earlycon to the crash kernel to see if it crashes early
> enough)? If yes, can you please share the same.
Maybe I wasn't clear enough. The crashed kernel does not even get to
the kexec's purgatory code, so there cannot be any output from the
crash kernel.
>[...]
> > #12 0xffff000001001cd0 in lan78xx_read_reg (index=152, data=0xffff000008e5396c <init_thread_union+14700>, dev=<optimized out>, dev=<optimized out>)
> > at ../drivers/net/usb/lan78xx.c:425
>
> Hmmm, this seems a bit misplaced, but are you using a usb-ethernet
> adapter which causes a URB submission to timeout?
Yes, RPi 3 B+ contains an on-board Microchip LAN7515, which is indeed a
USB device.
>[...]
> > #26 0xffff000008081478 in do_mem_abort (addr=0, esr=2248146948, regs=0xffff000008e53d70 <init_thread_union+15728>) at ../arch/arm64/mm/fault.c:657
> > #27 0xffff000008082dd0 in el1_sync () at ../arch/arm64/kernel/entry.S:548
>
> The ESR value from the logs (2248146948) indicates the following about
> the panic causes (see ARMv8 Architecture Reference Manual for more
> details):
Thank you for all the detailx, but that's not relevant here. I am
crashing my system intentionally to debug the kexec/kdump
infrastructure...
Petr T
^ permalink raw reply
* panic kexec broken on ARM64?
From: Petr Tesarik @ 2018-06-06 8:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5e539510-01b7-ebc5-778e-b49a5261f9bc@i2se.com>
On Wed, 6 Jun 2018 09:02:04 +0200
Stefan Wahren <stefan.wahren@i2se.com> wrote:
> Hi Petr,
>
> Am 05.06.2018 um 19:46 schrieb James Morse:
> > Hi Petr,
> >
> > (CC: +Akashi, Marc)
> >
> > On 05/06/18 09:01, Petr Tesarik wrote:
> >> I have observed hangs after crash on a Raspberry Pi 3 Model B+ board
> >> when a panic kernel is loaded.
> > kdump is a best-effort thing, it looks like this is a case where the
> > crashed-kernel can't tear itself down.
> >
> > Do you have the rest of the stack trace? Was it handling an irq when it decided
> > to panic?:
> > https://lkml.org/lkml/2018/3/13/1134
>
> the Raspberry Pi 3 B+ support is very fresh (linux-next). Since i didn't
> see a version, i need to doublecheck.
>
> You are actually using linux-next and not the downstream kernel?
Very good point. I'll try again with linux-next.
Stay tuned,
Petr T
^ permalink raw reply
* [PATCH][next] staging: vc04_services: make a couple of pointers static
From: Colin King @ 2018-06-06 8:06 UTC (permalink / raw)
To: linux-arm-kernel
From: Colin Ian King <colin.king@canonical.com>
The pointers vchiq_dbg_dir and vchiq_dbg_clients are local to the
source and do not need to be in global scope, so make them static.
Cleans up sparse warnings:
warning: symbol 'vchiq_dbg_dir' was not declared. Should it be static?
warning: symbol 'vchiq_dbg_clients' was not declared. Should it be static?
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
.../staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c
index 38805504d462..6a9e71a61142 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c
@@ -52,8 +52,8 @@
#define VCHIQ_LOG_TRACE_STR "trace"
/* Global 'vchiq' debugfs and clients entry used by all instances */
-struct dentry *vchiq_dbg_dir;
-struct dentry *vchiq_dbg_clients;
+static struct dentry *vchiq_dbg_dir;
+static struct dentry *vchiq_dbg_clients;
/* Log category debugfs entries */
struct vchiq_debugfs_log_entry {
--
2.17.0
^ permalink raw reply related
* [PATCH v5 2/4] dt-bindings: timer: add i.MX EPIT timer binding
From: Clément Péron @ 2018-06-06 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605152323.GA25218@rob-hp-laptop>
Hi Rob,
On Tue, 5 Jun 2018 at 17:23, Rob Herring <robh@kernel.org> wrote:
>
> On Mon, Jun 04, 2018 at 12:00:33PM +0200, Cl?ment P?ron wrote:
> > From: Cl?ment Peron <clement.peron@devialet.com>
> >
> > Add devicetree binding document for NXP's i.MX SoC specific
> > EPIT timer driver.
> >
> > Signed-off-by: Cl?ment Peron <clement.peron@devialet.com>
> > ---
> > .../devicetree/bindings/timer/fsl,imxepit.txt | 21 +++++++++++++++++++
> > 1 file changed, 21 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/timer/fsl,imxepit.txt
> >
> > diff --git a/Documentation/devicetree/bindings/timer/fsl,imxepit.txt b/Documentation/devicetree/bindings/timer/fsl,imxepit.txt
> > new file mode 100644
> > index 000000000000..de2e6ef68d24
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/timer/fsl,imxepit.txt
> > @@ -0,0 +1,21 @@
> > +Binding for the i.MX Enhanced Periodic Interrupt Timer (EPIT)
> > +
> > +The Enhanced Periodic Interrupt Timer (EPIT) is a 32-bit set-and-forget timer
> > +that is capable of providing precise interrupts at regular intervals with
> > +minimal processor intervention.
> > +
> > +Required properties:
> > +- compatible: should be "fsl,<chip>-epit", "fsl,imx31-epit" where <chip> is
> > + imx25, imx6qdl, imx6sl, imx6sul or imx6sx.
> > +- reg: physical base address of the controller and length of memory mapped
> > + region.
> > +- interrupts: Should contain EPIT controller interrupt
> > +- clocks : The clock provided by the SoC to drive the timer.
> > +
> > +Example for i.MX6QDL:
> > + epit1: epit at 20d0000 {
>
> I think I already mentioned this, but:
My bad, will update it
>
> timer at ...
>
> > + compatible = "fsl,imx6qdl-epit", "fsl,imx31-epit";
> > + reg = <0x020d0000 0x4000>;
> > + interrupts = <0 56 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX6QDL_CLK_EPIT1>;
> > + };
> > --
> > 2.17.0
> >
^ permalink raw reply
* [PATCH] pwm: stm32: fix build warning with CONFIG_DMA_ENGINE disabled
From: Thierry Reding @ 2018-06-06 8:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525210843.1821071-1-arnd@arndb.de>
On Fri, May 25, 2018 at 11:08:30PM +0200, Arnd Bergmann wrote:
> Without dmaengine support, we get a harmless warning about an
> unused function:
>
> drivers/pwm/pwm-stm32.c:166:12: error: 'stm32_pwm_capture' defined but not used [-Werror=unused-function]
>
> Changing the #ifdef to an IS_ENABLED() check shuts up that warning
> and is slightly nicer to read.
>
> Fixes: 53e38fe73f94 ("pwm: stm32: Add capture support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/pwm/pwm-stm32.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
Applied, thanks.
Lee, I applied this on top of your immutable MFD/PWM branch because it
depends on the capture support that you applied. I wasn't sure what your
PR timing was going to be, so I thought I'd do it this way since I'm
pulling in some last minute fixes for v4.18.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180606/e5ca7938/attachment-0001.sig>
^ permalink raw reply
* [PATCH 3/3] arm64: dts: renesas: v3hsk: specify GEther PHY IRQ
From: Geert Uytterhoeven @ 2018-06-06 8:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9e6c40eb-71d0-d35b-1cf7-9179e093ed10@cogentembedded.com>
On Fri, Jun 1, 2018 at 10:47 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Specify GEther PHY IRQ in the V3H Starter Kit board's device tree, now
> that we have the GPIO support (previously phylib had to resort to polling).
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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 v4 05/14] coresight: get/put module in coresight_build/release_path
From: Greg Kroah-Hartman @ 2018-06-06 8:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605210710.22227-6-kim.phillips@arm.com>
On Tue, Jun 05, 2018 at 04:07:01PM -0500, Kim Phillips wrote:
> Increment the refcnt for driver modules in current use by calling
> module_get in coresight_build_path and module_put in release_path.
>
> This prevents driver modules from being unloaded when they are in use,
> either in sysfs or perf mode.
Why does it matter? Shouldn't you be allowed to remove any module at
any point in time, much like a networking driver?
>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Cc: Leo Yan <leo.yan@linaro.org>
> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
> Cc: Randy Dunlap <rdunlap@infradead.org>
> Cc: Suzuki K Poulose <Suzuki.Poulose@arm.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Russell King <linux@armlinux.org.uk>
> Signed-off-by: Kim Phillips <kim.phillips@arm.com>
> ---
> drivers/hwtracing/coresight/coresight.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
> index 338f1719641c..1c941351f1d1 100644
> --- a/drivers/hwtracing/coresight/coresight.c
> +++ b/drivers/hwtracing/coresight/coresight.c
> @@ -465,6 +465,12 @@ static int _coresight_build_path(struct coresight_device *csdev,
>
> node->csdev = csdev;
> list_add(&node->link, path);
> +
> + if (!try_module_get(csdev->dev.parent->driver->owner)) {
What is to keep parent->driver from going away right here? What keeps
parent around? This feels very fragile to me, I don't see any locking
anywhere around this code path to try to keep things in place.
thanks,
greg k-h
^ permalink raw reply
* [PATCH v4 01/14] coresight: cpu_debug: minor module fixups
From: Greg Kroah-Hartman @ 2018-06-06 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605210710.22227-2-kim.phillips@arm.com>
On Tue, Jun 05, 2018 at 04:06:57PM -0500, Kim Phillips wrote:
> - provide the name of the module in the Kconfig help section
> - define a MODULE_DEVICE_TABLE in order to be autoloaded on boot
>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Cc: Leo Yan <leo.yan@linaro.org>
> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
> Cc: Randy Dunlap <rdunlap@infradead.org>
> Cc: Suzuki K Poulose <Suzuki.Poulose@arm.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Russell King <linux@armlinux.org.uk>
> Signed-off-by: Kim Phillips <kim.phillips@arm.com>
> ---
> drivers/hwtracing/coresight/Kconfig | 3 +++
> drivers/hwtracing/coresight/coresight-cpu-debug.c | 2 ++
> 2 files changed, 5 insertions(+)
>
> diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig
> index ef9cb3c164e1..d1209f5acf76 100644
> --- a/drivers/hwtracing/coresight/Kconfig
> +++ b/drivers/hwtracing/coresight/Kconfig
> @@ -103,4 +103,7 @@ config CORESIGHT_CPU_DEBUG
> properly, please refer Documentation/trace/coresight-cpu-debug.txt
> for detailed description and the example for usage.
>
> + To compile this driver as a module, choose M here: the
> + module will be called coresight-cpu-debug.
> +
> endif
> diff --git a/drivers/hwtracing/coresight/coresight-cpu-debug.c b/drivers/hwtracing/coresight/coresight-cpu-debug.c
> index 45b2460f3166..1efe9626eb6c 100644
> --- a/drivers/hwtracing/coresight/coresight-cpu-debug.c
> +++ b/drivers/hwtracing/coresight/coresight-cpu-debug.c
> @@ -671,6 +671,8 @@ static const struct amba_id debug_ids[] = {
> { 0, 0 },
> };
>
> +MODULE_DEVICE_TABLE(amba, debug_ids);
> +
> static struct amba_driver debug_driver = {
> .drv = {
> .name = "coresight-cpu-debug",
This should be 2 patches as you are doing two different things here.
thanks,
greg k-h
^ permalink raw reply
* [PATCH] arm: cntvoff: Add a function definition when !SMP
From: Geert Uytterhoeven @ 2018-06-06 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180528084016.9271-1-maxime.ripard@bootlin.com>
Hi Maxime,
On Mon, May 28, 2018 at 10:40 AM, Maxime Ripard
<maxime.ripard@bootlin.com> wrote:
> The secure_cntvoff_init function is only compiled if CONFIG_SMP is set to
> true. However, that will lead to linking errors if one uses this function
> without an ifdef CONFIG_SMP guard, which isn't ideal.
>
> Provide a dumb implementation when CONFIG_SMP is false so that we don't end
> up with a compilation error on our hands.
>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: Myl?ne Josserand <mylene.josserand@bootlin.com>
> Cc: Simon Horman <horms@verge.net.au>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Fixes: cad160ed0a94 ("ARM: shmobile: Convert file to use cntvoff")
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
NAKed-by: Geert Uytterhoeven <geert+renesas@glider.be>
cfr. for Arnd's similar fix (https://patchwork.kernel.org/patch/10427931/)
At least R-Car E2 also needs it for the boot CPU, cfr. commit 9ce3fa6816c2fb59
("ARM: shmobile: rcar-gen2: Add CA7 arch_timer initialization for r8a7794").
The proper fix is to build arch/arm/common/secure_cntvoff.o
unconditionally.
> --- a/arch/arm/include/asm/secure_cntvoff.h
> +++ b/arch/arm/include/asm/secure_cntvoff.h
> @@ -3,6 +3,10 @@
> #ifndef __ASMARM_ARCH_CNTVOFF_H
> #define __ASMARM_ARCH_CNTVOFF_H
>
> +#ifdef CONFIG_SMP
> extern void secure_cntvoff_init(void);
> +#else
> +static inline void secure_cntvoff_init(void) {};
> +#endif
>
> #endif
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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 v4 03/14] coresight: move shared barrier_pkt[] to coresight_priv.h
From: Greg Kroah-Hartman @ 2018-06-06 8:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605210710.22227-4-kim.phillips@arm.com>
On Tue, Jun 05, 2018 at 04:06:59PM -0500, Kim Phillips wrote:
> barrier_pkt[] is used in the etb and tmc-etf coresight
> components. Change barrier_pkt[] to a static definition,
> so as to allow them to be built as modules.
>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Cc: Leo Yan <leo.yan@linaro.org>
> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
> Cc: Randy Dunlap <rdunlap@infradead.org>
> Cc: Suzuki K Poulose <Suzuki.Poulose@arm.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Russell King <linux@armlinux.org.uk>
> Signed-off-by: Kim Phillips <kim.phillips@arm.com>
> ---
> drivers/hwtracing/coresight/coresight-priv.h | 8 +++++++-
> drivers/hwtracing/coresight/coresight.c | 7 -------
> 2 files changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h
> index 158c720119dd..e76f19ca9e04 100644
> --- a/drivers/hwtracing/coresight/coresight-priv.h
> +++ b/drivers/hwtracing/coresight/coresight-priv.h
> @@ -57,7 +57,13 @@ static DEVICE_ATTR_RO(name)
> #define coresight_simple_reg64(type, name, lo_off, hi_off) \
> __coresight_simple_func(type, NULL, name, lo_off, hi_off)
>
> -extern const u32 barrier_pkt[4];
> +/*
> + * When losing synchronisation a new barrier packet needs to be inserted at the
> + * beginning of the data collected in a buffer. That way the decoder knows that
> + * it needs to look for another sync sequence.
> + */
> +static const u32 barrier_pkt[4] = { 0x7fffffff, 0x7fffffff,
> + 0x7fffffff, 0x7fffffff };
Are you _sure_ this is doing what you think it is doing?
You now just created a bunch of different copies of this structure,
which might change the logic involved, right?
Putting a static variable in a .h file is generally considered a very
bad thing to do, I need a lot more "proof" this is ok before I can
accept this. Worse case, just put the variable in the individual places
where it is needed.
thanks,
greg k-h
^ permalink raw reply
* [PATCH v4 14/14] coresight: allow the coresight core driver to be built as a module
From: Greg Kroah-Hartman @ 2018-06-06 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605210710.22227-15-kim.phillips@arm.com>
On Tue, Jun 05, 2018 at 04:07:10PM -0500, Kim Phillips wrote:
> Allow to build coresight as a module. This enhances
> coresight developer efficiency by allowing the development to
> take place exclusively on the target, and without needing to
> reboot in between changes.
>
> - Kconfig becomes a tristate, to allow =m
> - append -core to source file name to allow module to
> be called coresight by the Makefile
> - modules can have only one init/exit, so we add the core bus
> register/unregister function calls to the etm_perf init/exit
> functions, since coresight.c does not have etm_pmu defined.
> - add a MODULE_DEVICE_TABLE for autoloading on boot
>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Cc: Leo Yan <leo.yan@linaro.org>
> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
> Cc: Randy Dunlap <rdunlap@infradead.org>
> Cc: Suzuki K Poulose <Suzuki.Poulose@arm.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Russell King <linux@armlinux.org.uk>
> Signed-off-by: Kim Phillips <kim.phillips@arm.com>
> ---
> drivers/hwtracing/coresight/Kconfig | 5 ++++-
> drivers/hwtracing/coresight/Makefile | 7 +++++--
> .../coresight/{coresight.c => coresight-core.c} | 6 ------
> .../hwtracing/coresight/coresight-etm-perf.c | 17 ++++++++++++++++-
> 4 files changed, 25 insertions(+), 10 deletions(-)
> rename drivers/hwtracing/coresight/{coresight.c => coresight-core.c} (99%)
>
> diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig
> index 181a44ea2d61..c05b265f7731 100644
> --- a/drivers/hwtracing/coresight/Kconfig
> +++ b/drivers/hwtracing/coresight/Kconfig
> @@ -2,7 +2,7 @@
> # Coresight configuration
> #
> menuconfig CORESIGHT
> - bool "CoreSight Tracing Support"
> + tristate "CoreSight Tracing Support"
> select ARM_AMBA
> select PERF_EVENTS
> help
> @@ -12,6 +12,9 @@ menuconfig CORESIGHT
> specification and configure the right series of components when a
> trace source gets enabled.
>
> + To compile this driver as a module, choose M here: the
> + module will be called coresight.
> +
> if CORESIGHT
> config CORESIGHT_LINKS_AND_SINKS
> tristate "CoreSight Link and Sink drivers"
> diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
> index 45d7a0f34170..ed2d4bcb017b 100644
> --- a/drivers/hwtracing/coresight/Makefile
> +++ b/drivers/hwtracing/coresight/Makefile
> @@ -2,8 +2,11 @@
> #
> # Makefile for CoreSight drivers.
> #
> -obj-$(CONFIG_CORESIGHT) += coresight.o coresight-etm-perf.o
> -obj-$(CONFIG_OF) += of_coresight.o
> +obj-$(CONFIG_CORESIGHT) += coresight.o
> +coresight-objs := coresight-core.o coresight-etm-perf.o
Shouldn't this line be:
coresight-y := coresight-core.o coresight-etm-perf.o
> +ifeq ($(CONFIG_OF), y)
> +coresight-objs += of_coresight.o
> +endif
Those 3 lines should be written as 1 line:
coresight-$(CONFIG_OF) += of_coresight.o
thanks,
greg k-h
^ permalink raw reply
* [PATCH v4 1/3] dt-bindings: cpu: Add Renesas R9A06G032 SMP enable method.
From: Simon Horman @ 2018-06-06 8:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528198148-23308-2-git-send-email-michel.pollet@bp.renesas.com>
On Tue, Jun 05, 2018 at 12:28:46PM +0100, Michel Pollet wrote:
> Add a special enable method for second CA7 of the R9A06G032
>
> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ 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