* [PATCH v3 5/5] arm64: mm: round memstart_addr to contiguous PUD/PMD size
From: Ard Biesheuvel @ 2016-10-12 11:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476271425-19401-1-git-send-email-ard.biesheuvel@linaro.org>
Given that contiguous PUDs/PMDs allow the linear region to be mapped more
efficiently, ensure that the relative alignment between the linear virtual
and physical mappings of system RAM are equal modulo the contiguous PUD
size (or contiguous PMD size, for 16k/64k granule size).
Note that this reduces the KASLR randomization of the linear range by
PUD_SHIFT (or PMD_SHIFT) bits.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/include/asm/kernel-pgtable.h | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/include/asm/kernel-pgtable.h b/arch/arm64/include/asm/kernel-pgtable.h
index 7e51d1b57c0c..71dbd9e1e809 100644
--- a/arch/arm64/include/asm/kernel-pgtable.h
+++ b/arch/arm64/include/asm/kernel-pgtable.h
@@ -83,16 +83,13 @@
/*
* To make optimal use of block mappings when laying out the linear
* mapping, round down the base of physical memory to a size that can
- * be mapped efficiently, i.e., either PUD_SIZE (4k granule) or PMD_SIZE
- * (64k granule), or a multiple that can be mapped using contiguous bits
- * in the page tables: 32 * PMD_SIZE (16k granule)
+ * be mapped efficiently, i.e., either CONT_PUD_SIZE (4k granule) or
+ * CONT_PMD_SIZE (16k/64k granules)
*/
#if defined(CONFIG_ARM64_4K_PAGES)
-#define ARM64_MEMSTART_SHIFT PUD_SHIFT
-#elif defined(CONFIG_ARM64_16K_PAGES)
-#define ARM64_MEMSTART_SHIFT (PMD_SHIFT + 5)
+#define ARM64_MEMSTART_SHIFT (PUD_SHIFT + CONT_PUD_SHIFT)
#else
-#define ARM64_MEMSTART_SHIFT PMD_SHIFT
+#define ARM64_MEMSTART_SHIFT (PMD_SHIFT + CONT_PMD_SHIFT)
#endif
/*
--
2.7.4
^ permalink raw reply related
* [PATCH v3 4/5] arm64: mm: support additional contiguous kernel mapping region sizes
From: Ard Biesheuvel @ 2016-10-12 11:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476271425-19401-1-git-send-email-ard.biesheuvel@linaro.org>
Extend the basic support for kernel mappings using contiguous regions
by adding support for contiguous PUDs (4k granule only), either as a
discrete level or folded into the PGDs. In the same way, handle folded
PMDs so that contiguous PMDs (for 16k and 64k granule kernels) will
work as expected for 2 levels of translation as well.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/include/asm/pgtable-hwdef.h | 6 +++
arch/arm64/mm/mmu.c | 40 +++++++++++++++++++-
2 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/pgtable-hwdef.h b/arch/arm64/include/asm/pgtable-hwdef.h
index eb0c2bd90de9..4192072af932 100644
--- a/arch/arm64/include/asm/pgtable-hwdef.h
+++ b/arch/arm64/include/asm/pgtable-hwdef.h
@@ -93,12 +93,15 @@
#ifdef CONFIG_ARM64_64K_PAGES
#define CONT_PTE_SHIFT 5
#define CONT_PMD_SHIFT 5
+#define CONT_PUD_SHIFT 0
#elif defined(CONFIG_ARM64_16K_PAGES)
#define CONT_PTE_SHIFT 7
#define CONT_PMD_SHIFT 5
+#define CONT_PUD_SHIFT 0
#else
#define CONT_PTE_SHIFT 4
#define CONT_PMD_SHIFT 4
+#define CONT_PUD_SHIFT 4
#endif
#define CONT_PTES (1 << CONT_PTE_SHIFT)
@@ -107,6 +110,9 @@
#define CONT_PMDS (1 << CONT_PMD_SHIFT)
#define CONT_PMD_SIZE (CONT_PMDS * PMD_SIZE)
#define CONT_PMD_MASK (~(CONT_PMD_SIZE - 1))
+#define CONT_PUDS (1 << CONT_PUD_SHIFT)
+#define CONT_PUD_SIZE (CONT_PUDS * PUD_SIZE)
+#define CONT_PUD_MASK (~(CONT_PUD_SIZE - 1))
/* the the numerical offset of the PTE within a range of CONT_PTES */
#define CONT_RANGE_OFFSET(addr) (((addr)>>PAGE_SHIFT)&(CONT_PTES-1))
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 40be4979102d..0e0eca45b54a 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -233,6 +233,7 @@ static void alloc_init_pud(pgd_t *pgd, unsigned long addr, unsigned long end,
phys_addr_t (*pgtable_alloc)(void),
bool page_mappings_only)
{
+ pgprot_t __prot = prot;
pud_t *pud;
unsigned long next;
@@ -254,7 +255,19 @@ static void alloc_init_pud(pgd_t *pgd, unsigned long addr, unsigned long end,
* For 4K granule only, attempt to put down a 1GB block
*/
if (use_1G_block(addr, next, phys) && !page_mappings_only) {
- pud_set_huge(pud, phys, prot);
+ /*
+ * Set the contiguous bit for the subsequent group of
+ * PUDs if its size and alignment are appropriate.
+ */
+ if (((addr | phys) & ~CONT_PUD_MASK) == 0) {
+ if (end - addr >= CONT_PUD_SIZE)
+ __prot = __pgprot(pgprot_val(prot) |
+ PTE_CONT);
+ else
+ __prot = prot;
+ }
+
+ pud_set_huge(pud, phys, __prot);
/*
* After the PUD entry has been populated once, we
@@ -284,6 +297,7 @@ static void __create_pgd_mapping(pgd_t *pgdir, phys_addr_t phys,
{
unsigned long addr, length, end, next;
pgd_t *pgd = pgd_offset_raw(pgdir, virt);
+ pgprot_t __prot = prot;
/*
* If the virtual and physical address don't have the same offset
@@ -299,7 +313,29 @@ static void __create_pgd_mapping(pgd_t *pgdir, phys_addr_t phys,
end = addr + length;
do {
next = pgd_addr_end(addr, end);
- alloc_init_pud(pgd, addr, next, phys, prot, pgtable_alloc,
+
+ /*
+ * If any intermediate levels are folded into the PGDs, we
+ * need to deal with the contiguous attributes here, since
+ * the contiguity can only be observed at this level.
+ */
+ if (PGDIR_SHIFT == PMD_SHIFT && !page_mappings_only &&
+ ((addr | phys) & ~CONT_PMD_MASK) == 0) {
+ if (end - addr >= CONT_PMD_SIZE)
+ __prot = __pgprot(pgprot_val(prot) |
+ PTE_CONT);
+ else
+ __prot = prot;
+ } else if (PGDIR_SHIFT == PUD_SHIFT && CONT_PUD_SHIFT > 0 &&
+ !page_mappings_only &&
+ ((addr | phys) & ~CONT_PUD_MASK) == 0) {
+ if (end - addr >= CONT_PUD_SIZE)
+ __prot = __pgprot(pgprot_val(prot) |
+ PTE_CONT);
+ else
+ __prot = prot;
+ }
+ alloc_init_pud(pgd, addr, next, phys, __prot, pgtable_alloc,
page_mappings_only);
phys += next - addr;
} while (pgd++, addr = next, addr != end);
--
2.7.4
^ permalink raw reply related
* [PATCH v3 3/5] arm64: mm: set the contiguous bit for kernel mappings where appropriate
From: Ard Biesheuvel @ 2016-10-12 11:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476271425-19401-1-git-send-email-ard.biesheuvel@linaro.org>
Now that we no longer allow live kernel PMDs to be split, it is safe to
start using the contiguous bit for kernel mappings. So set the contiguous
bit in the kernel page mappings for regions whose size and alignment are
suitable for this.
This enables the following contiguous range sizes for the virtual mapping
of the kernel image, and for the linear mapping:
granule size | cont PTE | cont PMD |
-------------+------------+------------+
4 KB | 64 KB | 32 MB |
16 KB | 2 MB | 1 GB* |
64 KB | 2 MB | 16 GB* |
* only when built for 3 or more levels of translation
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/mm/mmu.c | 35 +++++++++++++++++---
1 file changed, 31 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index bf1d71b62c4f..40be4979102d 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -102,8 +102,10 @@ static const pteval_t modifiable_attr_mask = PTE_PXN | PTE_RDONLY | PTE_WRITE;
static void alloc_init_pte(pmd_t *pmd, unsigned long addr,
unsigned long end, unsigned long pfn,
pgprot_t prot,
- phys_addr_t (*pgtable_alloc)(void))
+ phys_addr_t (*pgtable_alloc)(void),
+ bool page_mappings_only)
{
+ pgprot_t __prot = prot;
pte_t *pte;
BUG_ON(pmd_sect(*pmd));
@@ -121,7 +123,18 @@ static void alloc_init_pte(pmd_t *pmd, unsigned long addr,
do {
pte_t old_pte = *pte;
- set_pte(pte, pfn_pte(pfn, prot));
+ /*
+ * Set the contiguous bit for the subsequent group of PTEs if
+ * its size and alignment are appropriate.
+ */
+ if (((addr | PFN_PHYS(pfn)) & ~CONT_PTE_MASK) == 0) {
+ if (end - addr >= CONT_PTE_SIZE && !page_mappings_only)
+ __prot = __pgprot(pgprot_val(prot) | PTE_CONT);
+ else
+ __prot = prot;
+ }
+
+ set_pte(pte, pfn_pte(pfn, __prot));
pfn++;
/*
@@ -141,6 +154,7 @@ static void alloc_init_pmd(pud_t *pud, unsigned long addr, unsigned long end,
phys_addr_t (*pgtable_alloc)(void),
bool page_mappings_only)
{
+ pgprot_t __prot = prot;
pmd_t *pmd;
unsigned long next;
@@ -167,7 +181,19 @@ static void alloc_init_pmd(pud_t *pud, unsigned long addr, unsigned long end,
/* try section mapping first */
if (((addr | next | phys) & ~SECTION_MASK) == 0 &&
!page_mappings_only) {
- pmd_set_huge(pmd, phys, prot);
+ /*
+ * Set the contiguous bit for the subsequent group of
+ * PMDs if its size and alignment are appropriate.
+ */
+ if (((addr | phys) & ~CONT_PMD_MASK) == 0) {
+ if (end - addr >= CONT_PMD_SIZE)
+ __prot = __pgprot(pgprot_val(prot) |
+ PTE_CONT);
+ else
+ __prot = prot;
+ }
+
+ pmd_set_huge(pmd, phys, __prot);
/*
* After the PMD entry has been populated once, we
@@ -178,7 +204,8 @@ static void alloc_init_pmd(pud_t *pud, unsigned long addr, unsigned long end,
~modifiable_attr_mask) != 0);
} else {
alloc_init_pte(pmd, addr, next, __phys_to_pfn(phys),
- prot, pgtable_alloc);
+ prot, pgtable_alloc,
+ page_mappings_only);
BUG_ON(pmd_val(old_pmd) != 0 &&
pmd_val(old_pmd) != pmd_val(*pmd));
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/5] arm64: mm: replace 'block_mappings_allowed' with 'page_mappings_only'
From: Ard Biesheuvel @ 2016-10-12 11:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476271425-19401-1-git-send-email-ard.biesheuvel@linaro.org>
In preparation of adding support for contiguous PTE and PMD mappings,
let's replace 'block_mappings_allowed' with 'page_mappings_only', which
will be a more accurate description of the nature of the setting once we
add such contiguous mappings into the mix.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/include/asm/mmu.h | 2 +-
arch/arm64/kernel/efi.c | 8 ++---
arch/arm64/mm/mmu.c | 32 ++++++++++----------
3 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
index 8d9fce037b2f..a81454ad5455 100644
--- a/arch/arm64/include/asm/mmu.h
+++ b/arch/arm64/include/asm/mmu.h
@@ -34,7 +34,7 @@ extern void __iomem *early_io_map(phys_addr_t phys, unsigned long virt);
extern void init_mem_pgprot(void);
extern void create_pgd_mapping(struct mm_struct *mm, phys_addr_t phys,
unsigned long virt, phys_addr_t size,
- pgprot_t prot, bool allow_block_mappings);
+ pgprot_t prot, bool page_mappings_only);
extern void *fixmap_remap_fdt(phys_addr_t dt_phys);
#endif
diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index ba9bee389fd5..5d17f377d905 100644
--- a/arch/arm64/kernel/efi.c
+++ b/arch/arm64/kernel/efi.c
@@ -62,8 +62,8 @@ struct screen_info screen_info __section(.data);
int __init efi_create_mapping(struct mm_struct *mm, efi_memory_desc_t *md)
{
pteval_t prot_val = create_mapping_protection(md);
- bool allow_block_mappings = (md->type != EFI_RUNTIME_SERVICES_CODE &&
- md->type != EFI_RUNTIME_SERVICES_DATA);
+ bool page_mappings_only = (md->type == EFI_RUNTIME_SERVICES_CODE ||
+ md->type == EFI_RUNTIME_SERVICES_DATA);
if (!PAGE_ALIGNED(md->phys_addr) ||
!PAGE_ALIGNED(md->num_pages << EFI_PAGE_SHIFT)) {
@@ -76,12 +76,12 @@ int __init efi_create_mapping(struct mm_struct *mm, efi_memory_desc_t *md)
* from the MMU routines. So avoid block mappings altogether in
* that case.
*/
- allow_block_mappings = false;
+ page_mappings_only = true;
}
create_pgd_mapping(mm, md->phys_addr, md->virt_addr,
md->num_pages << EFI_PAGE_SHIFT,
- __pgprot(prot_val | PTE_NG), allow_block_mappings);
+ __pgprot(prot_val | PTE_NG), page_mappings_only);
return 0;
}
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index e1c34e5a1d7d..bf1d71b62c4f 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -139,7 +139,7 @@ static void alloc_init_pte(pmd_t *pmd, unsigned long addr,
static void alloc_init_pmd(pud_t *pud, unsigned long addr, unsigned long end,
phys_addr_t phys, pgprot_t prot,
phys_addr_t (*pgtable_alloc)(void),
- bool allow_block_mappings)
+ bool page_mappings_only)
{
pmd_t *pmd;
unsigned long next;
@@ -166,7 +166,7 @@ static void alloc_init_pmd(pud_t *pud, unsigned long addr, unsigned long end,
/* try section mapping first */
if (((addr | next | phys) & ~SECTION_MASK) == 0 &&
- allow_block_mappings) {
+ !page_mappings_only) {
pmd_set_huge(pmd, phys, prot);
/*
@@ -204,7 +204,7 @@ static inline bool use_1G_block(unsigned long addr, unsigned long next,
static void alloc_init_pud(pgd_t *pgd, unsigned long addr, unsigned long end,
phys_addr_t phys, pgprot_t prot,
phys_addr_t (*pgtable_alloc)(void),
- bool allow_block_mappings)
+ bool page_mappings_only)
{
pud_t *pud;
unsigned long next;
@@ -226,7 +226,7 @@ static void alloc_init_pud(pgd_t *pgd, unsigned long addr, unsigned long end,
/*
* For 4K granule only, attempt to put down a 1GB block
*/
- if (use_1G_block(addr, next, phys) && allow_block_mappings) {
+ if (use_1G_block(addr, next, phys) && !page_mappings_only) {
pud_set_huge(pud, phys, prot);
/*
@@ -238,7 +238,7 @@ static void alloc_init_pud(pgd_t *pgd, unsigned long addr, unsigned long end,
~modifiable_attr_mask) != 0);
} else {
alloc_init_pmd(pud, addr, next, phys, prot,
- pgtable_alloc, allow_block_mappings);
+ pgtable_alloc, page_mappings_only);
BUG_ON(pud_val(old_pud) != 0 &&
pud_val(old_pud) != pud_val(*pud));
@@ -253,7 +253,7 @@ static void __create_pgd_mapping(pgd_t *pgdir, phys_addr_t phys,
unsigned long virt, phys_addr_t size,
pgprot_t prot,
phys_addr_t (*pgtable_alloc)(void),
- bool allow_block_mappings)
+ bool page_mappings_only)
{
unsigned long addr, length, end, next;
pgd_t *pgd = pgd_offset_raw(pgdir, virt);
@@ -273,7 +273,7 @@ static void __create_pgd_mapping(pgd_t *pgdir, phys_addr_t phys,
do {
next = pgd_addr_end(addr, end);
alloc_init_pud(pgd, addr, next, phys, prot, pgtable_alloc,
- allow_block_mappings);
+ page_mappings_only);
phys += next - addr;
} while (pgd++, addr = next, addr != end);
}
@@ -302,17 +302,17 @@ static void __init create_mapping_noalloc(phys_addr_t phys, unsigned long virt,
&phys, virt);
return;
}
- __create_pgd_mapping(init_mm.pgd, phys, virt, size, prot, NULL, true);
+ __create_pgd_mapping(init_mm.pgd, phys, virt, size, prot, NULL, false);
}
void __init create_pgd_mapping(struct mm_struct *mm, phys_addr_t phys,
unsigned long virt, phys_addr_t size,
- pgprot_t prot, bool allow_block_mappings)
+ pgprot_t prot, bool page_mappings_only)
{
BUG_ON(mm == &init_mm);
__create_pgd_mapping(mm->pgd, phys, virt, size, prot,
- pgd_pgtable_alloc, allow_block_mappings);
+ pgd_pgtable_alloc, page_mappings_only);
}
static void create_mapping_late(phys_addr_t phys, unsigned long virt,
@@ -325,7 +325,7 @@ static void create_mapping_late(phys_addr_t phys, unsigned long virt,
}
__create_pgd_mapping(init_mm.pgd, phys, virt, size, prot,
- NULL, !debug_pagealloc_enabled());
+ NULL, debug_pagealloc_enabled());
}
static void __init __map_memblock(pgd_t *pgd, phys_addr_t start, phys_addr_t end)
@@ -343,7 +343,7 @@ static void __init __map_memblock(pgd_t *pgd, phys_addr_t start, phys_addr_t end
__create_pgd_mapping(pgd, start, __phys_to_virt(start),
end - start, PAGE_KERNEL,
early_pgtable_alloc,
- !debug_pagealloc_enabled());
+ debug_pagealloc_enabled());
return;
}
@@ -356,13 +356,13 @@ static void __init __map_memblock(pgd_t *pgd, phys_addr_t start, phys_addr_t end
__phys_to_virt(start),
kernel_start - start, PAGE_KERNEL,
early_pgtable_alloc,
- !debug_pagealloc_enabled());
+ debug_pagealloc_enabled());
if (kernel_end < end)
__create_pgd_mapping(pgd, kernel_end,
__phys_to_virt(kernel_end),
end - kernel_end, PAGE_KERNEL,
early_pgtable_alloc,
- !debug_pagealloc_enabled());
+ debug_pagealloc_enabled());
/*
* Map the linear alias of the [_text, __init_begin) interval as
@@ -372,7 +372,7 @@ static void __init __map_memblock(pgd_t *pgd, phys_addr_t start, phys_addr_t end
*/
__create_pgd_mapping(pgd, kernel_start, __phys_to_virt(kernel_start),
kernel_end - kernel_start, PAGE_KERNEL_RO,
- early_pgtable_alloc, !debug_pagealloc_enabled());
+ early_pgtable_alloc, debug_pagealloc_enabled());
}
static void __init map_mem(pgd_t *pgd)
@@ -422,7 +422,7 @@ static void __init map_kernel_segment(pgd_t *pgd, void *va_start, void *va_end,
BUG_ON(!PAGE_ALIGNED(size));
__create_pgd_mapping(pgd, pa_start, (unsigned long)va_start, size, prot,
- early_pgtable_alloc, !debug_pagealloc_enabled());
+ early_pgtable_alloc, debug_pagealloc_enabled());
vma->addr = va_start;
vma->phys_addr = pa_start;
--
2.7.4
^ permalink raw reply related
* [PATCH v3 1/5] arm64: mm: BUG on unsupported manipulations of live kernel mappings
From: Ard Biesheuvel @ 2016-10-12 11:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476271425-19401-1-git-send-email-ard.biesheuvel@linaro.org>
Now that we take care not manipulate the live kernel page tables in a
way that may lead to TLB conflicts, the case where a table mapping is
replaced by a block mapping can no longer occur. So remove the handling
of this at the PUD and PMD levels, and instead, BUG() on any occurrence
of live kernel page table manipulations that modify anything other than
the permission bits.
Since mark_rodata_ro() is the only caller where the kernel mappings that
are being manipulated are actually live, drop the various conditional
flush_tlb_all() invocations, and add a single call to mark_rodata_ro()
instead.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/mm/mmu.c | 68 ++++++++++++--------
1 file changed, 41 insertions(+), 27 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 05615a3fdc6f..e1c34e5a1d7d 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -28,8 +28,6 @@
#include <linux/memblock.h>
#include <linux/fs.h>
#include <linux/io.h>
-#include <linux/slab.h>
-#include <linux/stop_machine.h>
#include <asm/barrier.h>
#include <asm/cputype.h>
@@ -95,6 +93,12 @@ static phys_addr_t __init early_pgtable_alloc(void)
return phys;
}
+/*
+ * The following mapping attributes may be updated in live
+ * kernel mappings without the need for break-before-make.
+ */
+static const pteval_t modifiable_attr_mask = PTE_PXN | PTE_RDONLY | PTE_WRITE;
+
static void alloc_init_pte(pmd_t *pmd, unsigned long addr,
unsigned long end, unsigned long pfn,
pgprot_t prot,
@@ -115,8 +119,18 @@ static void alloc_init_pte(pmd_t *pmd, unsigned long addr,
pte = pte_set_fixmap_offset(pmd, addr);
do {
+ pte_t old_pte = *pte;
+
set_pte(pte, pfn_pte(pfn, prot));
pfn++;
+
+ /*
+ * After the PTE entry has been populated once, we
+ * only allow updates to the permission attributes.
+ */
+ BUG_ON(pte_val(old_pte) != 0 &&
+ ((pte_val(old_pte) ^ pte_val(*pte)) &
+ ~modifiable_attr_mask) != 0);
} while (pte++, addr += PAGE_SIZE, addr != end);
pte_clear_fixmap();
@@ -146,27 +160,28 @@ static void alloc_init_pmd(pud_t *pud, unsigned long addr, unsigned long end,
pmd = pmd_set_fixmap_offset(pud, addr);
do {
+ pmd_t old_pmd = *pmd;
+
next = pmd_addr_end(addr, end);
+
/* try section mapping first */
if (((addr | next | phys) & ~SECTION_MASK) == 0 &&
allow_block_mappings) {
- pmd_t old_pmd =*pmd;
pmd_set_huge(pmd, phys, prot);
+
/*
- * Check for previous table entries created during
- * boot (__create_page_tables) and flush them.
+ * After the PMD entry has been populated once, we
+ * only allow updates to the permission attributes.
*/
- if (!pmd_none(old_pmd)) {
- flush_tlb_all();
- if (pmd_table(old_pmd)) {
- phys_addr_t table = pmd_page_paddr(old_pmd);
- if (!WARN_ON_ONCE(slab_is_available()))
- memblock_free(table, PAGE_SIZE);
- }
- }
+ BUG_ON(pmd_val(old_pmd) != 0 &&
+ ((pmd_val(old_pmd) ^ pmd_val(*pmd)) &
+ ~modifiable_attr_mask) != 0);
} else {
alloc_init_pte(pmd, addr, next, __phys_to_pfn(phys),
prot, pgtable_alloc);
+
+ BUG_ON(pmd_val(old_pmd) != 0 &&
+ pmd_val(old_pmd) != pmd_val(*pmd));
}
phys += next - addr;
} while (pmd++, addr = next, addr != end);
@@ -204,33 +219,29 @@ static void alloc_init_pud(pgd_t *pgd, unsigned long addr, unsigned long end,
pud = pud_set_fixmap_offset(pgd, addr);
do {
+ pud_t old_pud = *pud;
+
next = pud_addr_end(addr, end);
/*
* For 4K granule only, attempt to put down a 1GB block
*/
if (use_1G_block(addr, next, phys) && allow_block_mappings) {
- pud_t old_pud = *pud;
pud_set_huge(pud, phys, prot);
/*
- * If we have an old value for a pud, it will
- * be pointing to a pmd table that we no longer
- * need (from swapper_pg_dir).
- *
- * Look up the old pmd table and free it.
+ * After the PUD entry has been populated once, we
+ * only allow updates to the permission attributes.
*/
- if (!pud_none(old_pud)) {
- flush_tlb_all();
- if (pud_table(old_pud)) {
- phys_addr_t table = pud_page_paddr(old_pud);
- if (!WARN_ON_ONCE(slab_is_available()))
- memblock_free(table, PAGE_SIZE);
- }
- }
+ BUG_ON(pud_val(old_pud) != 0 &&
+ ((pud_val(old_pud) ^ pud_val(*pud)) &
+ ~modifiable_attr_mask) != 0);
} else {
alloc_init_pmd(pud, addr, next, phys, prot,
pgtable_alloc, allow_block_mappings);
+
+ BUG_ON(pud_val(old_pud) != 0 &&
+ pud_val(old_pud) != pud_val(*pud));
}
phys += next - addr;
} while (pud++, addr = next, addr != end);
@@ -396,6 +407,9 @@ void mark_rodata_ro(void)
section_size = (unsigned long)__init_begin - (unsigned long)__start_rodata;
create_mapping_late(__pa(__start_rodata), (unsigned long)__start_rodata,
section_size, PAGE_KERNEL_RO);
+
+ /* flush the TLBs after updating live kernel mappings */
+ flush_tlb_all();
}
static void __init map_kernel_segment(pgd_t *pgd, void *va_start, void *va_end,
--
2.7.4
^ permalink raw reply related
* [PATCH v3 0/5] arm64/mm: use the contiguous attribute for kernel mappings
From: Ard Biesheuvel @ 2016-10-12 11:23 UTC (permalink / raw)
To: linux-arm-kernel
This 5-piece series is a followup to the single patch 'arm64: mmu: set the
contiguous for kernel mappings when appropriate' sent out on the 10th [0].
Changes in v3:
- add support for contiguous PMDs for all granule sizes (not just 16k)
- add a separate patch to deal with contiguous PUDs (4k granule only), and
contiguous PMDs for 2 levels of translation (which requires special handling)
- avoid pmd_none/pud_none in the BUG() statements in patch #1, since they
may resolve in unexpected ways with folded PMDs/PUDs
Version v2 [1] addressed the following issues:
- the contiguous attribute is also useful for contigous PMD mappings on 16k
granule kernels (i.e., 1 GB blocks)
- the function parameter 'block_mappings_allowed' does not clearly convey
whether contiguous page mappings should be used, so it is renamed to
'page_mappings_only', and its meaning inverted
- instead of BUGging on changes in the PTE_CONT attribute in PMD or PTE entries
that have been populated already, BUG on any modification except for
permission attributes, which don't require break-before-make when changed.
[0] http://marc.info/?l=linux-arm-kernel&m=147612332130714
[1] http://marc.info/?l=linux-arm-kernel&m=147618975314593
An example memory map from a Seattle system with 64 GB running a 4k/3 levels
kernel with KASLR enabled is included below.
Ard Biesheuvel (5):
arm64: mm: BUG on unsupported manipulations of live kernel mappings
arm64: mm: replace 'block_mappings_allowed' with 'page_mappings_only'
arm64: mm: set the contiguous bit for kernel mappings where
appropriate
arm64: mm: support additional contiguous kernel mapping region sizes
arm64: mm: round memstart_addr to contiguous PUD/PMD size
arch/arm64/include/asm/kernel-pgtable.h | 11 +-
arch/arm64/include/asm/mmu.h | 2 +-
arch/arm64/include/asm/pgtable-hwdef.h | 6 +
arch/arm64/kernel/efi.c | 8 +-
arch/arm64/mm/mmu.c | 173 ++++++++++++++------
5 files changed, 140 insertions(+), 60 deletions(-)
--
2.7.4
// Kernel mapping
0xffffff8a70100000-0xffffff8a70200000 1M PTE ro x SHD AF CON
0xffffff8a70200000-0xffffff8a70600000 4M PMD ro x SHD AF BLK
0xffffff8a70600000-0xffffff8a706d0000 832K PTE ro x SHD AF CON
0xffffff8a706d0000-0xffffff8a70920000 2368K PTE ro NX SHD AF CON
0xffffff8a70a90000-0xffffff8a70b40000 704K PTE RW NX SHD AF CON
0xffffff8a70b40000-0xffffff8a70b44000 16K PTE RW NX SHD AF
...
---[ Linear Mapping ]---
0xffffffcc00e80000-0xffffffcc01000000 1536K PTE RW NX SHD AF CON
0xffffffcc01000000-0xffffffcc02000000 16M PMD RW NX SHD AF BLK
0xffffffcc02000000-0xffffffcc40000000 992M PMD RW NX SHD AF CON BLK
0xffffffcc40000000-0xffffffd180000000 21G PGD RW NX SHD AF BLK
0xffffffd180000000-0xffffffd198000000 384M PMD RW NX SHD AF CON BLK
0xffffffd198000000-0xffffffd199200000 18M PMD RW NX SHD AF BLK
0xffffffd199200000-0xffffffd199300000 1M PTE RW NX SHD AF CON
0xffffffd199300000-0xffffffd199400000 1M PTE ro NX SHD AF CON
0xffffffd199400000-0xffffffd199a00000 6M PMD ro NX SHD AF BLK
0xffffffd199a00000-0xffffffd199b20000 1152K PTE ro NX SHD AF CON
0xffffffd199b20000-0xffffffd199c00000 896K PTE RW NX SHD AF CON
0xffffffd199c00000-0xffffffd19a000000 4M PMD RW NX SHD AF BLK
0xffffffd19a000000-0xffffffd1c0000000 608M PMD RW NX SHD AF CON BLK
0xffffffd1c0000000-0xffffffd400000000 9G PGD RW NX SHD AF BLK
0xffffffd400000000-0xffffffd800000000 16G PGD RW NX SHD AF CON BLK
0xffffffd800000000-0xffffffdbc0000000 15G PGD RW NX SHD AF BLK
0xffffffdbc0000000-0xffffffdbf8000000 896M PMD RW NX SHD AF CON BLK
0xffffffdbf8000000-0xffffffdbf8600000 6M PMD RW NX SHD AF BLK
0xffffffdbf8600000-0xffffffdbf8700000 1M PTE RW NX SHD AF CON
0xffffffdbf87a0000-0xffffffdbf8800000 384K PTE RW NX SHD AF CON
0xffffffdbf8800000-0xffffffdbfb800000 48M PMD RW NX SHD AF BLK
0xffffffdbfb800000-0xffffffdbfb830000 192K PTE RW NX SHD AF CON
0xffffffdbfbc10000-0xffffffdbfbcd0000 768K PTE RW NX SHD AF CON
0xffffffdbfc000000-0xffffffdbfe000000 32M PMD RW NX SHD AF CON BLK
0xffffffdbfe000000-0xffffffdbffe00000 30M PMD RW NX SHD AF BLK
0xffffffdbffe00000-0xffffffdbfffd0000 1856K PTE RW NX SHD AF CON
0xffffffdbffff0000-0xffffffdc00000000 64K PTE RW NX SHD AF CON
^ permalink raw reply
* [PATCH 0/2] ARM: at91: properly handle LPDDR poweroff
From: Alexandre Belloni @ 2016-10-12 11:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1791580.DIVsjjyavb@ws-stein>
On 10/10/2016 at 08:00:30 +0200, Alexander Stein wrote :
> Hi Alexandre,
>
> On Friday 07 October 2016 18:34:25, Alexandre Belloni wrote:
> > Hi,
> >
> > This patch set improves LPDDR support on SoCs using the Atmel MPDDR
> > controller.
> >
> > LPDDR memoris can only handle up to 400 uncontrolled power offs in their
> > life. The proper power off sequence has to be applied before shutting down
> > the SoC.
> >
> > I'm not too happy with the code duplication but this is a design choice
> > that has been made before because both shitdown controler are really
> ^^^^^^^^
>
> I guess you mean shutdown? :) Same for the suject of 2nd patch.
>
I'm planning to send a v2, hopefully fixing my typos ;)
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 3/4] arm64: Allow hw watchpoint of length 3,5,6 and 7
From: Yao Qi @ 2016-10-12 11:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d6ebb3e9776154da4c1a41f17446e9e31c891a7d.1476251587.git.panand@redhat.com>
On Wed, Oct 12, 2016 at 6:58 AM, Pratyush Anand <panand@redhat.com> wrote:
> Since, arm64 can support all offset within a double word limit. Therefore,
> now support other lengths within that range as well.
How does ptracer (like GDB) detect kernel has already supported all byte
address select values? I suppose ptrace(NT_ARM_HW_WATCH, ) with
len is 3 or 5 fail on current kernel but is of success after your patches
applied.
GDB is aware of the byte address select limitation in kernel, so it always
sets 1,2,4,8 in len in ctrl. GDB needs to know whether the limitation is still
there or not.
--
Yao (??)
^ permalink raw reply
* [PATCH RESEND] ARM: dts: keystone-k2*: Increase SPI Flash partition size for U-Boot
From: Vignesh R @ 2016-10-12 11:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d1a4b59e-5524-9851-425e-5e86e05a593c@oracle.com>
Hi,
On Monday 10 October 2016 09:31 PM, Santosh Shilimkar wrote:
> Vignesh,
>
> On 10/10/2016 7:31 AM, Russell King - ARM Linux wrote:
>> On Mon, Oct 10, 2016 at 07:41:41PM +0530, Vignesh R wrote:
>>> U-Boot SPI Boot image is now more than 512KB for Keystone2 devices and
>>> cannot fit into existing partition. So, increase the SPI Flash partition
>>> for U-Boot to 1MB for all Keystone2 devices.
>>>
>>> Signed-off-by: Vignesh R <vigneshr@ti.com>
>>> ---
>>>
>>> This was submitted to v4.9 merge window but was never picked up:
>>> https://patchwork.kernel.org/patch/9135023/
>
> Another point is, if you want me to pick your patch, please copy
> me next time :-). AFAIK, am seeing this patch in my inbox first time.
>
Sorry, I did address the previous patch to you. Not sure what happened :(
>>
>> I think you need to explain why it's safe to change the layout of the
>> flash partitions like this.
>>
>> - What is this "misc" partition?
>>
>> - Why is it safe to move the "misc" partition in this way?
>>
>> - Do users need to do anything with data stored in the "misc" partition
>> when changing kernels?
>>
>> If the "misc" partition is simply unused space on the flash device, why
>> list it in DT?
>>
> Thanks Russell. Yes, above clarification would be good to get first.
Ok, will send v2 with updated commit message as per my reply in other
thread.
--
Regards
Vignesh
^ permalink raw reply
* [PATCH RESEND] ARM: dts: keystone-k2*: Increase SPI Flash partition size for U-Boot
From: Vignesh R @ 2016-10-12 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161010143144.GB1041@n2100.armlinux.org.uk>
Hi,
On Monday 10 October 2016 08:01 PM, Russell King - ARM Linux wrote:
> On Mon, Oct 10, 2016 at 07:41:41PM +0530, Vignesh R wrote:
>> U-Boot SPI Boot image is now more than 512KB for Keystone2 devices and
>> cannot fit into existing partition. So, increase the SPI Flash partition
>> for U-Boot to 1MB for all Keystone2 devices.
>>
>> Signed-off-by: Vignesh R <vigneshr@ti.com>
>> ---
>>
>> This was submitted to v4.9 merge window but was never picked up:
>> https://patchwork.kernel.org/patch/9135023/
>
> I think you need to explain why it's safe to change the layout of the
> flash partitions like this.
>
> - What is this "misc" partition?
>
This partition seems to exists from the very beginning. I believe, this
is just a spare area of flash that can be used as per end-user
requirement. Either to store a small filesystem or kernel. Copying
Murali who added above partition if he has any input here.
> - Why is it safe to move the "misc" partition in this way?
>
> - Do users need to do anything with data stored in the "misc" partition
> when changing kernels?
>
MTD layer will take care of most abstractions (like start address etc).
Will add a note in commit message informing about the reduction in size
of the partition.
> If the "misc" partition is simply unused space on the flash device, why
> list it in DT?
>
If the unused space is not listed in the DT, then there is no /dev/mtdX
node created for the unused section. User will then have to manually
edit DT, in order to get the node and mount it. Instead, lets make it
available by default.
--
Regards
Vignesh
^ permalink raw reply
* [bug report] PCI: rockchip: Add Rockchip PCIe controller support
From: Dan Carpenter @ 2016-10-12 10:54 UTC (permalink / raw)
To: linux-arm-kernel
Hello Shawn Lin,
The patch e77f847df54c: "PCI: rockchip: Add Rockchip PCIe controller
support" from Sep 3, 2016, leads to the following static checker
warning:
drivers/pci/host/pcie-rockchip.c:552 rockchip_pcie_init_port()
warn: mask and shift to zero
drivers/pci/host/pcie-rockchip.c
549
550 /* Check the final link width from negotiated lane counter from MGMT */
551 status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL);
552 status = 0x1 << ((status & PCIE_CORE_PL_CONF_LANE_MASK) >>
553 PCIE_CORE_PL_CONF_LANE_MASK);
Presumably we should be shifting by PCIE_CORE_PL_CONF_LANE_SHIFT but
this still looks all kind of jumbled up.
554 dev_dbg(dev, "current link width is x%d\n", status);
555
regards,
dan carpenter
^ permalink raw reply
* [PATCH v3 2/2] clk: imx: improve precision of AV PLL to 1 Hz
From: Emil Lundmark @ 2016-10-12 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1476267249.git.emil@limesaudio.com>
The audio and video PLLs are designed to have a precision of 1 Hz if some
conditions are met. The current implementation only allows a precision that
depends on the rate of the parent clock. E.g., if the parent clock is 24
MHz, the precision will be 24 Hz; or more generally the precision will be
p / 10^6 Hz
where p is the parent clock rate. This comes down to how the register
values for the PLL's fractional loop divider are chosen.
The clock rate calculation for the PLL is
PLL output frequency = Fref * (DIV_SELECT + NUM / DENOM)
or with a shorter notation
r = p * (d + a / b)
In addition to all variables being integers, we also have the following
conditions:
27 <= d <= 54
-2^29 <= a <= 2^29-1
0 < b <= 2^30-1
|a| < b
Here, d, a and b are register values for the fractional loop divider. We
want to chose d, a and b such that f(p, r) = p, i.e. f is our round_rate
function. Currently, d and b are chosen as
d = r / p
b = 10^6
hence we get the poor precision. And a is defined in terms of r, d, p and
b:
a = (r - d * p) * b / p
I propose that if p <= 2^30-1 (i.e., the max value for b), we chose b as
b = p
We can do this since
|a| < b
|(r - d * p) * b / p| < b
|r - d * p| < p
Which have two solutions, one of them is when p < 0, so we can skip that
one. The other is when p > 0 and
p * (d - 1) < r < p * (d + 1)
Substitute d = r / p:
(r - p) < r < (r + p) <=> p > 0
So, as long as p > 0, we can chose b = p. This is a good choise for b since
a = (r - d * p) * b / p
= (r - d * p) * p / p
= r - d * p
r = p * (d + a / b)
= p * d + p * a / b
= p * d + p * a / p
= p * d + a
and if d = r / p:
a = r - d * p
= r - r / p * p
= 0
r = p * d + a
= p * d + 0
= p * r / p
= r
I reckon this is the intention by the design of the clock rate formula.
Signed-off-by: Emil Lundmark <emil@limesaudio.com>
---
drivers/clk/imx/clk-pllv3.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
index 7a6acc3e4a92..ed3a2df536ea 100644
--- a/drivers/clk/imx/clk-pllv3.c
+++ b/drivers/clk/imx/clk-pllv3.c
@@ -234,6 +234,7 @@ static long clk_pllv3_av_round_rate(struct clk_hw *hw, unsigned long rate,
unsigned long max_rate = parent_rate * 54;
u32 div;
u32 mfn, mfd = 1000000;
+ u32 max_mfd = 0x3FFFFFFF;
u64 temp64;
if (rate > max_rate)
@@ -241,6 +242,9 @@ static long clk_pllv3_av_round_rate(struct clk_hw *hw, unsigned long rate,
else if (rate < min_rate)
rate = min_rate;
+ if (parent_rate <= max_mfd)
+ mfd = parent_rate;
+
div = rate / parent_rate;
temp64 = (u64) (rate - div * parent_rate);
temp64 *= mfd;
@@ -262,11 +266,15 @@ static int clk_pllv3_av_set_rate(struct clk_hw *hw, unsigned long rate,
unsigned long max_rate = parent_rate * 54;
u32 val, div;
u32 mfn, mfd = 1000000;
+ u32 max_mfd = 0x3FFFFFFF;
u64 temp64;
if (rate < min_rate || rate > max_rate)
return -EINVAL;
+ if (parent_rate <= max_mfd)
+ mfd = parent_rate;
+
div = rate / parent_rate;
temp64 = (u64) (rate - div * parent_rate);
temp64 *= mfd;
--
2.7.4
^ permalink raw reply related
* [PATCH v3 1/2] clk: imx: fix integer overflow in AV PLL round rate
From: Emil Lundmark @ 2016-10-12 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1476267249.git.emil@limesaudio.com>
Since 'parent_rate * mfn' may overflow 32 bits, the result should be
stored using 64 bits.
The problem was discovered when trying to set the rate of the audio PLL
(pll4_post_div) on an i.MX6Q. The desired rate was 196.608 MHz, but
the actual rate returned was 192.000570 MHz. The round rate function should
have been able to return 196.608 MHz, i.e., the desired rate.
Fixes: ba7f4f557eb6 ("clk: imx: correct AV PLL rate formula")
Cc: Anson Huang <b20788@freescale.com>
Signed-off-by: Emil Lundmark <emil@limesaudio.com>
---
drivers/clk/imx/clk-pllv3.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
index 19f9b622981a..7a6acc3e4a92 100644
--- a/drivers/clk/imx/clk-pllv3.c
+++ b/drivers/clk/imx/clk-pllv3.c
@@ -223,7 +223,7 @@ static unsigned long clk_pllv3_av_recalc_rate(struct clk_hw *hw,
temp64 *= mfn;
do_div(temp64, mfd);
- return (parent_rate * div) + (u32)temp64;
+ return parent_rate * div + (unsigned long)temp64;
}
static long clk_pllv3_av_round_rate(struct clk_hw *hw, unsigned long rate,
@@ -247,7 +247,11 @@ static long clk_pllv3_av_round_rate(struct clk_hw *hw, unsigned long rate,
do_div(temp64, parent_rate);
mfn = temp64;
- return parent_rate * div + parent_rate * mfn / mfd;
+ temp64 = (u64)parent_rate;
+ temp64 *= mfn;
+ do_div(temp64, mfd);
+
+ return parent_rate * div + (unsigned long)temp64;
}
static int clk_pllv3_av_set_rate(struct clk_hw *hw, unsigned long rate,
--
2.7.4
^ permalink raw reply related
* [PATCH v3 0/2] clk: imx: fix AV PLL rate setting
From: Emil Lundmark @ 2016-10-12 10:31 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
I discovered a problem when trying to set the rate of the audio PLL
(pll4_post_div) on an i.MX6Q. The rate I wanted to set was 196.608 MHz, but
the actual rate I got was 192.000570 MHz. This patch series fixes this
issue and also improves the precision of the audio/video PLLs.
Changes since v2:
- Cast result of 'parent_rate * mfn / mfd' to unsigned long instead of u32.
- Clarify how this issue was discovered in the commit message.
- Rebased on Linux 4.8.
Changes since v1:
- Use correct subsystem name in commit summary.
- Use 'Fixes:' tag to indicate bug fix.
- Revise argument for choosing the denominator register value after
comments from Lothar Wa?mann.
v2: http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/460809.html
v1: http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/460350.html
Emil Lundmark (2):
clk: imx: fix integer overflow in AV PLL round rate
clk: imx: improve precision of AV PLL to 1 Hz
drivers/clk/imx/clk-pllv3.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v7 2/8] power: add power sequence library
From: Heiko Stuebner @ 2016-10-12 10:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474342607-27512-3-git-send-email-peter.chen@nxp.com>
Hi,
Am Dienstag, 20. September 2016, 11:36:41 CEST schrieb Peter Chen:
> We have an well-known problem that the device needs to do some power
> sequence before it can be recognized by related host, the typical
> example like hard-wired mmc devices and usb devices.
>
> This power sequence is hard to be described at device tree and handled by
> related host driver, so we have created a common power sequence
> library to cover this requirement. The core code has supplied
> some common helpers for host driver, and individual power sequence
> libraries handle kinds of power sequence for devices.
>
> pwrseq_generic is intended for general purpose of power sequence, which
> handles gpios and clocks currently, and can cover regulator and pinctrl
> in future. The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> if only one power sequence is needed, else call of_pwrseq_on_list
> /of_pwrseq_off_list instead (eg, USB hub driver).
>
> Signed-off-by: Peter Chen <peter.chen@nxp.com>
> Tested-by Joshua Clayton <stillcompiling@gmail.com>
> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
> Tested-by: Matthias Kaehlcke <mka@chromium.org>
first of all, glad to see this move forward. I've only some qualms with the
static number of allocated power sequences below.
[...]
> diff --git a/drivers/power/pwrseq/Kconfig b/drivers/power/pwrseq/Kconfig
> new file mode 100644
> index 0000000..dff5e35
> --- /dev/null
> +++ b/drivers/power/pwrseq/Kconfig
> @@ -0,0 +1,45 @@
> +#
> +# Power Sequence library
> +#
> +
> +config POWER_SEQUENCE
> + bool
> +
> +menu "Power Sequence Support"
> +
> +config PWRSEQ_GENERIC
> + bool "Generic power sequence control"
> + depends on OF
> + select POWER_SEQUENCE
> + help
> + It is used for drivers which needs to do power sequence
> + (eg, turn on clock, toggle reset gpio) before the related
> + devices can be found by hardware. This generic one can be
> + used for common power sequence control.
> +
> +config PWRSEQ_GENERIC_INSTANCE_NUMBER
> + int "Number of Generic Power Sequence Instance"
> + depends on PWRSEQ_GENERIC
> + range 1 10
> + default 2
> + help
> + Usually, there are not so many devices needs power sequence, we set two
> + as default value.
limiting this to some arbitary compile-time number somehow seems crippling for
the single-image approach. I.e. a distribution might select something and
during its lifetime the board requiring n+1 power-sequences appears and thus
needs a different kernel version just to support that additional sequence.
Also, board designers are creative, and there were already complex examples
mentioned elsewhere, so nothing keeps people from inventing something even
more complex.
[...]
> diff --git a/drivers/power/pwrseq/pwrseq_generic.c
> b/drivers/power/pwrseq/pwrseq_generic.c new file mode 100644
> index 0000000..bcd16c3
> --- /dev/null
> +++ b/drivers/power/pwrseq/pwrseq_generic.c
[...]
> +static int pwrseq_generic_get(struct device_node *np, struct pwrseq
> *pwrseq) +{
> + struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> + enum of_gpio_flags flags;
> + int reset_gpio, clk, ret = 0;
> +
> + for (clk = 0; clk < PWRSEQ_MAX_CLKS; clk++) {
> + pwrseq_gen->clks[clk] = of_clk_get(np, clk);
> + if (IS_ERR(pwrseq_gen->clks[clk])) {
> + ret = PTR_ERR(pwrseq_gen->clks[clk]);
> + if (ret != -ENOENT)
> + goto err_put_clks;
> + pwrseq_gen->clks[clk] = NULL;
> + break;
> + }
> + }
> +
> + reset_gpio = of_get_named_gpio_flags(np, "reset-gpios", 0, &flags);
> + if (gpio_is_valid(reset_gpio)) {
> + unsigned long gpio_flags;
> +
> + if (flags & OF_GPIO_ACTIVE_LOW)
> + gpio_flags = GPIOF_ACTIVE_LOW | GPIOF_OUT_INIT_LOW;
> + else
> + gpio_flags = GPIOF_OUT_INIT_HIGH;
> +
> + ret = gpio_request_one(reset_gpio, gpio_flags,
> + "pwrseq-reset-gpios");
> + if (ret)
> + goto err_put_clks;
> +
> + pwrseq_gen->gpiod_reset = gpio_to_desc(reset_gpio);
> + of_property_read_u32(np, "reset-duration-us",
> + &pwrseq_gen->duration_us);
> + } else {
> + if (reset_gpio == -ENOENT)
> + return 0;
> +
> + ret = reset_gpio;
> + pr_err("Failed to get reset gpio on %s, err = %d\n",
> + np->full_name, reset_gpio);
> + goto err_put_clks;
> + }
> +
> + return ret;
> +
> +err_put_clks:
> + while (--clk >= 0)
> + clk_put(pwrseq_gen->clks[clk]);
> + return ret;
> +}
> +
> +static const struct of_device_id generic_id_table[] = {
> + { .compatible = "generic",},
> + { /* sentinel */ }
> +};
> +
> +static int __init pwrseq_generic_register(void)
> +{
> + struct pwrseq_generic *pwrseq_gen;
> + int i;
> +
> + for (i = 0; i < CONFIG_PWRSEQ_GENERIC_INSTANCE_NUMBER; i++) {
> + pwrseq_gen = kzalloc(sizeof(*pwrseq_gen), GFP_KERNEL);
> + if (!pwrseq_gen)
> + return -ENOMEM;
> +
> + pwrseq_gen->pwrseq.pwrseq_of_match_table = generic_id_table;
> + pwrseq_gen->pwrseq.get = pwrseq_generic_get;
> + pwrseq_gen->pwrseq.on = pwrseq_generic_on;
> + pwrseq_gen->pwrseq.off = pwrseq_generic_off;
> + pwrseq_gen->pwrseq.put = pwrseq_generic_put;
> + pwrseq_gen->pwrseq.free = pwrseq_generic_free;
> +
> + pwrseq_register(&pwrseq_gen->pwrseq);
> + }
> +
> + return 0;
> +}
> +postcore_initcall(pwrseq_generic_register)
I see that you need to have it preallocated for the compatible matching, but
wouldn't it also work to either just register the type and allocate
dynamically or otherwise just allocate a new spare everytime
pwrseq_generic_get() picks up the previous spare?
That way the total number of power sequences can still be dynamic without
haggling over how many power sequences should be the build-default in the
generic configs.
^ permalink raw reply
* [PATCH v3 07/11] arm64/tracing: fix compat syscall handling
From: Will Deacon @ 2016-10-12 10:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fed0151c-ebfd-18d2-939c-21e315dc7584@imgtec.com>
On Wed, Oct 12, 2016 at 09:07:03AM +0200, Marcin Nowakowski wrote:
> On 11.10.2016 15:36, Will Deacon wrote:
> >On Tue, Oct 11, 2016 at 12:42:52PM +0200, Marcin Nowakowski wrote:
> >>diff --git a/arch/arm64/include/asm/unistd.h b/arch/arm64/include/asm/unistd.h
> >>index e78ac26..276d049 100644
> >>--- a/arch/arm64/include/asm/unistd.h
> >>+++ b/arch/arm64/include/asm/unistd.h
> >>@@ -45,6 +45,7 @@
> >> #define __ARM_NR_compat_set_tls (__ARM_NR_COMPAT_BASE+5)
> >>
> >> #define __NR_compat_syscalls 394
> >>+#define NR_compat_syscalls (__NR_compat_syscalls)
> >
> >We may as well just define NR_compat_syscalls instead of
> >__NR_compat_syscalls and move the handful of users over.
>
> I had tried to minimise the amount of arch-specific changes here -
> especially those that are not directly related to the proposed syscall
> handling change. But I agree having these 2 #defines is a bit unnecessary
There's only three users of __NR_compat_syscalls, so I think you can
move them over.
> >>diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
> >>index 40ad08a..75d010f 100644
> >>--- a/arch/arm64/kernel/ftrace.c
> >>+++ b/arch/arm64/kernel/ftrace.c
> >>@@ -176,4 +176,20 @@ int ftrace_disable_ftrace_graph_caller(void)
> >> return ftrace_modify_graph_caller(false);
> >> }
> >> #endif /* CONFIG_DYNAMIC_FTRACE */
> >>+
> >> #endif /* CONFIG_FUNCTION_GRAPH_TRACER */
> >>+
> >>+#if (defined CONFIG_FTRACE_SYSCALLS) && (defined CONFIG_COMPAT)
> >>+
> >>+extern const void *sys_call_table[];
> >>+extern const void *compat_sys_call_table[];
> >>+
> >>+unsigned long __init arch_syscall_addr(int nr, bool compat)
> >>+{
> >>+ if (compat)
> >>+ return (unsigned long)compat_sys_call_table[nr];
> >>+
> >>+ return (unsigned long)sys_call_table[nr];
> >>+}
> >
> >Do we care about the compat private syscalls (from base 0x0f0000)? We
> >need to make sure that we exhibit the same behaviour as a native
> >32-bit ARM machine.
> >
> >Will
>
> Tracing of such syscalls has been disabled for a long time (see
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=086ba77a6db0).
> Apart from using non-contiguous numbers, they are not defined using standard
> SYSCALL macros, so they do not have any metadata generated either.
> My suggestion is that if you wanted those to be included in the trace then
> it should be done separately from these changes.
Fine by me -- I just wanted to make sure our compat behaviour matched
the behaviour of native arch/arm/. It sounds like it does, so no need to
change anything here.
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [PATCH] drm/bridge: analogix: protect power when get_modes or detect
From: Mark Yao @ 2016-10-12 10:00 UTC (permalink / raw)
To: linux-arm-kernel
The drm callback ->detect and ->get_modes seems is not power safe,
they may be called when device is power off, do register access on
detect or get_modes will cause system die.
Here is the path call ->detect before analogix_dp power on
[<ffffff800843babc>] analogix_dp_detect+0x44/0xdc
[<ffffff80083fd840>] drm_helper_probe_single_connector_modes_merge_bits+0xe8/0x41c
[<ffffff80083fdb84>] drm_helper_probe_single_connector_modes+0x10/0x18
[<ffffff8008418d24>] drm_mode_getconnector+0xf4/0x304
[<ffffff800840cff0>] drm_ioctl+0x23c/0x390
[<ffffff80081a8adc>] do_vfs_ioctl+0x4b8/0x58c
[<ffffff80081a8c10>] SyS_ioctl+0x60/0x88
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Cc: "Ville Syrj?l?" <ville.syrjala@linux.intel.com>
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 28 ++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index efac8ab..09dece2 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1062,6 +1062,13 @@ int analogix_dp_get_modes(struct drm_connector *connector)
return 0;
}
+ if (dp->dpms_mode != DRM_MODE_DPMS_ON) {
+ pm_runtime_get_sync(dp->dev);
+
+ if (dp->plat_data->power_on)
+ dp->plat_data->power_on(dp->plat_data);
+ }
+
if (analogix_dp_handle_edid(dp) == 0) {
drm_mode_connector_update_edid_property(&dp->connector, edid);
num_modes += drm_add_edid_modes(&dp->connector, edid);
@@ -1073,6 +1080,13 @@ int analogix_dp_get_modes(struct drm_connector *connector)
if (dp->plat_data->get_modes)
num_modes += dp->plat_data->get_modes(dp->plat_data, connector);
+ if (dp->dpms_mode != DRM_MODE_DPMS_ON) {
+ if (dp->plat_data->power_off)
+ dp->plat_data->power_off(dp->plat_data);
+
+ pm_runtime_put_sync(dp->dev);
+ }
+
ret = analogix_dp_prepare_panel(dp, false, false);
if (ret)
DRM_ERROR("Failed to unprepare panel (%d)\n", ret);
@@ -1106,9 +1120,23 @@ analogix_dp_detect(struct drm_connector *connector, bool force)
return connector_status_disconnected;
}
+ if (dp->dpms_mode != DRM_MODE_DPMS_ON) {
+ pm_runtime_get_sync(dp->dev);
+
+ if (dp->plat_data->power_on)
+ dp->plat_data->power_on(dp->plat_data);
+ }
+
if (!analogix_dp_detect_hpd(dp))
status = connector_status_connected;
+ if (dp->dpms_mode != DRM_MODE_DPMS_ON) {
+ if (dp->plat_data->power_off)
+ dp->plat_data->power_off(dp->plat_data);
+
+ pm_runtime_put_sync(dp->dev);
+ }
+
ret = analogix_dp_prepare_panel(dp, false, false);
if (ret)
DRM_ERROR("Failed to unprepare panel (%d)\n", ret);
--
1.9.1
^ permalink raw reply related
* [RFC 0/1] misc: Add Allwinner Q8 tablet hardware manager
From: Mark Rutland @ 2016-10-12 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJVkPPiDh66nhfh0D7BvkZ7KKN0X7uhfPGgiYbc2Ca1rg@mail.gmail.com>
Hi,
On Fri, Sep 09, 2016 at 04:32:06PM -0500, Rob Herring wrote:
> On Thu, Sep 1, 2016 at 2:08 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> > Hi All,
> >
> > Here is a first RFC for the q8 tablet hw-manager I've been talking
> > about for a while now.
> >
> > The touchscreen part is finished, I'll start working on the
> > accelerometer bits next.
>
> This at least partially overlaps with the "overlay manager" just
> posted. A dev board having different devices attached and a production
> device have 2nd source components are not really different problems.
> We need a common solution and can't have each platform making up their
> own scheme.
To follow up discussions at ELC-E, I agree that we need a common solution (if
this has to happen in the kernel rather than in an earlier stage of the boot
process).
Otherwise, we're creating pseudo-board-files, and a whole new set of problems
for ourselves.
Thanks
Mark.
^ permalink raw reply
* [patch] serial: stm32: fix a type issue
From: Dan Carpenter @ 2016-10-12 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161012085239.GD1041@n2100.armlinux.org.uk>
On Wed, Oct 12, 2016 at 09:52:39AM +0100, Russell King - ARM Linux wrote:
> On Wed, Oct 12, 2016 at 09:21:03AM +0300, Dan Carpenter wrote:
> > We store UNDEF_REG in a u8. It causes a problem in functions like
> > stm32_tx_dma_complete() where we check "if (ofs->icr == UNDEF_REG)".
> >
> > Fixes: 3489187204eb ('serial: stm32: adding dma support')
>
> Correct form is:
>
> Fixes: 12-digit-hash ("summary line")
When I originally created the Fixes tag format, I used single quotes.
I don't remember why though and I can change with the times. :)
regards,
dan carpenter
^ permalink raw reply
* [PATCH v4 08/10] ARM: dts: sun8i: Enable sun8i-emac on the Orange Pi 2
From: Maxime Ripard @ 2016-10-12 9:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161012105559.aaf9122e376fa5969a2e61d9@free.fr>
On Wed, Oct 12, 2016 at 10:55:59AM +0200, Jean-Francois Moine wrote:
> On Fri, 7 Oct 2016 10:25:55 +0200
> Corentin Labbe <clabbe.montjoie@gmail.com> wrote:
>
> > The sun8i-emac hardware is present on the Orange PI 2.
> > It uses the internal PHY.
> >
> > This patch create the needed emac node.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > ---
> > arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
> > index f93f5d1..5608eb4 100644
> > --- a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
> > +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
> > @@ -54,6 +54,7 @@
> >
> > aliases {
> > serial0 = &uart0;
> > + ethernet0 = &emac;
>
> As there is no 'of_alias_get_id' in the driver, this alias is
> useless.
Not really, this is used by U-Boot to set the mac address.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161012/982f5d88/attachment.sig>
^ permalink raw reply
* [PATCH 3/3] mtd: s3c2410: parse the device configuration from OF node
From: Boris Brezillon @ 2016-10-12 9:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475711217-974-4-git-send-email-sergio.prado@e-labworks.com>
Hi Sergio,
On Wed, 5 Oct 2016 20:46:57 -0300
Sergio Prado <sergio.prado@e-labworks.com> wrote:
> Allows configuring Samsung's s3c2410 memory controller using a
> devicetree.
>
> Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
> ---
> drivers/mtd/nand/s3c2410.c | 171 ++++++++++++++++++++++---
> include/linux/platform_data/mtd-nand-s3c2410.h | 1 +
> 2 files changed, 156 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/mtd/nand/s3c2410.c b/drivers/mtd/nand/s3c2410.c
> index 174ac9dc4265..352cf2656bc8 100644
> --- a/drivers/mtd/nand/s3c2410.c
> +++ b/drivers/mtd/nand/s3c2410.c
[...]
> +
> +static int s3c2410_nand_init_timings(struct s3c2410_nand_info *info,
> + struct nand_chip *chip)
> +{
> + struct s3c2410_platform_nand *pdata = info->platform;
> + const struct nand_sdr_timings *t;
> + int tacls, mode;
> +
> + mode = onfi_get_async_timing_mode(chip);
> + if (mode == ONFI_TIMING_MODE_UNKNOWN)
> + mode = chip->onfi_timing_mode_default;
> +
> + t = onfi_async_timing_mode_to_sdr_timings(mode);
> + if (IS_ERR(t))
> + return PTR_ERR(t);
We recently introduced an method to automate timing selection and
configuration [1]. Can you switch to this approach (the changes are in
the nand/next branch [2] and should appear in 4.9-rc1)?
Thanks,
Boris
[1]https://www.spinics.net/lists/arm-kernel/msg532007.html
[2]https://github.com/linux-nand/linux/tree/nand/next
^ permalink raw reply
* [PATCH v4 08/10] ARM: dts: sun8i: Enable sun8i-emac on the Orange Pi 2
From: Jean-Francois Moine @ 2016-10-12 8:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475828757-926-9-git-send-email-clabbe.montjoie@gmail.com>
On Fri, 7 Oct 2016 10:25:55 +0200
Corentin Labbe <clabbe.montjoie@gmail.com> wrote:
> The sun8i-emac hardware is present on the Orange PI 2.
> It uses the internal PHY.
>
> This patch create the needed emac node.
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> ---
> arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
> index f93f5d1..5608eb4 100644
> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
> @@ -54,6 +54,7 @@
>
> aliases {
> serial0 = &uart0;
> + ethernet0 = &emac;
As there is no 'of_alias_get_id' in the driver, this alias is useless.
> };
>
> chosen {
> @@ -184,3 +185,10 @@
> usb1_vbus-supply = <®_usb1_vbus>;
> status = "okay";
> };
> +
> +&emac {
> + phy-handle = <&int_mii_phy>;
> + phy-mode = "mii";
> + allwinner,leds-active-low;
> + status = "okay";
> +};
> --
> 2.7.3
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [patch] serial: stm32: fix a type issue
From: Russell King - ARM Linux @ 2016-10-12 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161012062103.GS12841@mwanda>
On Wed, Oct 12, 2016 at 09:21:03AM +0300, Dan Carpenter wrote:
> We store UNDEF_REG in a u8. It causes a problem in functions like
> stm32_tx_dma_complete() where we check "if (ofs->icr == UNDEF_REG)".
>
> Fixes: 3489187204eb ('serial: stm32: adding dma support')
Correct form is:
Fixes: 12-digit-hash ("summary line")
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v4 10/10] ARM: sunxi: Enable sun8i-emac driver on multi_v7_defconfig
From: LABBE Corentin @ 2016-10-12 8:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161011094042.GS3462@lukather>
On Tue, Oct 11, 2016 at 11:40:42AM +0200, Maxime Ripard wrote:
> On Mon, Oct 10, 2016 at 03:09:43PM +0200, Jean-Francois Moine wrote:
> > On Mon, 10 Oct 2016 14:35:11 +0200
> > LABBE Corentin <clabbe.montjoie@gmail.com> wrote:
> >
> > > On Mon, Oct 10, 2016 at 02:30:46PM +0200, Maxime Ripard wrote:
> > > > On Fri, Oct 07, 2016 at 10:25:57AM +0200, Corentin Labbe wrote:
> > > > > Enable the sun8i-emac driver in the multi_v7 default configuration
> > > > >
> > > > > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > > > > ---
> > > > > arch/arm/configs/multi_v7_defconfig | 1 +
> > > > > 1 file changed, 1 insertion(+)
> > > > >
> > > > > diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> > > > > index 5845910..f44d633 100644
> > > > > --- a/arch/arm/configs/multi_v7_defconfig
> > > > > +++ b/arch/arm/configs/multi_v7_defconfig
> > > > > @@ -229,6 +229,7 @@ CONFIG_NETDEVICES=y
> > > > > CONFIG_VIRTIO_NET=y
> > > > > CONFIG_HIX5HD2_GMAC=y
> > > > > CONFIG_SUN4I_EMAC=y
> > > > > +CONFIG_SUN8I_EMAC=y
> > > >
> > > > Any reason to build it statically?
> > >
> > > No, just copied the same than CONFIG_SUN4I_EMAC that probably do
> > > not need it also.
> >
> > All arm configs are done the same way, and, some day, the generic ARM
> > V7 kernel will not be loadable in 1Gb RAM...
>
> Yeah, if possible, I'd really like to avoid introducing statically
> built drivers to multi_v7.
>
I forgot to said it in my first answer, but yes I will change it.
Regards
^ permalink raw reply
* [PATCH v3 0/11] Add R8A7743/SK-RZG1M board support
From: Sergei Shtylyov @ 2016-10-12 8:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161012080905.GD31183@verge.net.au>
On 10/12/2016 11:09 AM, Simon Horman wrote:
>>> Here's the set of 11 patches against Simon Horman's 'renesas.git' repo's
>>> 'renesas-devel-20161003-v4.8' tag. I'm adding the device tree support for
>>> the R8A7743-based SK-RZG1M board. The SoC is close to R8A7791 and the board
>>> seems identical to the R8A7791/Porter board. The device tree patches depend on
>>> the R8A7743 CPG/MSSR driver series just posted in order to compile and work.
>>
>> Forgot to mention that this version causes a regression with the sh_eth
>> driver (well, actually with phylib): since IRQC now gets a deferred probing,
>> PHY IRQ doesn't work anymore -- phylib falls back to polling.
>
> Is there a resolution to that problem?
Geert has posted his IRQC driver patch recently. Not sure if it was
intended for merging but it solves the issue.
MBR, Sergei
^ 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