Re: [PATCH 4.14 58/62] mtd: rawnand: atmel: fix OF child-node lookup
On Mon, Nov 26, 2018 at 07:48:24AM -0800, Johan Hovold wrote:
> On Mon, Nov 26, 2018 at 04:14:18PM +0100, Greg Kroah-Hartman wrote:
> > On Mon, Nov 26, 2018 at 04:08:40PM +0100, Boris Brezillon wrote:
> > > On Mon, 26 Nov 2018 19:46:15 +0530
> > > Naresh Kamboju wrote:
> > >
> > > > Do you see build failure arm x15 beagleboard on 4.14 due to this patch ?
> > > >
> > > > On Mon, 26 Nov 2018 at 16:31, Greg Kroah-Hartman
> > > > wrote:
> > > > >
> > > > > 4.14-stable review patch. If anyone has any objections, please let
> > > > > me know.
> > > > >
> > > > > --
> > > > >
> > > > > From: Johan Hovold
> > > > >
> > > > > commit 5d1e9c2212ea6b4dd735e4fc3dd6279a365d5d10 upstream.
> > > > >
> > > > > Use the new of_get_compatible_child() helper to lookup the nfc child
> > > > > node instead of using of_find_compatible_node(), which searches the
> > > > > entire tree from a given start node and thus can return an unrelated
> > > > > (i.e. non-child) node.
> > > > >
> > > > > This also addresses a potential use-after-free (e.g. after probe
> > > > > deferral) as the tree-wide helper drops a reference to its first
> > > > > argument (i.e. the node of the device being probed).
> > > > >
> > > > > While at it, also fix a related nfc-node reference leak.
> > > > >
> > > > > Fixes: f88fc122cc34 ("mtd: nand: Cleanup/rework the atmel_nand
> > > > > driver")
> > > > > Cc: stable # 4.11
> > > > > Cc: Nicolas Ferre
> > > > > Cc: Josh Wu
> > > > > Cc: Boris Brezillon
> > > > > Signed-off-by: Johan Hovold
> > > > > Signed-off-by: Boris Brezillon
> > > > > Signed-off-by: Greg Kroah-Hartman
> > > > >
> > > > > ---
> > > > > drivers/mtd/nand/atmel/nand-controller.c | 11 +++
> > > > > 1 file changed, 7 insertions(+), 4 deletions(-)
> > > > >
> > > > > --- a/drivers/mtd/nand/atmel/nand-controller.c
> > > > > +++ b/drivers/mtd/nand/atmel/nand-controller.c
> > > > > @@ -2077,8 +2077,7 @@ atmel_hsmc_nand_controller_legacy_init(s
> > > > > int ret;
> > > > >
> > > > > nand_np = dev->of_node;
> > > > > - nfc_np = of_find_compatible_node(dev->of_node, NULL,
> > > > > -"atmel,sama5d3-nfc");
> > > > > + nfc_np = of_get_compatible_child(dev->of_node,
> > > > > "atmel,sama5d3-nfc");
> > > > > if (!nfc_np) {
> > > > > dev_err(dev, "Could not find device node for
> > > > > sama5d3-nfc\n");
> > > > > return -ENODEV;
> > > > > @@ -2492,15 +2491,19 @@ static int atmel_nand_controller_probe(s
> > > > > }
> > > > >
> > > > > if (caps->legacy_of_bindings) {
> > > > > + struct device_node *nfc_node;
> > > > > u32 ale_offs = 21;
> > > > >
> > > > > /*
> > > > > * If we are parsing legacy DT props and the DT
> > > > > contains a
> > > > > * valid NFC node, forward the request to the sama5
> > > > > logic.
> > > > > */
> > > > > - if (of_find_compatible_node(pdev->dev.of_node, NULL,
> > > > > - "atmel,sama5d3-nfc"))
> > > > > + nfc_node = of_get_compatible_child(pdev->dev.of_node,
> > > > > +
> > > > > "atmel,sama5d3-nfc");
> > > > > + if (nfc_node) {
> > > > > caps = &atmel_sama5_nand_caps;
> > > > > + of_node_put(nfc_node);
> > > > > + }
> > > > >
> > > > > /*
> > > > > * Even if the compatible says we are dealing with an
> > > > >
> > > > >
> > > >
> > > > /drivers/mtd/nand/atmel/nand-controller.c: In function
> > > > 'atmel_hsmc_nand_controller_legacy_init':
> > > > /drivers/mtd/nand/atmel/nand-controller.c:2080:11: error: implicit
> > > > declaration of function 'of_get_compatible_child'; did you mean
> > > > 'of_get_next_available_child'? [-Werror=implicit-function-declaration]
> > > >nfc_np = of_get_compatible_child(dev->of_node, "atmel,sama5d3-nfc");
> > >
> > > Looks like of_get_compatible_child() has been introduced in 4.18, hence
> > > this error.
> > >
> > > Greg, can you drop this patch from 4.14.y?
> >
> > Yes, my fault, I fixed a number of these in the past, missed this one :(
> >
> > Now dropped.
>
> The intention here was that the helper should be backported along with
> the fixes. I mentioned this in the cover letter to the series
> introducing the helper and the fixes. As they were submitted together I
> could not use the usual
>
> Cc: stable # 4.xx: 36156f9241cb
>
> notation for this. I realise I should still have mentioned this in each
> individual commit messages as well, sorry about that.
>
> The dependency for all of these fixes is:
>
> 36156f9241cb ("of: add helper to lookup compatible child node")
>
> and the original thread can be found here:
>
> https://lkml.kernel.org/r/20180827082153.22537-1-jo
Re: [PATCH] ubi: fastmap: Check each mapping only once
On Mon, Nov 26, 2018 at 11:38:42AM +0100, Martin Kepplinger wrote:
> From: Richard Weinberger
>
> [ Upstream commit 34653fd8c46e771585fce5975e4243f8fd401914 ]
>
> This commit got merged along with commit 781932375ffc
> ("ubi: fastmap: Correctly handle interrupted erasures in EBA") upstream but
> only the latter has been applied to stable v4.14.54 as commit a23cf10d9abb.
> This resulted in a performance regression. Startup on i.MX platforms is
> delayed for up to a few seconds depending on the platform.
> This fixes ubi fastmap to be of the same performance as it has been before
> said fastmap changes.
>
> Fixes: a23cf10d9abb ("ubi: fastmap: Correctly handle interrupted erasures in
> EBA")
> Signed-off-by: Richard Weinberger
> Signed-off-by: Martin Kepplinger
> ---
>
> Richard, although this fixes a major slowdown regression in -stable, do you
> consider this "stable" too?
>
> This applies and is tested only for the 4.14 stable tree. It seems to be
> equally relevant for 4.9 and 4.4 though.
Now queued up for 4.14.y, thanks.
greg k-h
[PATCH v12 1/5] x86/boot: Add get_acpi_rsdp() to parse RSDP in cmdline from KEXEC
To fix the conflict between KASLR and memory-hotremove, memory
information in SRAT table is necessary.
ACPI SRAT (System/Static Resource Affinity Table) can show the details
about memory ranges, including ranges of memory provided by hot-added
memory devices. SRAT table must be introduced by RSDP pointer (Root
System Description Pointer). So RSDP should be found firstly.
When booting form KEXEC/EFI/BIOS, the methods to find RSDP pointer
are different. When booting from KEXEC, 'acpi_rsdp' may have been
added to cmdline, so parse the cmdline and find the RSDP pointer.
Signed-off-by: Chao Fan
---
arch/x86/boot/compressed/acpitb.c | 33 +++
arch/x86/boot/compressed/misc.c | 5 +
arch/x86/boot/compressed/misc.h | 4
lib/kstrtox.c | 5 +
4 files changed, 47 insertions(+)
create mode 100644 arch/x86/boot/compressed/acpitb.c
diff --git a/arch/x86/boot/compressed/acpitb.c
b/arch/x86/boot/compressed/acpitb.c
new file mode 100644
index ..614c45655cff
--- /dev/null
+++ b/arch/x86/boot/compressed/acpitb.c
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0
+#define BOOT_CTYPE_H
+#include "misc.h"
+#include "error.h"
+
+#include
+#include
+#include
+#include
+
+#define STATIC
+#include
+
+/* Store the immovable memory regions. */
+struct mem_vector immovable_mem[MAX_NUMNODES*2];
+#endif
+
+static acpi_physical_address get_acpi_rsdp(void)
+{
+#ifdef CONFIG_KEXEC
+ unsigned long long res;
+ int len = 0;
+ char *val;
+
+ val = malloc(19);
+ len = cmdline_find_option("acpi_rsdp", val, 19);
+ if (len > 0) {
+ val[len] = 0;
+ return (acpi_physical_address)kstrtoull(val, 16, &res);
+ }
+ return 0;
+#endif
+}
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index 8dd1d5ccae58..e51713fe3add 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -12,6 +12,7 @@
* High loaded stuff by Hans Lermen & Werner Almesberger, Feb. 1996
*/
+#define BOOT_CTYPE_H
#include "misc.h"
#include "error.h"
#include "pgtable.h"
@@ -426,3 +427,7 @@ void fortify_panic(const char *name)
{
error("detected buffer overflow");
}
+
+#ifdef BOOT_STRING
+#include "../../../../lib/kstrtox.c"
+#endif
diff --git a/arch/x86/boot/compressed/misc.h b/arch/x86/boot/compressed/misc.h
index a1d5918765f3..809c31effa4b 100644
--- a/arch/x86/boot/compressed/misc.h
+++ b/arch/x86/boot/compressed/misc.h
@@ -116,3 +116,7 @@ static inline void console_init(void)
void set_sev_encryption_mask(void);
#endif
+
+/* acpitb.c */
+#define BOOT_STRING
+extern int kstrtoull(const char *s, unsigned int base, unsigned long long
*res);
diff --git a/lib/kstrtox.c b/lib/kstrtox.c
index 1006bf70bf74..a0ac1b2257b8 100644
--- a/lib/kstrtox.c
+++ b/lib/kstrtox.c
@@ -126,6 +126,9 @@ int kstrtoull(const char *s, unsigned int base, unsigned
long long *res)
}
EXPORT_SYMBOL(kstrtoull);
+/* Make compressed period code be able to use kstrtoull(). */
+#ifndef BOOT_STRING
+
/**
* kstrtoll - convert a string to a long long
* @s: The start of the string. The string must be null-terminated, and may
also
@@ -408,3 +411,5 @@ kstrto_from_user(kstrtou16_from_user, kstrtou16,
u16);
kstrto_from_user(kstrtos16_from_user, kstrtos16, s16);
kstrto_from_user(kstrtou8_from_user, kstrtou8, u8);
kstrto_from_user(kstrtos8_from_user, kstrtos8, s8);
+
+#endif /* BOOT_STRING */
--
2.19.1
[PATCH v12 5/5] x86/boot/KASLR: Limit KASLR to extracting kernel in immovable memory
KASLR may randomly choose some positions which are located in movable
memory regions. This will break memory hotplug feature and make the
movable memory chosen by KASLR practically immovable.
The solution is to limit KASLR to choose memory regions in immovable
node according to SRAT tables.
If CONFIG_EARLY_PARSE_RSDP is enabled, walk through the SRAT memory
tables and store those immovable memory regions so that KASLR can get
where to choose for randomization.
Also, rename process_mem_region() as __process_mem_region() and name new
function as process_mem_region().
Signed-off-by: Chao Fan
---
arch/x86/boot/compressed/kaslr.c | 75 +++-
1 file changed, 64 insertions(+), 11 deletions(-)
diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index b251572e77af..f0c30e3ddcb4 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -97,6 +97,11 @@ static bool memmap_too_large;
/* Store memory limit specified by "mem=nn[KMG]" or "memmap=nn[KMG]" */
static unsigned long long mem_limit = ULLONG_MAX;
+#ifdef CONFIG_MEMORY_HOTREMOVE
+/* Store the immovable memory regions */
+extern struct mem_vector immovable_mem[MAX_NUMNODES*2];
+#endif
+
enum mem_avoid_index {
MEM_AVOID_ZO_RANGE = 0,
@@ -413,6 +418,9 @@ static void mem_avoid_init(unsigned long input, unsigned
long input_size,
/* Mark the memmap regions we need to avoid */
handle_mem_options();
+ /* Mark the immovable regions we need to choose */
+ get_immovable_mem();
+
#ifdef CONFIG_X86_VERBOSE_BOOTUP
/* Make sure video RAM can be used. */
add_identity_map(0, PMD_SIZE);
@@ -568,9 +576,9 @@ static unsigned long slots_fetch_random(void)
return 0;
}
-static void process_mem_region(struct mem_vector *entry,
- unsigned long minimum,
- unsigned long image_size)
+static void __process_mem_region(struct mem_vector *entry,
+unsigned long minimum,
+unsigned long image_size)
{
struct mem_vector region, overlap;
unsigned long start_orig, end;
@@ -646,6 +654,57 @@ static void process_mem_region(struct mem_vector *entry,
}
}
+static bool process_mem_region(struct mem_vector *region,
+ unsigned long long minimum,
+ unsigned long long image_size)
+{
+ int i;
+ /*
+* If no immovable memory found, or MEMORY_HOTREMOVE disabled,
+* walk all the regions, so use region directly.
+*/
+ if (!num_immovable_mem) {
+ __process_mem_region(region, minimum, image_size);
+
+ if (slot_area_index == MAX_SLOT_AREA) {
+ debug_putstr("Aborted e820/efi memmap scan (slot_areas
full)!\n");
+ return 1;
+ }
+ return 0;
+ }
+
+#ifdef CONFIG_EARLY_PARSE_RSDP
+ /*
+* If immovable memory found, filter the intersection between
+* immovable memory and region to __process_mem_region().
+* Otherwise, go on old code.
+*/
+ for (i = 0; i < num_immovable_mem; i++) {
+ struct mem_vector entry;
+ unsigned long long start, end, entry_end, region_end;
+
+ if (!mem_overlaps(region, &immovable_mem[i]))
+ continue;
+
+ start = immovable_mem[i].start;
+ end = start + immovable_mem[i].size;
+ region_end = region->start + region->size;
+
+ entry.start = clamp(region->start, start, end);
+ entry_end = clamp(region_end, start, end);
+ entry.size = entry_end - entry.start;
+
+ __process_mem_region(&entry, minimum, image_size);
+
+ if (slot_area_index == MAX_SLOT_AREA) {
+ debug_putstr("Aborted e820/efi memmap scan (slot_areas
full)!\n");
+ return 1;
+ }
+ }
+ return 0;
+#endif
+}
+
#ifdef CONFIG_EFI
/*
* Returns true if mirror region found (and must have been processed
@@ -711,11 +770,8 @@ process_efi_entries(unsigned long minimum, unsigned long
image_size)
region.start = md->phys_addr;
region.size = md->num_pages << EFI_PAGE_SHIFT;
- process_mem_region(®ion, minimum, image_size);
- if (slot_area_index == MAX_SLOT_AREA) {
- debug_putstr("Aborted EFI scan (slot_areas full)!\n");
+ if (process_mem_region(®ion, minimum, image_size))
break;
- }
}
return true;
}
@@ -742,11 +798,8 @@ static void process_e820_entries(unsigned long minimum,
continue;
region.start = entry->addr;
region.size = entry->size;
- process
[PATCH v12 2/5] x86/boot: Add efi_get_rsdp_addr() to find RSDP from EFI table
To fix the conflict between KASLR and memory-hotremove, memory
information in SRAT table is necessary. So RSDP and SRAT table
should be parsed.
When booting form KEXEC/EFI/BIOS, the methods to compute RSDP pointer
are different. When booting from EFI, EFI table points to RSDP.
So parse the EFI table and find the RSDP pointer.
Signed-off-by: Chao Fan
---
arch/x86/boot/compressed/acpitb.c | 79 +++
1 file changed, 79 insertions(+)
diff --git a/arch/x86/boot/compressed/acpitb.c
b/arch/x86/boot/compressed/acpitb.c
index 614c45655cff..c43546648638 100644
--- a/arch/x86/boot/compressed/acpitb.c
+++ b/arch/x86/boot/compressed/acpitb.c
@@ -31,3 +31,82 @@ static acpi_physical_address get_acpi_rsdp(void)
return 0;
#endif
}
+
+/* Search EFI table for RSDP. */
+static acpi_physical_address efi_get_rsdp_addr(void)
+{
+#ifdef CONFIG_EFI
+ acpi_physical_address rsdp_addr = 0;
+ efi_system_table_t *systab;
+ struct efi_info *e;
+ bool efi_64;
+ char *sig;
+ int size;
+ int i;
+
+ e = &boot_params->efi_info;
+ sig = (char *)&e->efi_loader_signature;
+
+ if (!strncmp(sig, EFI64_LOADER_SIGNATURE, 4))
+ efi_64 = true;
+ else if (!strncmp(sig, EFI32_LOADER_SIGNATURE, 4))
+ efi_64 = false;
+ else {
+ debug_putstr("Wrong EFI loader signature.\n");
+ return 0;
+ }
+
+ /* Get systab from boot params. Based on efi_init(). */
+#ifdef CONFIG_X86_64
+ systab = (efi_system_table_t *)(e->efi_systab |
((__u64)e->efi_systab_hi<<32));
+#else
+ if (e->efi_systab_hi || e->efi_memmap_hi) {
+ debug_putstr("Error getting RSDP address: EFI system table
located above 4GB.\n");
+ return 0;
+ }
+ systab = (efi_system_table_t *)e->efi_systab;
+#endif
+
+ if (!systab)
+ return 0;
+
+ /*
+* Get EFI tables from systab. Based on efi_config_init() and
+* efi_config_parse_tables().
+*/
+ size = efi_64 ? sizeof(efi_config_table_64_t) :
+ sizeof(efi_config_table_32_t);
+
+ for (i = 0; i < systab->nr_tables; i++) {
+ void *config_tables;
+ unsigned long table;
+ efi_guid_t guid;
+
+ config_tables = (void *)(systab->tables + size * i);
+ if (efi_64) {
+ efi_config_table_64_t *tmp_table;
+
+ tmp_table = (efi_config_table_64_t *)config_tables;
+ guid = tmp_table->guid;
+ table = tmp_table->table;
+
+ if (!IS_ENABLED(CONFIG_X86_64) && table >> 32) {
+ debug_putstr("Error getting RSDP address: EFI
system table located above 4GB.\n");
+ return 0;
+ }
+ } else {
+ efi_config_table_32_t *tmp_table;
+
+ tmp_table = (efi_config_table_32_t *)config_tables;
+ guid = tmp_table->guid;
+ table = tmp_table->table;
+ }
+
+ if (!(efi_guidcmp(guid, ACPI_TABLE_GUID)))
+ rsdp_addr = (acpi_physical_address)table;
+ else if (!(efi_guidcmp(guid, ACPI_20_TABLE_GUID)))
+ return (acpi_physical_address)table;
+ }
+ return rsdp_addr;
+#endif
+}
--
2.19.1
[PATCH v12 0/5] x86/boot/KASLR: Parse ACPI table and limit KASLR to choosing immovable memory
***Background: People reported that KASLR may randomly choose some positions which are located in movable memory regions. This will break memory hotplug feature and make the movable memory chosen by KASLR can't be removed. ***Solutions: Get the information of memory hot-remove, then KASLR will know the right regions. Information about memory hot-remove is in ACPI tables, which will be parsed after start_kernel(), so that KASLR can't get the information. Somebody suggest to add a kernel parameter to specify the immovable memory so that limit KASLR in these regions. Then I make a patchset. After several versions, Ingo gave a suggestion: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1634024.html Follow Ingo's suggestion, imitate the ACPI code to parse the ACPI tables, so that the kaslr can get necessary memory information in ACPI tables. I think ACPI code is an independent part, so imitate the codes and functions to 'compressed/' directory, so that kaslr won't influence the initialization of ACPI. PATCH 1/5 Add get_acpi_rsdp() to parse RSDP in cmdline from KEXEC PATCH 2/5 Add efi_get_rsdp_addr() to find RSDP from EFI table when booting from EFI. PATCH 3/5 Add bios_get_rsdp_addr() to search RSDP in memory when EFI table not found. PATCH 4/5 Compute SRAT table from RSDP and walk SRAT table to store the immovable memory regions. PATCH 5/5 Calculate the intersection between memory regions from e820/efi memory table and immovable memory regions. Limit KASLR to choosing these regions for randomization. v1->v2: - Simplify some code. Follow Baoquan He's suggestion: - Reuse the head file of acpi code. v2->v3: - Test in more conditions, so remove the 'RFC' tag. - Change some comments. v3->v4: Follow Thomas Gleixner's suggetsion: - Put the whole efi related function into #define CONFIG_EFI and return false in the other stub. v4->v5: Follow Dou Liyang's suggestion: - Add more comments about some functions based on kernel code. - Change some typo in comments. - Clean useless variable. - Add check for the boundary of array. - Add check for 'movable_node' parameter v5->v6: Follow Baoquan He's suggestion: - Change some log. - Add the check for acpi_rsdp - Change some code logical to make code clear v6->v7: Follow Rafael's suggestion: - Add more comments and patch log. Follow test robot's suggestion: - Add "static" tag for function v7-v8: Follow Kees Cook's suggestion: - Use mem_overlaps() to check memory region. - Use #ifdef in the definition of function. v8-v9: Follow Boris' suggestion: - Change code style. - Splite PATCH 1/3 to more path. - Introduce some new function - Use existing function to rework some code Follow Masayoshi's suggetion: - Make code more readable v9->v10: Follow Baoquan's suggestion: - Change some log - Merge last two patch together. v10->v11: Follow Boris' suggestion: - Link kstrtoull() instead of copying it. - Drop the useless wrapped function. v11->v12: Follow Boris' suggestion: - Change patch log and code comments. - Add 'CONFIG_EARLY_PARSE_RSDP' to make code easy to read - Put strtoull() to misc.c Follow Masa's suggestion: - Remove the detection for 'movable_node' - Change the code logical about cmdline_find_option() Any comments will be welcome. Chao Fan (5): x86/boot: Add get_acpi_rsdp() to parse RSDP in cmdline from KEXEC x86/boot: Add efi_get_rsdp_addr() to find RSDP from EFI table x86/boot: Add bios_get_rsdp_addr() to search RSDP in memory x86/boot: Parse SRAT table from RSDP and store immovable memory x86/boot/KASLR: Limit KASLR to extracting kernel in immovable memory arch/x86/Kconfig | 10 + arch/x86/boot/compressed/Makefile | 2 + arch/x86/boot/compressed/acpitb.c | 322 ++ arch/x86/boot/compressed/kaslr.c | 79 ++-- arch/x86/boot/compressed/misc.c | 5 + arch/x86/boot/compressed/misc.h | 24 +++ lib/kstrtox.c | 5 + 7 files changed, 432 insertions(+), 15 deletions(-) create mode 100644 arch/x86/boot/compressed/acpitb.c -- 2.19.1
RE: [PATCH] [repost] Drivers: hv: vmbus: Offload the handling of channels to two workqueues
> From: gre...@linuxfoundation.org
> Sent: Wednesday, November 28, 2018 11:45 PM
> >
> > There is no change in this repost. I just rebased this patch to today's
> > char-misc's char-misc-next branch. Previously KY posted the patch with his
> > Signed-off-by (which is kept in this repost), but there was a conflict
> > issue.
> >
> > Note: the patch can't be cleanly applied to char-misc's char-misc-linus
> > branch
> --
> > to do that, we need to cherry-pick the supporting patch first:
> > 4d3c5c69191f ("Drivers: hv: vmbus: Remove the useless API
> vmbus_get_outgoing_channel()")
>
> That is not going to work for the obvious reason that this dependant
> patch is not going to be merged into 4.20-final.
It looks the dependent patch (4d3c5c69191f) is going to miss the v4.20 release.
This is not a big issue, as the dependent patch isn't really important.
> So, what do you expect us to do here? The only way this can be accepted
> is to have it go into my -next branch, which means it will show up in
> 4.21-rc1, is that ok?
Is there any chance for this patch ("Drivers: hv: vmbus: Offload the handling
...") to
go into v4.20?
If yes, I can quickly do a rebase to char-misc's char-misc-linus branch,
because actually the conflict can be very easily fixed. And I can help to fix
any
conflict when the dependent patch is backported to v4.20.1.
If no, I think this patch and the dependent patch can both go into v4.21, and
they can be both backported to v4.20.1 in future.
> But then, if that happens, it will fail to apply to any stable tree for
> 4.20 and older, like you are asking it to be done for.
>
> So what do you expect me to do here with this?
>
> totally confused,
>
> greg k-h
I hope my above reply made me clear. Sorry, I'm not really know how exactly
the releasing procedure works...
Thanks,
-- Dexuan
[PATCH v12 4/5] x86/boot: Parse SRAT table from RSDP and store immovable memory
To fix the conflict between KASLR and memory-hotremove, SRAT table
should be parsed by RSDP pointer, then find the immovable
memory regions and store them in an array called immovable_mem[].
The array called immovable_mem[] will extern to KASLR, then
KASLR will avoid to extract kernel to these regions.
Add 'CONFIG_EARLY_PARSE_RSDP' which depends on RANDOMIZE_BASE &&
MEMORY_HOTREMOVE, cause only when both KASLR and memory-hotremove
are enabled, RSDP needs to be parsed in compressed period.
Signed-off-by: Chao Fan
---
arch/x86/Kconfig | 10 +++
arch/x86/boot/compressed/Makefile | 2 +
arch/x86/boot/compressed/acpitb.c | 125 ++
arch/x86/boot/compressed/kaslr.c | 4 -
arch/x86/boot/compressed/misc.h | 20 +
5 files changed, 157 insertions(+), 4 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index a29d49ef4d56..bc775968557b 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2146,6 +2146,16 @@ config X86_NEED_RELOCS
def_bool y
depends on RANDOMIZE_BASE || (X86_32 && RELOCATABLE)
+config CONFIG_EARLY_PARSE_RSDP
+ bool "Parse RSDP pointer on compressed period for KASLR"
+ def_bool n
+ depends on RANDOMIZE_BASE && MEMORY_HOTREMOVE
+ help
+ This option parses RSDP pointer in compressed period. Works
+ for KASLR to get memory information by SRAT table and choose
+ immovable memory to extract kernel.
+ Say Y if you want to use both KASLR and memory-hotremove.
+
config PHYSICAL_ALIGN
hex "Alignment value to which kernel should be aligned"
default "0x20"
diff --git a/arch/x86/boot/compressed/Makefile
b/arch/x86/boot/compressed/Makefile
index 466f66c8a7f8..4cbfb58bf083 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -84,6 +84,8 @@ ifdef CONFIG_X86_64
vmlinux-objs-y += $(obj)/pgtable_64.o
endif
+vmlinux-objs-$(CONFIG_EARLY_PARSE_RSDP) += $(obj)/acpitb.o
+
$(obj)/eboot.o: KBUILD_CFLAGS += -fshort-wchar -mno-red-zone
vmlinux-objs-$(CONFIG_EFI_STUB) += $(obj)/eboot.o $(obj)/efi_stub_$(BITS).o \
diff --git a/arch/x86/boot/compressed/acpitb.c
b/arch/x86/boot/compressed/acpitb.c
index 82d27c4b8978..023b33d0cd3b 100644
--- a/arch/x86/boot/compressed/acpitb.c
+++ b/arch/x86/boot/compressed/acpitb.c
@@ -195,3 +195,128 @@ static acpi_physical_address bios_get_rsdp_addr(void)
return (acpi_physical_address)address;
}
}
+
+/* Used to determine RSDP table, based on acpi_os_get_root_pointer(). */
+static acpi_physical_address get_rsdp_addr(void)
+{
+ acpi_physical_address pa = 0;
+
+ pa = get_acpi_rsdp();
+
+ if (!pa)
+ pa = efi_get_rsdp_addr();
+
+ if (!pa)
+ pa = bios_get_rsdp_addr();
+
+ return pa;
+}
+
+/* Compute SRAT table from RSDP. */
+static struct acpi_table_header *get_acpi_srat_table(void)
+{
+ acpi_physical_address acpi_table;
+ acpi_physical_address root_table;
+ struct acpi_table_header *header;
+ struct acpi_table_rsdp *rsdp;
+ int num_entries;
+ char arg[10];
+ u8 *entry;
+ u32 size;
+ u32 len;
+
+ rsdp = (struct acpi_table_rsdp *)get_rsdp_addr();
+ if (!rsdp)
+ return NULL;
+
+ /* Get RSDT or XSDT from RSDP. */
+ if (!(cmdline_find_option("acpi", arg, sizeof(arg)) == 4 &&
+ !strncmp(arg, "rsdt", 4)) &&
+ rsdp->xsdt_physical_address &&
+ rsdp->revision > 1) {
+ root_table = rsdp->xsdt_physical_address;
+ size = ACPI_XSDT_ENTRY_SIZE;
+ } else {
+ root_table = rsdp->rsdt_physical_address;
+ size = ACPI_RSDT_ENTRY_SIZE;
+ }
+
+ /* Get ACPI root table from RSDT or XSDT.*/
+ header = (struct acpi_table_header *)root_table;
+ if (!header)
+ return NULL;
+
+ len = header->length;
+ num_entries = (u32)((len - sizeof(struct acpi_table_header)) / size);
+ if (num_entries > MAX_ACPI_SIG)
+ return NULL;
+
+ entry = ACPI_ADD_PTR(u8, header, sizeof(struct acpi_table_header));
+
+ while (num_entries--) {
+ u64 address64;
+
+ if (size == ACPI_RSDT_ENTRY_SIZE)
+ acpi_table = ((acpi_physical_address)
+ (*ACPI_CAST_PTR(u32, entry)));
+ else {
+ *(u64 *)(void *)&address64 = *(u64 *)(void *)entry;
+ acpi_table = (acpi_physical_address) address64;
+ }
+
+ if (acpi_table) {
+ header = (struct acpi_table_header *)acpi_table;
+
+ if (ACPI_COMPARE_NAME(header->signature, ACPI_SIG_SRAT))
+ return header;
+ }
+ entry += size;
+ }
+ return NULL;
+}
+
+/*
+ * According to ACPI table, filter t
[PATCH v12 3/5] x86/boot: Add bios_get_rsdp_addr() to search RSDP in memory
To fix the conflict between KASLR and memory-hotremove, memory
information in SRAT table is necessary. So RSDP and SRAT table
should be parsed.
When booting form KEXEC/EFI/BIOS, the methods to compute RSDP pointer
are different. When booting from BIOS, there is no variable who can
point to RSDP directly, so scan memory for the RSDP and verify RSDP
by signature and checksum.
Signed-off-by: Chao Fan
---
arch/x86/boot/compressed/acpitb.c | 85 +++
1 file changed, 85 insertions(+)
diff --git a/arch/x86/boot/compressed/acpitb.c
b/arch/x86/boot/compressed/acpitb.c
index c43546648638..82d27c4b8978 100644
--- a/arch/x86/boot/compressed/acpitb.c
+++ b/arch/x86/boot/compressed/acpitb.c
@@ -110,3 +110,88 @@ static acpi_physical_address efi_get_rsdp_addr(void)
return rsdp_addr;
#endif
}
+
+static u8 compute_checksum(u8 *buffer, u32 length)
+{
+ u8 *end = buffer + length;
+ u8 sum = 0;
+
+ while (buffer < end)
+ sum += *(buffer++);
+
+ return sum;
+}
+
+/* Search a block of memory for the RSDP signature. */
+static u8 *scan_mem_for_rsdp(u8 *start, u32 length)
+{
+ struct acpi_table_rsdp *rsdp;
+ u8 *address;
+ u8 *end;
+
+ end = start + length;
+
+ /* Search from given start address for the requested length */
+ for (address = start; address < end; address += ACPI_RSDP_SCAN_STEP) {
+ /*
+* Both RSDP signature and checksum must be correct.
+* Note: Sometimes there exists more than one RSDP in memory;
+* the valid RSDP has a valid checksum, all others have an
+* invalid checksum.
+*/
+ rsdp = (struct acpi_table_rsdp *)address;
+
+ /* BAD Signature */
+ if (!ACPI_VALIDATE_RSDP_SIG(rsdp->signature))
+ continue;
+
+ /* Check the standard checksum */
+ if (compute_checksum((u8 *) rsdp, ACPI_RSDP_CHECKSUM_LENGTH))
+ continue;
+
+ /* Check extended checksum if table version >= 2 */
+ if ((rsdp->revision >= 2) &&
+ (compute_checksum((u8 *) rsdp, ACPI_RSDP_XCHECKSUM_LENGTH)))
+ continue;
+
+ /* Signature and checksum valid, we have found a real RSDP */
+ return address;
+ }
+ return NULL;
+}
+
+/* Used to search RSDP physical address, based on acpi_find_root_pointer(). */
+static acpi_physical_address bios_get_rsdp_addr(void)
+{
+ u8 *table_ptr;
+ u32 address;
+ u8 *rsdp;
+
+ /* Get the location of the Extended BIOS Data Area (EBDA) */
+ table_ptr = (u8 *)ACPI_EBDA_PTR_LOCATION;
+ *(u32 *)(void *)&address = *(u16 *)(void *)table_ptr;
+ address <<= 4;
+ table_ptr = (u8 *)(long)address;
+
+ /*
+* Search EBDA paragraphs (EBDA is required to be a minimum of
+* 1K length)
+*/
+ if (address > 0x400) {
+ rsdp = scan_mem_for_rsdp(table_ptr, ACPI_EBDA_WINDOW_SIZE);
+ if (rsdp) {
+ address += (u32)ACPI_PTR_DIFF(rsdp, table_ptr);
+ return (acpi_physical_address)address;
+ }
+ }
+
+ table_ptr = (u8 *)ACPI_HI_RSDP_WINDOW_BASE;
+ rsdp = scan_mem_for_rsdp(table_ptr, ACPI_HI_RSDP_WINDOW_SIZE);
+
+ /* Search upper memory: 16-byte boundaries in Eh-Fh */
+ if (rsdp) {
+ address = (u32)(ACPI_HI_RSDP_WINDOW_BASE +
+ ACPI_PTR_DIFF(rsdp, table_ptr));
+ return (acpi_physical_address)address;
+ }
+}
--
2.19.1
Re: [PATCH v2] module: make it clearer when we're handling kallsyms symbols vs exported symbols
On Fri, 23 Nov 2018, Jessica Yu wrote: > The module loader internally works with both exported symbols > represented as struct kernel_symbol, as well as Elf symbols from a > module's symbol table. It's hard to distinguish sometimes which type of > symbol we're handling given that some helper function names are not > consistent or helpful. Take get_ksymbol() for instance - are we > looking for an exported symbol or a kallsyms symbol here? Or symname() > and kernel_symbol_name() - which function handles an exported symbol and > which one an Elf symbol? > > Clean up and unify the function naming scheme a bit to make it clear > which kind of symbol we're handling. This change only affects static > functions internal to the module loader. > > Signed-off-by: Jessica Yu Reviewed-by: Miroslav Benes M
Re: [PATCH] mm: remove pte_lock_deinit()
On Wed 28-11-18 16:55:25, Yu Zhao wrote:
> Pagetable page doesn't touch page->mapping or have any used field
> that overlaps with it. No need to clear mapping in dtor. In fact,
> doing so might mask problems that otherwise would be detected by
> bad_page().
yes the layour of the structure has changed since Hugh introduced the
pte lock split
> Signed-off-by: Yu Zhao
Acked-by: Michal Hocko
> ---
> include/linux/mm.h | 11 ++-
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 5411de93a363..7c8f4fc9244e 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1900,13 +1900,6 @@ static inline bool ptlock_init(struct page *page)
> return true;
> }
>
> -/* Reset page->mapping so free_pages_check won't complain. */
> -static inline void pte_lock_deinit(struct page *page)
> -{
> - page->mapping = NULL;
> - ptlock_free(page);
> -}
> -
> #else/* !USE_SPLIT_PTE_PTLOCKS */
> /*
> * We use mm->page_table_lock to guard all pagetable pages of the mm.
> @@ -1917,7 +1910,7 @@ static inline spinlock_t *pte_lockptr(struct mm_struct
> *mm, pmd_t *pmd)
> }
> static inline void ptlock_cache_init(void) {}
> static inline bool ptlock_init(struct page *page) { return true; }
> -static inline void pte_lock_deinit(struct page *page) {}
> +static inline void ptlock_free(struct page *page) {}
> #endif /* USE_SPLIT_PTE_PTLOCKS */
>
> static inline void pgtable_init(void)
> @@ -1937,7 +1930,7 @@ static inline bool pgtable_page_ctor(struct page *page)
>
> static inline void pgtable_page_dtor(struct page *page)
> {
> - pte_lock_deinit(page);
> + ptlock_free(page);
> __ClearPageTable(page);
> dec_zone_page_state(page, NR_PAGETABLE);
> }
> --
> 2.20.0.rc1.387.gf8505762e3-goog
>
--
Michal Hocko
SUSE Labs
rcu_preempt caused oom
Hi, we test on kernel 4.19.0 on android, after run more than 24 Hours monkey stress test, we see OOM on 1/10 2G memory board, the issue is not seen on the 4.14 kernel. we have done some debugs: 1. OOM is due to the filp consume too many memory: 300M vs 2G board. 2. with the 120s hung task detect, most of the tasks will block at __wait_rcu_gp: wait_for_completion(&rs_array[i].completion); [47571.863839] Kernel panic - not syncing: hung_task: blocked tasks [47571.875446] CPU: 1 PID: 13626 Comm: FinalizerDaemon Tainted: G U O 4.19.0-quilt-2e5dc0ac-gf3f313245eb6 #1 [47571.887603] Call Trace: [47571.890547] dump_stack+0x70/0xa5 [47571.894456] panic+0xe3/0x241 [47571.897977] ? wait_for_completion_timeout+0x72/0x1b0 [47571.903830] __wait_rcu_gp+0x17b/0x180 [47571.908226] synchronize_rcu.part.76+0x38/0x50 [47571.913393] ? __call_rcu.constprop.79+0x3a0/0x3a0 [47571.918948] ? __bpf_trace_rcu_invoke_callback+0x10/0x10 [47571.925094] synchronize_rcu+0x43/0x50 [47571.929487] evdev_detach_client+0x59/0x60 [47571.934264] evdev_release+0x4e/0xd0 [47571.938464] __fput+0xfa/0x1f0 [47571.942072] fput+0xe/0x10 [47571.945683] task_work_run+0x90/0xc0 [47571.949884] exit_to_usermode_loop+0x9f/0xb0 [47571.954855] do_syscall_64+0xfa/0x110 [47571.959151] entry_SYSCALL_64_after_hwframe+0x49/0xbe 3. after enable the rcu trace, we don't see rcu_quiescent_state_report trace in a long time, we see rcu_callback: rcu_preempt will never response with the rcu_invoke_callback. [47572.040668] ps-12388 1d..1 47566097572us : rcu_grace_period: rcu_preempt 23716088 AccWaitCB [47572.040707] ps-12388 1d... 47566097621us : rcu_callback: rcu_preempt rhp=783a728b func=file_free_rcu 4354/82824 [47572.040734] ps-12388 1d..1 47566097622us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Startleaf [47572.040756] ps-12388 1d..1 47566097623us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Prestarted [47572.040778] ps-12388 1d..1 47566097623us : rcu_grace_period: rcu_preempt 23716088 AccWaitCB [47572.040802] ps-12388 1d... 47566097674us : rcu_callback: rcu_preempt rhp=42c76521 func=file_free_rcu 4354/82825 [47572.040824] ps-12388 1d..1 47566097676us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Startleaf [47572.040847] ps-12388 1d..1 47566097676us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Prestarted [47572.040868] ps-12388 1d..1 47566097676us : rcu_grace_period: rcu_preempt 23716088 AccWaitCB [47572.040895] ps-12388 1d..1 47566097716us : rcu_callback: rcu_preempt rhp=5e40fde2 func=avc_node_free 4354/82826 [47572.040919] ps-12388 1d..1 47566097735us : rcu_callback: rcu_preempt rhp=f80fe353 func=avc_node_free 4354/82827 [47572.040943] ps-12388 1d..1 47566097758us : rcu_callback: rcu_preempt rhp=7486f400 func=avc_node_free 4354/82828 [47572.040967] ps-12388 1d..1 47566097760us : rcu_callback: rcu_preempt rhp=b87872a8 func=avc_node_free 4354/82829 [47572.040990] ps-12388 1d... 47566097789us : rcu_callback: rcu_preempt rhp=8c656343 func=file_free_rcu 4354/82830 [47572.041013] ps-12388 1d..1 47566097790us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Startleaf [47572.041036] ps-12388 1d..1 47566097790us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Prestarted [47572.041057] ps-12388 1d..1 47566097791us : rcu_grace_period: rcu_preempt 23716088 AccWaitCB [47572.041081] ps-12388 1d... 47566097871us : rcu_callback: rcu_preempt rhp=7e6c898c func=file_free_rcu 4354/82831 [47572.041103] ps-12388 1d..1 47566097872us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Startleaf [47572.041126] ps-12388 1d..1 47566097872us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Prestarted [47572.041147] ps-12388 1d..1 47566097873us : rcu_grace_period: rcu_preempt 23716088 AccWaitCB [47572.041170] ps-12388 1d... 47566097945us : rcu_callback: rcu_preempt rhp=32f4f174 func=file_free_rcu 4354/82832 [47572.041193] ps-12388 1d..1 47566097946us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Startleaf Do you have any suggestions to debug the issue?
Re: [PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings
David, On 28/11/18 17:42, David Lechner wrote: > On 11/27/18 9:15 AM, Roger Quadros wrote: >> >> On 26/11/18 23:14, David Lechner wrote: >>> On 11/22/18 5:38 AM, Roger Quadros wrote: From: Suman Anna This patch adds the bindings for the Programmable Real-Time Unit and Industrial Communication Subsystem (PRU-ICSS) present on various TI SoCs. The IP is present on multiple TI SoC architecture families including the OMAP architecture SoCs such as AM33xx, AM437x and AM57xx; and on a Keystone 2 architecture based 66AK2G SoC. It is also present on the Davinci based OMAPL138 SoCs and K3 architecture based AM65x SoCs as well (not covered for now). Details have been added to include bindings for various core sub-modules like the PRU Cores, the PRUSS Interrupt Controller, and other sub-modules used for Industrial Communication purposes, covering the MDIO, MII_RT and the IEP sub-modules. The binding mostly uses standard DT properties. Signed-off-by: Suman Anna Signed-off-by: Roger Quadros --- .../devicetree/bindings/soc/ti/ti,pruss.txt| 360 + 1 file changed, 360 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/ti/ti,pruss.txt diff --git a/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt b/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt new file mode 100644 index 000..24fedad --- /dev/null +++ b/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt >>> >>> ... >>> + +PRU-ICSS SoC Bus Parent Node += +This node represents the integration of the PRU-ICSS IP into a SoC, and is +required for all SoCs. The PRU-ICSS parent nodes need to be defined as child +nodes of this node. + +Required Properties: + +- compatible : should be one of, + "ti,am3356-pruss-soc-bus" for AM335x family of SoCs + "ti,am4376-pruss-soc-bus" for AM437x family of SoCs + "ti,am5728-pruss-soc-bus" for AM57xx family of SoCs + "ti,k2g-pruss-soc-bus" for 66AK2G family of SoCs +- reg: address and size of the PRUSS CFG sub-module registers + dictating the interconnect configuration >>> >>> I haven't looked into Tony's suggestion of using ti-sysc yet, so this may >>> be a >>> moot point, but how will this work with AM18xx that does not have a PRUSS >>> CFG >>> register? It seems to me that reg here should be the address and size of the >>> entire PRUSS IP block and the CFG register should be a syscon node or >>> something >>> like that. >> >> The reg property description is incorrect in the patch. It should have been >> >> reg: address of SYSCFG register. >> >> The SYSCFG register is used to enable and reset the module. >> >> But based on Tony's suggestion this wrapper driver will change to ti,sysc for >> OMAP like SoCs. >> >> For AM18xx it could be a simple wrapper driver that just populates the >> children? > > I suppose that could work. I will look into it (perhaps after seeing what you > come up with in v2). > >> >>> +- #address-cells : should be 1 +- #size-cells: should be 1 +- ranges : standard ranges definition + >>> >>> ... >>> + +PRUSS INTC Child Node +== +Each PRUSS has a single interrupt controller instance that is common to both +the PRU cores. Each interrupt controller can detect 64 input events which are +then mapped to 10 possible output interrupts through two levels of mapping. The +input events can be triggered by either the PRUs and/or various other PRUSS +internal and external peripherals. The first 2 output interrupts are fed +exclusively to the internal PRU cores, with the remaining 8 connected to +external interrupt controllers including the MPU. >>> >>> FYI, on AM18xx, there is a PRUSSEVTSEL bit in CFGCHIP3[3] (already a syscon >>> node >>> in the device tree) that allows selecting one of two groups of 32 input >>> events >>> out of this group of 64. This is perhaps getting out of the scope of this >>> patch >>> series, but I just want to make sure we end up with something that can be >>> easily >>> extended for this case. For example, I was thinking that this binding could >>> be >>> modified so that #interrupt-cells could be 1 or 2. If it is 2, then the >>> first >>> cell specifies the PRUSSEVTSEL value and the second value is the event >>> number. >>> >> >> this is da850.dtsi correct? > > Yes. > >> >> As PRUSSEVTSEL is not SYSEVENT specific but applies to all the SYSEVENTs at >> a time. >> I don't think interrupt-cells is the right place to specify this. >> >> Can it be set in DT in the board file? But this can't ch
Re: [PATCH 02/16] remoteproc: Add a rproc_set_firmware() API
On 26/11/18 23:41, David Lechner wrote:
> On 11/26/18 1:52 AM, Roger Quadros wrote:
>> From: Suman Anna
>>
>> A new API, rproc_set_firmware() is added to allow the remoteproc platform
>> drivers and remoteproc client drivers to be able to configure a custom
>> firmware name that is different from the default name used during
>> remoteproc registration. This function is being introduced to provide
>> a kernel-level equivalent of the current sysfs interface to remoteproc
>> client drivers. This allows some remoteproc drivers to choose different
>> firmwares at runtime when the remote processor is not running based on
>> the functional feature it is providing using that remote processor.
>> The TI PRU Ethernet driver will be an example of such usage as it
>> requires to use different firmwares for different supported protocols.
>>
>> Also, update the firmware_store() function used by the sysfs interface
>> to reuse this function to avoid code duplication.
>>
>> Signed-off-by: Suman Anna
>> ---
>> drivers/remoteproc/remoteproc_core.c | 61
>> +++
>> drivers/remoteproc/remoteproc_sysfs.c | 33 ++-
>> include/linux/remoteproc.h| 1 +
>> 3 files changed, 64 insertions(+), 31 deletions(-)
>>
>> diff --git a/drivers/remoteproc/remoteproc_core.c
>> b/drivers/remoteproc/remoteproc_core.c
>> index 39458a7..581e6e8 100644
>> --- a/drivers/remoteproc/remoteproc_core.c
>> +++ b/drivers/remoteproc/remoteproc_core.c
>> @@ -2151,6 +2151,67 @@ void rproc_report_crash(struct rproc *rproc, enum
>> rproc_crash_type type)
>
> ...
>
>> +int rproc_set_firmware(struct rproc *rproc, const char *fw_name)
>> +{
>> +struct device *dev = rproc->dev.parent;
>> +int ret, len;
>> +char *p;
>> +
>> +if (!rproc || !fw_name)
>> +return -EINVAL;
>> +
>> +ret = mutex_lock_interruptible(&rproc->lock);
>> +if (ret) {
>> +dev_err(dev, "can't lock rproc %s: %d\n", rproc->name, ret);
>> +return -EINVAL;
>> +}
>> +
>> +if (rproc->state != RPROC_OFFLINE) {
>> +dev_err(dev, "can't change firmware while running\n");
>> +ret = -EBUSY;
>> +goto out;
>> +}
>> +
>> +len = strcspn(fw_name, "\n");
>> +if (!len) {
>> +dev_err(dev, "can't provide a NULL firmware\n");
>
> I realize this was just copied, but technically, this would be an
> empty string rather than NULL.
>
Noted. Thanks.
cheers,
-roger
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH] armv8: GPIO: enable port input and interrupt
From: Zhang Ying-22455 The GPIO Input Buffer Enable register is used to control the input enable of each individual GPIO port. When an individual GPIO port’s direction is set to input (GPIO_GPDIR[DRn=0]), the associated input enable must be set (GPIOxGPIE[IEn]=1) to propagate the port value to the GPIO Data Register. This patch enable port input and interrupt. Signed-off-by: Zhang Ying-22455 --- drivers/gpio/gpio-mpc8xxx.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c index 793518a..f97cd23 100644 --- a/drivers/gpio/gpio-mpc8xxx.c +++ b/drivers/gpio/gpio-mpc8xxx.c @@ -362,9 +362,10 @@ static int mpc8xxx_probe(struct platform_device *pdev) if (!mpc8xxx_gc->irq) return 0; - /* ack and mask all irqs */ + /* ack and enable irqs */ gc->write_reg(mpc8xxx_gc->regs + GPIO_IER, 0x); - gc->write_reg(mpc8xxx_gc->regs + GPIO_IMR, 0); + gc->write_reg(mpc8xxx_gc->regs + GPIO_IMR, 0x); + gc->write_reg(mpc8xxx_gc->regs + GPIO_ICR2, 0x); irq_set_chained_handler_and_data(mpc8xxx_gc->irqn, mpc8xxx_gpio_irq_cascade, mpc8xxx_gc); -- 1.7.1
[PATCH] ALSA: hda: Add support for AMD Stoney Ridge
It's similar to other AMD audio devices, it also supports D3, which can
save some power drain.
Signed-off-by: Kai-Heng Feng
---
sound/pci/hda/hda_intel.c | 4
1 file changed, 4 insertions(+)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index d8eb2b5f51ae..3f5659064585 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2496,6 +2496,10 @@ static const struct pci_device_id azx_ids[] = {
/* AMD Hudson */
{ PCI_DEVICE(0x1022, 0x780d),
.driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB },
+ /* AMD Stoney */
+ { PCI_DEVICE(0x1022, 0x157a),
+ .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB |
+AZX_DCAPS_PM_RUNTIME },
/* AMD Raven */
{ PCI_DEVICE(0x1022, 0x15e3),
.driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB |
--
2.17.1
Re: [PATCH] arm64: io: specify asm operand width for __iormb()
On 29/11/18 04:19, Nick Desaulniers wrote:
> Fixes the warning produced from Clang:
> ./include/asm-generic/io.h:711:9: warning: value size does not match
> register size specified by the constraint and modifier
> [-Wasm-operand-widths]
> return readl(addr);
>^
> ./arch/arm64/include/asm/io.h:149:58: note: expanded from macro 'readl'
> ^
> ./include/asm-generic/io.h:711:9: note: use constraint modifier "w"
> ./arch/arm64/include/asm/io.h:149:50: note: expanded from macro 'readl'
> ^
> ./arch/arm64/include/asm/io.h:118:25: note: expanded from macro '__iormb'
> asm volatile("eor %w0, %1, %1\n" \
> ^
Why does the "eor %0, %1, %1" become "eor %w0, %1, %1" ?
The variable passed to the inline assembly for %0 is unsigned long, so
always 64-bits wide on arm64. Why is clang trying to use a 32-bit
register for it?
Although it's not really important since all this is just introducing a
control dependency, I find it a bit odd.
Thanks,
> Though we disable Clang's integrated assembler with -no-integrated-as,
> it still tries to do some validation of assembler constraints.
>
> While __iormb() is type agnostic to operand widths for argument v, its
> lone use is to zero'd out via eor (exclusive or).
>
> Fixes commit 6460d3201471 ("arm64: io: Ensure calls to delay routines
> are ordered against prior readX()")
> Link: https://github.com/ClangBuiltLinux/continuous-integration/issues/78
> Suggested-by: Nathan Chancellor
> Reviewed-by: Nathan Chancellor
> Signed-off-by: Nick Desaulniers
> ---
> Side note: is it not correct to cite SHAs from linux-next in "Fixes
> commit ..." lines? I guess we can drop it.
>
> Link to regression build:
> https://travis-ci.com/ClangBuiltLinux/continuous-integration/builds/92799938
>
> Link to build w/ this patch:
> https://travis-ci.com/ClangBuiltLinux/continuous-integration/builds/92935901
>
>
> arch/arm64/include/asm/io.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> index d42d00d8d5b6..dbdebf81162b 100644
> --- a/arch/arm64/include/asm/io.h
> +++ b/arch/arm64/include/asm/io.h
> @@ -115,7 +115,7 @@ static inline u64 __raw_readq(const volatile void __iomem
> *addr)
> * later instructions. This ensures that a subsequent call to\
> * udelay() will be ordered due to the ISB in get_cycles().\
> */\
> -asm volatile("eor%0, %1, %1\n"\
> +asm volatile("eor%0, %x1, %x1\n"\
> "cbnz%0, ."\
> : "=r" (tmp) : "r" (v) : "memory");\
> })
>
--
Julien Thierry
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
Re: [PATCH v6 2/2] PCI: amlogic: Add the Amlogic Meson PCIe controller driver
Hi Yue,
url:
https://github.com/0day-ci/linux/commits/Hanjie-Lin/dt-bindings-PCI-meson-add-DT-bindings-for-Amlogic-Meson-PCIe-controller/20181122-225955
base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
smatch warnings:
drivers/pci/controller/dwc/pci-meson.c:171 meson_pcie_get_mem_shared() error:
passing non negative 6 to ERR_PTR
#
https://github.com/0day-ci/linux/commit/c882cdc75e49b6de65cd3d95ebf688272af6b5f9
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout c882cdc75e49b6de65cd3d95ebf688272af6b5f9
vim +171 drivers/pci/controller/dwc/pci-meson.c
c882cdc75 Yue Wang 2018-11-22 160
c882cdc75 Yue Wang 2018-11-22 161 static void __iomem
*meson_pcie_get_mem_shared(struct platform_device *pdev,
c882cdc75 Yue Wang 2018-11-22 162
struct meson_pcie *mp,
c882cdc75 Yue Wang 2018-11-22 163
const char *id)
c882cdc75 Yue Wang 2018-11-22 164 {
c882cdc75 Yue Wang 2018-11-22 165 struct device *dev = mp->pci.dev;
c882cdc75 Yue Wang 2018-11-22 166 struct resource *res;
c882cdc75 Yue Wang 2018-11-22 167
c882cdc75 Yue Wang 2018-11-22 168 res =
platform_get_resource_byname(pdev, IORESOURCE_MEM, id);
c882cdc75 Yue Wang 2018-11-22 169 if (!res) {
c882cdc75 Yue Wang 2018-11-22 170 dev_err(dev, "No REG resource
%s\n", id);
c882cdc75 Yue Wang 2018-11-22 @171 return ERR_PTR(ENXIO);
^
-ENXIO
c882cdc75 Yue Wang 2018-11-22 172 }
c882cdc75 Yue Wang 2018-11-22 173
c882cdc75 Yue Wang 2018-11-22 174 return devm_ioremap(dev, res->start,
resource_size(res));
c882cdc75 Yue Wang 2018-11-22 175 }
c882cdc75 Yue Wang 2018-11-22 176
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
Re: [PATCH v4 20/21] mk68/mac: Switch to use %ptR
CC linux-m68k
On Wed, Nov 28, 2018 at 8:07 PM Andy Shevchenko
wrote:
> Use %ptR instead of open coded variant to print content of
> struct rtc_time in human readable format.
>
> Cc: Geert Uytterhoeven
> Signed-off-by: Andy Shevchenko
> ---
> arch/m68k/mac/misc.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/arch/m68k/mac/misc.c b/arch/m68k/mac/misc.c
> index ebb3b6d169ea..71c4735a31ee 100644
> --- a/arch/m68k/mac/misc.c
> +++ b/arch/m68k/mac/misc.c
> @@ -605,13 +605,9 @@ int mac_hwclk(int op, struct rtc_time *t)
> unmktime(now, 0,
> &t->tm_year, &t->tm_mon, &t->tm_mday,
> &t->tm_hour, &t->tm_min, &t->tm_sec);
> - pr_debug("%s: read %04d-%02d-%-2d %02d:%02d:%02d\n",
> -__func__, t->tm_year + 1900, t->tm_mon + 1,
> t->tm_mday,
> -t->tm_hour, t->tm_min, t->tm_sec);
> + pr_debug("%s: read %ptR\n", __func__, t);
> } else { /* write */
> - pr_debug("%s: tried to write %04d-%02d-%-2d %02d:%02d:%02d\n",
> -__func__, t->tm_year + 1900, t->tm_mon + 1,
> t->tm_mday,
> -t->tm_hour, t->tm_min, t->tm_sec);
> + pr_debug("%s: tried to write %ptR\n", __func__, t);
>
> switch (macintosh_config->adb_type) {
> case MAC_ADB_IOP:
> --
> 2.19.2
Re: [PATCH v4 20/21] mk68/mac: Switch to use %ptR
CC linux-m68k (now for real, stumbling to Senseo machine)
On Wed, Nov 28, 2018 at 8:07 PM Andy Shevchenko
wrote:
>
> Use %ptR instead of open coded variant to print content of
> struct rtc_time in human readable format.
>
> Cc: Geert Uytterhoeven
> Signed-off-by: Andy Shevchenko
> ---
> arch/m68k/mac/misc.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/arch/m68k/mac/misc.c b/arch/m68k/mac/misc.c
> index ebb3b6d169ea..71c4735a31ee 100644
> --- a/arch/m68k/mac/misc.c
> +++ b/arch/m68k/mac/misc.c
> @@ -605,13 +605,9 @@ int mac_hwclk(int op, struct rtc_time *t)
> unmktime(now, 0,
> &t->tm_year, &t->tm_mon, &t->tm_mday,
> &t->tm_hour, &t->tm_min, &t->tm_sec);
> - pr_debug("%s: read %04d-%02d-%-2d %02d:%02d:%02d\n",
> -__func__, t->tm_year + 1900, t->tm_mon + 1,
> t->tm_mday,
> -t->tm_hour, t->tm_min, t->tm_sec);
> + pr_debug("%s: read %ptR\n", __func__, t);
> } else { /* write */
> - pr_debug("%s: tried to write %04d-%02d-%-2d %02d:%02d:%02d\n",
> -__func__, t->tm_year + 1900, t->tm_mon + 1,
> t->tm_mday,
> -t->tm_hour, t->tm_min, t->tm_sec);
> + pr_debug("%s: tried to write %ptR\n", __func__, t);
>
> switch (macintosh_config->adb_type) {
> case MAC_ADB_IOP:
> --
> 2.19.2
Re: [PATCH V5 1/2] base/drivers/arch_topology: Replace mutex with READ_ONCE / WRITE_ONCE
On 29/11/2018 08:04, Juri Lelli wrote:
[ ... ]
>> With or without this patch, it is the case:
>>
>> task1 task2
>> | |
>> read("/sys/.../cpu1/cpu_capacity) |
>> | write("/sys/.../cpu1/cpu_capacity")
>> read("/sys/.../cpu2/cpu_capacity) |
>>
>>
>> There is no guarantee userspace can have a consistent view of the
>> capacity. As soon as it reads a capacity, it can be changed in its back.
>
> True, but w/o the mutex task1 could read different cpu_capacity values
> for a cluster (it actually can also with current implementation, we
> should grab the mutex in the read path as well if we want to avoid
> this).
Even if the mutex is on the read path, the userspace can see different
capacities because it will read the cpu_capacity per cpu directory.
The mutex will be take when reading cpu0/cpu_capacity, not for
cpu[0-9]/cpu_capacity. Between two reads, a write can happen because the
lock is released in between.
Do you agree with the patch ? Or do you want me to drop it ?
--
Facebook |
Twitter |
Re: [PATCH V3 1/3] mmc: sdhci: add support for using external DMA devices
On 29/11/18 8:07 AM, Chunyan Zhang wrote:
> Some standard SD host controllers can support both external dma
> controllers as well as ADMA/SDMA in which the SD host controller
> acts as DMA master. TI's omap controller is the case as an example.
>
> Currently the generic SDHCI code supports ADMA/SDMA integrated in
> the host controller but does not have any support for external DMA
> controllers implemented using dmaengine, meaning that custom code is
> needed for any systems that use an external DMA controller with SDHCI.
>
> Signed-off-by: Chunyan Zhang
> ---
> drivers/mmc/host/Kconfig | 14
> drivers/mmc/host/sdhci.c | 185
> ++-
> drivers/mmc/host/sdhci.h | 8 ++
> 3 files changed, 206 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 1b58739..4183f43 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -969,6 +969,7 @@ config MMC_SDHCI_XENON
> config MMC_SDHCI_OMAP
> tristate "TI SDHCI Controller Support"
> depends on MMC_SDHCI_PLTFM && OF
> + select MMC_SDHCI_EXTERNAL_DMA if DMA_ENGINE
> help
> This selects the Secure Digital Host Controller Interface (SDHCI)
> support present in TI's DRA7 SOCs. The controller supports
> @@ -977,3 +978,16 @@ config MMC_SDHCI_OMAP
> If you have a controller with this interface, say Y or M here.
>
> If unsure, say N.
> +
> +config MMC_SDHCI_EXTERNAL_DMA
> +bool "Support external DMA in standard SD host controller"
> + depends on MMC_SDHCI
> + depends on DMA_ENGINE
> + help
> + This is an option for using external DMA device via dmaengine
> + framework.
> +
> + If you have a controller which support using external DMA device
> + for data transfer, can say Y.
> +
> + If unsure, say N.
So if you are going to select this, then you don't need the prompt or help
anymore i.e.
config MMC_SDHCI_EXTERNAL_DMA
bool
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 99bdae5..ad7cc80 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -14,6 +14,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -1309,6 +1310,162 @@ static void sdhci_del_timer(struct sdhci_host *host,
> struct mmc_request *mrq)
> del_timer(&host->timer);
> }
>
> +#if IS_ENABLED(CONFIG_MMC_SDHCI_EXTERNAL_DMA)
> +static int sdhci_external_dma_init(struct sdhci_host *host)
> +{
> + int ret = 0;
> + struct mmc_host *mmc = host->mmc;
> +
> + host->tx_chan = dma_request_chan(mmc->parent, "tx");
> + if (IS_ERR(host->tx_chan)) {
> + ret = PTR_ERR(host->tx_chan);
> + if (ret != -EPROBE_DEFER)
> + pr_warn("Failed to request TX DMA channel.\n");
> + host->tx_chan = NULL;
> + return ret;
> + }
> +
> + host->rx_chan = dma_request_chan(mmc->parent, "rx");
> + if (IS_ERR(host->rx_chan)) {
> + if (host->tx_chan) {
> + dma_release_channel(host->tx_chan);
> + host->tx_chan = NULL;
> + }
> +
> + ret = PTR_ERR(host->rx_chan);
> + if (ret != -EPROBE_DEFER)
> + pr_warn("Failed to request RX DMA channel.\n");
> + host->rx_chan = NULL;
> + }
> +
> + return ret;
> +}
> +
> +static inline struct dma_chan *
> +sdhci_external_dma_channel(struct sdhci_host *host, struct mmc_data *data)
> +{
> + return data->flags & MMC_DATA_WRITE ? host->tx_chan : host->rx_chan;
> +}
> +
> +static int sdhci_external_dma_setup(struct sdhci_host *host,
> + struct mmc_command *cmd)
> +{
> + int ret, i;
> + struct dma_async_tx_descriptor *desc;
> + struct mmc_data *data = cmd->data;
> + struct dma_chan *chan;
> + struct dma_slave_config cfg;
> + dma_cookie_t cookie;
> +
> + if (!host->mapbase)
> + return -EINVAL;
> +
> + if (!data)
> + return 0;
It would read better if the above 2 if-statements were the other way around i.e.
if (!data)
return 0;
if (!host->mapbase)
return -EINVAL;
> +
> + cfg.src_addr = host->mapbase + SDHCI_BUFFER;
> + cfg.dst_addr = host->mapbase + SDHCI_BUFFER;
> + cfg.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
> + cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
> + cfg.src_maxburst = data->blksz / 4;
> + cfg.dst_maxburst = data->blksz / 4;
> +
> + /* Sanity check: all the SG entries must be aligned by block size. */
> + for (i = 0; i < data->sg_len; i++) {
> + if ((data->sg + i)->length % data->blksz)
> + return -EINVAL;
> + }
> +
> + chan = sdhci_external_dma_channel(host, data);
> +
> + ret = dmaengine_slave_config(chan, &cfg);
> + if (ret)
> +
Re: [PATCH 04/16] remoteproc/pru: Add PRU remoteproc driver
On 27/11/18 00:32, David Lechner wrote:
> On 11/26/18 1:52 AM, Roger Quadros wrote:
>
>> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
>> index ce5d061..88a86cc 100644
>> --- a/drivers/remoteproc/Makefile
>> +++ b/drivers/remoteproc/Makefile
>> @@ -26,3 +26,4 @@ qcom_wcnss_pil-y+= qcom_wcnss.o
>> qcom_wcnss_pil-y+= qcom_wcnss_iris.o
>> obj-$(CONFIG_ST_REMOTEPROC)+= st_remoteproc.o
>> obj-$(CONFIG_ST_SLIM_REMOTEPROC)+= st_slim_rproc.o
>> +obj-$(CONFIG_PRUSS_REMOTEPROC)+= pru_rproc.o
>> diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rproc.c
>> new file mode 100644
>> index 000..c35f432
>> --- /dev/null
>> +++ b/drivers/remoteproc/pru_rproc.c
>> @@ -0,0 +1,392 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * PRU-ICSS remoteproc driver for various TI SoCs
>> + *
>> + * Copyright (C) 2014-2018 Texas Instruments Incorporated -
>> http://www.ti.com/
>> + *Suman Anna
>> + *Andrew F. Davis
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>
> alphabetical order?
>
>> +#include
>> +
>> +#include "remoteproc_internal.h"
>
> alphabetical order?
ok for both.
>
>> +#include "pru_rproc.h"
>> +
>> +/* PRU_ICSS_PRU_CTRL registers */
>> +#define PRU_CTRL_CTRL0x
>> +#define PRU_CTRL_STS0x0004
>> +#define PRU_CTRL_WAKEUP_EN0x0008
>> +#define PRU_CTRL_CYCLE0x000C
>> +#define PRU_CTRL_STALL0x0010
>> +#define PRU_CTRL_CTBIR00x0020
>> +#define PRU_CTRL_CTBIR10x0024
>> +#define PRU_CTRL_CTPPR00x0028
>> +#define PRU_CTRL_CTPPR10x002C
>> +
>> +/* CTRL register bit-fields */
>> +#define CTRL_CTRL_SOFT_RST_NBIT(0)
>> +#define CTRL_CTRL_ENBIT(1)
>> +#define CTRL_CTRL_SLEEPINGBIT(2)
>> +#define CTRL_CTRL_CTR_ENBIT(3)
>> +#define CTRL_CTRL_SINGLE_STEPBIT(8)
>> +#define CTRL_CTRL_RUNSTATEBIT(15)
>> +
>> +/**
>> + * enum pru_mem - PRU core memory range identifiers
>> + */
>> +enum pru_mem {
>> +PRU_MEM_IRAM = 0,
>> +PRU_MEM_CTRL,
>> +PRU_MEM_DEBUG,
>> +PRU_MEM_MAX,
>> +};
>
> I am finding the name "mem" here to be confusing. I keep thinking
> these are just RAM regions instead of memory mapped I/O. Maybe call
> it "iomem" instead of "mem"?
>
ok.
> ...
>
>> +static int pru_rproc_set_id(struct pru_rproc *pru)
>> +{
>> +int ret = 0;
>> +u32 mask1 = 0x34000;
>> +u32 mask2 = 0x38000;
>
> These values are non-obvious and could use some comments. Also,
> they could be made into constants or macros.
>
ok.
>> +
>> +if ((pru->mem_regions[0].pa & mask1) == mask1)
>
> how about this instead:
>
> if ((pru->mem_regions[PRU_MEM_IRAM].pa & 0xf) == mask1)
>
> The 0xf mask will be important on AM18xx where INTC is at 0x34000,
> PRU0 IRAM is at 0x38000 and PRU1 IRAM is at 0x3C000.
>
I think this approach of figuring out id based on IRAM address is not scalable.
At the moment ID is used for these operations
pruss_cfg_gpimode()
pruss_cfg_get_gpmux()
pruss_cfg_set_gpmux()
All of which affect the GPCFG register of the respective PRU.
I think a better approach is to get rid of this ID logic and provide the
GPCFG syscon address to the PRU node and let the pru driver directly affect the
register.
e.g. on am335x
pru0: pru@4a334000 {
compatible = "ti,am3356-pru";
...
gpcfg = <&pruss_cfg 8>;
};
So the API changes from
int pruss_cfg_get_gpmux(struct pruss *pruss, enum pruss_pru_id id, u8 *mux)
to
int pru_rproc_cfg_get_gpmux(struct pru_rproc *pru, u8 *mux)
>> +pru->id = 0;
>> +else if ((pru->mem_regions[0].pa & mask2) == mask2)
>> +pru->id = 1;
>> +else
>> +ret = -EINVAL;
>> +
>> +return ret;
>> +}
>
cheers,
-roger
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH v14 0/5] Add i.MX8MQ clock driver
Here is a link to the 13th version: https://lkml.org/lkml/2018/11/13/1020 Changes since v13: * included changes suggested by Stephen Boyd Abel Vesa (2): clk: imx: Add imx composite clock clk: imx: Add clock driver for i.MX8MQ CCM Lucas Stach (3): dt-bindings: Add binding for i.MX8MQ CCM clk: imx: Add fractional PLL output clock clk: imx: Add SCCG PLL type .../devicetree/bindings/clock/imx8mq-clock.txt | 20 + drivers/clk/imx/Makefile | 6 +- drivers/clk/imx/clk-composite-8m.c | 178 +++ drivers/clk/imx/clk-frac-pll.c | 223 drivers/clk/imx/clk-imx8mq.c | 589 + drivers/clk/imx/clk-sccg-pll.c | 256 + drivers/clk/imx/clk.h | 64 +++ include/dt-bindings/clock/imx8mq-clock.h | 395 ++ 8 files changed, 1730 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/clock/imx8mq-clock.txt create mode 100644 drivers/clk/imx/clk-composite-8m.c create mode 100644 drivers/clk/imx/clk-frac-pll.c create mode 100644 drivers/clk/imx/clk-imx8mq.c create mode 100644 drivers/clk/imx/clk-sccg-pll.c create mode 100644 include/dt-bindings/clock/imx8mq-clock.h -- 2.7.4
[PATCH v14 2/5] clk: imx: Add fractional PLL output clock
From: Lucas Stach
This is a new fractional clock type introduced on i.MX8.
The description of this fractional clock can be found here:
https://www.nxp.com/docs/en/reference-manual/IMX8MDQLQRM.pdf#page=834
Signed-off-by: Lucas Stach
Signed-off-by: Abel Vesa
Reviewed-by: Sascha Hauer
---
drivers/clk/imx/Makefile | 1 +
drivers/clk/imx/clk-frac-pll.c | 223 +
drivers/clk/imx/clk.h | 3 +
3 files changed, 227 insertions(+)
create mode 100644 drivers/clk/imx/clk-frac-pll.c
diff --git a/drivers/clk/imx/Makefile b/drivers/clk/imx/Makefile
index 8c3baa7..4893c1f 100644
--- a/drivers/clk/imx/Makefile
+++ b/drivers/clk/imx/Makefile
@@ -6,6 +6,7 @@ obj-y += \
clk-cpu.o \
clk-fixup-div.o \
clk-fixup-mux.o \
+ clk-frac-pll.o \
clk-gate-exclusive.o \
clk-gate2.o \
clk-pllv1.o \
diff --git a/drivers/clk/imx/clk-frac-pll.c b/drivers/clk/imx/clk-frac-pll.c
new file mode 100644
index 000..9872620
--- /dev/null
+++ b/drivers/clk/imx/clk-frac-pll.c
@@ -0,0 +1,223 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2018 NXP.
+ *
+ * This driver supports the fractional plls found in the imx8m SOCs
+ *
+ * Documentation for this fractional pll can be found at:
+ * https://www.nxp.com/docs/en/reference-manual/IMX8MDQLQRM.pdf#page=834
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "clk.h"
+
+#define PLL_CFG0 0x0
+#define PLL_CFG1 0x4
+
+#define PLL_LOCK_STATUSBIT(31)
+#define PLL_PD_MASKBIT(19)
+#define PLL_BYPASS_MASKBIT(14)
+#define PLL_NEWDIV_VAL BIT(12)
+#define PLL_NEWDIV_ACK BIT(11)
+#define PLL_FRAC_DIV_MASK GENMASK(30, 7)
+#define PLL_INT_DIV_MASK GENMASK(6, 0)
+#define PLL_OUTPUT_DIV_MASKGENMASK(4, 0)
+#define PLL_FRAC_DENOM 0x100
+
+#define PLL_FRAC_LOCK_TIMEOUT 1
+#define PLL_FRAC_ACK_TIMEOUT 50
+
+struct clk_frac_pll {
+ struct clk_hw hw;
+ void __iomem*base;
+};
+
+#define to_clk_frac_pll(_hw) container_of(_hw, struct clk_frac_pll, hw)
+
+static int clk_wait_lock(struct clk_frac_pll *pll)
+{
+ u32 val;
+
+ return readl_poll_timeout(pll->base, val, val & PLL_LOCK_STATUS, 0,
+ PLL_FRAC_LOCK_TIMEOUT);
+}
+
+static int clk_wait_ack(struct clk_frac_pll *pll)
+{
+ u32 val;
+
+ /* return directly if the pll is in powerdown or in bypass */
+ if (readl_relaxed(pll->base) & (PLL_PD_MASK | PLL_BYPASS_MASK))
+ return 0;
+
+ /* Wait for the pll's divfi and divff to be reloaded */
+ return readl_poll_timeout(pll->base, val, val & PLL_NEWDIV_ACK, 0,
+ PLL_FRAC_ACK_TIMEOUT);
+}
+
+static int clk_pll_prepare(struct clk_hw *hw)
+{
+ struct clk_frac_pll *pll = to_clk_frac_pll(hw);
+ u32 val;
+
+ val = readl_relaxed(pll->base + PLL_CFG0);
+ val &= ~PLL_PD_MASK;
+ writel_relaxed(val, pll->base + PLL_CFG0);
+
+ return clk_wait_lock(pll);
+}
+
+static void clk_pll_unprepare(struct clk_hw *hw)
+{
+ struct clk_frac_pll *pll = to_clk_frac_pll(hw);
+ u32 val;
+
+ val = readl_relaxed(pll->base + PLL_CFG0);
+ val |= PLL_PD_MASK;
+ writel_relaxed(val, pll->base + PLL_CFG0);
+}
+
+static int clk_pll_is_prepared(struct clk_hw *hw)
+{
+ struct clk_frac_pll *pll = to_clk_frac_pll(hw);
+ u32 val;
+
+ val = readl_relaxed(pll->base + PLL_CFG0);
+ return (val & PLL_PD_MASK) ? 0 : 1;
+}
+
+static unsigned long clk_pll_recalc_rate(struct clk_hw *hw,
+unsigned long parent_rate)
+{
+ struct clk_frac_pll *pll = to_clk_frac_pll(hw);
+ u32 val, divff, divfi, divq;
+ u64 temp64 = parent_rate;
+
+ val = readl_relaxed(pll->base + PLL_CFG0);
+ divq = ((val & PLL_OUTPUT_DIV_MASK) + 1) * 2;
+ val = readl_relaxed(pll->base + PLL_CFG1);
+ divff = FIELD_GET(PLL_FRAC_DIV_MASK, val);
+ divfi = val & PLL_INT_DIV_MASK;
+
+ temp64 *= 8;
+ temp64 *= divff;
+ do_div(temp64, PLL_FRAC_DENOM);
+ do_div(temp64, divq);
+
+ return parent_rate * 8 * (divfi + 1) / divq + (unsigned long)temp64;
+}
+
+static long clk_pll_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *prate)
+{
+ u64 parent_rate = *prate;
+ u32 divff, divfi;
+ u64 temp64;
+
+ parent_rate *= 8;
+ rate *= 2;
+ divfi = rate / parent_rate;
+ temp64 = rate - divfi * parent_rate;
+ temp64 *= PLL_FRAC_DENOM;
+ do_div(temp64, parent_rate);
+ divff = temp64;
+
+ temp64 = parent_rate;
+ temp64 *= divff;
+ do_div(temp64, PLL_FRAC_DENOM);
+
+ return (parent_rate * divfi + temp64) / 2;
+}
+
+/*
+ * To simplify the clock calculation, we can keep the 'PLL_OUTPUT_VAL' at z
[PATCH v14 5/5] clk: imx: Add clock driver for i.MX8MQ CCM
Add driver for the Clock Control Module found on i.MX8MQ.
Signed-off-by: Anson Huang
Signed-off-by: Bai Ping
Signed-off-by: Lucas Stach
Signed-off-by: Abel Vesa
Reviewed-by: Sascha Hauer
---
drivers/clk/imx/Makefile | 1 +
drivers/clk/imx/clk-imx8mq.c | 589 +++
drivers/clk/imx/clk.h| 36 +++
3 files changed, 626 insertions(+)
create mode 100644 drivers/clk/imx/clk-imx8mq.c
diff --git a/drivers/clk/imx/Makefile b/drivers/clk/imx/Makefile
index 237444b..6952f05 100644
--- a/drivers/clk/imx/Makefile
+++ b/drivers/clk/imx/Makefile
@@ -29,4 +29,5 @@ obj-$(CONFIG_SOC_IMX6SLL) += clk-imx6sll.o
obj-$(CONFIG_SOC_IMX6SX) += clk-imx6sx.o
obj-$(CONFIG_SOC_IMX6UL) += clk-imx6ul.o
obj-$(CONFIG_SOC_IMX7D) += clk-imx7d.o
+obj-$(CONFIG_SOC_IMX8MQ) += clk-imx8mq.o
obj-$(CONFIG_SOC_VF610) += clk-vf610.o
diff --git a/drivers/clk/imx/clk-imx8mq.c b/drivers/clk/imx/clk-imx8mq.c
new file mode 100644
index 000..26b57f4
--- /dev/null
+++ b/drivers/clk/imx/clk-imx8mq.c
@@ -0,0 +1,589 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2018 NXP.
+ * Copyright (C) 2017 Pengutronix, Lucas Stach
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "clk.h"
+
+static u32 share_count_sai1;
+static u32 share_count_sai2;
+static u32 share_count_sai3;
+static u32 share_count_sai4;
+static u32 share_count_sai5;
+static u32 share_count_sai6;
+static u32 share_count_dcss;
+static u32 share_count_nand;
+
+static struct clk *clks[IMX8MQ_CLK_END];
+
+static const char *pll_ref_sels[] = { "osc_25m", "osc_27m", "dummy", "dummy",
};
+static const char *arm_pll_bypass_sels[] = {"arm_pll", "arm_pll_ref_sel", };
+static const char *gpu_pll_bypass_sels[] = {"gpu_pll", "gpu_pll_ref_sel", };
+static const char *vpu_pll_bypass_sels[] = {"vpu_pll", "vpu_pll_ref_sel", };
+static const char *audio_pll1_bypass_sels[] = {"audio_pll1",
"audio_pll1_ref_sel", };
+static const char *audio_pll2_bypass_sels[] = {"audio_pll2",
"audio_pll2_ref_sel", };
+static const char *video_pll1_bypass_sels[] = {"video_pll1",
"video_pll1_ref_sel", };
+
+static const char *sys1_pll1_out_sels[] = {"sys1_pll1", "sys1_pll1_ref_sel", };
+static const char *sys2_pll1_out_sels[] = {"sys2_pll1", "sys1_pll1_ref_sel", };
+static const char *sys3_pll1_out_sels[] = {"sys3_pll1", "sys3_pll1_ref_sel", };
+static const char *dram_pll1_out_sels[] = {"dram_pll1", "dram_pll1_ref_sel", };
+
+static const char *sys1_pll2_out_sels[] = {"sys1_pll2_div",
"sys1_pll1_ref_sel", };
+static const char *sys2_pll2_out_sels[] = {"sys2_pll2_div",
"sys2_pll1_ref_sel", };
+static const char *sys3_pll2_out_sels[] = {"sys3_pll2_div",
"sys2_pll1_ref_sel", };
+static const char *dram_pll2_out_sels[] = {"dram_pll2_div",
"dram_pll1_ref_sel", };
+
+/* CCM ROOT */
+static const char *imx8mq_a53_sels[] = {"osc_25m", "arm_pll_out",
"sys2_pll_500m", "sys2_pll_1000m",
+ "sys1_pll_800m", "sys1_pll_400m",
"audio_pll1_out", "sys3_pll2_out", };
+
+static const char *imx8mq_vpu_sels[] = {"osc_25m", "arm_pll_out",
"sys2_pll_500m", "sys2_pll_1000m",
+ "sys1_pll_800m", "sys1_pll_400m",
"audio_pll1_out", "vpu_pll_out", };
+
+static const char *imx8mq_gpu_core_sels[] = {"osc_25m", "gpu_pll_out",
"sys1_pll_800m", "sys3_pll2_out",
+"sys2_pll_1000m",
"audio_pll1_out", "video_pll1_out", "audio_pll2_out", };
+
+static const char *imx8mq_gpu_shader_sels[] = {"osc_25m", "gpu_pll_out",
"sys1_pll_800m", "sys3_pll2_out",
+ "sys2_pll_1000m",
"audio_pll1_out", "video_pll1_out", "audio_pll2_out", };
+
+static const char *imx8mq_main_axi_sels[] = {"osc_25m", "sys2_pll_333m",
"sys1_pll_800m", "sys2_pll_250m",
+"sys2_pll_1000m",
"audio_pll1_out", "video_pll1_out", "sys1_pll_100m",};
+
+static const char *imx8mq_enet_axi_sels[] = {"osc_25m", "sys1_pll_266m",
"sys1_pll_800m", "sys2_pll_250m",
+"sys2_pll_200m", "audio_pll1_out",
"video_pll1_out", "sys3_pll2_out", };
+
+static const char *imx8mq_nand_usdhc_sels[] = {"osc_25m", "sys1_pll_266m",
"sys1_pll_800m", "sys2_pll_200m",
+ "sys1_pll_133m",
"sys3_pll2_out", "sys2_pll_250m", "audio_pll1_out", };
+
+static const char *imx8mq_vpu_bus_sels[] = {"osc_25m", "sys1_pll_800m",
"vpu_pll_out", "audio_pll2_out", "sys3_pll2_out", "sys2_pll_1000m",
"sys2_pll_200m", "sys1_pll_100m", };
+
+static const char *imx8mq_disp_axi_sels[] = {"osc_25m", "sys2_pll_125m",
"sys1_pll_800m", "sys3_pll2_out", "sys1_pll_400m", "audio_pll2_out",
"clk_ext1", "clk_ext4", };
+
+static const char *imx8mq_disp_apb_sels[] = {"osc_25m", "sys2_pll_125m",
"sys1_pll_800m", "sys3_pll2_out",
+"sys1_pll_40m", "audio_pll2_out",
"clk_ext1", "clk_ext3",
[PATCH v14 1/5] dt-bindings: Add binding for i.MX8MQ CCM
From: Lucas Stach This adds the binding for the i.MX8MQ Clock Controller Module. Signed-off-by: Lucas Stach Signed-off-by: Abel Vesa Reviewed-by: Rob Herring --- .../devicetree/bindings/clock/imx8mq-clock.txt | 20 ++ include/dt-bindings/clock/imx8mq-clock.h | 395 + 2 files changed, 415 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/imx8mq-clock.txt create mode 100644 include/dt-bindings/clock/imx8mq-clock.h diff --git a/Documentation/devicetree/bindings/clock/imx8mq-clock.txt b/Documentation/devicetree/bindings/clock/imx8mq-clock.txt new file mode 100644 index 000..52de826 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imx8mq-clock.txt @@ -0,0 +1,20 @@ +* Clock bindings for NXP i.MX8M Quad + +Required properties: +- compatible: Should be "fsl,imx8mq-ccm" +- reg: Address and length of the register set +- #clock-cells: Should be <1> +- clocks: list of clock specifiers, must contain an entry for each required + entry in clock-names +- clock-names: should include the following entries: +- "ckil" +- "osc_25m" +- "osc_27m" +- "clk_ext1" +- "clk_ext2" +- "clk_ext3" +- "clk_ext4" + +The clock consumer should specify the desired clock by having the clock +ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx8mq-clock.h +for the full list of i.MX8M Quad clock IDs. diff --git a/include/dt-bindings/clock/imx8mq-clock.h b/include/dt-bindings/clock/imx8mq-clock.h new file mode 100644 index 000..b53be41 --- /dev/null +++ b/include/dt-bindings/clock/imx8mq-clock.h @@ -0,0 +1,395 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright 2016 Freescale Semiconductor, Inc. + * Copyright 2017 NXP + */ + +#ifndef __DT_BINDINGS_CLOCK_IMX8MQ_H +#define __DT_BINDINGS_CLOCK_IMX8MQ_H + +#define IMX8MQ_CLK_DUMMY 0 +#define IMX8MQ_CLK_32K 1 +#define IMX8MQ_CLK_25M 2 +#define IMX8MQ_CLK_27M 3 +#define IMX8MQ_CLK_EXT14 +#define IMX8MQ_CLK_EXT25 +#define IMX8MQ_CLK_EXT36 +#define IMX8MQ_CLK_EXT47 + +/* ANAMIX PLL clocks */ +/* FRAC PLLs */ +/* ARM PLL */ +#define IMX8MQ_ARM_PLL_REF_SEL 8 +#define IMX8MQ_ARM_PLL_REF_DIV 9 +#define IMX8MQ_ARM_PLL 10 +#define IMX8MQ_ARM_PLL_BYPASS 11 +#define IMX8MQ_ARM_PLL_OUT 12 + +/* GPU PLL */ +#define IMX8MQ_GPU_PLL_REF_SEL 13 +#define IMX8MQ_GPU_PLL_REF_DIV 14 +#define IMX8MQ_GPU_PLL 15 +#define IMX8MQ_GPU_PLL_BYPASS 16 +#define IMX8MQ_GPU_PLL_OUT 17 + +/* VPU PLL */ +#define IMX8MQ_VPU_PLL_REF_SEL 18 +#define IMX8MQ_VPU_PLL_REF_DIV 19 +#define IMX8MQ_VPU_PLL 20 +#define IMX8MQ_VPU_PLL_BYPASS 21 +#define IMX8MQ_VPU_PLL_OUT 22 + +/* AUDIO PLL1 */ +#define IMX8MQ_AUDIO_PLL1_REF_SEL 23 +#define IMX8MQ_AUDIO_PLL1_REF_DIV 24 +#define IMX8MQ_AUDIO_PLL1 25 +#define IMX8MQ_AUDIO_PLL1_BYPASS 26 +#define IMX8MQ_AUDIO_PLL1_OUT 27 + +/* AUDIO PLL2 */ +#define IMX8MQ_AUDIO_PLL2_REF_SEL 28 +#define IMX8MQ_AUDIO_PLL2_REF_DIV 29 +#define IMX8MQ_AUDIO_PLL2 30 +#define IMX8MQ_AUDIO_PLL2_BYPASS 31 +#define IMX8MQ_AUDIO_PLL2_OUT 32 + +/* VIDEO PLL1 */ +#define IMX8MQ_VIDEO_PLL1_REF_SEL 33 +#define IMX8MQ_VIDEO_PLL1_REF_DIV 34 +#define IMX8MQ_VIDEO_PLL1 35 +#define IMX8MQ_VIDEO_PLL1_BYPASS 36 +#define IMX8MQ_VIDEO_PLL1_OUT 37 + +/* SYS1 PLL */ +#define IMX8MQ_SYS1_PLL1_REF_SEL 38 +#define IMX8MQ_SYS1_PLL1_REF_DIV 39 +#define IMX8MQ_SYS1_PLL1 40 +#define IMX8MQ_SYS1_PLL1_OUT 41 +#define IMX8MQ_SYS1_PLL1_OUT_DIV 42 +#define IMX8MQ_SYS1_PLL2 43 +#define IMX8MQ_SYS1_PLL2_DIV 44 +#define IMX8MQ_SYS1_PLL2_OUT 45 + +/* SYS2 PLL */ +#define IMX8MQ_SYS2_PLL1_REF_SEL 46 +#define IMX8MQ_SYS2_PLL1_REF_DIV 47 +#define IMX8MQ_SYS2_PLL1 48 +#define IMX8MQ_SYS2_PLL1_OUT 49 +#define IMX8MQ_SYS2_PLL1_OUT_DIV 50 +#define IMX8MQ_SYS2_PLL2 51 +#define IMX8MQ_SYS2_PLL2_DIV 52 +#define IMX8MQ_SYS2_PLL2_OUT 53 + +/* SYS3 PLL */ +#define IMX8MQ_SYS3_PLL1_REF_SEL 54 +#define IMX8MQ_SYS3_PLL1_REF_DIV 55 +#define IMX8MQ_SYS3_PLL1 56 +#define IMX8MQ_SYS3_PLL1_OUT 57 +#define IMX8MQ_SYS3_PLL1_OUT_DIV 58 +#define IMX8MQ_SYS3_PLL2 59 +#define IMX8MQ_SYS3_PLL2_DIV 60 +#define IMX8MQ_SYS3_PLL2_OUT 61 + +/* DRAM PLL */ +#define IMX8MQ_DRAM_PLL1_REF_SEL 62 +#define IMX8MQ_DRAM_PLL1_REF_DIV 63 +#define IMX8MQ_DRAM_PLL1 64 +#define IMX8MQ_DRAM_PLL1_OUT 65 +#define IMX8MQ_DRAM_PLL1_OUT_DIV 66 +#define IMX8MQ_DRAM_PLL2
[PATCH v14 3/5] clk: imx: Add SCCG PLL type
From: Lucas Stach
The SCCG is a new PLL type introduced on i.MX8.
The description of this SCCG clock can be found here:
https://www.nxp.com/docs/en/reference-manual/IMX8MDQLQRM.pdf#page=834
Signed-off-by: Lucas Stach
Signed-off-by: Abel Vesa
Reviewed-by: Sascha Hauer
---
drivers/clk/imx/Makefile | 3 +-
drivers/clk/imx/clk-sccg-pll.c | 256 +
drivers/clk/imx/clk.h | 9 ++
3 files changed, 267 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/imx/clk-sccg-pll.c
diff --git a/drivers/clk/imx/Makefile b/drivers/clk/imx/Makefile
index 4893c1f..b87513c 100644
--- a/drivers/clk/imx/Makefile
+++ b/drivers/clk/imx/Makefile
@@ -12,7 +12,8 @@ obj-y += \
clk-pllv1.o \
clk-pllv2.o \
clk-pllv3.o \
- clk-pfd.o
+ clk-pfd.o \
+ clk-sccg-pll.o
obj-$(CONFIG_SOC_IMX1) += clk-imx1.o
obj-$(CONFIG_SOC_IMX21) += clk-imx21.o
diff --git a/drivers/clk/imx/clk-sccg-pll.c b/drivers/clk/imx/clk-sccg-pll.c
new file mode 100644
index 000..ee7752b
--- /dev/null
+++ b/drivers/clk/imx/clk-sccg-pll.c
@@ -0,0 +1,256 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2018 NXP.
+ *
+ * This driver supports the SCCG plls found in the imx8m SOCs
+ *
+ * Documentation for this SCCG pll can be found at:
+ * https://www.nxp.com/docs/en/reference-manual/IMX8MDQLQRM.pdf#page=834
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "clk.h"
+
+/* PLL CFGs */
+#define PLL_CFG0 0x0
+#define PLL_CFG1 0x4
+#define PLL_CFG2 0x8
+
+#define PLL_DIVF1_MASK GENMASK(18, 13)
+#define PLL_DIVF2_MASK GENMASK(12, 7)
+#define PLL_DIVR1_MASK GENMASK(27, 25)
+#define PLL_DIVR2_MASK GENMASK(24, 19)
+#define PLL_REF_MASK GENMASK(2, 0)
+
+#define PLL_LOCK_MASK BIT(31)
+#define PLL_PD_MASKBIT(7)
+
+#define OSC_25M2500
+#define OSC_27M2700
+
+#define PLL_SCCG_LOCK_TIMEOUT 70
+
+struct clk_sccg_pll {
+ struct clk_hw hw;
+ void __iomem*base;
+};
+
+#define to_clk_sccg_pll(_hw) container_of(_hw, struct clk_sccg_pll, hw)
+
+static int clk_pll_wait_lock(struct clk_sccg_pll *pll)
+{
+ u32 val;
+
+ return readl_poll_timeout(pll->base, val, val & PLL_LOCK_MASK, 0,
+ PLL_SCCG_LOCK_TIMEOUT);
+}
+
+static int clk_pll1_is_prepared(struct clk_hw *hw)
+{
+ struct clk_sccg_pll *pll = to_clk_sccg_pll(hw);
+ u32 val;
+
+ val = readl_relaxed(pll->base + PLL_CFG0);
+ return (val & PLL_PD_MASK) ? 0 : 1;
+}
+
+static unsigned long clk_pll1_recalc_rate(struct clk_hw *hw,
+unsigned long parent_rate)
+{
+ struct clk_sccg_pll *pll = to_clk_sccg_pll(hw);
+ u32 val, divf;
+
+ val = readl_relaxed(pll->base + PLL_CFG2);
+ divf = FIELD_GET(PLL_DIVF1_MASK, val);
+
+ return parent_rate * 2 * (divf + 1);
+}
+
+static long clk_pll1_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *prate)
+{
+ unsigned long parent_rate = *prate;
+ u32 div;
+
+ if (!parent_rate)
+ return 0;
+
+ div = rate / (parent_rate * 2);
+
+ return parent_rate * div * 2;
+}
+
+static int clk_pll1_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ struct clk_sccg_pll *pll = to_clk_sccg_pll(hw);
+ u32 val;
+ u32 divf;
+
+ if (!parent_rate)
+ return -EINVAL;
+
+ divf = rate / (parent_rate * 2);
+
+ val = readl_relaxed(pll->base + PLL_CFG2);
+ val &= ~PLL_DIVF1_MASK;
+ val |= FIELD_PREP(PLL_DIVF1_MASK, divf - 1);
+ writel_relaxed(val, pll->base + PLL_CFG2);
+
+ return clk_pll_wait_lock(pll);
+}
+
+static int clk_pll1_prepare(struct clk_hw *hw)
+{
+ struct clk_sccg_pll *pll = to_clk_sccg_pll(hw);
+ u32 val;
+
+ val = readl_relaxed(pll->base + PLL_CFG0);
+ val &= ~PLL_PD_MASK;
+ writel_relaxed(val, pll->base + PLL_CFG0);
+
+ return clk_pll_wait_lock(pll);
+}
+
+static void clk_pll1_unprepare(struct clk_hw *hw)
+{
+ struct clk_sccg_pll *pll = to_clk_sccg_pll(hw);
+ u32 val;
+
+ val = readl_relaxed(pll->base + PLL_CFG0);
+ val |= PLL_PD_MASK;
+ writel_relaxed(val, pll->base + PLL_CFG0);
+
+}
+
+static unsigned long clk_pll2_recalc_rate(struct clk_hw *hw,
+unsigned long parent_rate)
+{
+ struct clk_sccg_pll *pll = to_clk_sccg_pll(hw);
+ u32 val, ref, divr1, divf1, divr2, divf2;
+ u64 temp64;
+
+ val = readl_relaxed(pll->base + PLL_CFG0);
+ switch (FIELD_GET(PLL_REF_MASK, val)) {
+ case 0:
+ ref = OSC_25M;
+ break;
+ case 1:
+ ref = OSC_27M;
+ b
[PATCH v14 4/5] clk: imx: Add imx composite clock
Since a lot of clocks on imx8m are formed by a mux, gate, predivider and
divider, the idea here is to combine all of those into one composite clock,
but we need to deal with both predivider and divider at the same time and
therefore we add the imx8m_clk_composite_divider_ops and register
the composite clock with those.
Signed-off-by: Abel Vesa
Suggested-by: Sascha Hauer
Reviewed-by: Sascha Hauer
---
drivers/clk/imx/Makefile | 1 +
drivers/clk/imx/clk-composite-8m.c | 178 +
drivers/clk/imx/clk.h | 16
3 files changed, 195 insertions(+)
create mode 100644 drivers/clk/imx/clk-composite-8m.c
diff --git a/drivers/clk/imx/Makefile b/drivers/clk/imx/Makefile
index b87513c..237444b 100644
--- a/drivers/clk/imx/Makefile
+++ b/drivers/clk/imx/Makefile
@@ -3,6 +3,7 @@
obj-y += \
clk.o \
clk-busy.o \
+ clk-composite-8m.o \
clk-cpu.o \
clk-fixup-div.o \
clk-fixup-mux.o \
diff --git a/drivers/clk/imx/clk-composite-8m.c
b/drivers/clk/imx/clk-composite-8m.c
new file mode 100644
index 000..6d9d371
--- /dev/null
+++ b/drivers/clk/imx/clk-composite-8m.c
@@ -0,0 +1,178 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2018 NXP
+ */
+
+#include
+#include
+#include
+
+#include "clk.h"
+
+#define PCG_PREDIV_SHIFT 16
+#define PCG_PREDIV_WIDTH 3
+#define PCG_PREDIV_MAX 8
+
+#define PCG_DIV_SHIFT 0
+#define PCG_DIV_WIDTH 6
+#define PCG_DIV_MAX64
+
+#define PCG_PCS_SHIFT 24
+#define PCG_PCS_MASK 0x7
+
+#define PCG_CGC_SHIFT 28
+
+static unsigned long imx8m_clk_composite_divider_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct clk_divider *divider = to_clk_divider(hw);
+ unsigned long prediv_rate;
+ unsigned int prediv_value;
+ unsigned int div_value;
+
+ prediv_value = readl(divider->reg) >> divider->shift;
+ prediv_value &= clk_div_mask(divider->width);
+
+ prediv_rate = divider_recalc_rate(hw, parent_rate, prediv_value,
+ NULL, divider->flags,
+ divider->width);
+
+ div_value = readl(divider->reg) >> PCG_DIV_SHIFT;
+ div_value &= clk_div_mask(PCG_DIV_WIDTH);
+
+ return divider_recalc_rate(hw, prediv_rate, div_value, NULL,
+ divider->flags, PCG_DIV_WIDTH);
+}
+
+static int imx8m_clk_composite_compute_dividers(unsigned long rate,
+ unsigned long parent_rate,
+ int *prediv, int *postdiv)
+{
+ int div1, div2;
+ int error = INT_MAX;
+ int ret = -EINVAL;
+
+ *prediv = 1;
+ *postdiv = 1;
+
+ for (div1 = 1; div1 <= PCG_PREDIV_MAX; div1++) {
+ for (div2 = 1; div2 <= PCG_DIV_MAX; div2++) {
+ int new_error = ((parent_rate / div1) / div2) - rate;
+
+ if (abs(new_error) < abs(error)) {
+ *prediv = div1;
+ *postdiv = div2;
+ error = new_error;
+ ret = 0;
+ }
+ }
+ }
+ return ret;
+}
+
+static long imx8m_clk_composite_divider_round_rate(struct clk_hw *hw,
+ unsigned long rate,
+ unsigned long *prate)
+{
+ int prediv_value;
+ int div_value;
+
+ imx8m_clk_composite_compute_dividers(rate, *prate,
+ &prediv_value, &div_value);
+ rate = DIV_ROUND_UP(*prate, prediv_value);
+
+ return DIV_ROUND_UP(rate, div_value);
+
+}
+
+static int imx8m_clk_composite_divider_set_rate(struct clk_hw *hw,
+ unsigned long rate,
+ unsigned long parent_rate)
+{
+ struct clk_divider *divider = to_clk_divider(hw);
+ unsigned long flags = 0;
+ int prediv_value;
+ int div_value;
+ int ret = 0;
+ u32 val;
+
+ ret = imx8m_clk_composite_compute_dividers(rate, parent_rate,
+ &prediv_value, &div_value);
+ if (ret)
+ return -EINVAL;
+
+ spin_lock_irqsave(divider->lock, flags);
+
+ val = readl(divider->reg);
+ val &= ~((clk_div_mask(divider->width) << divider->shift) |
+ (clk_div_mask(PCG_DIV_WIDTH) << PCG_DIV_SHIFT));
+
+ val |= (u32)(prediv_value - 1) << divider->shift;
+ val |= (u32)(div_value - 1) << PCG_DIV_SHIFT;
+ writel(val, divider->reg);
+
+ spin_unlock_irqrestore(divider->lock, flags);
+
+ return ret;
+}
+
+static const struct clk_ops imx8m_clk_comp
Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
On Wed, Nov 28, 2018 at 10:05:54PM -0800, Andy Lutomirski wrote:
> >> +static void static_call_bp_handler(struct pt_regs *regs, void *_data)
> >> +{
> >> +struct static_call_bp_data *data = _data;
> >> +
> >> +/*
> >> + * For inline static calls, push the return address on the stack so
> >> the
> >> + * "called" function will return to the location immediately after the
> >> + * call site.
> >> + *
> >> + * NOTE: This code will need to be revisited when kernel CET gets
> >> + * implemented.
> >> + */
> >> +if (data->ret) {
> >> +regs->sp -= sizeof(long);
> >> +*(unsigned long *)regs->sp = data->ret;
> >> +}
>
> You can’t do this. Depending on the alignment of the old RSP, which
> is not guaranteed, this overwrites regs->cs. IRET goes boom.
I don't get it; can you spell that out?
The way I understand it is that we're at a location where a "E8 - Near
CALL" instruction should be, and thus RSP should be the regular kernel
stack, and the above simply does "PUSH ret", which is what that CALL
would've done too.
Re: [RFC/RFT][PATCH v6] cpuidle: New timer events oriented governor for tickless systems
Hi Doug, On Thu, Nov 29, 2018 at 12:20 AM Doug Smythies wrote: > > On 2018.11.23 02:36 Rafael J. Wysocki wrote: > > v5 -> v6: > * Avoid applying poll_time_limit to non-polling idle states by mistake. > * Use idle duration measured by the governor for everything (as it likely is >more accurate than the one measured by the core). > > -- above missing-- (see follow up e-mail from Rafael) > > * Rename SPIKE to PULSE. > * Do not run pattern detection upfront. Instead, use recent idle duration >values to refine the state selection after finding a candidate idle state. > * Do not use the expected idle duration as an extra latency constraint >(exit latency is less than the target residency for all of the idle states >known to me anyway, so this doesn't change anything in practice). > > Hi Rafael, > > I did some minimal testing on teov6, using kernel 4.20-rc3 as my baseline > reference kernel. > > Test 1: Phoronix bdench test, all options: 1, 6, 12, 48, 128, 256 clients. > > Note: because it uses the disk, the dbench test is somewhat non-repeatable. > However, if particular attention is paid to not doing anything else with > the disk between tests, then it seems to be repeatable to within about 6%. > > Anyway no significant difference observed between kernel 4.20-rc3 and the > same with the teov6 patch. > > Test 2: Pipe test, non cross core. (And idle state 0 test, really) > I ran 4 pipe tests, 1 for each of my 4 cores, @2 CPUs per core. > Thus, pretty much only idle state 0 was ever used. > Processor package power was similar for both kernels. > teov6 entered/exited idle state 0 about 60,984 times/second/cpu. > -rc3 entered/exited idle state 0 about 62,806 times/second/cpu. > There was a difference in percentage time spent in idle state 0, > with kernel 4.20-rc3 spending 0.2441% in idle state 0 verses > teov6 at 0.0641%. > > For throughput, teov6 was 1.4% faster. > > Test 3: was an attempt to sweep through a preference for > all idle states. > > 40 threads were launched with nothing to do except sleep > for a variable duration of 1 to 500 uSec, each step was > run for 1 minute. With 1 minute idle before the test and a few > minutes idle after, the total test duration was about 505 minutes. > Recall that when one asks for a short sleep of 1 uSec, they actually > get about 50 uSec, due to overheads. So I use 40 threads in an attempt > to get the average time between wakeup events per CPU down somewhat. > > The results are here: > http://fast.smythies.com/linux-pm/k420/k420-pn-sweep-teo6-2.htm > > I might try to get some histogram information at a later date. Thank you for the results, much appreciated!
[PATCH v14 05/11] livepatch: Simplify API by removing registration step
The possibility to re-enable a registered patch was useful for immediate patches where the livepatch module had to stay until the system reboot. The improved consistency model allows to achieve the same result by unloading and loading the livepatch module again. Also we are going to add a feature called atomic replace. It will allow to create a patch that would replace all already registered patches. The aim is to handle dependent patches more securely. It will obsolete the stack of patches that helped to handle the dependencies so far. Then it might be unclear when a cumulative patch re-enabling is safe. It would be complicated to support the many modes. Instead we could actually make the API and code easier to understand. This patch removes the two step public API. All the checks and init calls are moved from klp_register_patch() to klp_enabled_patch(). Also the patch is automatically freed, including the sysfs interface when the transition to the disabled state is completed. As a result, there is never a disabled patch on the top of the stack. Therefore we do not need to check the stack in __klp_enable_patch(). And we could simplify the check in __klp_disable_patch(). Also the API and logic is much easier. It is enough to call klp_enable_patch() in module_init() call. The patch patch can be disabled by writing '0' into /sys/kernel/livepatch//enabled. Then the module can be removed once the transition finishes and sysfs interface is freed. The only problem is how to free the structures and kobjects a safe way. The operation is triggered from the sysfs interface. We could not put the related kobject from there because it would cause lock inversion between klp_mutex and kernfs locks, see kn->count lockdep map. This patch solved the problem by offloading the free task to a workqueue. It is perfectly fine: + The patch cannot not longer be used in the livepatch operations. + The module could not be removed until the free operation finishes and module_put() is called. + The operation is asynchronous already when the first klp_try_complete_transition() fails and another call is queued with a delay. Suggested-by: Josh Poimboeuf Signed-off-by: Petr Mladek --- Documentation/livepatch/livepatch.txt| 137 ++--- include/linux/livepatch.h| 5 +- kernel/livepatch/core.c | 275 +-- kernel/livepatch/core.h | 2 + kernel/livepatch/transition.c| 19 +- samples/livepatch/livepatch-callbacks-demo.c | 13 +- samples/livepatch/livepatch-sample.c | 13 +- samples/livepatch/livepatch-shadow-fix1.c| 14 +- samples/livepatch/livepatch-shadow-fix2.c| 14 +- 9 files changed, 166 insertions(+), 326 deletions(-) diff --git a/Documentation/livepatch/livepatch.txt b/Documentation/livepatch/livepatch.txt index 2d7ed09dbd59..d849af312576 100644 --- a/Documentation/livepatch/livepatch.txt +++ b/Documentation/livepatch/livepatch.txt @@ -12,12 +12,11 @@ Table of Contents: 4. Livepatch module 4.1. New functions 4.2. Metadata - 4.3. Livepatch module handling 5. Livepatch life-cycle - 5.1. Registration + 5.1. Loading 5.2. Enabling 5.3. Disabling - 5.4. Unregistration + 5.4. Removing 6. Sysfs 7. Limitations @@ -298,117 +297,91 @@ into three levels: see the "Consistency model" section. -4.3. Livepatch module handling --- - -The usual behavior is that the new functions will get used when -the livepatch module is loaded. For this, the module init() function -has to register the patch (struct klp_patch) and enable it. See the -section "Livepatch life-cycle" below for more details about these -two operations. - -Module removal is only safe when there are no users of the underlying -functions. This is the reason why the force feature permanently disables -the removal. The forced tasks entered the functions but we cannot say -that they returned back. Therefore it cannot be decided when the -livepatch module can be safely removed. When the system is successfully -transitioned to a new patch state (patched/unpatched) without being -forced it is guaranteed that no task sleeps or runs in the old code. - - 5. Livepatch life-cycle === -Livepatching defines four basic operations that define the life cycle of each -live patch: registration, enabling, disabling and unregistration. There are -several reasons why it is done this way. - -First, the patch is applied only when all patched symbols for already -loaded objects are found. The error handling is much easier if this -check is done before particular functions get redirected. +Livepatching can be described by four basic operations: +loading, enabling, disabling, removing. -Second, it might take some time until the entire system is migrated with -the hybrid consistency model being used. The patch revert might block -the livepatch module rem
[PATCH v14 11/11] selftests/livepatch: introduce tests
From: Joe Lawrence Add a few livepatch modules and simple target modules that the included regression suite can run tests against: - basic livepatching (multiple patches, atomic replace) - pre/post (un)patch callbacks - shadow variable API Signed-off-by: Joe Lawrence Signed-off-by: Petr Mladek --- Documentation/livepatch/callbacks.txt | 489 + MAINTAINERS| 1 + lib/Kconfig.debug | 21 + lib/Makefile | 2 + lib/livepatch/Makefile | 15 + lib/livepatch/test_klp_atomic_replace.c| 57 ++ lib/livepatch/test_klp_callbacks_busy.c| 43 ++ lib/livepatch/test_klp_callbacks_demo.c| 121 + lib/livepatch/test_klp_callbacks_demo2.c | 93 lib/livepatch/test_klp_callbacks_mod.c | 24 + lib/livepatch/test_klp_livepatch.c | 51 ++ lib/livepatch/test_klp_shadow_vars.c | 236 + tools/testing/selftests/Makefile | 1 + tools/testing/selftests/livepatch/Makefile | 8 + tools/testing/selftests/livepatch/README | 43 ++ tools/testing/selftests/livepatch/config | 1 + tools/testing/selftests/livepatch/functions.sh | 203 +++ .../testing/selftests/livepatch/test-callbacks.sh | 587 + .../testing/selftests/livepatch/test-livepatch.sh | 168 ++ .../selftests/livepatch/test-shadow-vars.sh| 60 +++ 20 files changed, 1740 insertions(+), 484 deletions(-) create mode 100644 lib/livepatch/Makefile create mode 100644 lib/livepatch/test_klp_atomic_replace.c create mode 100644 lib/livepatch/test_klp_callbacks_busy.c create mode 100644 lib/livepatch/test_klp_callbacks_demo.c create mode 100644 lib/livepatch/test_klp_callbacks_demo2.c create mode 100644 lib/livepatch/test_klp_callbacks_mod.c create mode 100644 lib/livepatch/test_klp_livepatch.c create mode 100644 lib/livepatch/test_klp_shadow_vars.c create mode 100644 tools/testing/selftests/livepatch/Makefile create mode 100644 tools/testing/selftests/livepatch/README create mode 100644 tools/testing/selftests/livepatch/config create mode 100644 tools/testing/selftests/livepatch/functions.sh create mode 100755 tools/testing/selftests/livepatch/test-callbacks.sh create mode 100755 tools/testing/selftests/livepatch/test-livepatch.sh create mode 100755 tools/testing/selftests/livepatch/test-shadow-vars.sh diff --git a/Documentation/livepatch/callbacks.txt b/Documentation/livepatch/callbacks.txt index c9776f48e458..182e31d4abce 100644 --- a/Documentation/livepatch/callbacks.txt +++ b/Documentation/livepatch/callbacks.txt @@ -118,488 +118,9 @@ similar change to their hw_features value. (Client functions of the value may need to be updated accordingly.) -Test cases -== - -What follows is not an exhaustive test suite of every possible livepatch -pre/post-(un)patch combination, but a selection that demonstrates a few -important concepts. Each test case uses the kernel modules located in -the samples/livepatch/ and assumes that no livepatches are loaded at the -beginning of the test. - - -Test 1 --- - -Test a combination of loading a kernel module and a livepatch that -patches a function in the first module. (Un)load the target module -before the livepatch module: - -- load target module -- load livepatch -- disable livepatch -- unload target module -- unload livepatch - -First load a target module: - - % insmod samples/livepatch/livepatch-callbacks-mod.ko - [ 34.475708] livepatch_callbacks_mod: livepatch_callbacks_mod_init - -On livepatch enable, before the livepatch transition starts, pre-patch -callbacks are executed for vmlinux and livepatch_callbacks_mod (those -klp_objects currently loaded). After klp_objects are patched according -to the klp_patch, their post-patch callbacks run and the transition -completes: - - % insmod samples/livepatch/livepatch-callbacks-demo.ko - [ 36.503719] livepatch: enabling patch 'livepatch_callbacks_demo' - [ 36.504213] livepatch: 'livepatch_callbacks_demo': initializing patching transition - [ 36.504238] livepatch_callbacks_demo: pre_patch_callback: vmlinux - [ 36.504721] livepatch_callbacks_demo: pre_patch_callback: livepatch_callbacks_mod -> [MODULE_STATE_LIVE] Normal state - [ 36.505849] livepatch: 'livepatch_callbacks_demo': starting patching transition - [ 37.727133] livepatch: 'livepatch_callbacks_demo': completing patching transition - [ 37.727232] livepatch_callbacks_demo: post_patch_callback: vmlinux - [ 37.727860] livepatch_callbacks_demo: post_patch_callback: livepatch_callbacks_mod -> [MODULE_STATE_LIVE] Normal state - [ 37.728792] livepatch: 'livepatch_callbacks_demo': patching complete - -Similarly, on livepatch disable, pre-patch callbacks run before the -unpatching transition starts. klp_ob
[PATCH v14 09/11] livepatch: Atomic replace and cumulative patches documentation
User documentation for the atomic replace feature. It makes it easier
to maintain livepatches using so-called cumulative patches.
Signed-off-by: Petr Mladek
---
Documentation/livepatch/cumulative-patches.txt | 105 +
1 file changed, 105 insertions(+)
create mode 100644 Documentation/livepatch/cumulative-patches.txt
diff --git a/Documentation/livepatch/cumulative-patches.txt
b/Documentation/livepatch/cumulative-patches.txt
new file mode 100644
index ..a8089f7fe306
--- /dev/null
+++ b/Documentation/livepatch/cumulative-patches.txt
@@ -0,0 +1,105 @@
+===
+Atomic Replace & Cumulative Patches
+===
+
+There might be dependencies between livepatches. If multiple patches need
+to do different changes to the same function(s) then we need to define
+an order in which the patches will be installed. And function implementations
+from any newer livepatch must be done on top of the older ones.
+
+This might become a maintenance nightmare. Especially if anyone would want
+to remove a patch that is in the middle of the stack.
+
+An elegant solution comes with the feature called "Atomic Replace". It allows
+to create so called "Cumulative Patches". They include all wanted changes
+from all older livepatches and completely replace them in one transition.
+
+Usage
+-
+
+The atomic replace can be enabled by setting "replace" flag in struct
klp_patch,
+for example:
+
+ static struct klp_patch patch = {
+ .mod = THIS_MODULE,
+ .objs = objs,
+ .replace = true,
+ };
+
+Such a patch is added on top of the livepatch stack when enabled.
+
+All processes are then migrated to use the code only from the new patch.
+Once the transition is finished, all older patches are automatically
+disabled and removed from the stack of patches.
+
+Ftrace handlers are transparently removed from functions that are no
+longer modified by the new cumulative patch.
+
+As a result, the livepatch authors might maintain sources only for one
+cumulative patch. It helps to keep the patch consistent while adding or
+removing various fixes or features.
+
+Users could keep only the last patch installed on the system after
+the transition to has finished. It helps to clearly see what code is
+actually in use. Also the livepatch might then be seen as a "normal"
+module that modifies the kernel behavior. The only difference is that
+it can be updated at runtime without breaking its functionality.
+
+
+Features
+
+
+The atomic replace allows:
+
+ + Atomically revert some functions in a previous patch while
+upgrading other functions.
+
+ + Remove eventual performance impact caused by core redirection
+for functions that are no longer patched.
+
+ + Decrease user confusion about stacking order and what code
+is actually in use.
+
+
+Limitations:
+
+
+ + Once the operation finishes, there is no straightforward way
+to reverse it and restore the replaced patches atomically.
+
+A good practice is to set .replace flag in any released livepatch.
+Then re-adding an older livepatch is equivalent to downgrading
+to that patch. This is safe as long as the livepatches do _not_ do
+extra modifications in (un)patching callbacks or in the module_init()
+or module_exit() functions, see below.
+
+Also note that the replaced patch can be removed and loaded again
+only when the transition was not forced.
+
+
+ + Only the (un)patching callbacks from the _new_ cumulative livepatch are
+executed. Any callbacks from the replaced patches are ignored.
+
+In other words, the cumulative patch is responsible for doing any actions
+that are necessary to properly replace any older patch.
+
+As a result, it might be dangerous to replace newer cumulative patches by
+older ones. The old livepatches might not provide the necessary callbacks.
+
+This might be seen as a limitation in some scenarios. But it makes the life
+easier in many others. Only the new cumulative livepatch knows what
+fixes/features are added/removed and what special actions are necessary
+for a smooth transition.
+
+In any case, it would be a nightmare to think about the order of
+the various callbacks and their interactions if the callbacks from all
+enabled patches were called.
+
+
+ + There is no special handling of shadow variables. Livepatch authors
+must create their own rules how to pass them from one cumulative
+patch to the other. Especially they should not blindly remove them
+in module_exit() functions.
+
+A good practice might be to remove shadow variables in the post-unpatch
+callback. It is called only when the livepatch is properly disabled.
--
2.13.7
[PATCH v14 08/11] livepatch: Remove Nop structures when unused
Replaced patches are removed from the stack when the transition is
finished. It means that Nop structures will never be needed again
and can be removed. Why should we care?
+ Nop structures make false feeling that the function is patched
even though the ftrace handler has no effect.
+ Ftrace handlers are not completely for free. They cause slowdown that
might be visible in some workloads. The ftrace-related slowdown might
actually be the reason why the function is not longer patched in
the new cumulative patch. One would expect that cumulative patch
would allow to solve these problems as well.
+ Cumulative patches are supposed to replace any earlier version of
the patch. The amount of NOPs depends on which version was replaced.
This multiplies the amount of scenarios that might happen.
One might say that NOPs are innocent. But there are even optimized
NOP instructions for different processor, for example, see
arch/x86/kernel/alternative.c. And klp_ftrace_handler() is much
more complicated.
+ It sounds natural to clean up a mess that is not longer needed.
It could only be worse if we do not do it.
This patch allows to unpatch and free the dynamic structures independently
when the transition finishes.
The free part is a bit tricky because kobject free callbacks are called
asynchronously. We could not wait for them easily. Fortunately, we do
not have to. Any further access can be avoided by removing them from
the dynamic lists.
Signed-off-by: Petr Mladek
---
include/linux/livepatch.h | 6
kernel/livepatch/core.c | 64 ++-
kernel/livepatch/core.h | 1 +
kernel/livepatch/patch.c | 31 +
kernel/livepatch/patch.h | 1 +
kernel/livepatch/transition.c | 4 ++-
6 files changed, 94 insertions(+), 13 deletions(-)
diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h
index a44bc730cc47..ad29f17e1f55 100644
--- a/include/linux/livepatch.h
+++ b/include/linux/livepatch.h
@@ -180,6 +180,9 @@ struct klp_patch {
#define klp_for_each_object_static(patch, obj) \
for (obj = patch->objs; obj->funcs || obj->name; obj++)
+#define klp_for_each_object_safe(patch, obj, tmp_obj) \
+ list_for_each_entry_safe(obj, tmp_obj, &patch->obj_list, node)
+
#define klp_for_each_object(patch, obj)\
list_for_each_entry(obj, &patch->obj_list, node)
@@ -188,6 +191,9 @@ struct klp_patch {
func->old_name || func->new_func || func->old_sympos; \
func++)
+#define klp_for_each_func_safe(obj, func, tmp_func)\
+ list_for_each_entry_safe(func, tmp_func, &obj->func_list, node)
+
#define klp_for_each_func(obj, func) \
list_for_each_entry(func, &obj->func_list, node)
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index 7092d288cfa6..0ce752e9e8bb 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -611,11 +611,20 @@ static struct kobj_type klp_ktype_func = {
.sysfs_ops = &kobj_sysfs_ops,
};
-static void klp_free_funcs(struct klp_object *obj)
+static void __klp_free_funcs(struct klp_object *obj, bool free_all)
{
- struct klp_func *func;
+ struct klp_func *func, *tmp_func;
+
+ klp_for_each_func_safe(obj, func, tmp_func) {
+ if (!free_all && !func->nop)
+ continue;
+
+ /*
+* Avoid double free. It would be tricky to wait for kobject
+* callbacks when only NOPs are handled.
+*/
+ list_del(&func->node);
- klp_for_each_func(obj, func) {
/* Might be called from klp_init_patch() error path. */
if (func->kobj_alive) {
func->kobj_alive = false;
@@ -641,12 +650,21 @@ static void klp_free_object_loaded(struct klp_object *obj)
}
}
-static void klp_free_objects(struct klp_patch *patch)
+static void __klp_free_objects(struct klp_patch *patch, bool free_all)
{
- struct klp_object *obj;
+ struct klp_object *obj, *tmp_obj;
- klp_for_each_object(patch, obj) {
- klp_free_funcs(obj);
+ klp_for_each_object_safe(patch, obj, tmp_obj) {
+ __klp_free_funcs(obj, free_all);
+
+ if (!free_all && !obj->dynamic)
+ continue;
+
+ /*
+* Avoid double free. It would be tricky to wait for kobject
+* callbacks when only dynamic objects are handled.
+*/
+ list_del(&obj->node);
/* Might be called from klp_init_patch() error path. */
if (obj->kobj_alive) {
@@ -658,6 +676,16 @@ static void klp_free_objects(struct klp_patch *patch)
}
}
+static void klp_free_objects(struct klp_patch *patch)
+{
+ __klp_free_objects(patch, true);
+}
+
+static void klp_free_objects_
[PATCH v14 04/11] livepatch: Refuse to unload only livepatches available during a forced transition
module_put() is currently never called in klp_complete_transition() when
klp_force is set. As a result, we might keep the reference count even when
klp_enable_patch() fails and klp_cancel_transition() is called.
This might make an assumption that a module might get blocked in some
strange init state. Fortunately, it is not the case. The reference count
is ignored when mod->init fails and erroneous modules are always removed.
Anyway, this might make some confusion. Instead, this patch moves
the global klp_forced flag into struct klp_patch. As a result,
we block only modules that might still be in use after a forced
transition. Newly loaded livepatches might be eventually completely
removed later.
It is not a big deal. But the code is at least consistent with
the reality.
Signed-off-by: Petr Mladek
---
include/linux/livepatch.h | 2 ++
kernel/livepatch/core.c | 4 +++-
kernel/livepatch/core.h | 1 +
kernel/livepatch/transition.c | 11 ++-
4 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h
index 6646bc4730bc..b71892693da5 100644
--- a/include/linux/livepatch.h
+++ b/include/linux/livepatch.h
@@ -143,6 +143,7 @@ struct klp_object {
* @kobj: kobject for sysfs resources
* @kobj_alive: @kobj has been added and needs freeing
* @enabled: the patch is enabled (but operation may be incomplete)
+ * @forced:was involved in a forced transition
* @finish:for waiting till it is safe to remove the patch module
*/
struct klp_patch {
@@ -155,6 +156,7 @@ struct klp_patch {
struct kobject kobj;
bool kobj_alive;
bool enabled;
+ bool forced;
struct completion finish;
};
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index 6c255dbcc517..972520144713 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -45,7 +45,8 @@
*/
DEFINE_MUTEX(klp_mutex);
-static LIST_HEAD(klp_patches);
+/* Registered patches */
+LIST_HEAD(klp_patches);
static struct kobject *klp_root_kobj;
@@ -665,6 +666,7 @@ static int klp_init_patch_before_free(struct klp_patch
*patch)
INIT_LIST_HEAD(&patch->list);
patch->kobj_alive = false;
patch->enabled = false;
+ patch->forced = false;
init_completion(&patch->finish);
klp_for_each_object(patch, obj) {
diff --git a/kernel/livepatch/core.h b/kernel/livepatch/core.h
index 48a83d4364cf..d0cb5390e247 100644
--- a/kernel/livepatch/core.h
+++ b/kernel/livepatch/core.h
@@ -5,6 +5,7 @@
#include
extern struct mutex klp_mutex;
+extern struct list_head klp_patches;
static inline bool klp_is_object_loaded(struct klp_object *obj)
{
diff --git a/kernel/livepatch/transition.c b/kernel/livepatch/transition.c
index 512913c1452d..e1aed2e18e70 100644
--- a/kernel/livepatch/transition.c
+++ b/kernel/livepatch/transition.c
@@ -33,8 +33,6 @@ struct klp_patch *klp_transition_patch;
static int klp_target_state = KLP_UNDEFINED;
-static bool klp_forced = false;
-
/*
* This work can be performed periodically to finish patching or unpatching any
* "straggler" tasks which failed to transition in the first attempt.
@@ -137,10 +135,10 @@ static void klp_complete_transition(void)
klp_target_state == KLP_PATCHED ? "patching" : "unpatching");
/*
-* klp_forced set implies unbounded increase of module's ref count if
+* patch->forced set implies unbounded increase of module's ref count if
* the module is disabled/enabled in a loop.
*/
- if (!klp_forced && klp_target_state == KLP_UNPATCHED)
+ if (!klp_transition_patch->forced && klp_target_state == KLP_UNPATCHED)
module_put(klp_transition_patch->mod);
klp_target_state = KLP_UNDEFINED;
@@ -620,6 +618,7 @@ void klp_send_signals(void)
*/
void klp_force_transition(void)
{
+ struct klp_patch *patch;
struct task_struct *g, *task;
unsigned int cpu;
@@ -633,5 +632,7 @@ void klp_force_transition(void)
for_each_possible_cpu(cpu)
klp_update_patch_state(idle_task(cpu));
- klp_forced = true;
+ /* Refuse unloading all livepatches. The code might be in use. */
+ list_for_each_entry(patch, &klp_patches, list)
+ patch->forced = true;
}
--
2.13.7
[PATCH v14 10/11] livepatch: Remove ordering and refuse loading conflicting patches
The atomic replace and cumulative patches were introduced as a more secure way to handle dependent patches. They simplify the logic: + Any new cumulative patch is supposed to take over shadow variables and changes made by callbacks from previous livepatches. + All replaced patches are discarded and the modules can be unloaded. As a result, there is only one scenario when a cumulative livepatch gets disabled. The different handling of "normal" and cumulative patches might cause confusion. It would make sense to keep only one mode. On the other hand, it would be rude to enforce using the cumulative livepatches even for trivial and independent (hot) fixes. This patch removes the stack of patches. The list of enabled patches is still needed but the ordering is not longer enforced. Note that it is not possible to catch all possible dependencies. It is the responsibility of the livepatch authors to decide. Nevertheless this patch prevents having two patches for the same function enabled at the same time after the transition finishes. It might help to catch obvious mistakes. But more importantly, we do not need to handle situation when a patch in the middle of the function stack (ops->func_stack) is being removed. Signed-off-by: Petr Mladek --- Documentation/livepatch/cumulative-patches.txt | 11 ++ Documentation/livepatch/livepatch.txt | 30 --- kernel/livepatch/core.c| 51 -- 3 files changed, 68 insertions(+), 24 deletions(-) diff --git a/Documentation/livepatch/cumulative-patches.txt b/Documentation/livepatch/cumulative-patches.txt index a8089f7fe306..ca1fbb4351c8 100644 --- a/Documentation/livepatch/cumulative-patches.txt +++ b/Documentation/livepatch/cumulative-patches.txt @@ -7,8 +7,8 @@ to do different changes to the same function(s) then we need to define an order in which the patches will be installed. And function implementations from any newer livepatch must be done on top of the older ones. -This might become a maintenance nightmare. Especially if anyone would want -to remove a patch that is in the middle of the stack. +This might become a maintenance nightmare. Especially when more patches +modified the same function in different ways. An elegant solution comes with the feature called "Atomic Replace". It allows to create so called "Cumulative Patches". They include all wanted changes @@ -26,11 +26,9 @@ for example: .replace = true, }; -Such a patch is added on top of the livepatch stack when enabled. - All processes are then migrated to use the code only from the new patch. Once the transition is finished, all older patches are automatically -disabled and removed from the stack of patches. +disabled. Ftrace handlers are transparently removed from functions that are no longer modified by the new cumulative patch. @@ -57,8 +55,7 @@ The atomic replace allows: + Remove eventual performance impact caused by core redirection for functions that are no longer patched. - + Decrease user confusion about stacking order and what code -is actually in use. + + Decrease user confusion about dependencies between livepatches. Limitations: diff --git a/Documentation/livepatch/livepatch.txt b/Documentation/livepatch/livepatch.txt index ba6e83a08209..3c150ab19b99 100644 --- a/Documentation/livepatch/livepatch.txt +++ b/Documentation/livepatch/livepatch.txt @@ -143,9 +143,9 @@ without HAVE_RELIABLE_STACKTRACE are not considered fully supported by the kernel livepatching. The /sys/kernel/livepatch//transition file shows whether a patch -is in transition. Only a single patch (the topmost patch on the stack) -can be in transition at a given time. A patch can remain in transition -indefinitely, if any of the tasks are stuck in the initial patch state. +is in transition. Only a single patch can be in transition at a given +time. A patch can remain in transition indefinitely, if any of the tasks +are stuck in the initial patch state. A transition can be reversed and effectively canceled by writing the opposite value to the /sys/kernel/livepatch//enabled file while @@ -329,9 +329,10 @@ The livepatch gets enabled by calling klp_enable_patch() typically from module_init() callback. The system will start using the new implementation of the patched functions at this stage. -First, the addresses of the patched functions are found according to their -names. The special relocations, mentioned in the section "New functions", -are applied. The relevant entries are created under +First, possible conflicts are checked for non-cummulative patches with +disabled replace flag. The addresses of the patched functions are found +according to their names. The special relocations, mentioned in the section +"New functions", are applied. The relevant entries are created under /sys/kernel/livepatch/. The patch is rejected when any above operation fails. @@ -345,11 +3
Re: [PATCH V3 1/3] mmc: sdhci: add support for using external DMA devices
On Thu, 29 Nov 2018 at 17:25, Adrian Hunter wrote:
>
> On 29/11/18 8:07 AM, Chunyan Zhang wrote:
> > Some standard SD host controllers can support both external dma
> > controllers as well as ADMA/SDMA in which the SD host controller
> > acts as DMA master. TI's omap controller is the case as an example.
> >
> > Currently the generic SDHCI code supports ADMA/SDMA integrated in
> > the host controller but does not have any support for external DMA
> > controllers implemented using dmaengine, meaning that custom code is
> > needed for any systems that use an external DMA controller with SDHCI.
> >
> > Signed-off-by: Chunyan Zhang
> > ---
> > drivers/mmc/host/Kconfig | 14
> > drivers/mmc/host/sdhci.c | 185
> > ++-
> > drivers/mmc/host/sdhci.h | 8 ++
> > 3 files changed, 206 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> > index 1b58739..4183f43 100644
> > --- a/drivers/mmc/host/Kconfig
> > +++ b/drivers/mmc/host/Kconfig
> > @@ -969,6 +969,7 @@ config MMC_SDHCI_XENON
> > config MMC_SDHCI_OMAP
> > tristate "TI SDHCI Controller Support"
> > depends on MMC_SDHCI_PLTFM && OF
> > + select MMC_SDHCI_EXTERNAL_DMA if DMA_ENGINE
> > help
> > This selects the Secure Digital Host Controller Interface (SDHCI)
> > support present in TI's DRA7 SOCs. The controller supports
> > @@ -977,3 +978,16 @@ config MMC_SDHCI_OMAP
> > If you have a controller with this interface, say Y or M here.
> >
> > If unsure, say N.
> > +
> > +config MMC_SDHCI_EXTERNAL_DMA
> > +bool "Support external DMA in standard SD host controller"
> > + depends on MMC_SDHCI
> > + depends on DMA_ENGINE
> > + help
> > + This is an option for using external DMA device via dmaengine
> > + framework.
> > +
> > + If you have a controller which support using external DMA device
> > + for data transfer, can say Y.
> > +
> > + If unsure, say N.
>
> So if you are going to select this, then you don't need the prompt or help
> anymore i.e.
>
> config MMC_SDHCI_EXTERNAL_DMA
> bool
>
>
> > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> > index 99bdae5..ad7cc80 100644
> > --- a/drivers/mmc/host/sdhci.c
> > +++ b/drivers/mmc/host/sdhci.c
> > @@ -14,6 +14,7 @@
> > */
> >
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -1309,6 +1310,162 @@ static void sdhci_del_timer(struct sdhci_host
> > *host, struct mmc_request *mrq)
> > del_timer(&host->timer);
> > }
> >
> > +#if IS_ENABLED(CONFIG_MMC_SDHCI_EXTERNAL_DMA)
> > +static int sdhci_external_dma_init(struct sdhci_host *host)
> > +{
> > + int ret = 0;
> > + struct mmc_host *mmc = host->mmc;
> > +
> > + host->tx_chan = dma_request_chan(mmc->parent, "tx");
> > + if (IS_ERR(host->tx_chan)) {
> > + ret = PTR_ERR(host->tx_chan);
> > + if (ret != -EPROBE_DEFER)
> > + pr_warn("Failed to request TX DMA channel.\n");
> > + host->tx_chan = NULL;
> > + return ret;
> > + }
> > +
> > + host->rx_chan = dma_request_chan(mmc->parent, "rx");
> > + if (IS_ERR(host->rx_chan)) {
> > + if (host->tx_chan) {
> > + dma_release_channel(host->tx_chan);
> > + host->tx_chan = NULL;
> > + }
> > +
> > + ret = PTR_ERR(host->rx_chan);
> > + if (ret != -EPROBE_DEFER)
> > + pr_warn("Failed to request RX DMA channel.\n");
> > + host->rx_chan = NULL;
> > + }
> > +
> > + return ret;
> > +}
> > +
> > +static inline struct dma_chan *
> > +sdhci_external_dma_channel(struct sdhci_host *host, struct mmc_data *data)
> > +{
> > + return data->flags & MMC_DATA_WRITE ? host->tx_chan : host->rx_chan;
> > +}
> > +
> > +static int sdhci_external_dma_setup(struct sdhci_host *host,
> > + struct mmc_command *cmd)
> > +{
> > + int ret, i;
> > + struct dma_async_tx_descriptor *desc;
> > + struct mmc_data *data = cmd->data;
> > + struct dma_chan *chan;
> > + struct dma_slave_config cfg;
> > + dma_cookie_t cookie;
> > +
> > + if (!host->mapbase)
> > + return -EINVAL;
> > +
> > + if (!data)
> > + return 0;
>
> It would read better if the above 2 if-statements were the other way around
> i.e.
>
> if (!data)
> return 0;
>
> if (!host->mapbase)
> return -EINVAL;
>
Ok.
> > +
> > + cfg.src_addr = host->mapbase + SDHCI_BUFFER;
> > + cfg.dst_addr = host->mapbase + SDHCI_BUFFER;
> > + cfg.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
> > + cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
> > + cfg.src_maxburst = data->blksz / 4;
> > + cfg.dst_maxburst = data->blksz / 4;
> > +
> > + /* Sanity check: all the SG en
[PATCH v14 03/11] livepatch: Consolidate klp_free functions
The code for freeing livepatch structures is a bit scattered and tricky:
+ direct calls to klp_free_*_limited() and kobject_put() are
used to release partially initialized objects
+ klp_free_patch() removes the patch from the public list
and releases all objects except for patch->kobj
+ object_put(&patch->kobj) and the related wait_for_completion()
are called directly outside klp_mutex; this code is duplicated;
Now, we are going to remove the registration stage to simplify the API
and the code. This would require handling more situations in
klp_enable_patch() error paths.
More importantly, we are going to add a feature called atomic replace.
It will need to dynamically create func and object structures. We will
want to reuse the existing init() and free() functions. This would
create even more error path scenarios.
This patch implements a more clever free functions:
+ checks kobj_alive flag instead of @limit[*]
+ initializes patch->list early so that the check for empty list
always works
+ The action(s) that has to be done outside klp_mutex are done
in separate klp_free_patch_finish() function. It waits only
when patch->kobj was really released via the _start() part.
The patch does not change the existing behavior.
[*] We need our own flag. Note that kobject_put() cannot be called safely
when kobj.state_initialized is set. This flag is true when kobject_add()
part failed. And it is never cleared.
Signed-off-by: Petr Mladek
Cc: Josh Poimboeuf
Cc: Miroslav Benes
Cc: Jessica Yu
Cc: Jiri Kosina
Cc: Jason Baron
---
include/linux/livepatch.h | 6 ++
kernel/livepatch/core.c | 145 +++---
2 files changed, 104 insertions(+), 47 deletions(-)
diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h
index 634e13876380..6646bc4730bc 100644
--- a/include/linux/livepatch.h
+++ b/include/linux/livepatch.h
@@ -45,6 +45,7 @@
* @stack_node:list node for klp_ops func_stack list
* @old_size: size of the old function
* @new_size: size of the new function
+ * @kobj_alive: @kobj has been added and needs freeing
* @patched: the func has been added to the klp_ops list
* @transition:the func is currently being applied or reverted
*
@@ -81,6 +82,7 @@ struct klp_func {
struct kobject kobj;
struct list_head stack_node;
unsigned long old_size, new_size;
+ bool kobj_alive;
bool patched;
bool transition;
};
@@ -117,6 +119,7 @@ struct klp_callbacks {
* @kobj: kobject for sysfs resources
* @mod: kernel module associated with the patched object
* (NULL for vmlinux)
+ * @kobj_alive: @kobj has been added and needs freeing
* @patched: the object's funcs have been added to the klp_ops list
*/
struct klp_object {
@@ -128,6 +131,7 @@ struct klp_object {
/* internal */
struct kobject kobj;
struct module *mod;
+ bool kobj_alive;
bool patched;
};
@@ -137,6 +141,7 @@ struct klp_object {
* @objs: object entries for kernel objects to be patched
* @list: list node for global list of registered patches
* @kobj: kobject for sysfs resources
+ * @kobj_alive: @kobj has been added and needs freeing
* @enabled: the patch is enabled (but operation may be incomplete)
* @finish:for waiting till it is safe to remove the patch module
*/
@@ -148,6 +153,7 @@ struct klp_patch {
/* internal */
struct list_head list;
struct kobject kobj;
+ bool kobj_alive;
bool enabled;
struct completion finish;
};
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index 20589da35194..6c255dbcc517 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -465,17 +465,17 @@ static struct kobj_type klp_ktype_func = {
.sysfs_ops = &kobj_sysfs_ops,
};
-/*
- * Free all functions' kobjects in the array up to some limit. When limit is
- * NULL, all kobjects are freed.
- */
-static void klp_free_funcs_limited(struct klp_object *obj,
- struct klp_func *limit)
+static void klp_free_funcs(struct klp_object *obj)
{
struct klp_func *func;
- for (func = obj->funcs; func->old_name && func != limit; func++)
- kobject_put(&func->kobj);
+ klp_for_each_func(obj, func) {
+ /* Might be called from klp_init_patch() error path. */
+ if (func->kobj_alive) {
+ func->kobj_alive = false;
+ kobject_put(&func->kobj);
+ }
+ }
}
/* Clean up when a patched object is unloaded */
@@ -489,30 +489,63 @@ static void klp_free_object_loaded(struct klp_object *obj)
func->old_func = NULL;
}
-/*
- * Free all objects' kobjects in the array up to some limit. When limit is
- * NULL, all kobjects are freed.
- */
-static void klp_free_objects_limited(struct klp_patch *pa
[PATCH v14 07/11] livepatch: Add atomic replace
From: Jason Baron Sometimes we would like to revert a particular fix. Currently, this is not easy because we want to keep all other fixes active and we could revert only the last applied patch. One solution would be to apply new patch that implemented all the reverted functions like in the original code. It would work as expected but there will be unnecessary redirections. In addition, it would also require knowing which functions need to be reverted at build time. Another problem is when there are many patches that touch the same functions. There might be dependencies between patches that are not enforced on the kernel side. Also it might be pretty hard to actually prepare the patch and ensure compatibility with the other patches. Atomic replace && cumulative patches: A better solution would be to create cumulative patch and say that it replaces all older ones. This patch adds a new "replace" flag to struct klp_patch. When it is enabled, a set of 'nop' klp_func will be dynamically created for all functions that are already being patched but that will no longer be modified by the new patch. They are used as a new target during the patch transition. The idea is to handle Nops' structures like the static ones. When the dynamic structures are allocated, we initialize all values that are normally statically defined. The only exception is "new_func" in struct klp_func. It has to point to the original function and the address is known only when the object (module) is loaded. Note that we really need to set it. The address is used, for example, in klp_check_stack_func(). Nevertheless we still need to distinguish the dynamically allocated structures in some operations. For this, we add "nop" flag into struct klp_func and "dynamic" flag into struct klp_object. They need special handling in the following situations: + The structures are added into the lists of objects and functions immediately. In fact, the lists were created for this purpose. + The address of the original function is known only when the patched object (module) is loaded. Therefore it is copied later in klp_init_object_loaded(). + The ftrace handler must not set PC to func->new_func. It would cause infinite loop because the address points back to the beginning of the original function. + The various free() functions must free the structure itself. Note that other ways to detect the dynamic structures are not considered safe. For example, even the statically defined struct klp_object might include empty funcs array. It might be there just to run some callbacks. Special callbacks handling: The callbacks from the replaced patches are _not_ called by intention. It would be pretty hard to define a reasonable semantic and implement it. It might even be counter-productive. The new patch is cumulative. It is supposed to include most of the changes from older patches. In most cases, it will not want to call pre_unpatch() post_unpatch() callbacks from the replaced patches. It would disable/break things for no good reasons. Also it should be easier to handle various scenarios in a single script in the new patch than think about interactions caused by running many scripts from older patches. Not to say that the old scripts even would not expect to be called in this situation. Removing replaced patches: One nice effect of the cumulative patches is that the code from the older patches is no longer used. Therefore the replaced patches can be removed. It has several advantages: + Nops' structs will not longer be necessary and might be removed. This would save memory, restore performance (no ftrace handler), allow clear view on what is really patched. + Disabling the patch will cause using the original code everywhere. Therefore the livepatch callbacks could handle only one scenario. Note that the complication is already complex enough when the patch gets enabled. It is currently solved by calling callbacks only from the new cumulative patch. + The state is clean in both the sysfs interface and lsmod. The modules with the replaced livepatches might even get removed from the system. Some people actually expected this behavior from the beginning. After all a cumulative patch is supposed to "completely" replace an existing one. It is like when a new version of an application replaces an older one. This patch does the first step. It removes the replaced patches from the list of patches. It is safe. The consistency model ensures that they are not longer used. By other words, each process works only with the structures from klp_transition_patch. The removal is done by a special function. It combines actions done by __disable_patch() and klp_complete_transition(). But it is a fast track without all the transaction-related stuff. Signed-off-by: Jason Baron [pmla...@suse.com: Split, reuse existing code, simplified] Signed-off-by: Petr Mladek Cc: Josh Poimboeuf Cc: Jessica Yu Cc: Jiri
[PATCH v14 06/11] livepatch: Use lists to manage patches, objects and functions
From: Jason Baron
Currently klp_patch contains a pointer to a statically allocated array of
struct klp_object and struct klp_objects contains a pointer to a statically
allocated array of klp_func. In order to allow for the dynamic allocation
of objects and functions, link klp_patch, klp_object, and klp_func together
via linked lists. This allows us to more easily allocate new objects and
functions, while having the iterator be a simple linked list walk.
The static structures are added to the lists early. It allows to add
the dynamically allocated objects before klp_init_object() and
klp_init_func() calls. Therefore it reduces the further changes
to the code.
This patch does not change the existing behavior.
Signed-off-by: Jason Baron
[pmla...@suse.com: Initialize lists before init calls]
Signed-off-by: Petr Mladek
Cc: Josh Poimboeuf
Cc: Jessica Yu
Cc: Jiri Kosina
Cc: Miroslav Benes
---
include/linux/livepatch.h | 19 +--
kernel/livepatch/core.c | 9 +++--
2 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h
index 1366dbb159ab..662e4cf664b8 100644
--- a/include/linux/livepatch.h
+++ b/include/linux/livepatch.h
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#if IS_ENABLED(CONFIG_LIVEPATCH)
@@ -42,6 +43,7 @@
* can be found (optional)
* @old_func: pointer to the function being patched
* @kobj: kobject for sysfs resources
+ * @node: list node for klp_object func_list
* @stack_node:list node for klp_ops func_stack list
* @old_size: size of the old function
* @new_size: size of the new function
@@ -80,6 +82,7 @@ struct klp_func {
/* internal */
void *old_func;
struct kobject kobj;
+ struct list_head node;
struct list_head stack_node;
unsigned long old_size, new_size;
bool kobj_alive;
@@ -117,6 +120,8 @@ struct klp_callbacks {
* @funcs: function entries for functions to be patched in the object
* @callbacks: functions to be executed pre/post (un)patching
* @kobj: kobject for sysfs resources
+ * @func_list: dynamic list of the function entries
+ * @node: list node for klp_patch obj_list
* @mod: kernel module associated with the patched object
* (NULL for vmlinux)
* @kobj_alive: @kobj has been added and needs freeing
@@ -130,6 +135,8 @@ struct klp_object {
/* internal */
struct kobject kobj;
+ struct list_head func_list;
+ struct list_head node;
struct module *mod;
bool kobj_alive;
bool patched;
@@ -141,6 +148,7 @@ struct klp_object {
* @objs: object entries for kernel objects to be patched
* @list: list node for global list of registered patches
* @kobj: kobject for sysfs resources
+ * @obj_list: dynamic list of the object entries
* @kobj_alive: @kobj has been added and needs freeing
* @enabled: the patch is enabled (but operation may be incomplete)
* @forced:was involved in a forced transition
@@ -155,6 +163,7 @@ struct klp_patch {
/* internal */
struct list_head list;
struct kobject kobj;
+ struct list_head obj_list;
bool kobj_alive;
bool enabled;
bool forced;
@@ -162,14 +171,20 @@ struct klp_patch {
struct completion finish;
};
-#define klp_for_each_object(patch, obj) \
+#define klp_for_each_object_static(patch, obj) \
for (obj = patch->objs; obj->funcs || obj->name; obj++)
-#define klp_for_each_func(obj, func) \
+#define klp_for_each_object(patch, obj)\
+ list_for_each_entry(obj, &patch->obj_list, node)
+
+#define klp_for_each_func_static(obj, func) \
for (func = obj->funcs; \
func->old_name || func->new_func || func->old_sympos; \
func++)
+#define klp_for_each_func(obj, func) \
+ list_for_each_entry(func, &obj->func_list, node)
+
int klp_enable_patch(struct klp_patch *);
void arch_klp_init_object_loaded(struct klp_patch *patch,
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index e01dfa3b58d2..c48f34272473 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -662,20 +662,25 @@ static int klp_init_patch_before_free(struct klp_patch
*patch)
return -EINVAL;
INIT_LIST_HEAD(&patch->list);
+ INIT_LIST_HEAD(&patch->obj_list);
patch->kobj_alive = false;
patch->enabled = false;
patch->forced = false;
INIT_WORK(&patch->free_work, klp_free_patch_work_fn);
init_completion(&patch->finish);
- klp_for_each_object(patch, obj) {
+ klp_for_each_object_static(patch, obj) {
if (!obj->funcs)
return -EINVAL;
+ INIT_LIST_HEAD(&obj->func_list);
obj->kobj_alive = false;
+ list_add_tail(&obj->node, &patch->obj_list);
- klp_for_each_func(ob
[PATCH v14 02/11] livepatch: Shuffle klp_enable_patch()/klp_disable_patch() code
We are going to simplify the API and code by removing the registration
step. This would require calling init/free functions from enable/disable
ones.
This patch just moves the code to prevent more forward declarations.
This patch does not change the code except of two forward declarations.
Signed-off-by: Petr Mladek
---
kernel/livepatch/core.c | 330
1 file changed, 166 insertions(+), 164 deletions(-)
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index cb59c7fb94cb..20589da35194 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -278,170 +278,6 @@ static int klp_write_object_relocations(struct module
*pmod,
return ret;
}
-static int __klp_disable_patch(struct klp_patch *patch)
-{
- struct klp_object *obj;
-
- if (WARN_ON(!patch->enabled))
- return -EINVAL;
-
- if (klp_transition_patch)
- return -EBUSY;
-
- /* enforce stacking: only the last enabled patch can be disabled */
- if (!list_is_last(&patch->list, &klp_patches) &&
- list_next_entry(patch, list)->enabled)
- return -EBUSY;
-
- klp_init_transition(patch, KLP_UNPATCHED);
-
- klp_for_each_object(patch, obj)
- if (obj->patched)
- klp_pre_unpatch_callback(obj);
-
- /*
-* Enforce the order of the func->transition writes in
-* klp_init_transition() and the TIF_PATCH_PENDING writes in
-* klp_start_transition(). In the rare case where klp_ftrace_handler()
-* is called shortly after klp_update_patch_state() switches the task,
-* this ensures the handler sees that func->transition is set.
-*/
- smp_wmb();
-
- klp_start_transition();
- klp_try_complete_transition();
- patch->enabled = false;
-
- return 0;
-}
-
-/**
- * klp_disable_patch() - disables a registered patch
- * @patch: The registered, enabled patch to be disabled
- *
- * Unregisters the patched functions from ftrace.
- *
- * Return: 0 on success, otherwise error
- */
-int klp_disable_patch(struct klp_patch *patch)
-{
- int ret;
-
- mutex_lock(&klp_mutex);
-
- if (!klp_is_patch_registered(patch)) {
- ret = -EINVAL;
- goto err;
- }
-
- if (!patch->enabled) {
- ret = -EINVAL;
- goto err;
- }
-
- ret = __klp_disable_patch(patch);
-
-err:
- mutex_unlock(&klp_mutex);
- return ret;
-}
-EXPORT_SYMBOL_GPL(klp_disable_patch);
-
-static int __klp_enable_patch(struct klp_patch *patch)
-{
- struct klp_object *obj;
- int ret;
-
- if (klp_transition_patch)
- return -EBUSY;
-
- if (WARN_ON(patch->enabled))
- return -EINVAL;
-
- /* enforce stacking: only the first disabled patch can be enabled */
- if (patch->list.prev != &klp_patches &&
- !list_prev_entry(patch, list)->enabled)
- return -EBUSY;
-
- /*
-* A reference is taken on the patch module to prevent it from being
-* unloaded.
-*/
- if (!try_module_get(patch->mod))
- return -ENODEV;
-
- pr_notice("enabling patch '%s'\n", patch->mod->name);
-
- klp_init_transition(patch, KLP_PATCHED);
-
- /*
-* Enforce the order of the func->transition writes in
-* klp_init_transition() and the ops->func_stack writes in
-* klp_patch_object(), so that klp_ftrace_handler() will see the
-* func->transition updates before the handler is registered and the
-* new funcs become visible to the handler.
-*/
- smp_wmb();
-
- klp_for_each_object(patch, obj) {
- if (!klp_is_object_loaded(obj))
- continue;
-
- ret = klp_pre_patch_callback(obj);
- if (ret) {
- pr_warn("pre-patch callback failed for object '%s'\n",
- klp_is_module(obj) ? obj->name : "vmlinux");
- goto err;
- }
-
- ret = klp_patch_object(obj);
- if (ret) {
- pr_warn("failed to patch object '%s'\n",
- klp_is_module(obj) ? obj->name : "vmlinux");
- goto err;
- }
- }
-
- klp_start_transition();
- klp_try_complete_transition();
- patch->enabled = true;
-
- return 0;
-err:
- pr_warn("failed to enable patch '%s'\n", patch->mod->name);
-
- klp_cancel_transition();
- return ret;
-}
-
-/**
- * klp_enable_patch() - enables a registered patch
- * @patch: The registered, disabled patch to be enabled
- *
- * Performs the needed symbol lookups and code relocations,
- * then registers the patched functions with ftrace.
- *
- * Return: 0 on success, otherwise error
- */
-int klp_enable_patch(st
[PATCH v14 00/11] livepatch: Atomic replace feature
Hi, I have an updated present for your mailboxes. The atomic replace allows to create cumulative patches. They are useful when you maintain many livepatches and want to remove one that is lower on the stack. In addition it is very useful when more patches touch the same function and there are dependencies between them. All the changes were simple in principle but they required quite some refactoring again :-( IMHO, the biggest change is renaming klp_init_lists() ->klp_init_patch_before_free(). It does all init actions that need to succeed before klp_free() functions can be safely called. The main motivation was the need to initialize also the new .kobj_alive flags. Changes against v13: + Rename old_addr -> old_func instead of new_func -> new_addr. [Josh] + Do not add the helper macros to define structures. [Miroslav, Josh] + Add custom kobj_alive flag to reliably handle kobj state. [Miroslav] + Avoid renaming .forced flag to .module_put by calling klp_free functions only with taken module reference. [Josh] + Use list_add_tail() instead of list_add() when updating the dynamic lists of klp_object and klp_func structures. Note that this required also updating the order of messages from the pre/post callbacks in the selftest. [Josh, Miroslav] + Do not unnecessarily initialize ret variable in klp_add_nops(). [Miroslav] + Got rid of klp_discard_replaced_stuff(). [Josh] + Updated commit messages, comments and documentation, especially the section "Livepatch life-cycle" [Josh, Miroslav] Changes against v12: + Finish freeing the patch using workqueues to prevent deadlock against kobject code. + Check for valid pointers when initializing the dynamic lists objects and functions. + Mark klp_free_objects_dynamic() static. + Improved documentation and fixed typos Changes against v11: + Functional changes: + Livepatches get automatically unregistered when disabled. Note that the sysfs interface disappears at this point. It simplifies the API and code. The only drawback is that the patch can be enabled again only by reloading the module. + Refuse to load conflicting patches. The same function can be patched again only by a new cumulative patch that replaces all older ones. + Non-conflicting patches can be loaded and disabled in any order. + API related changes: + Change void *new_func -> unsigned long new_addr in struct klp_func. + Several new macros to hide implementation details and avoid casting when defining struct klp-func and klp_object. + Remove obsolete klp_register_patch() klp_unregister_patch() API + Change in selftest against v4: + Use new macros to define struct klp_func and klp_object. + Remove klp_register_patch()/klp_unregister_patch() calls. + Replace load_mod() + wait_for_transition() with three variants load_mod(), load_lp(), load_lp_nowait(). IMHO, it is easier to use because we need to detect the end of transaction another way after disable_lp() now. + Replaced unload_mod() with two variants unload_mod(), unload_lp() to match the above change. + Wait for the end of transition in disable_lp() instead of the unreliable check of the sysfs interface. Note that I did not touch the logs with expected result. They stay exactly the same as in v4 posted by Joe. I hope that it is a good sign ;-) Changes against v10: + Bug fixes and functional changes: + Handle Nops in klp_ftrace_handled() to avoid infinite loop [Mirek] + Really add dynamically allocated klp_object into the list [Petr] + Clear patch->replace when transition finishes [Josh] + Refactoring and clean up [Josh]: + Replace enum types with bools + Avoid using ERR_PTR + Remove too paranoid warnings + Distinguish registered patches by a flag instead of a list + Squash some functions + Update comments, documentation, and commit messages + Squashed and split patches to do more controversial changes later Changes against v9: + Fixed check of valid NOPs for already loaded objects, regression introduced in v9 [Joe, Mirek] + Allow to replace even disabled patches [Evgenii] Changes against v8: + Fixed handling of statically defined struct klp_object with empty array of functions [Joe, Mirek] + Removed redundant func->new_func assignment for NOPs [Mirek] + Improved some wording [Mirek] Changes against v7: + Fixed handling of NOPs for not-yet-loaded modules + Made klp_replaced_patches list static [Mirek] + Made klp_free_object() public later [Mirek] + Fixed several reported typos [Mirek, Joe] + Updated documentation according to the feedback [Joe] + Added some Acks [Mirek] Changes against v6: + used list_move when disabling replaced patches [Jason] + renamed KLP_FUNC_ORIGINAL -> KLP_FUNC_STATIC [Mirek] + used klp_is_func_typ
Re: [RFC PATCH 1/5] x86: introduce preemption disable prefix
On Fri, Oct 19, 2018 at 07:29:45AM -0700, Andy Lutomirski wrote:
> > On Oct 19, 2018, at 1:33 AM, Peter Zijlstra wrote:
> >
> >> On Fri, Oct 19, 2018 at 01:08:23AM +, Nadav Amit wrote:
> >> Consider for example do_int3(), and see my inlined comments:
> >>
> >> dotraplinkage void notrace do_int3(struct pt_regs *regs, long error_code)
> >> {
> >>...
> >>ist_enter(regs);// => preempt_disable()
> >>cond_local_irq_enable(regs);// => assume it enables IRQs
> >>
> >>...
> >>// resched irq can be delivered here. It will not caused rescheduling
> >>// since preemption is disabled
> >>
> >>cond_local_irq_disable(regs);// => assume it disables IRQs
> >>ist_exit(regs);// => preempt_enable_no_resched()
> >> }
> >>
> >> At this point resched will not happen for unbounded length of time (unless
> >> there is another point when exiting the trap handler that checks if
> >> preemption should take place).
> >>
> >> Another example is __BPF_PROG_RUN_ARRAY(), which also uses
> >> preempt_enable_no_resched().
> >>
> >> Am I missing something?
> >
> > Would not the interrupt return then check for TIF_NEED_RESCHED and call
> > schedule() ?
>
> The paranoid exit path doesn’t check TIF_NEED_RESCHED because it’s
> fundamentally atomic — it’s running on a percpu stack and it can’t
> schedule. In theory we could do some evil stack switching, but we
> don’t.
>
> How does NMI handle this? If an NMI that hit interruptible kernel
> code overflows a perf counter, how does the wake up work?
NMIs should never set NEED_RESCHED. What the perf does it self-IPI
(irq_work) and do the wakeup from there.
[PATCH v14 01/11] livepatch: Change unsigned long old_addr -> void *old_func in struct klp_func
The address of the to be patched function and new function is stored
in struct klp_func as:
void *new_func;
unsigned long old_addr;
The different naming scheme and type is derived from the way how
the addresses are set. @old_addr is assigned at runtime using
kallsyms-based search. @new_func is statically initialized,
for example:
static struct klp_func funcs[] = {
{
.old_name = "cmdline_proc_show",
.new_func = livepatch_cmdline_proc_show,
}, { }
};
This patch changes unsigned log old_addr -> void *old_func. It removes
some confusion when these address are later used in the code. It is
motivated by a followup patch that adds special NOP struct klp_func
where we want to assign func->new_func = func->old_addr respectively
func->new_func = func->old_func.
This patch does not modify the existing behavior.
Suggested-by: Josh Poimboeuf
Signed-off-by: Petr Mladek
---
include/linux/livepatch.h | 4 ++--
kernel/livepatch/core.c | 6 +++---
kernel/livepatch/patch.c | 18 ++
kernel/livepatch/patch.h | 2 +-
kernel/livepatch/transition.c | 4 ++--
5 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h
index aec44b1d9582..634e13876380 100644
--- a/include/linux/livepatch.h
+++ b/include/linux/livepatch.h
@@ -40,7 +40,7 @@
* @new_func: pointer to the patched function code
* @old_sympos: a hint indicating which symbol position the old function
* can be found (optional)
- * @old_addr: the address of the function being patched
+ * @old_func: pointer to the function being patched
* @kobj: kobject for sysfs resources
* @stack_node:list node for klp_ops func_stack list
* @old_size: size of the old function
@@ -77,7 +77,7 @@ struct klp_func {
unsigned long old_sympos;
/* internal */
- unsigned long old_addr;
+ void *old_func;
struct kobject kobj;
struct list_head stack_node;
unsigned long old_size, new_size;
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index 5b77a7314e01..cb59c7fb94cb 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -648,7 +648,7 @@ static void klp_free_object_loaded(struct klp_object *obj)
obj->mod = NULL;
klp_for_each_func(obj, func)
- func->old_addr = 0;
+ func->old_func = NULL;
}
/*
@@ -721,11 +721,11 @@ static int klp_init_object_loaded(struct klp_patch *patch,
klp_for_each_func(obj, func) {
ret = klp_find_object_symbol(obj->name, func->old_name,
func->old_sympos,
-&func->old_addr);
+(unsigned long *)&func->old_func);
if (ret)
return ret;
- ret = kallsyms_lookup_size_offset(func->old_addr,
+ ret = kallsyms_lookup_size_offset((unsigned long)func->old_func,
&func->old_size, NULL);
if (!ret) {
pr_err("kallsyms size lookup failed for '%s'\n",
diff --git a/kernel/livepatch/patch.c b/kernel/livepatch/patch.c
index 82d584225dc6..130002eaadb8 100644
--- a/kernel/livepatch/patch.c
+++ b/kernel/livepatch/patch.c
@@ -34,7 +34,7 @@
static LIST_HEAD(klp_ops);
-struct klp_ops *klp_find_ops(unsigned long old_addr)
+struct klp_ops *klp_find_ops(void *old_func)
{
struct klp_ops *ops;
struct klp_func *func;
@@ -42,7 +42,7 @@ struct klp_ops *klp_find_ops(unsigned long old_addr)
list_for_each_entry(ops, &klp_ops, node) {
func = list_first_entry(&ops->func_stack, struct klp_func,
stack_node);
- if (func->old_addr == old_addr)
+ if (func->old_func == old_func)
return ops;
}
@@ -142,17 +142,18 @@ static void klp_unpatch_func(struct klp_func *func)
if (WARN_ON(!func->patched))
return;
- if (WARN_ON(!func->old_addr))
+ if (WARN_ON(!func->old_func))
return;
- ops = klp_find_ops(func->old_addr);
+ ops = klp_find_ops(func->old_func);
if (WARN_ON(!ops))
return;
if (list_is_singular(&ops->func_stack)) {
unsigned long ftrace_loc;
- ftrace_loc = klp_get_ftrace_location(func->old_addr);
+ ftrace_loc =
+ klp_get_ftrace_location((unsigned long)func->old_func);
if (WARN_ON(!ftrace_loc))
return;
@@ -174,17 +175,18 @@ static int klp_patch_func(struct klp_func *func)
struct klp_ops *ops;
int ret;
- if (WARN_ON(!func->old_addr))
+ if (WARN_ON(!func->old_func))
return -EINVAL;
Re: [PATCH] pci: imx6: support kernels built in Thumb-2 mode
On 28.11.2018 19:01, Russell King - ARM Linux wrote:
> On Wed, Nov 28, 2018 at 02:25:54PM +0100, Stefan Agner wrote:
>> Add a fault handler which handles reads in Thumb-2 mode. Install
>> the appropriate handler depending on which mode the kernel has
>> been built. This avoids an "Unhandled fault: external abort on
>> non-linefetch (0x1008) at 0xf0a8" during boot on a device
>> with a PCIe switch connected.
>>
>> Link:
>> https://lore.kernel.org/linux-pci/20181126161645.8177-1-ste...@agner.ch/
>> Signed-off-by: Stefan Agner
>> ---
>> FWIW, I found this manual helpful to write the code below:
>> http://hermes.wings.cs.wisc.edu/files/Thumb-2SupplementReferenceManual.pdf#page=43&zoom=100,0,66
>>
>> --
>> Stefan
>>
>> drivers/pci/controller/dwc/pci-imx6.c | 37 ++-
>> 1 file changed, 36 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/pci/controller/dwc/pci-imx6.c
>> b/drivers/pci/controller/dwc/pci-imx6.c
>> index 69f86234f7c0..683deb74d69f 100644
>> --- a/drivers/pci/controller/dwc/pci-imx6.c
>> +++ b/drivers/pci/controller/dwc/pci-imx6.c
>> @@ -29,6 +29,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "pcie-designware.h"
>>
>> @@ -299,6 +300,37 @@ static int imx6q_pcie_abort_handler(unsigned long addr,
>> return 1;
>> }
>>
>> +static int imx6q_pcie_abort_handler_thumb2(unsigned long addr,
>> +unsigned int fsr, struct pt_regs *regs)
>> +{
>> +unsigned long pc = instruction_pointer(regs);
>> +unsigned long instr = *(unsigned long *)pc;
>
> So what happens if userspace mmap()s the PCIe space (eg, via
> /dev/mem), and then accesses it, triggering this fault? You'll
> be attempting to read from userspace here, which will oops the
> kernel. The kernel is not allowed to access userspace by
> simply dereferencing a pointer.
>
Note that imx6q_pcie_abort_handler above does the same for ARM code. I
guess a quick fix for now would be just using user_mode before
dereferencing the pc:
if (user_mode(regs))
return 1;
Is userspace mmap'ing PCIe space common?
If we want to support user space, I guess we anyway should merge the ARM
and Thumb2 handler, and detect & act accordingly.
--
Stefan
>> +unsigned long thumb2_instr = __mem_to_opcode_thumb16(instr);
>> +int reg = thumb2_instr & 7;
>> +
>> +if (!__opcode_is_thumb16(instr & 0xUL))
>> +return 1;
>> +
>> +/* Load word/byte and halfword immediate offset */
>> +if (((thumb2_instr & 0xe800) == 0x6800) ||
>> +((thumb2_instr & 0xf800) == 0x8800)) {
>> +unsigned long val;
>> +
>> +if (thumb2_instr & 0x1000)
>> +val = 0xff;
>> +else if (thumb2_instr & 0x8000)
>> +val = 0x;
>> +else
>> +val = 0xUL;
>> +
>> +regs->uregs[reg] = val;
>> +regs->ARM_pc += 2;
>> +return 0;
>> +}
>> +
>> +return 1;
>> +}
>> +
>> static int imx6_pcie_attach_pd(struct device *dev)
>> {
>> struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
>> @@ -1069,6 +1101,8 @@ static struct platform_driver imx6_pcie_driver = {
>>
>> static int __init imx6_pcie_init(void)
>> {
>> +bool thumb2 = IS_ENABLED(CONFIG_THUMB2_KERNEL);
>> +
>> /*
>> * Since probe() can be deferred we need to make sure that
>> * hook_fault_code is not called after __init memory is freed
>> @@ -1076,7 +1110,8 @@ static int __init imx6_pcie_init(void)
>> * we can install the handler here without risking it
>> * accessing some uninitialized driver state.
>> */
>> -hook_fault_code(8, imx6q_pcie_abort_handler, SIGBUS, 0,
>> +hook_fault_code(8, thumb2 ? imx6q_pcie_abort_handler_thumb2 :
>> +imx6q_pcie_abort_handler, SIGBUS, 0,
>> "external abort on non-linefetch");
>>
>> return platform_driver_register(&imx6_pcie_driver);
>> --
>> 2.19.1
>>
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH] pci: imx6: support kernels built in Thumb-2 mode
On 28.11.2018 20:35, Robin Murphy wrote:
> On 28/11/2018 17:53, Stefan Agner wrote:
>> On 28.11.2018 17:16, Robin Murphy wrote:
>>> Hi Stefan,
>>>
>>> On 28/11/2018 13:25, Stefan Agner wrote:
Add a fault handler which handles reads in Thumb-2 mode. Install
the appropriate handler depending on which mode the kernel has
been built. This avoids an "Unhandled fault: external abort on
non-linefetch (0x1008) at 0xf0a8" during boot on a device
with a PCIe switch connected.
Link:
https://lore.kernel.org/linux-pci/20181126161645.8177-1-ste...@agner.ch/
Signed-off-by: Stefan Agner
---
FWIW, I found this manual helpful to write the code below:
http://hermes.wings.cs.wisc.edu/files/Thumb-2SupplementReferenceManual.pdf#page=43&zoom=100,0,66
>>>
>>> This one's rather less ancient and even more authoritative ;)
>>>
>>> https://static.docs.arm.com/ddi0406/cd/DDI0406C_d_armv7ar_arm.pdf
>>>
>>> (ARMv7 had a few new encodings over and above ARMv6T2, although in
>>> fairness I don't think any should be relevant to this specific case)
>>>
>>
>> Thanks, I tried to find the right document on arm.com, but I timed out
>> after 5 minutes or so :-)
>>
--
Stefan
drivers/pci/controller/dwc/pci-imx6.c | 37 ++-
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/dwc/pci-imx6.c
b/drivers/pci/controller/dwc/pci-imx6.c
index 69f86234f7c0..683deb74d69f 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include "pcie-designware.h"
@@ -299,6 +300,37 @@ static int imx6q_pcie_abort_handler(unsigned long
addr,
return 1;
}
+static int imx6q_pcie_abort_handler_thumb2(unsigned long addr,
+ unsigned int fsr, struct pt_regs *regs)
+{
+ unsigned long pc = instruction_pointer(regs);
+ unsigned long instr = *(unsigned long *)pc;
+ unsigned long thumb2_instr = __mem_to_opcode_thumb16(instr);
+ int reg = thumb2_instr & 7;
+
+ if (!__opcode_is_thumb16(instr & 0xUL))
+ return 1;
>>>
>>> There are plenty of 32-bit Thumb encodings of various LDR/STR
>>> variants, and I doubt we can guarantee that the offset, target
>>> register, and/or addressing mode for a config space access will
>>> *always* suit the (relatively limited) 16-bit ones.
>>
>> Hm, I guess they should be handled too?
>>
>> I looked at the code where I had the abort at hand triggered
>> (dw_pcie_read).
>
> For the sake of robustness, I think it makes sense to at least handle
> all LDR/LDRH/LDRB encodings which might possibly fall out of a
> read[lwb]() call. Given that we seem to have various versions of this
> decoding in differing states of completeness, perhaps it's even worth
> factoring out into some kind of common "Arm PCI synchronous abort
> handler".
>
That was actually my approach. dw_pcie_read uses read[lwb](), and this
is how it disassembles:
:
0: 1e4bsubsr3, r1, #1
2: 4003andsr3, r0
4: d112bne.n 2c
6: 2904cmp r1, #4
8: d00abeq.n 20
a: 2902cmp r1, #2
c: d012beq.n 34
e: 2901cmp r1, #1
10: d10cbne.n 2c
12: 7801ldrbr1, [r0, #0]
14: b2c9uxtbr1, r1
16: f3bf 8f4f dsb sy
1a: 4618mov r0, r3
Re: [PATCH v2] mtd: spinand: Fix ECC status and OOB layout for Toshiba TC58CVG2S0H
Hi Frieder,
On Wed, 28 Nov 2018 at 14:18, Schrempf Frieder
wrote:
>
> When reading the status of the on-chip ECC, the Toshiba chip returns
> two different states for reporting corrected bitflips. We should check
> for both of them.
>
> Also return the free OOB bytes as one contiguous area, instead of
> multiple sections.
>
> Suggested-by: Clément Péron
> Signed-off-by: Frieder Schrempf
Acked-by: Clément Péron
> ---
> drivers/mtd/nand/spi/toshiba.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mtd/nand/spi/toshiba.c b/drivers/mtd/nand/spi/toshiba.c
> index 294bcf6..9731752 100644
> --- a/drivers/mtd/nand/spi/toshiba.c
> +++ b/drivers/mtd/nand/spi/toshiba.c
> @@ -11,6 +11,7 @@
> #include
>
> #define SPINAND_MFR_TOSHIBA0x98
> +#define TOSH_STATUS_ECC_HAS_BITFLIPS_T (3 << 4)
>
> static SPINAND_OP_VARIANTS(read_cache_variants,
> SPINAND_PAGE_READ_FROM_CACHE_X4_OP(0, 1, NULL, 0),
> @@ -33,19 +34,17 @@ static int tc58cvg2s0h_ooblayout_ecc(struct mtd_info
> *mtd, int section,
> region->offset = 128 + 16 * section;
> region->length = 16;
>
> -
> return 0;
> }
>
> static int tc58cvg2s0h_ooblayout_free(struct mtd_info *mtd, int section,
> struct mtd_oob_region *region)
> {
> - if (section > 7)
> + if (section > 0)
> return -ERANGE;
>
> - region->offset = 2 + 16 * section;
> - region->length = 14;
> -
I will just add a comment here to say that we reserve 2 bytes for BBM.
Else, it's fine for me.
Regards,
Clement
> + region->offset = 2;
> + region->length = 126;
>
> return 0;
> }
> @@ -70,6 +69,7 @@ static int tc58cvg2s0h_ecc_get_status(struct spinand_device
> *spinand,
> return -EBADMSG;
>
> case STATUS_ECC_HAS_BITFLIPS:
> + case TOSH_STATUS_ECC_HAS_BITFLIPS_T:
> /*
> * Let's try to retrieve the real maximum number of bitflips
> * in order to avoid forcing the wear-leveling layer to move
> --
> 2.7.4
Re: [PATCH V5 1/2] base/drivers/arch_topology: Replace mutex with READ_ONCE / WRITE_ONCE
On 29/11/18 10:18, Daniel Lezcano wrote:
> On 29/11/2018 08:04, Juri Lelli wrote:
>
> [ ... ]
>
> >> With or without this patch, it is the case:
> >>
> >> task1 task2
> >> | |
> >> read("/sys/.../cpu1/cpu_capacity) |
> >> | write("/sys/.../cpu1/cpu_capacity")
> >> read("/sys/.../cpu2/cpu_capacity) |
> >>
> >>
> >> There is no guarantee userspace can have a consistent view of the
> >> capacity. As soon as it reads a capacity, it can be changed in its back.
> >
> > True, but w/o the mutex task1 could read different cpu_capacity values
> > for a cluster (it actually can also with current implementation, we
> > should grab the mutex in the read path as well if we want to avoid
> > this).
>
> Even if the mutex is on the read path, the userspace can see different
> capacities because it will read the cpu_capacity per cpu directory.
>
> The mutex will be take when reading cpu0/cpu_capacity, not for
> cpu[0-9]/cpu_capacity. Between two reads, a write can happen because the
> lock is released in between.
>
> Do you agree with the patch ? Or do you want me to drop it ?
I don't actually have cases at hand that are showing regression with it,
I was just trying to understand if we might potentially hit problems in
the future. So, I'm not against this patch. :-)
Re: [PATCH 24/27] locking/lockdep: Introduce __lockdep_free_key_range()
On Wed, Nov 28, 2018 at 03:43:22PM -0800, Bart Van Assche wrote:
> This patch does not change any functionality but makes the next patch
> in this series easier to read.
Ooh, I completely forgot about commit:
35a9393c95b3 ("lockdep: Fix the module unload key range freeing logic")
I was still thinking that all was broken... yes, I think I see where
you're going.
Re: [PATCH v2 1/3] mmc: sdhci: add support for using external DMA devices
Hi Adrian, On Thu, 29 Nov 2018 at 15:36, Adrian Hunter wrote: > > On 29/11/18 8:22 AM, Chunyan Zhang wrote: > > On Tue, 20 Nov 2018 at 21:41, Adrian Hunter wrote: > >> > >> On 12/11/18 9:26 AM, Chunyan Zhang wrote: > >>> Some standard SD host controllers can support both external dma > >>> controllers as well as ADMA/SDMA in which the SD host controller > >>> acts as DMA master. TI's omap controller is the case as an example. > >>> > >>> Currently the generic SDHCI code supports ADMA/SDMA integrated in > >>> the host controller but does not have any support for external DMA > >>> controllers implemented using dmaengine, meaning that custom code is > >>> needed for any systems that use an external DMA controller with SDHCI. > >> > >> I still think you probably need to reset the DMA if there are transfer > >> errors - perhaps you could comment on that. Also there are some comments > >> below. > > > > With regard to "transfer error", do you mean if > > sdhci_external_dma_setup() failed? > > No, I mean any error interrupt that can leave the DMA uncompleted. For > SDHCI, resetting the data circuit cleans that up, but presumably something > is needed for external DMA? Yes, it should need a dmaengine_terminate_all(). How about adding that at here (I will wrap it up of course): https://elixir.bootlin.com/linux/v4.19.5/source/drivers/mmc/host/sdhci.c#L2553 Is there somewhere else I'm missing? Thanks, Chunyan
Re: [PATCH AUTOSEL 4.19 15/68] batman-adv: Expand merged fragment buffer for full packet
Hello!
On 11/29/2018 08:55 AM, Sasha Levin wrote:
> From: Sven Eckelmann
>
> [ Upstream commit d7d8bbb40a5b1f682ee6589e212934f4c6b8ad60 ]
>
> The complete size ("total_size") of the fragmented packet is stored in the
> fragment header and in the size of the fragment chain. When the fragments
> are ready for merge, the skbuff's tail of the first fragment is expanded to
> have enough room after the data pointer for at least total_size. This means
> that it gets expanded by total_size - first_skb->len.
>
> But this is ignoring the fact that after expanding the buffer, the fragment
> header is pulled by from this buffer. Assuming that the tailroom of the
Pulled by what?
> buffer was already 0, the buffer after the data pointer of the skbuff is
> now only total_size - len(fragment_header) large. When the merge function
> is then processing the remaining fragments, the code to copy the data over
> to the merged skbuff will cause an skb_over_panic when it tries to actually
> put enough data to fill the total_size bytes of the packet.
>
> The size of the skb_pull must therefore also be taken into account when the
> buffer's tailroom is expanded.
>
> Fixes: 610bfc6bc99b ("batman-adv: Receive fragmented packets and merge")
> Reported-by: Martin Weinelt
> Co-authored-by: Linus Lüssing
> Signed-off-by: Sven Eckelmann
> Signed-off-by: Simon Wunderlich
> Signed-off-by: Sasha Levin
[...]
MBR, Sergei
Re: [RFC PATCH] net: macb: Apply RXUBR workaround only to versions with errata
On 28.11.2018 23:09, Brandon Streiff wrote:
> On 11/23/2018 3:59 AM, Harini Katakam wrote:
>> +/* Errata mask bits */
>> +#define MACB_ERRATA_RXLOCKUP0x0001
>> +
>> /* LSO settings */
>> #define MACB_LSO_UFO_ENABLE 0x01
>> #define MACB_LSO_TSO_ENABLE 0x02
>> @@ -1085,6 +1088,7 @@ struct macb_config {
>> struct clk **rx_clk);
>> int (*init)(struct platform_device *pdev);
>> int jumbo_max_len;
>> +u32 errata;
>> };
>>
>> struct tsu_incr {
>> @@ -1214,6 +1218,8 @@ struct macb {
>>
>> int rx_bd_rd_prefetch;
>> int tx_bd_rd_prefetch;
>> +
>> +u32 errata;
>> };
>
> Hi Harini,
>
> Could this be made into simpler by instead adding a caps bit, named
> (perhaps) MACB_CAPS_BUGGY_RXUBR or MACB_CAPS_NEEDS_RXUBR_RESETS or
> something?
>
> That would save needing to add a new u32 field into the macb_config and
> macb structs (both of which already have this caps field).
>
I avoid duplicating these fields from struct macb_config to struct macb I
would start to move macb_config part of struct macb as a const * member
(see [1]).
[1]
https://github.com/linux4sam/linux-at91/commit/8c588136189148d79c4078c55da2242a2ba2b8d3#diff-921c839dba439fd502a24aed0845dc9d
Re: [PATCH V5 1/2] base/drivers/arch_topology: Replace mutex with READ_ONCE / WRITE_ONCE
On 29/11/2018 10:58, Juri Lelli wrote:
> On 29/11/18 10:18, Daniel Lezcano wrote:
>> On 29/11/2018 08:04, Juri Lelli wrote:
>>
>> [ ... ]
>>
With or without this patch, it is the case:
task1 task2
| |
read("/sys/.../cpu1/cpu_capacity) |
| write("/sys/.../cpu1/cpu_capacity")
read("/sys/.../cpu2/cpu_capacity) |
There is no guarantee userspace can have a consistent view of the
capacity. As soon as it reads a capacity, it can be changed in its back.
>>>
>>> True, but w/o the mutex task1 could read different cpu_capacity values
>>> for a cluster (it actually can also with current implementation, we
>>> should grab the mutex in the read path as well if we want to avoid
>>> this).
>>
>> Even if the mutex is on the read path, the userspace can see different
>> capacities because it will read the cpu_capacity per cpu directory.
>>
>> The mutex will be take when reading cpu0/cpu_capacity, not for
>> cpu[0-9]/cpu_capacity. Between two reads, a write can happen because the
>> lock is released in between.
>>
>> Do you agree with the patch ? Or do you want me to drop it ?
>
> I don't actually have cases at hand that are showing regression with it,
> I was just trying to understand if we might potentially hit problems in
> the future. So, I'm not against this patch. :-)
not-not-acked-by ? :)
--
Facebook |
Twitter |
[PATCH] ASoC: adau1761: Ensure DSP_RUN and DSP_ENABLE are disabled
DSP_RUN and DSP_ENABLE needs to be disabled during FW load. This is not
a problem after power-cycling but for soft reboots.
Signed-off-by: Niklas Carlsson
---
sound/soc/codecs/adau1761.c | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/sound/soc/codecs/adau1761.c b/sound/soc/codecs/adau1761.c
index bef3e9e74c26..3075c13bcbbc 100644
--- a/sound/soc/codecs/adau1761.c
+++ b/sound/soc/codecs/adau1761.c
@@ -460,8 +460,35 @@ static int adau1761_set_bias_level(struct
snd_soc_component *component,
regmap_update_bits(adau->regmap, ADAU17X1_CLOCK_CONTROL,
ADAU17X1_CLOCK_CONTROL_SYSCLK_EN,
ADAU17X1_CLOCK_CONTROL_SYSCLK_EN);
- if (snd_soc_component_get_bias_level(component) ==
SND_SOC_BIAS_OFF)
+ if (snd_soc_component_get_bias_level(component) ==
+ SND_SOC_BIAS_OFF) {
+ /*
+* When going OFF -> STANDBY, the device can be in two
+* states:
+* 1) Power-cycled and reset
+* 2) Soft reboot
+* In the case of soft reboot, we need to sync the HW
+* registers even if our regmap reports default values.
+* Marking the cache as dirty ensures that both cases
+* are handled.
+*/
+ regcache_mark_dirty(adau->regmap);
regcache_sync(adau->regmap);
+ /*
+* In order for FW to load correctly, the device needs
+* DSP_RUN and DSP_ENABLE to be 0. This might not be the
+* case for soft reboots. Ensure that DSP_RUN and
+* DSP_ENABLE is 0 by bypassing the cache and write
+* directly to HW when going OFF -> STANDBY.
+*/
+ if (adau17x1_has_dsp(adau)) {
+ regcache_cache_bypass(adau->regmap, true);
+ regmap_write(adau->regmap, ADAU17X1_DSP_RUN, 0);
+ regmap_write(adau->regmap,
+ ADAU17X1_DSP_ENABLE, 0);
+ regcache_cache_bypass(adau->regmap, false);
+ }
+ }
break;
case SND_SOC_BIAS_OFF:
regmap_update_bits(adau->regmap, ADAU17X1_CLOCK_CONTROL,
--
2.11.0
Re: linux-next: manual merge of the selinux tree with the vfs tree
On Wed, Nov 28, 2018 at 10:52 PM Paul Moore wrote: > On Tue, Nov 27, 2018 at 6:50 AM Stephen Rothwell > wrote: > > Hi Ondrej, > > > > On Tue, 27 Nov 2018 09:53:32 +0100 Ondrej Mosnacek > > wrote: > > > > > > Hm... seems that there was some massive overhaul in the VFS code right > > > at the wrong moment... There are new hooks for mounting now and the > > > > The mount changes have been in linux-next since before the last > > release ... > > > > > code that our commit changes is now here: > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git/tree/security/selinux/hooks.c?h=for-next#n3131 > > > > > > It seems that the logic is still the same, just now our patch (or the > > > VFS one) needs to be updated to change the above line as such > > > (untested pseudo-patch): > > > > > > - if (fc->purpose == FS_CONTEXT_FOR_KERNEL_MOUNT) > > > + if (fc->purpose == > > > (FS_CONTEXT_FOR_KERNEL_MOUNT|FS_CONTEXT_FOR_SUBMOUNT)) > > > > OK, so from tomorrow I will use that merge resolution. Someone needs > > to remember to tell Linus about this when the latter of the vfs and > > selinux trees reach him. > > I will, or at least I'll do my best to remember; since we only have a > few more week until the merge window I like my odds. FWIW, I > typically do a test merge on top of Linus' tree before sending the > SELinux PR just to verify that everything is relatively clean and > there are no surprises. > > Ondrej, please work with David Howells to ensure that submounts are > handled correctly in his mount rework. OK, I will verify that the SELinux submount fix rebased on top of vfs/work.mount in the way I suggested above passes the same testing (seliinux-testsuite + NFS crossmnt reproducer). I am now building two kernels (vfs/work.mount with and without the fix) to test. Let me know if there is anything more to do. Thanks, -- Ondrej Mosnacek Associate Software Engineer, Security Technologies Red Hat, Inc.
Re: [PATCH 12/16] dt-bindings: remoteproc: ti-pruss: Document application node bindings
On 27/11/18 01:27, David Lechner wrote: > On 11/26/18 1:52 AM, Roger Quadros wrote: >> From: Tero Kristo >> >> Add documentation for the Texas Instruments PRU application nodes. >> These are used to configure specific user applications for PRU instances. > > Could this be made into a generic remoteproc producer/consumer binding? Or > are there really things that are specific to the TI PRU that need to be > handled? The remoteproc handle and firmware name sound generic enough. But there are TI PRU specific properties as well which we'll discuss if they can be made generic. > >> >> Signed-off-by: Tero Kristo >> [s-a...@ti.com: some binding updates] >> Signed-off-by: Suman Anna >> Signed-off-by: Roger Quadros >> --- >> .../devicetree/bindings/soc/ti/ti,pruss.txt| 43 >> ++ >> 1 file changed, 43 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt >> b/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt >> index 3e5f32f..94c91ee 100644 >> --- a/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt >> +++ b/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt >> @@ -210,6 +210,38 @@ used in TI Davinci SoCs. Please refer to the >> corresponding binding document, >> Documentation/devicetree/bindings/net/davinci-mdio.txt for details. >> +Application/User Nodes >> +=== > > Are these supposed to be stand-alone platform devices? > Yes. The first use case we're going to address is the Ethernet ports on the IDKs. (Industrial development Kit) http://www.ti.com/tool/TMDXIDK437X >> +A PRU application/user node typically uses one or more PRU device nodes to >> +implement a PRU application/functionality. Each application/client node >> would >> +need a reference to at least a PRU node, and optionally pass some >> configuration >> +parameters. > > I thought device tree is not supposed to be used for configuration. I think we need to word it properly. It is really a hardware/firmware map. > >> + >> +Required Properties: >> + >> +- prus : phandles to the PRU nodes used >> + >> +Optional Properties: >> + >> +- firmware-name: firmwares for the PRU cores, the default firmware >> + for the core from the PRU node will be used if not >> + provided. The firmware names should correspond to >> + the PRU cores listed in the 'prus' property > > Perhaps this should be a "compatible" property instead of "firmware-name"? The > driver that matches the compatible string can then set the firmware names. Compatible property is there to choose the application driver. Should have mentioned it in Required properties. It is tricky for the driver to decipher the firmware-name as it needs to support the same use case on multiple platforms and the firmware name will be different for each. The driver itself is platform agnostic. So providing the firmware-name in the DT is the easiest and scalable solution. > >> +- ti,pruss-gp-mux-sel : array of values for the GP_MUX_SEL under >> PRUSS_GPCFG >> + register for a PRU. This selects the internal >> muxing >> + scheme for the PRU instance. If not provided, the >> + default out-of-reset value (0) for the PRU core is >> + used. Values should correspond to the PRU cores >> listed >> + in the 'prus' property > > Is this supposed to be a pinmux? So maybe we should be using pinmux bindings? We already have pinmux binding for the PRU pins. This GP mux setting is an odd duck. It provides a way for a set of signals inside the ICSS to be connected to the PRU pins on the SOC, which are again multiplexed with other SOC pins via the regular pinmux. Some of the sets are GPIO mode (0) EnDAT mode (1) SD mode (3) MII2 mode (4) The application node needs to decide which set it wants to use. > >> +- ti,pru-interrupt-map : PRU interrupt mappings, containing an array of >> entries >> + with each entry consisting of 4 cell-values. First >> one >> + is an index towards the "prus" property to >> identify the >> + PRU core for the interrupt map, second is the PRU >> + System Event id, third is the PRU interrupt >> channel id >> + and fourth is the PRU host interrupt id. If >> provided, >> + this map will supercede any other configuration >> + provided through firmware > > Could this mapping just be cells of the interrupt consumer nodes instead of an > extra property? As I mentioned in a reply to another patch, unless there is a > compelling reason to do otherwise, the channel to host mapping can be required > to be 1:1 as recommended in the TRMs, so that cell can be omitted. A
Re: [PATCH 3/3] lockdep: Use line-buffered printk() for lockdep messages.
On 2018/11/28 22:29, David Laight wrote: > I also spent a week trying to work out why a customer kernel was > locking up - only to finally find out that the distro they were > using set 'panic on opps' - making it almost impossible to find > out what was happening. How can line buffering negatively affect this case? The current thread which triggered an oops will keep calling printk() until that current thread reaches panic(), won't it? The only case where line buffering negatively affects will be that the initial 10 bytes of a critical line failed to reach log_store() because some other thread (not the current thread doing a series of printk()) halted CPUs / reset the whole machine _before_ the initial 10 bytes of a critical line reaches log_store(). On 2018/11/26 13:34, Sergey Senozhatsky wrote: > Or... Instead. > We can just leave pr_cont() alone for now. And make it possible to > reconstruct messages - IOW, inject some info to printk messages. We > do this at Samsung (inject CPU number at the beginning of every > message. `cat serial.0 | grep "\[1\]"` to grep for all messages from > CPU1). Probably this would be the simplest thing. Yes, I sent a patch which helps reconstructing messages at http://lkml.kernel.org/r/1543045075-3008-1-git-send-email-penguin-ker...@i-love.sakura.ne.jp .
[PATCH v4 1/3] thermal: tegra: remove unnecessary warnings
Convert warnings to info as not all platforms may
have all the thresholds and sensors enabled.
Signed-off-by: Wei Ni
---
drivers/thermal/tegra/soctherm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/thermal/tegra/soctherm.c b/drivers/thermal/tegra/soctherm.c
index ed28110a3535..55cc1f2f6a45 100644
--- a/drivers/thermal/tegra/soctherm.c
+++ b/drivers/thermal/tegra/soctherm.c
@@ -550,7 +550,7 @@ static int tegra_soctherm_set_hwtrips(struct device *dev,
ret = tz->ops->get_crit_temp(tz, &temperature);
if (ret) {
- dev_warn(dev, "thermtrip: %s: missing critical temperature\n",
+ dev_info(dev, "thermtrip: %s: missing critical temperature\n",
sg->name);
goto set_throttle;
}
@@ -569,7 +569,7 @@ static int tegra_soctherm_set_hwtrips(struct device *dev,
set_throttle:
ret = get_hot_temp(tz, &trip, &temperature);
if (ret) {
- dev_warn(dev, "throttrip: %s: missing hot temperature\n",
+ dev_info(dev, "throttrip: %s: missing hot temperature\n",
sg->name);
return 0;
}
@@ -600,7 +600,7 @@ static int tegra_soctherm_set_hwtrips(struct device *dev,
}
if (i == THROTTLE_SIZE)
- dev_warn(dev, "throttrip: %s: missing throttle cdev\n",
+ dev_info(dev, "throttrip: %s: missing throttle cdev\n",
sg->name);
return 0;
--
2.7.4
[PATCH v4 3/3] thermal: tegra: parse sensor id before sensor register
Since different platforms may not support all 4
sensors, so the sensor registration may be failed.
Add codes to parse dt to find sensor id which
need to be registered. So that the registration
can be successful on all platform.
Signed-off-by: Wei Ni
---
drivers/thermal/tegra/soctherm.c | 46 ++--
1 file changed, 44 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/tegra/soctherm.c b/drivers/thermal/tegra/soctherm.c
index 375cadbc24cd..bdc660f2794a 100644
--- a/drivers/thermal/tegra/soctherm.c
+++ b/drivers/thermal/tegra/soctherm.c
@@ -1224,6 +1224,42 @@ static void soctherm_init(struct platform_device *pdev)
tegra_soctherm_throttle(&pdev->dev);
}
+static bool tegra_soctherm_find_sensor_id(unsigned int sensor_id)
+{
+ bool ret = false;
+ struct of_phandle_args sensor_specs;
+ struct device_node *np, *sensor_np;
+
+ np = of_find_node_by_name(NULL, "thermal-zones");
+ if (!np)
+ return ret;
+
+ sensor_np = of_get_next_child(np, NULL);
+ for_each_available_child_of_node(np, sensor_np) {
+ if (of_parse_phandle_with_args(sensor_np, "thermal-sensors",
+"#thermal-sensor-cells",
+0, &sensor_specs))
+ continue;
+
+ if (sensor_specs.args_count != 1) {
+ WARN(sensor_specs.args_count != 1,
+"%s: wrong cells in sensor specifier %d\n",
+sensor_specs.np->name, sensor_specs.args_count);
+ continue;
+ }
+
+ if (sensor_specs.args[0] == sensor_id) {
+ ret = true;
+ break;
+ }
+ }
+
+ of_node_put(np);
+ of_node_put(sensor_np);
+
+ return ret;
+}
+
static const struct of_device_id tegra_soctherm_of_match[] = {
#ifdef CONFIG_ARCH_TEGRA_124_SOC
{
@@ -1365,13 +1401,16 @@ static int tegra_soctherm_probe(struct platform_device
*pdev)
zone->sg = soc->ttgs[i];
zone->ts = tegra;
+ if (!tegra_soctherm_find_sensor_id(soc->ttgs[i]->id))
+ continue;
+
z = devm_thermal_zone_of_sensor_register(&pdev->dev,
soc->ttgs[i]->id, zone,
&tegra_of_thermal_ops);
if (IS_ERR(z)) {
err = PTR_ERR(z);
- dev_err(&pdev->dev, "failed to register sensor: %d\n",
- err);
+ dev_err(&pdev->dev, "failed to register sensor %s:
%d\n",
+ soc->ttgs[i]->name, err);
goto disable_clocks;
}
@@ -1434,6 +1473,9 @@ static int __maybe_unused soctherm_resume(struct device
*dev)
struct thermal_zone_device *tz;
tz = tegra->thermctl_tzs[soc->ttgs[i]->id];
+ if (!tz)
+ continue;
+
err = tegra_soctherm_set_hwtrips(dev, soc->ttgs[i], tz);
if (err) {
dev_err(&pdev->dev,
--
2.7.4
Re: [PATCH 25/27] locking/lockdep: Add support for dynamic keys
On Wed, Nov 28, 2018 at 03:43:23PM -0800, Bart Van Assche wrote:
> +/* hash_entry is used to keep track of dynamically allocated keys. */
> struct lock_class_key {
> + struct hlist_node hash_entry;
> struct lockdep_subclass_key subkeys[MAX_LOCKDEP_SUBCLASSES];
> };
One consideration; and maybe we should have a BUILD_BUG for that, is
that this object should be no larger than the smallest lock primitive.
That typically is raw_spinlock_t, which normally is 4 bytes, but with
lockdep on that at least also includes struct lockdep_map.
So what we want is:
sizeof(lock_class_key) <= sizeof(raw_spinlock_t)
Otherwise, two consecutive spinlocks could end up with key overlap in
their subclass range.
Now, I think that is still valid after this patch, but it is something
that gave me pause.
[PATCH v4 0/3] Fixes for Tegra soctherm
This series fixed some issues for Tegra soctherm Main changes from v3: 1. updated codes for parsing sensor id, per Thierry's comments Main changes from v2: 1. add codes to parse sensor id to avoid registration failure. Main changes from v1: 1. Acked by Thierry Reding for the patch "thermal: tegra: fix memory allocation". 2. Print out the sensor name when register failed. 2. Remove patch "thermal: tegra: fix coverity defect" Wei Ni (3): thermal: tegra: remove unnecessary warnings thermal: tegra: fix memory allocation thermal: tegra: parse sensor id before sensor register drivers/thermal/tegra/soctherm.c | 54 +++- 1 file changed, 48 insertions(+), 6 deletions(-) -- 2.7.4
[PATCH v4 2/3] thermal: tegra: fix memory allocation
Fix memory allocation to store the pointers to thermal_zone_device. Signed-off-by: Wei Ni Acked-by: Thierry Reding --- drivers/thermal/tegra/soctherm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/tegra/soctherm.c b/drivers/thermal/tegra/soctherm.c index 55cc1f2f6a45..375cadbc24cd 100644 --- a/drivers/thermal/tegra/soctherm.c +++ b/drivers/thermal/tegra/soctherm.c @@ -1339,7 +1339,7 @@ static int tegra_soctherm_probe(struct platform_device *pdev) } tegra->thermctl_tzs = devm_kcalloc(&pdev->dev, - soc->num_ttgs, sizeof(*z), + soc->num_ttgs, sizeof(z), GFP_KERNEL); if (!tegra->thermctl_tzs) return -ENOMEM; -- 2.7.4
Re: [GIT PULL] Qualcomm Device Tree updates for 4.20
HI Arnd, On Tue, 2 Oct 2018 at 11:38, Arnd Bergmann wrote: > > On Sun, Sep 30, 2018 at 8:38 PM Andy Gross wrote: > > > > The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: > > > > Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) > > > > are available in the git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git > > tags/qcom-dts-for-4.20 > > > > for you to fetch changes up to ca02f96b95ca1a50344e7e2a7bb43fbb825aa3a2: > > > > ARM: dts: qcom: Update coresight bindings for hardware ports (2018-09-30 > > 13:14:05 -0500) > > > > > > Qualcomm Device Tree Changes for v4.20 > > > > * Fix IRQ constants usage on MSM8974 > > * Add led, gpio-button, sdcc, and pcie nodes for IPQ8064 > > * Move/cleanup common nodes for IPQ8064 > > * Add i2c sensor nodes for MSM8974 Hammerhead > > * Fixes for SAW, kpss, opp, pci range, and space/tab on IPQ4019 > > * Update coresight bindings > > Some of the ipq4019 changes look like important fixes, should > they be applied for linux-4.19 and possibly backported to stable? Just want to point that it has not been backported to 4.19 is it expected ? Thanks, Clement > If so, please submit them again for the fixes branch. > > I also get this one warning (both with and without your patches): > > arch/arm/boot/dts/qcom-apq8064-arrow-sd-600eval.dtb: Warning > (graph_endpoint): /soc/mdp@510/ports/port@3/endpoint: graph > connection to node '/soc/hdmi-tx@4a0/ports/port@0/endpoint' is not > bidirectional > > Can you have a look and see if it can be fixed in a follow-up? > > I pulled this version into next/dt for now, thanks! > > Arnd
Re: [PATCH v3 0/3] perf report/annotate: Support average IPC and IPC coverage for function
On Thu, Nov 29, 2018 at 02:24:27PM +0800, Jin, Yao wrote:
>
>
> On 11/28/2018 6:18 PM, Jiri Olsa wrote:
> > On Wed, Nov 28, 2018 at 11:17:57AM +0100, Jiri Olsa wrote:
> > > On Wed, Nov 28, 2018 at 11:14:55PM +0800, Jin Yao wrote:
> > > > Add supporting of displaying the average IPC and IPC coverage
> > > > percentage per function.
> > > >
> > > > For example,
> > > >
> > > > $ perf record -b ...
> > > > $ perf report -s symbol or
> > > >perf report -s symbol --stdio
> > > >
> > > > Overhead Symbol IPC [IPC Coverage]
> > > >39.60% [.] __random 2.30 [ 54.8%]
> > > >18.02% [.] main 0.43 [ 54.3%]
> > > >14.21% [.] compute_flag 2.29 [100.0%]
> > > >14.16% [.] rand 0.36 [100.0%]
> > > > 7.06% [.] __random_r 2.57 [ 70.5%]
> > > > 6.85% [.] rand@plt 0.00 [ 0.0%]
> > > >...
> > > >
> > > > $ perf annotate --stdio2
> > > >
> > > > Percent IPC Cycle (Average IPC: 2.30, IPC Coverage: 54.8%)
> > > >
> > > > Disassembly of section .text:
> > > >
> > > > 0003aac0 :
> > > >8.32 3.28 sub$0x18,%rsp
> > > > 3.28 mov$0x1,%esi
> > > > 3.28 xor%eax,%eax
> > > > 3.28 cmpl
> > > > $0x0,argp_program_version_hook@@GLIBC_2.2.5+0x1e0
> > > > 11.57 3.28 1 ↓ je 20
> > > >lock cmpxchg
> > > > %esi,__abort_msg@@GLIBC_PRIVATE+0x8a0
> > > > ↓ jne29
> > > > ↓ jmp43
> > > > 11.57 1.1020: cmpxchg %esi,__abort_msg@@GLIBC_PRIVATE+0x8a0
> > > > ...
> > > >
> > > > v3:
> > > > ---
> > > > Remove the sortkey "ipc" from command-line. The columns "IPC"
> > > > and "[IPC Coverage]" are automatically enabled when "symbol"
> > > > is specified.
> > > >
> > > > Patch "perf report: Display average IPC and IPC coverage per
> > > > symbol"
> > > > is impacted.
> > > >
> > > > v2:
> > > > ---
> > > >1. Merge in Jiri's patch to support stdio mode
> > > >
> > > >2. Add a new patch "perf annotate: Create a annotate2 flag
> > > > in struct symbol" which records if the symbol has been
> > > > annotated yet.
> > > >
> > > >3. Minor update such as adding { } for multiline code in 'if'
> > > > condition.
> > > >
> > > > Jin Yao (3):
> > > >perf annotate: Compute average IPC and IPC coverage per symbol
> > > >perf annotate: Create a annotate2 flag in struct symbol
> > > >perf report: Display average IPC and IPC coverage per symbol
> > >
> > > hi,
> > > I took he liberty and moved the annotation retrieval into
> > > resort phase under progress bar scope. It's currently on top
> > > of my perf/fixes branch, could you please check it?
> > >
> > >git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
> >
> > commits:
> > 7f3ffdb9783f perf tools: Move symbol annotation to resort
> > e87f7d3c4f10 perf tools: Add perf_evsel__output_resort_cb function
> > 40012b422108 perf tools: Add argument to hists__resort_cb_t callback
> >
> > jirka
> >
>
> Hi Jiri,
>
> Thanks for your patches. I have tested with your repo. Now I can see 2
> progress bars. One is displayed at the events processing phase, the other is
> displayed at resorting phase.
>
> I have only one concern that is, in my test, much of time is consumed by the
> event processing phase, for example, 90% of time. Only 10% of time is
> consumed at resorting phase.
>
> So do we really need the second progress bar?
well I did not add it, it's been always there, it just must
have been real quick for you so u did not notice I guess
it's strange, because for me the resorting takes much longer
even for small data.. let's have your patchset applied and
have this discussion when I send out the patches
thanks,
jirka
Re: [PATCH v2 0/2] KVM: x86: expose direct stores instructions into VM.
On 06.11.18 06:55, Liu Jingqi wrote: > Direct stores instructions MOVDIRI and MOVDIR64B will be available in > Tremont and other future x86 processors, > and need to be exposed to guest VM. > > The release document ref below link: > https://software.intel.com/sites/default/files/managed/c5/15/\ > architecture-instruction-set-extensions-programming-reference.pdf > > This series expose movdiri and movdir64b features to guest VM. > > Changelog: > v2: > Separated from the series https://lkml.org/lkml/2018/7/10/160 > since umonitor/umwait/tpause instructions patches are not ready yet. > v1: > Sent out with umonitor/umwait/tpause instructions patches. > > Liu Jingqi (2): > KVM: x86: expose MOVDIRI CPU feature into VM. > KVM: x86: expose MOVDIR64B CPU feature into VM. > > arch/x86/kvm/cpuid.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Does it make sense to squash both patches? (into a patch named just like this cover letter? :) ) -- Thanks, David / dhildenb
Re: [PATCH 1/1] crypto: cavium/nitrox - Enable interrups for PF in SR-IOV mode.
On Wed, Nov 21, 2018 at 09:52:24AM +, Srikanth, Jampala wrote: > Enable the available interrupt vectors for PF in SR-IOV Mode. > Only single vector entry 192 is valid of PF. This is used to > notify any hardware errors and mailbox messages from VF(s). > > Signed-off-by: Srikanth Jampala > --- > drivers/crypto/cavium/nitrox/nitrox_dev.h | 15 +++- > drivers/crypto/cavium/nitrox/nitrox_isr.c | 84 - > drivers/crypto/cavium/nitrox/nitrox_isr.h | 2 + > drivers/crypto/cavium/nitrox/nitrox_sriov.c | 51 +++-- > 4 files changed, 142 insertions(+), 10 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v5 0/2] Add device driver for APU2/APU3 GPIOs
Hello Andy, Thank you very very much for your code review "again" I will update my patch set with your hints. Should I send v6 or should i wait till I get feedback from you about ACPI? Until now it was not possible to get more information to detect the MMIO_BASE address from the ACPI subsystem. I'm sorry if I already asked, please, remind me where dump of ACPI tables can be found? https://www.spinics.net/lists/kernel/msg2887290.html Also would be nice to have the output of `lspci -nk -vv -xxx` on such platform. 00:00.0 0600: 1022:1566 Subsystem: 1022:1566 Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Latency: 0 lspci: Unable to load libkmod resources: error -12 00: 22 10 66 15 04 00 00 00 00 00 00 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 22 10 66 15 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 80 00 00 00 00 00 00 00 50: 22 10 66 15 00 00 00 00 00 00 00 00 00 00 00 00 60: 46 00 00 00 63 10 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 80: 00 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 7f 2c 00 00 00 02 02 19 00 00 00 00 00 a0: 01 80 30 01 ef be ad de 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 04 00 10 c2 03 00 00 00 c0: 00 00 00 00 00 00 00 00 01 00 12 00 00 00 14 00 d0: b6 14 30 01 00 00 00 00 00 00 00 00 00 00 00 00 e0: 10 00 40 01 01 11 e3 80 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 80 80 00 00 00 00 00 05 00 00 00 00:02.0 0600: 1022:156b Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 00: 22 10 6b 15 00 00 00 00 00 00 00 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:02.2 0604: 1022:1439 (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin B routed to IRQ 24 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 1000-1fff [size=4K] Memory behind bridge: fe50-fe5f [size=1M] Prefetchable memory behind bridge: None Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Express (v2) Root Port (Slot+), MSI 00 DevCap: MaxPayload 512 bytes, PhantFunc 0 ExtTag+ RBE+ DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ MaxPayload 256 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #1, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <512ns, L1 <64us ClockPM- Surprise- LLActRep+ BwNot+ ASPMOptComp+ LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt- SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise- Slot #0, PowerLimit 0.000W; Interlock- NoCompl+ SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg- Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock- SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock- Changed: MRL- PresDet+ LinkState+ RootCtl: ErrCorrectable- Err
Re: [PATCH] ALSA: hda: Add support for AMD Stoney Ridge
On Thu, 29 Nov 2018 09:57:37 +0100, Kai-Heng Feng wrote: > > It's similar to other AMD audio devices, it also supports D3, which can > save some power drain. > > Signed-off-by: Kai-Heng Feng Thanks, applied now (also Cc to stable). Takashi
Re: [PATCH v2] tty: serial: qcom_geni_serial: Fix softlock
Hi Ryan,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on tty/tty-testing]
[also build test WARNING on v4.20-rc4 next-20181129]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Ryan-Case/tty-serial-qcom_geni_serial-Fix-softlock/20181129-174407
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
tty-testing
config: mips-allyesconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=mips
All warnings (new ones prefixed by >>):
In file included from include/linux/clk.h:16:0,
from drivers/tty/serial/qcom_geni_serial.c:8:
drivers/tty/serial/qcom_geni_serial.c: In function
'qcom_geni_serial_handle_tx':
include/linux/kernel.h:845:29: warning: comparison of distinct pointer types
lacks a cast
(!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
^
include/linux/kernel.h:859:4: note: in expansion of macro '__typecheck'
(__typecheck(x, y) && __no_side_effects(x, y))
^~~
include/linux/kernel.h:869:24: note: in expansion of macro '__safe_cmp'
__builtin_choose_expr(__safe_cmp(x, y), \
^~
include/linux/kernel.h:878:19: note: in expansion of macro '__careful_cmp'
#define min(x, y) __careful_cmp(x, y, <)
^
include/linux/kernel.h:893:23: note: in expansion of macro 'min'
#define min3(x, y, z) min((typeof(x))min(x, y), z)
^~~
>> drivers/tty/serial/qcom_geni_serial.c:746:10: note: in expansion of macro
>> 'min3'
chunk = min3(avail, pending, (UART_XMIT_SIZE - tail));
^~~~
vim +/min3 +746 drivers/tty/serial/qcom_geni_serial.c
714
715 static void qcom_geni_serial_handle_tx(struct uart_port *uport, bool
done,
716 bool active)
717 {
718 struct qcom_geni_serial_port *port = to_dev_port(uport, uport);
719 struct circ_buf *xmit = &uport->state->xmit;
720 size_t avail;
721 size_t remaining;
722 size_t pending;
723 int i;
724 u32 status;
725 unsigned int chunk;
726 int tail;
727
728 status = readl_relaxed(uport->membase + SE_GENI_TX_FIFO_STATUS);
729
730 /* Complete the current tx command before taking newly added
data */
731 if (active)
732 pending = port->tx_remaining;
733 else
734 pending = uart_circ_chars_pending(xmit);
735
736 /* All data has been transmitted and acknowledged as received */
737 if (!pending && !status && done) {
738 qcom_geni_serial_stop_tx(uport);
739 goto out_write_wakeup;
740 }
741
742 avail = port->tx_fifo_depth - (status & TX_FIFO_WC);
743 avail *= port->tx_bytes_pw;
744
745 tail = xmit->tail;
> 746 chunk = min3(avail, pending, (UART_XMIT_SIZE - tail));
747 if (!chunk)
748 goto out_write_wakeup;
749
750 if (!port->tx_remaining) {
751 qcom_geni_serial_setup_tx(uport, pending);
752 port->tx_remaining = pending;
753 }
754
755 remaining = chunk;
756 for (i = 0; i < chunk; ) {
757 unsigned int tx_bytes;
758 u8 buf[sizeof(u32)];
759 int c;
760
761 memset(buf, 0, ARRAY_SIZE(buf));
762 tx_bytes = min_t(size_t, remaining, port->tx_bytes_pw);
763 for (c = 0; c < tx_bytes ; c++)
764 buf[c] = xmit->buf[tail + c];
765
766 iowrite32_rep(uport->membase + SE_GENI_TX_FIFOn, buf,
1);
767
768 i += tx_bytes;
769 tail += tx_bytes;
770 uport->icount.tx += tx_bytes;
771 remaining -= tx_bytes;
772 port->tx_remaining -= tx_bytes;
773 }
774
775 xmit->tail = tail & (UART_XMIT_SIZE - 1);
776 out_write_wakeup:
777 if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
778 uart_write_wakeup(uport);
779 }
780
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH 05/16] remoteproc/pru: Add pru-specific debugfs support
On 27/11/18 00:37, David Lechner wrote: > On 11/26/18 1:52 AM, Roger Quadros wrote: >> From: Suman Anna >> >> The remoteproc core creates certain standard debugfs entries, >> that does not give a whole lot of useful information for the >> PRUs. The PRU remoteproc driver is enhanced to add additional >> debugfs entries for PRU. These will be auto-cleaned up when >> the parent rproc debug directory is removed. >> >> The enhanced debugfs support adds two new entries: 'regs' and >> 'single_step'. The 'regs' dumps out the useful CTRL sub-module >> registers as well as each of the 32 GPREGs and CT_REGs registers. >> The GPREGs and CT_REGs though are printed only when the PRU is >> halted and accessible as per the IP design. >> > > If the driver used regmap to access the CTRL I/O memory, then > 'regs' wouldn't be needed since regmap already does debugfs. > ok, we could split out CTRL from this and use regmap. cheers, -roger -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH 7/7] lib/lzo: separate lzo-rle from lzo
On 29/11/2018 4:43 am, Sergey Senozhatsky wrote:
> On (11/27/18 16:19), Dave Rodgman wrote:
>> Documentation/lzo.txt | 12 ++-
>> crypto/Makefile | 2 +-
>> crypto/lzo-rle.c | 175
>> ++
>> crypto/tcrypt.c | 4 +-
>> drivers/block/zram/zcomp.c| 1 +
>> drivers/block/zram/zram_drv.c | 2 +-
>> include/linux/lzo.h | 4 +
>> lib/lzo/lzo1x_compress.c | 42 +++---
>> lib/lzo/lzodefs.h | 3 +-
>> 9 files changed, 227 insertions(+), 18 deletions(-)
>> create mode 100644 crypto/lzo-rle.c
>
> [..]
>
>> +static struct crypto_alg alg = {
>> +.cra_name = "lzo-rle",
>> +.cra_flags = CRYPTO_ALG_TYPE_COMPRESS,
>> +.cra_ctxsize= sizeof(struct lzorle_ctx),
>> +.cra_module = THIS_MODULE,
>> +.cra_init = lzorle_init,
>> +.cra_exit = lzorle_exit,
>> +.cra_u = { .compress = {
>> +.coa_compress = lzorle_compress,
>> +.coa_decompress = lzorle_decompress } }
>> +};
>
> A nitpick:
>indentation for .compress assignment is a bit confusing, maybe.
Agreed - I've copied this directly from crypto/lzo.c though, so I
retained the same style. Cleanup could be a separate patch.
> [..]
>> +++ b/drivers/block/zram/zcomp.c
>> @@ -20,6 +20,7 @@
>>
>> static const char * const backends[] = {
>> "lzo",
>> +"lzo-rle",
>> #if IS_ENABLED(CONFIG_CRYPTO_LZ4)
>> "lz4",
>> #endif
>
> [..]
>
>> +++ b/drivers/block/zram/zram_drv.c
>> @@ -41,7 +41,7 @@ static DEFINE_IDR(zram_index_idr);
>> static DEFINE_MUTEX(zram_index_mutex);
>>
>> static int zram_major;
>> -static const char *default_compressor = "lzo";
>> +static const char *default_compressor = "lzo-rle";
>
> OK, so it's not just "separate lzo-rle", it's also "switch zram to
> a new compression algorithm by default". I'd say that usually I'd
> expect this to be separate patches.
Yes, fair point. akpm has picked this up now though, so probably a bit
late to break it out into a separate patch?
Dave
[GIT PULL] sound fixes for 4.20-rc5
Linus, please pull sound fixes for v4.20-rc5 from: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git tags/sound-4.20-rc5 The topmost commit is 8159a6a4a7d2a092d5375f695ecfca22b4562b5f sound fixes for 4.20-rc5 As a usual pattern, we've got relatively large updates at rc5. - A fix for races in ALSA control user elements - ASoC DAPM regression due to component refactoring - A fix in error handling of ASoC iteration macro - ASoC Intel SST Skylake kconfig fix; a new Kconfig will appear as a consequence, but in the end it's a good cleanup - HD-audio and USB-audio quirks as always - Assort of ASoC driver fixes (pcm186x, Intel cht, rockchip, pcm3060, rsnd, omap, wm_adsp, qcom, sunxi, stm32) Andreas Dannenberg (1): ASoC: pcm186x: Fix device reset-registers trigger value Anisse Astier (1): ALSA: hda/realtek - fix headset mic detection for MSI MS-B171 Clément Péron (1): MAINTAINERS: add ASoC maintainers for sound dt-bindings Girija Kumar Kasinadhuni (1): ALSA: hda/realtek - Add auto-mute quirk for HP Spectre x360 laptop Hans de Goede (2): ASoC: intel: cht_bsw_max98090_ti: Add quirk for boards using pmc_plt_clk_0 ALSA: hda: Add ASRock N68C-S UCC the power_save blacklist Hui Wang (2): ALSA: hda/realtek - fix the pop noise on headphone for lenovo laptops ALSA: usb-audio: Add vendor and product name for Dell WD19 Dock Kailang Yang (1): ALSA: hda/realtek - Support ALC300 Katsuhiro Suzuki (1): ASoC: rockchip: add missing slave_config setting for I2S Keyon Jie (1): ASoC: acpi: fix: continue searching when machine is ignored Kirill Marinushkin (1): ASoC: pcm3060: Rename output widgets Kuninori Morimoto (1): ASoC: rsnd: fixup clock start checker Peter Ujfalusi (4): ASoC: omap-abe-twl6040: Fix missing audio card caused by deferred probing ASoC: omap-mcbsp: Fix latency value calculation for pm_qos ASoC: omap-mcpdm: Add pm_qos handling to avoid under/overruns with CPU_IDLE ASoC: omap-dmic: Add pm_qos handling to avoid overruns with CPU_IDLE Pierre-Louis Bossart (3): ASoC: fix oops w/ for_each_rtd_codec_dai_rollback() macro ASoC: Intel: Power down links before turning off display audio power ASoC: Intel: Skylake: fix Kconfigs, make HDaudio codec optional Richard Fitzgerald (1): ASoC: wm_adsp: Fix dma-unsafe read of scratch registers Rohit kumar (2): ASoC: qdsp6: q6afe: Fix wrong MI2S SD line mask ASoC: qcom: Set dai_link id to each dai_link Srinivas Kandagatla (2): ASoC: qdsp6: q6asm-dai: Only add routing once. ASoC: qdsp6: q6afe-dai: Fix the dai widgets Takashi Iwai (4): ALSA: ac97: Fix incorrect bit shift at AC97-SPSA control write ALSA: wss: Fix invalid snd_free_pages() at error path ALSA: sparc: Fix invalid snd_free_pages() at error path ALSA: control: Fix race between adding and removing a user element Tzung-Bi Shih (1): ASoC: dapm: Recalculate audio map forcely when card instantiated Vasily Khoruzhick (3): ASoC: sunxi: rename SND_SUNXI_ADDA_PR_REGMAP to SND_SUN8I_ADDA_PR_REGMAP ASoC: sun8i-codec: fix crash on module removal ASoC: sun8i-codec: add missing route for ADC kbuild test robot (1): ASoC: stm32: sai: fix noderef.cocci warnings --- MAINTAINERS | 1 + include/sound/soc.h | 2 +- sound/core/control.c | 80 ++- sound/isa/wss/wss_lib.c | 2 - sound/pci/ac97/ac97_codec.c | 2 +- sound/pci/hda/hda_intel.c| 2 + sound/pci/hda/patch_realtek.c| 36 + sound/soc/codecs/hdac_hdmi.c | 11 +- sound/soc/codecs/pcm186x.h | 2 +- sound/soc/codecs/pcm3060.c | 12 +- sound/soc/codecs/wm_adsp.c | 37 ++--- sound/soc/intel/Kconfig | 26 +++- sound/soc/intel/boards/Kconfig | 24 ++-- sound/soc/intel/boards/cht_bsw_max98090_ti.c | 32 - sound/soc/intel/skylake/skl.c| 32 +++-- sound/soc/omap/omap-abe-twl6040.c| 67 - sound/soc/omap/omap-dmic.c | 9 ++ sound/soc/omap/omap-mcbsp.c | 6 +- sound/soc/omap/omap-mcpdm.c | 43 +- sound/soc/qcom/common.c | 9 +- sound/soc/qcom/qdsp6/q6afe-dai.c | 208 +-- sound/soc/qcom/qdsp6/q6afe.c | 16 +-- sound/soc/qcom/qdsp6/q6asm-dai.c | 33 - sound/soc/qcom/qdsp6/q6routing.c | 19 +++ sound/soc/rockchip/rockchip_pcm.c| 1 + sound/soc/sh/rcar/ssi.c | 2 +- sound/soc/soc-acpi.c |
Re: [PATCH 0/8] HID: MS and Logitech high-resolution scroll wheel support
On Thu, Nov 29, 2018 at 5:27 AM Peter Hutterer wrote: > > On Wed, Nov 28, 2018 at 03:22:14PM -0800, Harry Cutts wrote: > > On Wed, 21 Nov 2018 at 22:34, Peter Hutterer > > wrote: > > > [snip] > > > Devices tested: > > > - Microsoft Comfort Optical Mouse 3000 > > > - Microsoft Sculpt Ergonomic Mouse > > > - Microsoft Surface mouse > > > - Logitech MX Anywhere 2S > > > > > > The following devices were tested for the HID feature and didn't have it: > > > - Logitech G500s, G303 > > > - Roccat Kone XTD > > > - all the cheap Lenovo, HP, Dell, Logitech USB mice that come with a > > > workstation that I could find in the local office > > > - Etekcity something something > > > - Razer Imperator > > > - Microsoft Classic IntelliMouse > > > - Microsoft Surface Mobile Mouse > > > > I just tested the patches with the Microsoft Comfort Optical Mouse > > 3000. I also tested with the Microsoft Surface Precision mouse [0], > > and like the Surface Mobile mouse it didn't seem to report the HID > > feature (at least, it was only reporting REL_WHEEL_HI_RES changes of > > 120 in evtest). > > IIRC that's the same mouse benjamin has and it does have the HID feature, it > just ends up reporting the same number of clicks anyway so there's no > visible effect. Which in itself is a good sign for the patch series, I > guess ;) > > > For the series: > > Acked-by: Harry Cutts > > Verified-by: Harry Cutts > > thanks, much appreciated. Thanks everyone. Just a small note that there is a mess up in Peter's series that he is already aware of: patch 6/8 depends on 8/8 so there is either a small refactoring to do or change the order of the patches. I also have asked Peter to look for regression tests in hid-tools[0] before I can merge this. FWIW, I am putting together a CI system that will run this test suite for every submitted patch (plus a few other tests). But the test suite simply lacks basic wheel testing, so it's hard to see regressions :) I should be able to apply the series in the next following days or next week I think. Cheers, Benjamin [0] https://gitlab.freedesktop.org/libevdev/hid-tools/
Re: [PATCH 2/3] phy: sr-usb: Add stingray usb phy driver
Hi,
On 13/11/18 9:43 AM, Srinath Mannam wrote:
> This driver supports all versions of stingray SS and HS
> USB phys.
> In version 1 is combo phy contain both SS and HS phys
> in a common IO space.
> In version 2 a single HS phy.
> These phys support both xHCI host driver and
> BDC Broadcom device controller driver.
>
> Signed-off-by: Srinath Mannam
> Reviewed-by: Florian Fainelli
> Reviewed-by: Scott Branden
> ---
> drivers/phy/broadcom/Kconfig | 11 +
> drivers/phy/broadcom/Makefile | 1 +
> drivers/phy/broadcom/phy-bcm-sr-usb.c | 367
> ++
> 3 files changed, 379 insertions(+)
> create mode 100644 drivers/phy/broadcom/phy-bcm-sr-usb.c
>
> diff --git a/drivers/phy/broadcom/Kconfig b/drivers/phy/broadcom/Kconfig
> index 8786a96..c1e4dd5 100644
> --- a/drivers/phy/broadcom/Kconfig
> +++ b/drivers/phy/broadcom/Kconfig
> @@ -10,6 +10,17 @@ config PHY_CYGNUS_PCIE
> Enable this to support the Broadcom Cygnus PCIe PHY.
> If unsure, say N.
>
> +config PHY_BCM_SR_USB
> + tristate "Broadcom Stingray USB PHY driver"
> + depends on OF && (ARCH_BCM_IPROC || COMPILE_TEST)
> + select GENERIC_PHY
> + default ARCH_BCM_IPROC
> + help
> + Enable this to support the Broadcom Stingray USB PHY
> + driver. It supports all versions of Superspeed and
> + Highspeed PHYs.
> + If unsure, say N.
> +
> config BCM_KONA_USB2_PHY
> tristate "Broadcom Kona USB2 PHY Driver"
> depends on HAS_IOMEM
> diff --git a/drivers/phy/broadcom/Makefile b/drivers/phy/broadcom/Makefile
> index 0f60184..f453c7d 100644
> --- a/drivers/phy/broadcom/Makefile
> +++ b/drivers/phy/broadcom/Makefile
> @@ -11,3 +11,4 @@ obj-$(CONFIG_PHY_BRCM_USB) += phy-brcm-usb-dvr.o
> phy-brcm-usb-dvr-objs := phy-brcm-usb.o phy-brcm-usb-init.o
>
> obj-$(CONFIG_PHY_BCM_SR_PCIE)+= phy-bcm-sr-pcie.o
> +obj-$(CONFIG_PHY_BCM_SR_USB) += phy-bcm-sr-usb.o
> diff --git a/drivers/phy/broadcom/phy-bcm-sr-usb.c
> b/drivers/phy/broadcom/phy-bcm-sr-usb.c
> new file mode 100644
> index 000..99de49f
> --- /dev/null
> +++ b/drivers/phy/broadcom/phy-bcm-sr-usb.c
> @@ -0,0 +1,367 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2016-2018 Broadcom
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +enum bcm_usb_phy_version {
> + BCM_USB_PHY_V1,
> + BCM_USB_PHY_V2,
> +};
> +
> +enum bcm_usb_phy_reg {
> + PLL_NDIV_FRAC,
> + PLL_NDIV_INT,
> + PLL_CTRL,
> + PHY_CTRL,
> + PHY_PLL_CTRL,
> +};
> +
> +/* USB PHY registers */
> +
> +static const u8 bcm_usb_u3phy_v1[] = {
> + [PLL_CTRL] = 0x18,
> + [PHY_CTRL] = 0x14,
> +};
> +
> +static const u8 bcm_usb_u2phy_v1[] = {
> + [PLL_NDIV_FRAC] = 0x04,
> + [PLL_NDIV_INT] = 0x08,
> + [PLL_CTRL] = 0x0c,
> + [PHY_CTRL] = 0x10,
> +};
> +
> +#define HSPLL_NDIV_INT_VAL 0x13
> +#define HSPLL_NDIV_FRAC_VAL 0x1005
> +
> +static const u8 bcm_usb_u2phy_v2[] = {
> + [PLL_NDIV_FRAC] = 0x0,
> + [PLL_NDIV_INT] = 0x4,
> + [PLL_CTRL] = 0x8,
> + [PHY_CTRL] = 0xc,
> +};
> +
> +enum pll_ctrl_bits {
> + PLL_RESETB,
> + SSPLL_SUSPEND_EN,
> + PLL_SEQ_START,
> + PLL_LOCK,
> + PLL_PDIV,
> +};
> +
> +static const u8 u3pll_ctrl[] = {
> + [PLL_RESETB]= 0,
> + [SSPLL_SUSPEND_EN] = 1,
> + [PLL_SEQ_START] = 2,
> + [PLL_LOCK] = 3,
> +};
> +
> +#define HSPLL_PDIV_MASK 0xF
> +#define HSPLL_PDIV_VAL 0x1
> +
> +static const u8 u2pll_ctrl[] = {
> + [PLL_PDIV] = 1,
> + [PLL_RESETB]= 5,
> + [PLL_LOCK] = 6,
> +};
> +
> +enum bcm_usb_phy_ctrl_bits {
> + CORERDY,
> + AFE_LDO_PWRDWNB,
> + AFE_PLL_PWRDWNB,
> + AFE_BG_PWRDWNB,
> + PHY_ISO,
> + PHY_RESETB,
> + PHY_PCTL,
> +};
> +
> +#define PHY_PCTL_MASK0x
> +/*
> + * 0x0806 of PCTL_VAL has below bits set
> + * BIT-8 : refclk divider 1
> + * BIT-3:2: device mode; mode is not effect
> + * BIT-1: soft reset active low
> + */
> +#define HSPHY_PCTL_VAL 0x0806
> +#define SSPHY_PCTL_VAL 0x0006
> +
> +static const u8 u3phy_ctrl[] = {
> + [PHY_RESETB]= 1,
> + [PHY_PCTL] = 2,
> +};
> +
> +static const u8 u2phy_ctrl[] = {
> + [CORERDY] = 0,
> + [AFE_LDO_PWRDWNB] = 1,
> + [AFE_PLL_PWRDWNB] = 2,
> + [AFE_BG_PWRDWNB]= 3,
> + [PHY_ISO] = 4,
> + [PHY_RESETB]= 5,
> + [PHY_PCTL] = 6,
> +};
> +
> +struct bcm_usb_phy_cfg {
> + uint32_t type;
> + uint32_t ver;
> + void __iomem *regs;
> + struct phy *phy;
> + const u8 *offset;
> +};
> +
> +#define PLL_LOCK_RETRY_COUNT 1000
> +
> +enum bcm_usb_phy_type {
> + USB_HS_PHY,
> + USB_SS_PHY,
> +};
> +
> +static inline void bcm_usb_reg32_clrbits(void __iomem *addr,
Dear Urgent Respond,
Sorry to have contacted you through this medium without a previous notice; I had to use the email because it is the easiest and more confidential way of making contact with people around the world. This communication is to inform you that we have programmed your payment of the $10,000.000.00 USD to be received by you in person , you are further not expected to pay a dime for the receiving of your funds and anybody who asks you to pay money must be lying to you. We have worked out all the modality for you to receive your funds without any further lapses. The $10,000.000.00 USD funds is currently in our corresponding vault in Holland now, and for security purpose we have to moved the documentation to our corresponding vault in South America where you need to come in person to sign your transfer legalization paper work. We have further arranged to pay your flight cost and hotel reservation for the trip, so that as soon as your funds are received by you then you can reimburse me of all the expenses that i made for your trip to South America where the legalization materials will be sign and giving to you in person to bring along to the paying Bank in Holland. You should also note that the mode of sharing ratio is 60% for you and 30% for me while I will take 10% for all expenses. Thank you for your cooperation and understanding as I look forward to helping you receive your funds without any hitches. Expect your valued response. Regards Mr David Cooper
Re: [PATCH 4.14] kbuild: allow to use GCC toolchain not in Clang search path
On Wed, Nov 28, 2018 at 10:35:12PM -0700, Nathan Chancellor wrote: > From: Stefan Agner > > commit ef8c4ed9db80261f397f0c0bf723684601ae3b52 upstream. > > When using a GCC cross toolchain which is not in a compiled in > Clang search path, Clang reverts to the system assembler and > linker. This leads to assembler or linker errors, depending on > which tool is first used for a given architecture. > > It seems that Clang is not searching $PATH for a matching > assembler or linker. > > Make sure that Clang picks up the correct assembler or linker by > passing the cross compilers bin directory as search path. > > This allows to use Clang provided by distributions with GCC > toolchains not in /usr/bin. > > Link: https://github.com/ClangBuiltLinux/linux/issues/78 > Signed-off-by: Stefan Agner > Reviewed-and-tested-by: Nick Desaulniers > Signed-off-by: Masahiro Yamada > [nc: Adjust context] > Signed-off-by: Nathan Chancellor > --- > Makefile | 8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) We also need this for 4.9, right? thanks, greg k-h
[PATCH 1/2] regulator: Factor out location of init data OF node
To support future additions factor out the location of the OF node
containing the init data for the regulator from the code that parses the
init data.
Signed-off-by: Charles Keepax
---
drivers/regulator/of_regulator.c | 64 +++-
1 file changed, 37 insertions(+), 27 deletions(-)
diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index c711a0a2bc4b..4bb8928bdb3f 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -371,13 +371,10 @@ int of_regulator_match(struct device *dev, struct
device_node *node,
}
EXPORT_SYMBOL_GPL(of_regulator_match);
-struct regulator_init_data *regulator_of_get_init_data(struct device *dev,
- const struct regulator_desc *desc,
- struct regulator_config *config,
- struct device_node **node)
+struct device_node *regulator_of_get_init_node(struct device *dev,
+ const struct regulator_desc
*desc)
{
struct device_node *search, *child;
- struct regulator_init_data *init_data = NULL;
const char *name;
if (!dev->of_node || !desc->of_match)
@@ -400,35 +397,48 @@ struct regulator_init_data
*regulator_of_get_init_data(struct device *dev,
if (!name)
name = child->name;
- if (strcmp(desc->of_match, name))
- continue;
+ if (!strcmp(desc->of_match, name))
+ return of_node_get(child);
+ }
- init_data = of_get_regulator_init_data(dev, child, desc);
- if (!init_data) {
- dev_err(dev,
- "failed to parse DT for regulator %pOFn\n",
- child);
- break;
- }
+ of_node_put(search);
- if (desc->of_parse_cb) {
- if (desc->of_parse_cb(child, desc, config)) {
- dev_err(dev,
- "driver callback failed to parse DT for
regulator %pOFn\n",
- child);
- init_data = NULL;
- break;
- }
- }
+ return NULL;
+}
- of_node_get(child);
- *node = child;
- break;
+struct regulator_init_data *regulator_of_get_init_data(struct device *dev,
+ const struct regulator_desc *desc,
+ struct regulator_config *config,
+ struct device_node **node)
+{
+ struct device_node *child;
+ struct regulator_init_data *init_data = NULL;
+
+ child = regulator_of_get_init_node(dev, desc);
+ if (!child)
+ return NULL;
+
+ init_data = of_get_regulator_init_data(dev, child, desc);
+ if (!init_data) {
+ dev_err(dev, "failed to parse DT for regulator %pOFn\n", child);
+ goto error;
}
- of_node_put(search);
+ if (desc->of_parse_cb && desc->of_parse_cb(child, desc, config)) {
+ dev_err(dev,
+ "driver callback failed to parse DT for regulator
%pOFn\n",
+ child);
+ goto error;
+ }
+
+ *node = child;
return init_data;
+
+error:
+ of_node_put(child);
+
+ return NULL;
}
static int of_node_match(struct device *dev, const void *data)
--
2.11.0
[PATCH 2/2] regulator: Allow regulator nodes to contain their own init data
Currently it is expected that regulator init data will be defined as a
series of sub-nodes from the node that bound in the driver. Add support
for a node to both bind in a driver and contain init data for that
regulator.
Signed-off-by: Charles Keepax
---
drivers/regulator/of_regulator.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index 4bb8928bdb3f..ffa5fc3724e4 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -380,12 +380,16 @@ struct device_node *regulator_of_get_init_node(struct
device *dev,
if (!dev->of_node || !desc->of_match)
return NULL;
- if (desc->regulators_node)
+ if (desc->regulators_node) {
search = of_get_child_by_name(dev->of_node,
desc->regulators_node);
- else
+ } else {
search = of_node_get(dev->of_node);
+ if (!strcmp(desc->of_match, search->name))
+ return search;
+ }
+
if (!search) {
dev_dbg(dev, "Failed to find regulator container node '%s'\n",
desc->regulators_node);
--
2.11.0
[PATCH 0/2] Allow regulator nodes to hold their own init data
Unfortunately due to a rather large testing oversight on my
part the recently merged Lochnagar regulator binding does not
actually work. The binding looks like this:
lochnagar {
compatible = "cirrus,lochnagar1";
...
lochnagar-micvdd: MICVDD {
compatible = "cirrus,lochnagar2-micvdd";
SYSVDD-supply = <&wallvdd>;
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
};
lochnagar-vddcore: VDDCORE {
compatible = "cirrus,lochnagar2-vddcore";
SYSVDD-supply = <&wallvdd>;
regulator-min-microvolt = <120>;
regulator-max-microvolt = <120>;
};
};
The trouble is that each regulator node individually binds
in a driver and contains the init data. The regulator core
appears to require the init data to be a sub-node of the node
that bound in the regulator driver. As the above binding seems
reasonable I opted to try and update the core to support the
current binding, although as the rest of the Lochnagar driver
isn't merged yet we could still update the binding if that comes
out of the review as a preferred option. Apologies for missing
such a glaring issue in my testing.
Thanks,
Charles
Charles Keepax (2):
regulator: Factor out location of init data OF node
regulator: Allow regulator nodes to contain their own init data
drivers/regulator/of_regulator.c | 72
1 file changed, 43 insertions(+), 29 deletions(-)
--
2.11.0
My Humble Request
Dear Friend, I am Abel Brent, a NATO soldier serving in Afghanistan. I and my Comrades, we are seeking your assistance to help us receive/invest our funds in your country in any lucrative business. Please if this proposal is acceptable by you, kindly respond back to me for more details. Thanks and waiting to hear from you. Abel.
Re: [PATCH 01/16] remoteproc: Extend rproc_da_to_va() API with a flags parameter
Bjorn, Suman, On 26/11/18 23:29, David Lechner wrote: > On 11/26/18 1:52 AM, Roger Quadros wrote: >> From: Suman Anna >> >> The rproc_da_to_va() API is currently used to perform any device >> to kernel address translations to meet the different needs of the >> remoteproc core/platform drivers (eg: loading). The function also >> invokes the da_to_va ops, if present, to allow the remoteproc >> platform drivers to provide address translation. However, not all >> platform implementations have linear address spaces, and may need >> an additional parameter to be able to perform proper translations. >> >> The rproc_da_to_va() API and the rproc .da_to_va ops have therefore >> been expanded to take in an additional flags field enabling some >> remoteproc implementations (like the TI PRUSS remoteproc driver) >> to use these flags. Also, define some semantics for this flags >> argument as this can vary from one implementation to another. A >> new flags type is encoded into the upper 16 bits along side the >> actual value in the lower 16-bits for the flags argument, to >> allow different individual implementations to have better >> flexibility in interpreting the flags as per their needs. > > This seems like an overly complex solution for a rather simple > problem. Instead of passing all sorts of flags, could we just add > a parameter named "page" to da_to_va() that indicates the memory > page of the address in the remote processor? > > Or perhaps there is some other use for all of these flags that I > am not aware of? I'm not a big fan of this patch either. rproc_da_to_va() is used at the following places 2 qcom_q6v5_mss.c qcom_q6v5_dump_segment 974 void *ptr = rproc_da_to_va(rproc, segment->da, segment->size, 3 remoteproc_core.c rproc_da_to_va 197 void *rproc_da_to_va(struct rproc *rproc, u64 da, int len, u32 flags) 4 remoteproc_core.c rproc_handle_trace 582 ptr = rproc_da_to_va(rproc, rsc->da, rsc->len, RPROC_FLAGS_NONE); 5 remoteproc_core.c rproc_coredump 1592 ptr = rproc_da_to_va(rproc, segment->da, segment->size, 6 remoteproc_elf_loader.c rproc_elf_load_segments 185 ptr = rproc_da_to_va(rproc, da, memsz, 7 remoteproc_elf_loader.c rproc_elf_find_loaded_rsc_table 337 return rproc_da_to_va(rproc, shdr->sh_addr, shdr->sh_size, At rproc_elf_load_segments() we need to pass enough information so that the rproc driver can load the segment into proper area (IRAM vs DRAM). So providing page should suffice. I want to understand more about rproc_elf_find_loaded_rsc_table() myself. rproc_elf_find_loaded_rsc_table() is called only in rproc_start() in remoteproc_core.c with the comment /* * The starting device has been given the rproc->cached_table as the * resource table. The address of the vring along with the other * allocated resources (carveouts etc) is stored in cached_table. * In order to pass this information to the remote device we must copy * this information to device memory. We also update the table_ptr so * that any subsequent changes will be applied to the loaded version. */ loaded_table = rproc_find_loaded_rsc_table(rproc, fw); Why isn't cached_table sufficient? Why do we need to call rproc_find_loaded_rsc_table()? why do we need to load the resource table into remote processor memory at all. As discussed earlier, some PRU systems have very little memory (512 bytes?) and we want to avoid unnecessary loading. cheers, -roger -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH] perf test: fix spelling mistake "sythesizing" -> "synthesizing"
From: Colin Ian King
There are spelling mistakes in TEST_ASSERT_VAL messages, fix them.
Signed-off-by: Colin Ian King
---
tools/perf/tests/mmap-thread-lookup.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/tests/mmap-thread-lookup.c
b/tools/perf/tests/mmap-thread-lookup.c
index b1af2499a3c9..e8498d3e0176 100644
--- a/tools/perf/tests/mmap-thread-lookup.c
+++ b/tools/perf/tests/mmap-thread-lookup.c
@@ -224,11 +224,11 @@ static int mmap_events(synth_cb synth)
int test__mmap_thread_lookup(struct test *test __maybe_unused, int subtest
__maybe_unused)
{
/* perf_event__synthesize_threads synthesize */
- TEST_ASSERT_VAL("failed with sythesizing all",
+ TEST_ASSERT_VAL("failed with synthesizing all",
!mmap_events(synth_all));
/* perf_event__synthesize_thread_map synthesize */
- TEST_ASSERT_VAL("failed with sythesizing process",
+ TEST_ASSERT_VAL("failed with synthesizing process",
!mmap_events(synth_process));
return 0;
--
2.19.1
Re: [PATCH 4.14 117/126] net: sk_buff rbnode reorg
On Thu, Oct 04, 2018 at 03:13:56PM -0500, Mitch Harder wrote:
> On Mon, Sep 17, 2018 at 5:42 PM, Greg Kroah-Hartman
> wrote:
> > 4.14-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Eric Dumazet
> >
> > commit bffa72cf7f9df842f0016ba03586039296b4caaf upstream
> >
> > skb->rbnode shares space with skb->next, skb->prev and skb->tstamp
> >
> > Current uses (TCP receive ofo queue and netem) need to save/restore
> > tstamp, while skb->dev is either NULL (TCP) or a constant for a given
> > queue (netem).
> >
> > Since we plan using an RB tree for TCP retransmit queue to speedup SACK
> > processing with large BDP, this patch exchanges skb->dev and
> > skb->tstamp.
> >
> > This saves some overhead in both TCP and netem.
> >
> > v2: removes the swtstamp field from struct tcp_skb_cb
> >
> > Signed-off-by: Eric Dumazet
> > Cc: Soheil Hassas Yeganeh
> > Cc: Wei Wang
> > Cc: Willem de Bruijn
> > Acked-by: Soheil Hassas Yeganeh
> > Signed-off-by: David S. Miller
> > Signed-off-by: Greg Kroah-Hartman
> > ---
> > include/linux/skbuff.h | 24 ++--
> > include/net/inet_frag.h |3
> > net/ipv4/inet_fragment.c| 14 +-
> > net/ipv4/ip_fragment.c | 182
> > +---
> > net/ipv6/netfilter/nf_conntrack_reasm.c |1
> > net/ipv6/reassembly.c |1
> > 6 files changed, 128 insertions(+), 97 deletions(-)
> >
> > --- a/include/linux/skbuff.h
> > +++ b/include/linux/skbuff.h
> > @@ -663,23 +663,27 @@ struct sk_buff {
> > struct sk_buff *prev;
> >
> > union {
> > - ktime_t tstamp;
> > - u64 skb_mstamp;
> > + struct net_device *dev;
> > + /* Some protocols might use this space to
> > store information,
> > +* while device pointer would be NULL.
> > +* UDP receive path is one user.
> > +*/
> > + unsigned long dev_scratch;
> > };
> > };
> > - struct rb_node rbnode; /* used in netem & tcp stack */
> > + struct rb_node rbnode; /* used in netem, ip4
> > defrag, and tcp stack */
> > + struct list_headlist;
> > };
> > - struct sock *sk;
> >
> > union {
> > - struct net_device *dev;
> > - /* Some protocols might use this space to store information,
> > -* while device pointer would be NULL.
> > -* UDP receive path is one user.
> > -*/
> > - unsigned long dev_scratch;
> > + struct sock *sk;
> > int ip_defrag_offset;
> > };
> > +
> > + union {
> > + ktime_t tstamp;
> > + u64 skb_mstamp;
> > + };
> > /*
> > * This is the control buffer. It is free to use for every
> > * layer. Please put your private variables there. If you
> > --- a/include/net/inet_frag.h
> > +++ b/include/net/inet_frag.h
> > @@ -75,7 +75,8 @@ struct inet_frag_queue {
> > struct timer_list timer;
> > spinlock_t lock;
> > refcount_t refcnt;
> > - struct sk_buff *fragments;
> > + struct sk_buff *fragments; /* Used in IPv6. */
> > + struct rb_root rb_fragments; /* Used in IPv4. */
> > struct sk_buff *fragments_tail;
> > ktime_t stamp;
> > int len;
> > --- a/net/ipv4/inet_fragment.c
> > +++ b/net/ipv4/inet_fragment.c
> > @@ -136,12 +136,16 @@ void inet_frag_destroy(struct inet_frag_
> > fp = q->fragments;
> > nf = q->net;
> > f = nf->f;
> > - while (fp) {
> > - struct sk_buff *xp = fp->next;
> > + if (fp) {
> > + do {
> > + struct sk_buff *xp = fp->next;
> >
> > - sum_truesize += fp->truesize;
> > - kfree_skb(fp);
> > - fp = xp;
> > + sum_truesize += fp->truesize;
> > + kfree_skb(fp);
> > + fp = xp;
> > + } while (fp);
> > + } else {
> > + sum_truesize = skb_rbtree_purge(&q->rb_fragments);
> > }
> > sum = sum_truesize + f->qsize;
> >
> > --- a/net/ipv4/ip_fragment.c
> > +++ b/net/ipv4/ip_fragment.c
> > @@ -136,7 +136,7 @@ static void ip_expire(struct timer_list
> > {
> > struct inet_frag_queue *frag = from_timer(frag, t, timer);
> > const st
Re: [PATCH v4 1/2] ptrace: save the type of syscall-stop in ptrace_message
On Wed, Nov 28, 2018 at 03:17:49PM -0800, Andy Lutomirski wrote:
> On Wed, Nov 28, 2018 at 2:11 PM Dmitry V. Levin wrote:
> >
> > On Wed, Nov 28, 2018 at 06:23:46PM +0300, Dmitry V. Levin wrote:
> > > On Wed, Nov 28, 2018 at 03:20:06PM +0100, Oleg Nesterov wrote:
> > > > On 11/28, Dmitry V. Levin wrote:
> > > > > On Wed, Nov 28, 2018 at 02:49:14PM +0100, Oleg Nesterov wrote:
> > > > > > On 11/28, Dmitry V. Levin wrote:
> > > > > > >
> > > > > > > +/*
> > > > > > > + * These values are stored in task->ptrace_message by
> > > > > > > tracehook_report_syscall_*
> > > > > > > + * to describe current syscall-stop.
> > > > > > > + *
> > > > > > > + * Values for these constants are chosen so that they do not
> > > > > > > appear
> > > > > > > + * in task->ptrace_message by other means.
> > > > > > > + */
> > > > > > > +#define PTRACE_EVENTMSG_SYSCALL_ENTRY0x8000U
> > > > > > > +#define PTRACE_EVENTMSG_SYSCALL_EXIT 0x9000U
> > > > > >
> > > > > > Again, I do not really understand the comment... Why should we care
> > > > > > about
> > > > > > "do not appear in task->ptrace_message by other means" ?
> > > > > >
> > > > > > 2/2 should detect ptrace_report_syscall() case correctly, so we can
> > > > > > use any
> > > > > > numbers, say, 1 and 2?
> > > > > >
> > > > > > If debugger does PTRACE_GETEVENTMSG it should know how to interpet
> > > > > > the value
> > > > > > anyway after wait(status).
> > > > >
> > > > > Given that without this patch the value returned by PTRACE_GETEVENTMSG
> > > > > during syscall stop is undefined, we need two different ptrace_message
> > > > > values that cannot be set by other ptrace events to enable reliable
> > > > > identification of syscall-enter-stop and syscall-exit-stop in
> > > > > userspace:
> > > > > if we make PTRACE_GETEVENTMSG return 0 or any other value routinely
> > > > > set by
> > > > > other ptrace events, it would be hard for userspace to find out
> > > > > whether
> > > > > the kernel implements new semantics or not.
> > > >
> > > > Hmm, why? Debugger can just do ptrace(PTRACE_GET_SYSCALL_INFO, NULL),
> > > > if it
> > > > returns EIO then it is not implemented?
> > >
> > > The debugger that uses PTRACE_GET_SYSCALL_INFO does not need to call
> > > PTRACE_GETEVENTMSG for syscall stops.
> > > My concern here is the PTRACE_GETEVENTMSG interface itself. If we use
> > > ptrace_message to implement PTRACE_GET_SYSCALL_INFO and expose
> > > PTRACE_EVENTMSG_SYSCALL_{ENTRY,EXIT} for regular PTRACE_GETEVENTMSG users,
> > > it should have clear semantics.
> >
> > Since our implementation of PTRACE_GET_SYSCALL_INFO uses ptrace_message
> > to distinguish syscall-enter-stop from syscall-exit-stop, we could choose
> > one of the following approaches:
> >
> > 1. Do not document the values saved into ptrace_message during syscall
> > stops (and exposed via PTRACE_GETEVENTMSG) as a part of ptrace API,
> > leaving the value returned by PTRACE_GETEVENTMSG during syscall stops
> > as undefined.
> >
> > 2. Document these values chosen to avoid collisions with ptrace_message
> > values
> > set by other ptrace events so that PTRACE_GETEVENTMSG users can easily tell
> > whether this new semantics is supported by the kernel or not.
>
> I don't like any of this at all. Can we please choose a sensible API
> design and let the API drive the implementation instead of vice versa?
What are your concerns? Do you see something wrong in exposing this
information via PTRACE_GETEVENTMSG?
Anyway, can we agree on the PTRACE_GET_SYSCALL_INFO API, please?
> ISTM the correct solution is to add some new state to task_struct for
> this.
>
> If we're concerned about making task_struct bigger, I have a
> half-finished patch to factor all the ptrace tracee state into a
> separate struct.
This is refactoring of the kernel - a thing userspace people are not
the best equipped to do. This part should rather be sorted out by kernel
people.
--
ldv
signature.asc
Description: PGP signature
Re: [PATCH 20/27] locking/lockdep: Free lock classes that are no longer in use
On Wed, Nov 28, 2018 at 03:43:18PM -0800, Bart Van Assche wrote:
> +/* Must be called with the graph lock held. */
> +static void remove_class_from_lock_chain(struct lock_chain *chain,
> + struct lock_class *class)
> +{
> + u64 chain_key;
> + int i;
> +
> + for (i = chain->base; i < chain->base + chain->depth; i++) {
> + if (chain_hlocks[i] != class - lock_classes)
> + continue;
> + if (--chain->depth == 0)
> + break;
> + memmove(&chain_hlocks[i], &chain_hlocks[i + 1],
> + (chain->base + chain->depth - i) *
> + sizeof(chain_hlocks[0]));
> + /*
> + * Each lock class occurs at most once in a
> + * lock chain so once we found a match we can
> + * break out of this loop.
> + */
> + break;
> + }
> + /*
> + * Note: calling hlist_del_rcu() from inside a
> + * hlist_for_each_entry_rcu() loop is safe.
> + */
> + if (chain->depth == 0) {
> + /* To do: decrease chain count. See also inc_chains(). */
> + hlist_del_rcu(&chain->entry);
> + return;
> + }
> + chain_key = 0;
> + for (i = chain->base; i < chain->base + chain->depth; i++)
> + chain_key = iterate_chain_key(chain_key, chain_hlocks[i] + 1);
> + if (chain->chain_key == chain_key)
> + return;
> + hlist_del_rcu(&chain->entry);
> + chain->chain_key = chain_key;
> + hlist_add_head_rcu(&chain->entry, chainhashentry(chain_key));
> +}
> +
> +/* Must be called with the graph lock held. */
> +static void remove_class_from_lock_chains(struct lock_class *class)
> +{
> + struct lock_chain *chain;
> + struct hlist_head *head;
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(chainhash_table); i++) {
> + head = chainhash_table + i;
> + hlist_for_each_entry_rcu(chain, head, entry) {
> + remove_class_from_lock_chain(chain, class);
> + }
> + }
> +}
*shudder*, I suppose that is the reason I never went there.
I suoppose that if you don't do this too often it doesn't matter it is
horribly epxneisve.
Re: [PATCH V3 1/3] mmc: sdhci: add support for using external DMA devices
On 29/11/18 11:44 AM, Chunyan Zhang wrote:
> On Thu, 29 Nov 2018 at 17:25, Adrian Hunter wrote:
>>
>> On 29/11/18 8:07 AM, Chunyan Zhang wrote:
>>> Some standard SD host controllers can support both external dma
>>> controllers as well as ADMA/SDMA in which the SD host controller
>>> acts as DMA master. TI's omap controller is the case as an example.
>>>
>>> Currently the generic SDHCI code supports ADMA/SDMA integrated in
>>> the host controller but does not have any support for external DMA
>>> controllers implemented using dmaengine, meaning that custom code is
>>> needed for any systems that use an external DMA controller with SDHCI.
>>>
>>> Signed-off-by: Chunyan Zhang
>>> ---
>>> drivers/mmc/host/Kconfig | 14
>>> drivers/mmc/host/sdhci.c | 185
>>> ++-
>>> drivers/mmc/host/sdhci.h | 8 ++
>>> 3 files changed, 206 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
>>> index 1b58739..4183f43 100644
>>> --- a/drivers/mmc/host/Kconfig
>>> +++ b/drivers/mmc/host/Kconfig
>>> @@ -969,6 +969,7 @@ config MMC_SDHCI_XENON
>>> config MMC_SDHCI_OMAP
>>> tristate "TI SDHCI Controller Support"
>>> depends on MMC_SDHCI_PLTFM && OF
>>> + select MMC_SDHCI_EXTERNAL_DMA if DMA_ENGINE
>>> help
>>> This selects the Secure Digital Host Controller Interface (SDHCI)
>>> support present in TI's DRA7 SOCs. The controller supports
>>> @@ -977,3 +978,16 @@ config MMC_SDHCI_OMAP
>>> If you have a controller with this interface, say Y or M here.
>>>
>>> If unsure, say N.
>>> +
>>> +config MMC_SDHCI_EXTERNAL_DMA
>>> +bool "Support external DMA in standard SD host controller"
>>> + depends on MMC_SDHCI
>>> + depends on DMA_ENGINE
>>> + help
>>> + This is an option for using external DMA device via dmaengine
>>> + framework.
>>> +
>>> + If you have a controller which support using external DMA device
>>> + for data transfer, can say Y.
>>> +
>>> + If unsure, say N.
>>
>> So if you are going to select this, then you don't need the prompt or help
>> anymore i.e.
>>
>> config MMC_SDHCI_EXTERNAL_DMA
>> bool
>>
>>
>>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>>> index 99bdae5..ad7cc80 100644
>>> --- a/drivers/mmc/host/sdhci.c
>>> +++ b/drivers/mmc/host/sdhci.c
>>> @@ -14,6 +14,7 @@
>>> */
>>>
>>> #include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> @@ -1309,6 +1310,162 @@ static void sdhci_del_timer(struct sdhci_host
>>> *host, struct mmc_request *mrq)
>>> del_timer(&host->timer);
>>> }
>>>
>>> +#if IS_ENABLED(CONFIG_MMC_SDHCI_EXTERNAL_DMA)
>>> +static int sdhci_external_dma_init(struct sdhci_host *host)
>>> +{
>>> + int ret = 0;
>>> + struct mmc_host *mmc = host->mmc;
>>> +
>>> + host->tx_chan = dma_request_chan(mmc->parent, "tx");
>>> + if (IS_ERR(host->tx_chan)) {
>>> + ret = PTR_ERR(host->tx_chan);
>>> + if (ret != -EPROBE_DEFER)
>>> + pr_warn("Failed to request TX DMA channel.\n");
>>> + host->tx_chan = NULL;
>>> + return ret;
>>> + }
>>> +
>>> + host->rx_chan = dma_request_chan(mmc->parent, "rx");
>>> + if (IS_ERR(host->rx_chan)) {
>>> + if (host->tx_chan) {
>>> + dma_release_channel(host->tx_chan);
>>> + host->tx_chan = NULL;
>>> + }
>>> +
>>> + ret = PTR_ERR(host->rx_chan);
>>> + if (ret != -EPROBE_DEFER)
>>> + pr_warn("Failed to request RX DMA channel.\n");
>>> + host->rx_chan = NULL;
>>> + }
>>> +
>>> + return ret;
>>> +}
>>> +
>>> +static inline struct dma_chan *
>>> +sdhci_external_dma_channel(struct sdhci_host *host, struct mmc_data *data)
>>> +{
>>> + return data->flags & MMC_DATA_WRITE ? host->tx_chan : host->rx_chan;
>>> +}
>>> +
>>> +static int sdhci_external_dma_setup(struct sdhci_host *host,
>>> + struct mmc_command *cmd)
>>> +{
>>> + int ret, i;
>>> + struct dma_async_tx_descriptor *desc;
>>> + struct mmc_data *data = cmd->data;
>>> + struct dma_chan *chan;
>>> + struct dma_slave_config cfg;
>>> + dma_cookie_t cookie;
>>> +
>>> + if (!host->mapbase)
>>> + return -EINVAL;
>>> +
>>> + if (!data)
>>> + return 0;
>>
>> It would read better if the above 2 if-statements were the other way around
>> i.e.
>>
>> if (!data)
>> return 0;
>>
>> if (!host->mapbase)
>> return -EINVAL;
>>
>
> Ok.
>
>>> +
>>> + cfg.src_addr = host->mapbase + SDHCI_BUFFER;
>>> + cfg.dst_addr = host->mapbase + SDHCI_BUFFER;
>>> + cfg.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
>>> + cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
>>> + cfg.src_maxburst = data->blksz / 4;
>>> + cfg.dst_max
[PATCH] IB/usnic: fix spelling mistake "miniumum" -> "minimum"
From: Colin Ian King
There is a spelling mistake in a usnic_err error message, fix it.
Signed-off-by: Colin Ian King
---
drivers/infiniband/hw/usnic/usnic_ib_qp_grp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/usnic/usnic_ib_qp_grp.c
b/drivers/infiniband/hw/usnic/usnic_ib_qp_grp.c
index bf5136533d49..0cdb156e165e 100644
--- a/drivers/infiniband/hw/usnic/usnic_ib_qp_grp.c
+++ b/drivers/infiniband/hw/usnic/usnic_ib_qp_grp.c
@@ -681,7 +681,7 @@ usnic_ib_qp_grp_create(struct usnic_fwd_dev *ufdev, struct
usnic_ib_vf *vf,
err = usnic_vnic_res_spec_satisfied(&min_transport_spec[transport],
res_spec);
if (err) {
- usnic_err("Spec does not meet miniumum req for transport %d\n",
+ usnic_err("Spec does not meet minimum req for transport %d\n",
transport);
log_spec(res_spec);
return ERR_PTR(err);
--
2.19.1
Re: [PATCH] Compiler Attributes: move kernel-only attributes into __KERNEL__
On Thu, Nov 29, 2018 at 3:16 AM Xiaozhou Liu wrote:
>
> On Wed, Nov 28, 2018 at 06:35:18PM +0100, Miguel Ojeda wrote:
>
> By `these' I mean inline and the like, to be clear.
Ah, that makes more sense! Sorry.
> > That is not exactly correct -- a3f8a30f3f00 moved some attributes to
> > another file, moving them into __KERNEL__ (in particular,__gnu_inline
> > is).
>
> Yes, that is what a3f8a30f3f00 did. Sorry.
> Turns out the commits in question are 815f0ddb346c and a3f8a30f3f00.
No problem! It was a bit confusing indeed.
> Yes and no. Let's recall the whole story.
>
> Before 815f0ddb346c("include/linux/compiler*.h: make compiler-*.h mutually
> exclusive"),
> __gnu_inline and inline were both *in* __KERNEL__ as the were in
> , which was entirely put to __KERNEL__ in
> . Everything was fine.
>
> Then 815f0ddb346c moved inline and __gnu_inline *out* of __KERNEL__
> and put them in so userspace could see them
> both. Not sure if it's intended behavior, but everything looked fine.
>
> Then a3f8a30f3f00 moved __gnu_inline back into __KERNEL__ and left
> inline behind. Since inline depends on __gnu_inline, error showing
> "unknown type name ‘__gnu_inline’" pops up.
Exactly, thanks a lot for clarifying it up (we should put this in the
commit message, I would say). That also answers my question: it is
clear everything should be back into __KERNEL__. The only worry is
that the v4.19 release contained 815f0ddb346c, so it has them exposed,
so someone could have started relying on them. Or, more likely, the
exposed macros could break some source code out there. Hm... Should a
"fix" be backported?
Cheers,
Miguel
Re: [PATCH v7 2/2] sched/fair: update scale invariance of PELT
On Wed, 28 Nov 2018 at 17:35, Patrick Bellasi wrote: > > On 28-Nov 16:42, Vincent Guittot wrote: > > On Wed, 28 Nov 2018 at 16:21, Patrick Bellasi > > wrote: > > > > > > On 28-Nov 15:55, Vincent Guittot wrote: > > > > On Wed, 28 Nov 2018 at 15:40, Patrick Bellasi > > > > wrote: > > > > > > > > > > On 28-Nov 14:33, Vincent Guittot wrote: > > > > > > On Wed, 28 Nov 2018 at 12:53, Patrick Bellasi > > > > > > wrote: > > > > > > > > > > > > > > On 28-Nov 11:02, Peter Zijlstra wrote: > > > > > > > > On Wed, Nov 28, 2018 at 10:54:13AM +0100, Vincent Guittot wrote: > > > > > > > > > > > > > > > > > Is there anything else that I should do for these patches ? > > > > > > > > > > > > > > > > IIRC, Morten mention they break util_est; Patrick was going to > > > > > > > > explain. > > > > > > > > > > > > > > I guess the problem is that, once we cross the current capacity, > > > > > > > strictly speaking util_avg does not represent anymore a > > > > > > > utilization. > > > > > > > > > > > > > > With the new signal this could happen and we end up storing > > > > > > > estimated > > > > > > > utilization samples which will overestimate the task requirements. > > > > > > > > > > > > > > We will have a spike in estimated utilization at next wakeup, > > > > > > > since we > > > > > > > use MAX(util_avg@dequeue_time, ewma). Potentially we also inflate > > > > > > > the EWMA in > > > > > > > case we collect multiple samples above the current capacity. > > > > > > > > > > > > TBH I don't see how it's different from current implementation with > > > > > > a > > > > > > task that was scheduled on big core and now wakes up on little core. > > > > > > The util_est is overestimated as well. > > > > > > > > > > While running below the capacity of a CPU, either big or LITTLE, we > > > > > can still measure the actual used bandwidth as long as we have idle > > > > > time. If the task is then moved into a lower capacity core, I think > > > > > it's still safe to assume that, likely, it would need more capacity. > > > > > > > > > > Why do you say it's the same ? > > > > > > > > In the example of a task that runs 39ms in period of 80ms that we used > > > > during previous version, > > > > the utilization on the big core will reach 709 so will util_est too > > > > When the task migrates on little core (512), util_est is higher than > > > > current cpu capacity > > > > > > Right, and what's the problem ? > > > > you worry about an util_est being higher than capacity which is the case > > there > > I worry about util_est being higher then the capacity the task WAS > running... not the capacity the task IS running... if that value does > not correspond to what the task really need... (more on that at the > end). > > > > 1) We know that PELT is calibrated to 32ms period task and in your > > >example, since the runtime is higher then the half-life, it's > > >correct to estimate a utilization higher then 50%. > > > > > >PELT utilization is defined _based on the half-life_: thus > > >your task having a 50% duty cycle does not mean we are not correct > > >if report a utilization != 50%. > > >It would be as broken as reporting 10% utilization for a task > > >running 100ms every 1s. > > > > > > 2) If it was a 70% task on a previous activation, once it's moved into > > >a lower capacity CPU it's still correct to assume that it's likely > > >going to require the same bandwidth and thus will be > > >under-provisioned. > > > > > > I still don't see where we are wrong in this case :/ > > > > > > To me it looks different then the problem I described. > > > > > > > > With your new signal instead, once we cross the current capacity, > > > > > utilization is just not anymore utilization. Thus, IMHO it make sense > > > > > avoid to accumulate a sample for what we call "estimated utilization". > > > > This is not true. With the example above, the util_est will be exactly the > > same > > on big and little cores with the new signal > > ... AFAIU only if we have idle time... > > > > > > I would also say that, with the current implementation which caps > > > > > utilization to the current capacity, we get better estimation in > > > > > general. At least we can say with absolute precision: > > > > > > > > > >"the task needs _at least_ that amount of capacity". > > > > > > > > > > Potentially we can also flag the task as being under-provisioned, in > > > > > case there was not idle time, and _let a policy_ decide what to do > > > > > with it and the granted information we have. > > > > > > > > > > While, with your new signal, once we are over the current capacity, > > > > > the "utilization" is just a sort of "random" number at best useful to > > > > > drive some conclusions about how long the task has been delayed. > > > > see my comment above > > > > > > > > > > > > IOW, I fear that we are embedding a policy within a signal which is > > > > > currently representing something very well defined: how much c
Re: [PATCH V3 1/3] mmc: sdhci: add support for using external DMA devices
On Thu, 29 Nov 2018 at 18:41, Adrian Hunter wrote:
>
> On 29/11/18 11:44 AM, Chunyan Zhang wrote:
> > On Thu, 29 Nov 2018 at 17:25, Adrian Hunter wrote:
> >>
> >> On 29/11/18 8:07 AM, Chunyan Zhang wrote:
> >>> Some standard SD host controllers can support both external dma
> >>> controllers as well as ADMA/SDMA in which the SD host controller
> >>> acts as DMA master. TI's omap controller is the case as an example.
> >>>
> >>> Currently the generic SDHCI code supports ADMA/SDMA integrated in
> >>> the host controller but does not have any support for external DMA
> >>> controllers implemented using dmaengine, meaning that custom code is
> >>> needed for any systems that use an external DMA controller with SDHCI.
> >>>
> >>> Signed-off-by: Chunyan Zhang
> >>> ---
> >>> drivers/mmc/host/Kconfig | 14
> >>> drivers/mmc/host/sdhci.c | 185
> >>> ++-
> >>> drivers/mmc/host/sdhci.h | 8 ++
> >>> 3 files changed, 206 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> >>> index 1b58739..4183f43 100644
> >>> --- a/drivers/mmc/host/Kconfig
> >>> +++ b/drivers/mmc/host/Kconfig
> >>> @@ -969,6 +969,7 @@ config MMC_SDHCI_XENON
> >>> config MMC_SDHCI_OMAP
> >>> tristate "TI SDHCI Controller Support"
> >>> depends on MMC_SDHCI_PLTFM && OF
> >>> + select MMC_SDHCI_EXTERNAL_DMA if DMA_ENGINE
> >>> help
> >>> This selects the Secure Digital Host Controller Interface (SDHCI)
> >>> support present in TI's DRA7 SOCs. The controller supports
> >>> @@ -977,3 +978,16 @@ config MMC_SDHCI_OMAP
> >>> If you have a controller with this interface, say Y or M here.
> >>>
> >>> If unsure, say N.
> >>> +
> >>> +config MMC_SDHCI_EXTERNAL_DMA
> >>> +bool "Support external DMA in standard SD host controller"
> >>> + depends on MMC_SDHCI
> >>> + depends on DMA_ENGINE
> >>> + help
> >>> + This is an option for using external DMA device via dmaengine
> >>> + framework.
> >>> +
> >>> + If you have a controller which support using external DMA device
> >>> + for data transfer, can say Y.
> >>> +
> >>> + If unsure, say N.
> >>
> >> So if you are going to select this, then you don't need the prompt or help
> >> anymore i.e.
> >>
> >> config MMC_SDHCI_EXTERNAL_DMA
> >> bool
> >>
> >>
> >>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> >>> index 99bdae5..ad7cc80 100644
> >>> --- a/drivers/mmc/host/sdhci.c
> >>> +++ b/drivers/mmc/host/sdhci.c
> >>> @@ -14,6 +14,7 @@
> >>> */
> >>>
> >>> #include
> >>> +#include
> >>> #include
> >>> #include
> >>> #include
> >>> @@ -1309,6 +1310,162 @@ static void sdhci_del_timer(struct sdhci_host
> >>> *host, struct mmc_request *mrq)
> >>> del_timer(&host->timer);
> >>> }
> >>>
> >>> +#if IS_ENABLED(CONFIG_MMC_SDHCI_EXTERNAL_DMA)
> >>> +static int sdhci_external_dma_init(struct sdhci_host *host)
> >>> +{
> >>> + int ret = 0;
> >>> + struct mmc_host *mmc = host->mmc;
> >>> +
> >>> + host->tx_chan = dma_request_chan(mmc->parent, "tx");
> >>> + if (IS_ERR(host->tx_chan)) {
> >>> + ret = PTR_ERR(host->tx_chan);
> >>> + if (ret != -EPROBE_DEFER)
> >>> + pr_warn("Failed to request TX DMA channel.\n");
> >>> + host->tx_chan = NULL;
> >>> + return ret;
> >>> + }
> >>> +
> >>> + host->rx_chan = dma_request_chan(mmc->parent, "rx");
> >>> + if (IS_ERR(host->rx_chan)) {
> >>> + if (host->tx_chan) {
> >>> + dma_release_channel(host->tx_chan);
> >>> + host->tx_chan = NULL;
> >>> + }
> >>> +
> >>> + ret = PTR_ERR(host->rx_chan);
> >>> + if (ret != -EPROBE_DEFER)
> >>> + pr_warn("Failed to request RX DMA channel.\n");
> >>> + host->rx_chan = NULL;
> >>> + }
> >>> +
> >>> + return ret;
> >>> +}
> >>> +
> >>> +static inline struct dma_chan *
> >>> +sdhci_external_dma_channel(struct sdhci_host *host, struct mmc_data
> >>> *data)
> >>> +{
> >>> + return data->flags & MMC_DATA_WRITE ? host->tx_chan : host->rx_chan;
> >>> +}
> >>> +
> >>> +static int sdhci_external_dma_setup(struct sdhci_host *host,
> >>> + struct mmc_command *cmd)
> >>> +{
> >>> + int ret, i;
> >>> + struct dma_async_tx_descriptor *desc;
> >>> + struct mmc_data *data = cmd->data;
> >>> + struct dma_chan *chan;
> >>> + struct dma_slave_config cfg;
> >>> + dma_cookie_t cookie;
> >>> +
> >>> + if (!host->mapbase)
> >>> + return -EINVAL;
> >>> +
> >>> + if (!data)
> >>> + return 0;
> >>
> >> It would read better if the above 2 if-statements were the other way
> >> around i.e.
> >>
> >> if (!data)
> >> return 0;
> >>
> >> if (!host->mapbase)
> >>
fs/ubifs/tnc.c:493: undefined reference to `ubifs_bad_hash'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 60b548237fed4b4164bab13c994dd9615f6c4323
commit: 16a26b20d2afd0cf063816725b45b12e78d5bb31 ubifs: authentication: Add
hashes to index nodes
date: 5 weeks ago
config: i386-randconfig-x0-11291730 (attached as .config)
compiler: gcc-5 (Debian 5.5.0-3) 5.4.1 20171010
reproduce:
git checkout 16a26b20d2afd0cf063816725b45b12e78d5bb31
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
fs/ubifs/tnc.o: In function `try_read_node':
>> fs/ubifs/tnc.c:493: undefined reference to `ubifs_bad_hash'
fs/ubifs/tnc.o: In function `validate_data_node':
fs/ubifs/tnc.c:1724: undefined reference to `ubifs_bad_hash'
fs/ubifs/tnc_misc.o: In function `read_znode':
>> fs/ubifs/tnc_misc.c:298: undefined reference to `ubifs_bad_hash'
fs/ubifs/tnc_misc.o: In function `ubifs_tnc_read_node':
fs/ubifs/tnc_misc.c:509: undefined reference to `ubifs_bad_hash'
vim +493 fs/ubifs/tnc.c
430
431 /**
432 * try_read_node - read a node if it is a node.
433 * @c: UBIFS file-system description object
434 * @buf: buffer to read to
435 * @type: node type
436 * @zbr: the zbranch describing the node to read
437 *
438 * This function tries to read a node of known type and length, checks
it and
439 * stores it in @buf. This function returns %1 if a node is present and
%0 if
440 * a node is not present. A negative error code is returned for I/O
errors.
441 * This function performs that same function as ubifs_read_node except
that
442 * it does not require that there is actually a node present and instead
443 * the return code indicates if a node was read.
444 *
445 * Note, this function does not check CRC of data nodes if
@c->no_chk_data_crc
446 * is true (it is controlled by corresponding mount option). However, if
447 * @c->mounting or @c->remounting_rw is true (we are mounting or
re-mounting to
448 * R/W mode), @c->no_chk_data_crc is ignored and CRC is checked. This is
449 * because during mounting or re-mounting from R/O mode to R/W mode we
may read
450 * journal nodes (when replying the journal or doing the recovery) and
the
451 * journal nodes may potentially be corrupted, so checking is required.
452 */
453 static int try_read_node(const struct ubifs_info *c, void *buf, int
type,
454 struct ubifs_zbranch *zbr)
455 {
456 int len = zbr->len;
457 int lnum = zbr->lnum;
458 int offs = zbr->offs;
459 int err, node_len;
460 struct ubifs_ch *ch = buf;
461 uint32_t crc, node_crc;
462
463 dbg_io("LEB %d:%d, %s, length %d", lnum, offs, dbg_ntype(type),
len);
464
465 err = ubifs_leb_read(c, lnum, buf, offs, len, 1);
466 if (err) {
467 ubifs_err(c, "cannot read node type %d from LEB %d:%d,
error %d",
468type, lnum, offs, err);
469 return err;
470 }
471
472 if (le32_to_cpu(ch->magic) != UBIFS_NODE_MAGIC)
473 return 0;
474
475 if (ch->node_type != type)
476 return 0;
477
478 node_len = le32_to_cpu(ch->len);
479 if (node_len != len)
480 return 0;
481
482 if (type == UBIFS_DATA_NODE && c->no_chk_data_crc &&
!c->mounting &&
483 !c->remounting_rw)
484 return 1;
485
486 crc = crc32(UBIFS_CRC32_INIT, buf + 8, node_len - 8);
487 node_crc = le32_to_cpu(ch->crc);
488 if (crc != node_crc)
489 return 0;
490
491 err = ubifs_node_check_hash(c, buf, zbr->hash);
492 if (err) {
> 493 ubifs_bad_hash(c, buf, zbr->hash, lnum, offs);
494 return 0;
495 }
496
497 return 1;
498 }
499
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH] arm64: io: specify asm operand width for __iormb()
On Thu, Nov 29, 2018 at 09:03:54AM +, Julien Thierry wrote:
>
>
> On 29/11/18 04:19, Nick Desaulniers wrote:
> > Fixes the warning produced from Clang:
> > ./include/asm-generic/io.h:711:9: warning: value size does not match
> > register size specified by the constraint and modifier
> > [-Wasm-operand-widths]
> > return readl(addr);
> >^
> > ./arch/arm64/include/asm/io.h:149:58: note: expanded from macro 'readl'
> > ^
> > ./include/asm-generic/io.h:711:9: note: use constraint modifier "w"
> > ./arch/arm64/include/asm/io.h:149:50: note: expanded from macro 'readl'
> > ^
> > ./arch/arm64/include/asm/io.h:118:25: note: expanded from macro '__iormb'
> > asm volatile("eor %w0, %1, %1\n" \
> > ^
>
> Why does the "eor %0, %1, %1" become "eor %w0, %1, %1" ?
> The variable passed to the inline assembly for %0 is unsigned long, so
> always 64-bits wide on arm64. Why is clang trying to use a 32-bit
> register for it?
Yeah, the message above looks bogus to me. I can see %1 being 32-bit for
read[bwl], so maybe clang is just getting the diagnostic wrong. If so,
I wonder if the following fixes the problem:
diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index d42d00d8d5b6..13befec8b64e 100644
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -117,7 +117,7 @@ static inline u64 __raw_readq(const volatile void __iomem
*addr)
*/ \
asm volatile("eor %0, %1, %1\n" \
"cbnz %0, ." \
-: "=r" (tmp) : "r" (v) : "memory");\
+: "=r" (tmp) : "r" (unsigned long)(v) : "memory"); \
})
#define __iowmb() wmb()
Will
Re: [PATCH 22/27] locking/lockdep: Reuse list entries that are no longer in use
On Wed, Nov 28, 2018 at 03:43:20PM -0800, Bart Van Assche wrote:
> Instead of abandoning elements of list_entries[] that are no longer in
> use, make alloc_list_entry() reuse array elements that have been freed.
> diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
> index 43327a1dd488..01e55fca7c2c 100644
> --- a/include/linux/lockdep.h
> +++ b/include/linux/lockdep.h
> @@ -183,6 +183,11 @@ static inline void lockdep_copy_map(struct lockdep_map
> *to,
> struct lock_list {
> /* Entry in locks_after or locks_before. */
> struct list_headlock_order_entry;
> + /*
> + * Entry in all_list_entries when in use and entry in
> + * free_list_entries when not in use.
> + */
> + struct list_headalloc_entry;
> struct lock_class *class;
> struct lock_class *links_to;
> struct stack_trace trace;
> +static LIST_HEAD(all_list_entries);
> +static LIST_HEAD(free_list_entries);
>
> @@ -862,7 +867,10 @@ register_lock_class(struct lockdep_map *lock, unsigned
> int subclass, int force)
> */
> static struct lock_list *alloc_list_entry(void)
> {
> - if (nr_list_entries >= MAX_LOCKDEP_ENTRIES) {
> + struct lock_list *e = list_first_entry_or_null(&free_list_entries,
> +typeof(*e), alloc_entry);
> +
> + if (!e) {
> if (!debug_locks_off_graph_unlock())
> return NULL;
>
> @@ -870,7 +878,8 @@ static struct lock_list *alloc_list_entry(void)
> dump_stack();
> return NULL;
> }
> - return list_entries + nr_list_entries++;
> + list_move_tail(&e->alloc_entry, &all_list_entries);
> + return e;
> }
> @@ -4235,19 +4244,19 @@ static void zap_class(struct list_head
> *zapped_classes,
> struct lock_class *class)
> {
> struct lock_class *links_to;
> + struct lock_list *entry, *tmp;
>
> /*
>* Remove all dependencies this lock is
>* involved in:
>*/
> + list_for_each_entry_safe(entry, tmp, &all_list_entries, alloc_entry) {
> if (entry->class != class && entry->links_to != class)
> continue;
> links_to = entry->links_to;
> WARN_ON_ONCE(entry->class == links_to);
> list_del_rcu(&entry->lock_order_entry);
> + list_move(&entry->alloc_entry, &free_list_entries);
> entry->class = NULL;
> entry->links_to = NULL;
> check_free_class(zapped_classes, class);
Hurm.. I'm confused here.
The reason you cannot re-use lock_order_entry for the free list is
because list_del_rcu(), right? But if so, then what ensures the
list_entry is not re-used before it's grace-period?
Re: [PATCH v2 1/3] mmc: sdhci: add support for using external DMA devices
On 29/11/18 11:59 AM, Chunyan Zhang wrote:
> Hi Adrian,
>
> On Thu, 29 Nov 2018 at 15:36, Adrian Hunter wrote:
>>
>> On 29/11/18 8:22 AM, Chunyan Zhang wrote:
>>> On Tue, 20 Nov 2018 at 21:41, Adrian Hunter wrote:
On 12/11/18 9:26 AM, Chunyan Zhang wrote:
> Some standard SD host controllers can support both external dma
> controllers as well as ADMA/SDMA in which the SD host controller
> acts as DMA master. TI's omap controller is the case as an example.
>
> Currently the generic SDHCI code supports ADMA/SDMA integrated in
> the host controller but does not have any support for external DMA
> controllers implemented using dmaengine, meaning that custom code is
> needed for any systems that use an external DMA controller with SDHCI.
I still think you probably need to reset the DMA if there are transfer
errors - perhaps you could comment on that. Also there are some comments
below.
>>>
>>> With regard to "transfer error", do you mean if
>>> sdhci_external_dma_setup() failed?
>>
>> No, I mean any error interrupt that can leave the DMA uncompleted. For
>> SDHCI, resetting the data circuit cleans that up, but presumably something
>> is needed for external DMA?
>
> Yes, it should need a dmaengine_terminate_all().
>
> How about adding that at here (I will wrap it up of course):
> https://elixir.bootlin.com/linux/v4.19.5/source/drivers/mmc/host/sdhci.c#L2553
Yes except we really need to reverse
if (host->flags & SDHCI_REQ_USE_DMA) {
}
if (sdhci_needs_reset(host, mrq)) {
}
so that we do not unmap before killing the dma
Perhaps you could send that as a separate patch.
> Is there somewhere else I'm missing?
Testing ;-)
RE: [PATCH 3/3] PCI: imx: Add support for i.MX8MQ
> -Original Message-
> From: Andrey Smirnov [mailto:andrew.smir...@gmail.com]
> Sent: 2018年11月27日 2:10
> To: Richard Zhu
> Cc: linux-kernel ; Bjorn Helgaas
> ; Fabio Estevam ; Chris
> Healy ; Lucas Stach ;
> Leonard Crestez ; Aisheng DONG
> ; dl-linux-imx ;
> linux-arm-kernel ;
> linux-...@vger.kernel.org
> Subject: Re: [PATCH 3/3] PCI: imx: Add support for i.MX8MQ
>
> On Sun, Nov 18, 2018 at 11:07 PM Richard Zhu
> wrote:
> >
> > Hi Andrey:
> > Thanks for your patch-set.
> > I have comment about the L1SS implementation below.
> > It's better to figure out one method to fix it.
> >
> > BR
> > Richard
> >
> > > -Original Message-
> > > From: Andrey Smirnov [mailto:andrew.smir...@gmail.com]
> > > Sent: 2018年11月18日 2:12
> > > To: linux-kernel@vger.kernel.org
> > > Cc: Andrey Smirnov ;
> bhelg...@google.com;
> > > Fabio Estevam ; cphe...@gmail.com;
> > > l.st...@pengutronix.de; Leonard Crestez ;
> > > Aisheng DONG ; Richard Zhu
> > > ; dl-linux-imx ;
> > > linux-arm-ker...@lists.infradead.org; linux-...@vger.kernel.org
> > > Subject: [PATCH 3/3] PCI: imx: Add support for i.MX8MQ
> > >
> > > Cc: bhelg...@google.com
> > > Cc: Fabio Estevam
> > > Cc: cphe...@gmail.com
> > > Cc: l.st...@pengutronix.de
> > > Cc: Leonard Crestez
> > > Cc: "A.s. Dong"
> > > Cc: Richard Zhu
> > > Cc: linux-...@nxp.com
> > > Cc: linux-arm-ker...@lists.infradead.org
> > > Cc: linux-kernel@vger.kernel.org
> > > Cc: linux-...@vger.kernel.org
> > > Signed-off-by: Andrey Smirnov
> > > ---
> > > drivers/pci/controller/dwc/Kconfig| 2 +-
> > > drivers/pci/controller/dwc/pci-imx6.c | 117
> > > --
> > > 2 files changed, 113 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/dwc/Kconfig
> > > b/drivers/pci/controller/dwc/Kconfig
> > > index 91b0194240a5..2b139acccf32 100644
> > > --- a/drivers/pci/controller/dwc/Kconfig
> > > +++ b/drivers/pci/controller/dwc/Kconfig
> > > @@ -90,7 +90,7 @@ config PCI_EXYNOS
> > >
> > > config PCI_IMX6
> > > bool "Freescale i.MX6 PCIe controller"
> > > - depends on SOC_IMX6Q || (ARM && COMPILE_TEST)
> > > + depends on SOC_IMX8MQ || SOC_IMX6Q || (ARM &&
> COMPILE_TEST)
> > > depends on PCI_MSI_IRQ_DOMAIN
> > > select PCIE_DW_HOST
> > >
> > > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > > b/drivers/pci/controller/dwc/pci-imx6.c
> > > index 3c3002861d25..8d1f310e41a6 100644
> > > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > > @@ -8,6 +8,7 @@
> > > * Author: Sean Cross
> > > */
> > >
> > > +#include
> > > #include
> > > #include
> > > #include
> > > @@ -30,6 +31,14 @@
> > >
> > > #include "pcie-designware.h"
> > >
> > > +#define IMX8MQ_PCIE_LINK_CAP_REG_OFFSET 0x7C
> > > +#define IMX8MQ_PCIE_LINK_CAP_L1EL_64US (0x6 <<
> 15)
> > > +
> > > +#define IMX8MQ_GPR_PCIE_REF_USE_PAD BIT(9)
> > > +#define IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN BIT(10)
> > > +#define IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE BIT(11)
> > > +
> > > +
> > > #define to_imx6_pcie(x) dev_get_drvdata((x)->dev)
> > >
> > > enum imx6_pcie_variants {
> > > @@ -37,6 +46,7 @@ enum imx6_pcie_variants {
> > > IMX6SX,
> > > IMX6QP,
> > > IMX7D,
> > > + IMX8MQ,
> > > };
> > >
> > > struct imx6_pcie {
> > > @@ -48,8 +58,10 @@ struct imx6_pcie {
> > > struct clk *pcie_inbound_axi;
> > > struct clk *pcie;
> > > struct regmap *iomuxc_gpr;
> > > + u32 gpr1x;
> > > struct reset_control*pciephy_reset;
> > > struct reset_control*apps_reset;
> > > + struct reset_control*apps_clk_req;
> > > struct reset_control*turnoff_reset;
> > > enum imx6_pcie_variants variant;
> > > u32 tx_deemph_gen1;
> > > @@ -59,6 +71,7 @@ struct imx6_pcie {
> > > u32 tx_swing_low;
> > > int link_gen;
> > > struct regulator*vpcie;
> > > + u32 device_type[2];
> > > };
> > >
> > > /* Parameters for the waiting for PCIe PHY PLL to lock on i.MX7 */
> > > @@
> > > -245,7 +258,8 @@ static void imx6_pcie_reset_phy(struct imx6_pcie
> > > *imx6_pcie) {
> > > u32 tmp;
> > >
> > > - if (imx6_pcie->variant == IMX7D)
> > > + if (imx6_pcie->variant == IMX7D ||
> > > + imx6_pcie->variant == IMX8MQ)
> > > return;
> > >
> > > pcie_phy_read(imx6_pcie, PHY_RX_OVRD_IN_LO, &tmp); @@
> -261,6
> > > +275,7 @@ static void imx6_pcie_reset_phy(struct imx6_pcie
> > > +*imx6_pcie)
> > > pcie_phy_write(imx6_pcie, PHY_RX_OVRD_IN_LO, tmp); }
> > >
> > > +#ifdef CONFIG_ARM
> > > /* Added for PCI abort handling */ static int
> > > imx6q_pcie_abort_handler(unsigned long addr,
> > > unsigned int fsr, struct pt_regs *regs) @@ -294,6
> > > +309,7 @@ static int imx6q_pcie_abort_handler(unsi
[PATCH 1/2] dt-bindings: i2c: meson: add Meson G12A SoC i2c compatible string
Add Meson G12A SoC i2c controller compatible string Signed-off-by: Jian Hu --- Documentation/devicetree/bindings/i2c/i2c-meson.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/i2c/i2c-meson.txt b/Documentation/devicetree/bindings/i2c/i2c-meson.txt index 13d410d..795bc12 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-meson.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-meson.txt @@ -5,6 +5,7 @@ Required properties: "amlogic,meson6-i2c" for Meson8 and compatible SoCs "amlogic,meson-gxbb-i2c" for GXBB and compatible SoCs "amlogic,meson-axg-i2c"for AXG and compatible SoCs + "amlogic,meson-g12a-i2c" for G12A and compatible SoCs - reg: physical address and length of the device registers - interrupts: a single interrupt specifier -- 1.9.1
[PATCH 0/2] i2c: meson: add support for Meson G12A SoC i2c controller
1)Add G12A SoC i2c compatible string in dt-bindings. 2)Add compatible and data for G12A I2C controller driver. Jian Hu (2): dt-bindings: i2c: meson: add Meson G12A SoC i2c compatible string i2c: meson: add support for Meson G12A SoC I2C controller Documentation/devicetree/bindings/i2c/i2c-meson.txt | 1 + drivers/i2c/busses/i2c-meson.c | 5 + 2 files changed, 6 insertions(+) -- 1.9.1
[PATCH 2/2] i2c: meson: add support for Meson G12A SoC I2C controller
Add compatible and data for G12A I2C controller.
Signed-off-by: Jian Hu
---
drivers/i2c/busses/i2c-meson.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/i2c/busses/i2c-meson.c b/drivers/i2c/busses/i2c-meson.c
index 90f5d04..b86eed7 100644
--- a/drivers/i2c/busses/i2c-meson.c
+++ b/drivers/i2c/busses/i2c-meson.c
@@ -462,10 +462,15 @@ static int meson_i2c_remove(struct platform_device *pdev)
.div_factor = 3,
};
+static const struct meson_i2c_data i2c_g12a_data = {
+ .div_factor = 3,
+};
+
static const struct of_device_id meson_i2c_match[] = {
{ .compatible = "amlogic,meson6-i2c", .data = &i2c_meson6_data },
{ .compatible = "amlogic,meson-gxbb-i2c", .data = &i2c_gxbb_data },
{ .compatible = "amlogic,meson-axg-i2c", .data = &i2c_axg_data },
+ { .compatible = "amlogic,meson-g12a-i2c", .data = &i2c_g12a_data },
{},
};
--
1.9.1
Re: [PATCH 0/2] i2c: meson: add support for Meson G12A SoC i2c controller
On Thu, 2018-11-29 at 18:59 +0800, Jian Hu wrote: > 1)Add G12A SoC i2c compatible string in dt-bindings. > 2)Add compatible and data for G12A I2C controller driver. > > Jian Hu (2): > dt-bindings: i2c: meson: add Meson G12A SoC i2c compatible string > i2c: meson: add support for Meson G12A SoC I2C controller Looks to me that the g12a is compatible with the axg. What is the point of adding this new compatible string ? > > Documentation/devicetree/bindings/i2c/i2c-meson.txt | 1 + > drivers/i2c/busses/i2c-meson.c | 5 + > 2 files changed, 6 insertions(+) >
