* [xlnx:2017.3_video_ea 6589/6607] warning: (VIDEO_XILINX && ..) selects XILINX_FRMBUF which has unmet direct dependencies (DMADEVICES && ..)
From: kbuild test robot @ 2017-12-13 6:28 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://github.com/Xilinx/linux-xlnx 2017.3_video_ea
head: af045f9682c65a0c26afb2f638603d3c01079222
commit: 62a7ed2f02d28f73f2c09d61ecbe1f289aecc6e5 [6589/6607] staging: xilinx: mixer: Initial commit of Xilinx Video Mixer IP DRM driver
config: x86_64-randconfig-x008-12131414 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
git checkout 62a7ed2f02d28f73f2c09d61ecbe1f289aecc6e5
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
warning: (VIDEO_XILINX && DRM_XILINX && DRM_XILINX_XVMIXER) selects XILINX_FRMBUF which has unmet direct dependencies (DMADEVICES && XILINX_DMA_ENGINES)
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 24654 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171213/93e5cdcf/attachment-0001.gz>
^ permalink raw reply
* [PATCH V7 0/7] dmaengine: qcom_hidma: add support for bugfixed HW
From: Vinod Koul @ 2017-12-13 3:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9de34cfa-361e-38bf-0c06-ecff0fc26a5c@codeaurora.org>
On Tue, Dec 12, 2017 at 07:44:27PM -0500, Sinan Kaya wrote:
> On 12/12/2017 7:09 PM, Sinan Kaya wrote:
> > On 12/12/2017 7:36 AM, Rafael J. Wysocki wrote:
> >> On Tue, Dec 12, 2017 at 6:38 AM, Vinod Koul <vinod.koul@intel.com> wrote:
> >>> On Thu, Dec 07, 2017 at 04:10:24PM -0500, Sinan Kaya wrote:
> >>>> Introduce new ACPI and OF device ids for thw HW along with the helper
> >>>> functions.
> >>>>
> >>>> Changes from v6:
> >>>> * add const to the device callback parameter in fwnode.
> >>>> * reorganize the callbacks in the code
> >>>> * rename get_match_data() as device_get_match_data()
> >>>> * place pointer checks into acpi_get_match_data()
> >>>
> >>> This fails for me at 3rd patch. I am on -rc1 is there a dependency?
> >>
> >> There shouldn't be any.
> >>
> >> According to git, all changes to the files touched by the [3/7] are in
> >> -rc1 already.
> >>
> >
> > Let me know if you were able to resolve the conflict. I can rebase against
> > a development tree if you can point me to there.
> >
>
> Apparently, my patches were based of 4.14 kernel.
>
> I just rebased to 4.15-rc1.
>
> I can post a new version. Let me know.
Sure that should help
--
~Vinod
^ permalink raw reply
* [RESEND PATCH V2] arm64: fault: avoid send SIGBUS two times
From: gengdongjiu @ 2017-12-13 2:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5A301D4C.6070906@arm.com>
> Reviewed-by: James Morse <james.morse@arm.com>
>
>
> Nit: Your 'RESEND V2' and 'V2' are not the same patch.
> 'RESEND' is to indicate you're reposting exactly the same patch, usually with a
> fixed CC list. Anyone who receives both can ignore one as you've said they are
> the same.
James,
Thanks for the reminder and guild, I will send a version V3 to eliminate this confusion
^ permalink raw reply
* [PATCH v2] arm64: v8.4: Support for new floating point multiplication instructions
From: gengdongjiu @ 2017-12-13 2:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212145340.GN22781@e103592.cambridge.arm.com>
On 2017/12/12 22:53, Dave Martin wrote:
>> +HWCAP_FHM
> This needs to match the name of the #define in hwcap.h.
Thanks for the comments, have changed it.
>
> With that change, Reviewed-by: Dave Martin <Dave.Martin@arm.com>
Dave, appreciate for the review
>
> Cheers
> ---Dave
>
>
^ permalink raw reply
* [PATCH v3 1/2] cpuidle: Add new macro to enter a retention idle state
From: Rafael J. Wysocki @ 2017-12-13 1:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1510765910-23739-2-git-send-email-pprakash@codeaurora.org>
On Wednesday, November 15, 2017 6:11:49 PM CET Prashanth Prakash wrote:
> If a CPU is entering a low power idle state where it doesn't lose any
> context, then there is no need to call cpu_pm_enter()/cpu_pm_exit().
> Add a new macro(CPU_PM_CPU_IDLE_ENTER_RETENTION) to be used by cpuidle
> drivers when they are entering retention state. By not calling
> cpu_pm_enter and cpu_pm_exit we reduce the latency involved in
> entering and exiting the retention idle states.
>
> CPU_PM_CPU_IDLE_ENTER_RETENTION assumes that no state is lost and
> hence CPU PM notifiers will not be called. We may need a broader
> change if we need to support partial retention states effeciently.
>
> On ARM64 based Qualcomm Server Platform we measured below overhead for
> for calling cpu_pm_enter and cpu_pm_exit for retention states.
>
> workload: stress --hdd #CPUs --hdd-bytes 32M -t 30
> Average overhead of cpu_pm_enter - 1.2us
> Average overhead of cpu_pm_exit - 3.1us
>
> Signed-off-by: Prashanth Prakash <pprakash@codeaurora.org>
> Acked-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> include/linux/cpuidle.h | 40 ++++++++++++++++++++++++----------------
> 1 file changed, 24 insertions(+), 16 deletions(-)
>
> diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
> index 8f7788d..871f9e2 100644
> --- a/include/linux/cpuidle.h
> +++ b/include/linux/cpuidle.h
> @@ -257,22 +257,30 @@ static inline int cpuidle_register_governor(struct cpuidle_governor *gov)
> {return 0;}
> #endif
>
> -#define CPU_PM_CPU_IDLE_ENTER(low_level_idle_enter, idx) \
> -({ \
> - int __ret; \
> - \
> - if (!idx) { \
> - cpu_do_idle(); \
> - return idx; \
> - } \
> - \
> - __ret = cpu_pm_enter(); \
> - if (!__ret) { \
> - __ret = low_level_idle_enter(idx); \
> - cpu_pm_exit(); \
> - } \
> - \
> - __ret ? -1 : idx; \
> +#define __CPU_PM_CPU_IDLE_ENTER(low_level_idle_enter, idx, is_retention) \
> +({ \
> + int __ret = 0; \
> + \
> + if (!idx) { \
> + cpu_do_idle(); \
> + return idx; \
> + } \
> + \
> + if (!is_retention) \
> + __ret = cpu_pm_enter(); \
> + if (!__ret) { \
> + __ret = low_level_idle_enter(idx); \
> + if (!is_retention) \
> + cpu_pm_exit(); \
> + } \
> + \
> + __ret ? -1 : idx; \
> })
>
> +#define CPU_PM_CPU_IDLE_ENTER(low_level_idle_enter, idx) \
> + __CPU_PM_CPU_IDLE_ENTER(low_level_idle_enter, idx, 0)
> +
> +#define CPU_PM_CPU_IDLE_ENTER_RETENTION(low_level_idle_enter, idx) \
> + __CPU_PM_CPU_IDLE_ENTER(low_level_idle_enter, idx, 1)
> +
> #endif /* _LINUX_CPUIDLE_H */
>
This change is fine by me, so you can add
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
to it, but it kind of doesn't make sense to apply it alone, so please feel free
to route it via ARM64.
Thanks,
Rafael
^ permalink raw reply
* [PATCH] arm64: mm: Fix false positives in set_pte_at access/dirty race detection
From: Yisheng Xie @ 2017-12-13 1:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513079030-8557-1-git-send-email-will.deacon@arm.com>
Hi Will,
On 2017/12/12 19:43, Will Deacon wrote:
> Jiankang reports that our race detection in set_pte_at is firing when
> copying the page tables in dup_mmap as a result of a fork(). In this
> situation, the page table isn't actually live and so there is no way
> that we can race with a concurrent update from the hardware page table
> walker.
>
> This patch reworks the race detection so that we require either the
> mm to match the current active_mm (i.e. currently installed in our TTBR0)
> or the mm_users count to be greater than 1, implying that the page table
> could be live in another CPU. The mm_users check might still be racy,
> but we'll avoid false positives and it's not realistic to validate that
> all the necessary locks are held as part of this assertion.
>
> Cc: Yisheng Xie <xieyisheng1@huawei.com>
> Reported-by: Jiankang Chen <chenjiankang1@huawei.com>
> Tested-by: Jiankang Chen <chenjiankang1@huawei.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm64/include/asm/pgtable.h | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index 3ff03a755c32..bdcc7f1c9d06 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -42,6 +42,8 @@
> #include <asm/cmpxchg.h>
> #include <asm/fixmap.h>
> #include <linux/mmdebug.h>
> +#include <linux/mm_types.h>
> +#include <linux/sched.h>
>
Do you have compiled kernel after apply this patch? In our environment, it will
fail to compile kernel if include file here(I will attach some log later).
Instead, we move these included file after mmdebug.h, and I do not know whether
this is just my compiler's problem:
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -42,6 +42,8 @@
#include <asm/cmpxchg.h>
#include <asm/fixmap.h>
#include <linux/mmdebug.h>
+#include <linux/mm_types.h>
+#include <linux/sched.h>
Sorry for not having told you this information.
Thanks
Yisheng Xie
compiler err log: ==========
[...]
include/linux/mm_types_task.h:60: Error: unknown mnemonic `struct' -- `struct page_frag{'
include/asm-generic/preempt.h:9: Error: unknown mnemonic `static' -- `static inline int preempt_count(void)'
include/linux/mm_types_task.h:61: Error: unknown mnemonic `struct' -- `struct page*page'
include/asm-generic/preempt.h:10: Error: junk at end of line, first unrecognized character is `{'
include/linux/mm_types_task.h:63: Error: unknown mnemonic `__u32' -- `__u32 offset'
include/asm-generic/preempt.h:11: Error: unknown mnemonic `return' -- `return READ_ONCE(((struct thread_info*)current)->preempt_count)'
include/linux/mm_types_task.h:64: Error: unknown mnemonic `__u32' -- `__u32 size'
[...]
^ permalink raw reply
* [PATCH V7 0/7] dmaengine: qcom_hidma: add support for bugfixed HW
From: Sinan Kaya @ 2017-12-13 0:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0ed35958-22c9-50e5-3b6a-732821de6d20@codeaurora.org>
On 12/12/2017 7:09 PM, Sinan Kaya wrote:
> On 12/12/2017 7:36 AM, Rafael J. Wysocki wrote:
>> On Tue, Dec 12, 2017 at 6:38 AM, Vinod Koul <vinod.koul@intel.com> wrote:
>>> On Thu, Dec 07, 2017 at 04:10:24PM -0500, Sinan Kaya wrote:
>>>> Introduce new ACPI and OF device ids for thw HW along with the helper
>>>> functions.
>>>>
>>>> Changes from v6:
>>>> * add const to the device callback parameter in fwnode.
>>>> * reorganize the callbacks in the code
>>>> * rename get_match_data() as device_get_match_data()
>>>> * place pointer checks into acpi_get_match_data()
>>>
>>> This fails for me at 3rd patch. I am on -rc1 is there a dependency?
>>
>> There shouldn't be any.
>>
>> According to git, all changes to the files touched by the [3/7] are in
>> -rc1 already.
>>
>
> Let me know if you were able to resolve the conflict. I can rebase against
> a development tree if you can point me to there.
>
Apparently, my patches were based of 4.14 kernel.
I just rebased to 4.15-rc1.
I can post a new version. Let me know.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH V4] ACPI / GED: unregister interrupts during shutdown
From: Sinan Kaya @ 2017-12-13 0:37 UTC (permalink / raw)
To: linux-arm-kernel
Some GED interrupts could be pending by the time we are doing a reboot.
Even though GED driver uses devm_request_irq() to register the interrupt
handler, the handler is not being freed on time during a shutdown since
the driver is missing a shutdown callback.
If the ACPI handler is no longer available, this causes an interrupt
storm and delays shutdown.
1. Don't use devm family of functions for IRQ registration/free
2. Keep track of the events since free_irq() requires the dev_id parameter
passed into the request_irq() function.
3. Call free_irq() on both remove and shutdown explicitly.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/acpi/evged.c | 47 +++++++++++++++++++++++++++++++++++++++++------
1 file changed, 41 insertions(+), 6 deletions(-)
diff --git a/drivers/acpi/evged.c b/drivers/acpi/evged.c
index 46f0603..f13ba2c 100644
--- a/drivers/acpi/evged.c
+++ b/drivers/acpi/evged.c
@@ -49,6 +49,11 @@
#define MODULE_NAME "acpi-ged"
+struct acpi_ged_device {
+ struct device *dev;
+ struct list_head event_list;
+};
+
struct acpi_ged_event {
struct list_head node;
struct device *dev;
@@ -76,7 +81,8 @@ static acpi_status acpi_ged_request_interrupt(struct acpi_resource *ares,
unsigned int irq;
unsigned int gsi;
unsigned int irqflags = IRQF_ONESHOT;
- struct device *dev = context;
+ struct acpi_ged_device *geddev = context;
+ struct device *dev = geddev->dev;
acpi_handle handle = ACPI_HANDLE(dev);
acpi_handle evt_handle;
struct resource r;
@@ -102,8 +108,6 @@ static acpi_status acpi_ged_request_interrupt(struct acpi_resource *ares,
return AE_ERROR;
}
- dev_info(dev, "GED listening GSI %u @ IRQ %u\n", gsi, irq);
-
event = devm_kzalloc(dev, sizeof(*event), GFP_KERNEL);
if (!event)
return AE_ERROR;
@@ -116,29 +120,58 @@ static acpi_status acpi_ged_request_interrupt(struct acpi_resource *ares,
if (r.flags & IORESOURCE_IRQ_SHAREABLE)
irqflags |= IRQF_SHARED;
- if (devm_request_threaded_irq(dev, irq, NULL, acpi_ged_irq_handler,
- irqflags, "ACPI:Ged", event)) {
+ if (request_threaded_irq(irq, NULL, acpi_ged_irq_handler,
+ irqflags, "ACPI:Ged", event)) {
dev_err(dev, "failed to setup event handler for irq %u\n", irq);
return AE_ERROR;
}
+ dev_dbg(dev, "GED listening GSI %u @ IRQ %u\n", gsi, irq);
+ list_add_tail(&event->node, &geddev->event_list);
return AE_OK;
}
static int ged_probe(struct platform_device *pdev)
{
+ struct acpi_ged_device *geddev;
acpi_status acpi_ret;
+ geddev = devm_kzalloc(&pdev->dev, sizeof(*geddev), GFP_KERNEL);
+ if (!geddev)
+ return -ENOMEM;
+
+ geddev->dev = &pdev->dev;
+ INIT_LIST_HEAD(&geddev->event_list);
acpi_ret = acpi_walk_resources(ACPI_HANDLE(&pdev->dev), "_CRS",
- acpi_ged_request_interrupt, &pdev->dev);
+ acpi_ged_request_interrupt, geddev);
if (ACPI_FAILURE(acpi_ret)) {
dev_err(&pdev->dev, "unable to parse the _CRS record\n");
return -EINVAL;
}
+ platform_set_drvdata(pdev, geddev);
return 0;
}
+static void ged_shutdown(struct platform_device *pdev)
+{
+ struct acpi_ged_device *geddev = platform_get_drvdata(pdev);
+ struct acpi_ged_event *event, *next;
+
+ list_for_each_entry_safe(event, next, &geddev->event_list, node) {
+ free_irq(event->irq, event);
+ list_del(&event->node);
+ dev_dbg(geddev->dev, "GED releasing GSI %u @ IRQ %u\n",
+ event->gsi, event->irq);
+ }
+}
+
+static int ged_remove(struct platform_device *pdev)
+{
+ ged_shutdown(pdev);
+ return 0;
+}
+
static const struct acpi_device_id ged_acpi_ids[] = {
{"ACPI0013"},
{},
@@ -146,6 +179,8 @@ static int ged_probe(struct platform_device *pdev)
static struct platform_driver ged_driver = {
.probe = ged_probe,
+ .remove = ged_remove,
+ .shutdown = ged_shutdown,
.driver = {
.name = MODULE_NAME,
.acpi_match_table = ACPI_PTR(ged_acpi_ids),
--
1.9.1
^ permalink raw reply related
* [PATCH v2 1/2] acpi, spcr: Make SPCR avialable to other architectures
From: Rafael J. Wysocki @ 2017-12-13 0:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211155059.17062-2-prarit@redhat.com>
On Monday, December 11, 2017 4:50:58 PM CET Prarit Bhargava wrote:
> Other architectures can use SPCR to setup an early console or console
> but the current code is ARM64 specific.
>
> Change the name of parse_spcr() to acpi_parse_spcr(). Add a weak
> function acpi_arch_setup_console() that can be used for arch-specific
> setup. Move flags into ACPI code. Update the Documention on the use of
> the SPCR.
>
> [v2]: Don't return an error in the baud_rate check of acpi_parse_spcr().
> Keep ACPI_SPCR_TABLE selected for ARM64. Fix 8-bit port access width
> mmio value. Move baud rate check earlier.
>
> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
This mostly affects ARM64, so ACKs from that side are requisite for it.
> Cc: linux-doc at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-pm at vger.kernel.org
> Cc: linux-acpi at vger.kernel.org
> Cc: linux-serial at vger.kernel.org
> Cc: Bhupesh Sharma <bhsharma@redhat.com>
> Cc: Lv Zheng <lv.zheng@intel.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: x86 at kernel.org
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Cc: Timur Tabi <timur@codeaurora.org>
> ---
> Documentation/admin-guide/kernel-parameters.txt | 6 +-
> arch/arm64/kernel/acpi.c | 128 ++++++++++++++++-
> drivers/acpi/Kconfig | 7 +-
> drivers/acpi/spcr.c | 175 ++++++------------------
> drivers/tty/serial/earlycon.c | 15 +-
> include/linux/acpi.h | 11 +-
> include/linux/serial_core.h | 2 -
> 7 files changed, 184 insertions(+), 160 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 6571fbfdb2a1..0d173289c67e 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -914,9 +914,9 @@
>
> earlycon= [KNL] Output early console device and options.
>
> - When used with no options, the early console is
> - determined by the stdout-path property in device
> - tree's chosen node.
> + [ARM64] The early console is determined by the
> + stdout-path property in device tree's chosen node,
> + or determined by the ACPI SPCR table.
>
> cdns,<addr>[,options]
> Start an early, polled-mode console on a Cadence
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index b3162715ed78..b3e33bbdf3b7 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -25,7 +25,6 @@
> #include <linux/memblock.h>
> #include <linux/of_fdt.h>
> #include <linux/smp.h>
> -#include <linux/serial_core.h>
>
> #include <asm/cputype.h>
> #include <asm/cpu_ops.h>
> @@ -177,6 +176,128 @@ static int __init acpi_fadt_sanity_check(void)
> return ret;
> }
>
> +/*
> + * Erratum 44 for QDF2432v1 and QDF2400v1 SoCs describes the BUSY bit as
> + * occasionally getting stuck as 1. To avoid the potential for a hang, check
> + * TXFE == 0 instead of BUSY == 1. This may not be suitable for all UART
> + * implementations, so only do so if an affected platform is detected in
> + * acpi_parse_spcr().
> + */
> +bool qdf2400_e44_present;
> +EXPORT_SYMBOL(qdf2400_e44_present);
> +
> +/*
> + * Some Qualcomm Datacenter Technologies SoCs have a defective UART BUSY bit.
> + * Detect them by examining the OEM fields in the SPCR header, similar to PCI
> + * quirk detection in pci_mcfg.c.
> + */
> +static bool qdf2400_erratum_44_present(struct acpi_table_header *h)
> +{
> + if (memcmp(h->oem_id, "QCOM ", ACPI_OEM_ID_SIZE))
> + return false;
> +
> + if (!memcmp(h->oem_table_id, "QDF2432 ", ACPI_OEM_TABLE_ID_SIZE))
> + return true;
> +
> + if (!memcmp(h->oem_table_id, "QDF2400 ", ACPI_OEM_TABLE_ID_SIZE) &&
> + h->oem_revision == 1)
> + return true;
> +
> + return false;
> +}
> +
> +/*
> + * APM X-Gene v1 and v2 UART hardware is an 16550 like device but has its
> + * register aligned to 32-bit. In addition, the BIOS also encoded the
> + * access width to be 8 bits. This function detects this errata condition.
> + */
> +static bool xgene_8250_erratum_present(struct acpi_table_spcr *tb)
> +{
> + bool xgene_8250 = false;
> +
> + if (tb->interface_type != ACPI_DBG2_16550_COMPATIBLE)
> + return false;
> +
> + if (memcmp(tb->header.oem_id, "APMC0D", ACPI_OEM_ID_SIZE) &&
> + memcmp(tb->header.oem_id, "HPE ", ACPI_OEM_ID_SIZE))
> + return false;
> +
> + if (!memcmp(tb->header.oem_table_id, "XGENESPC",
> + ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 0)
> + xgene_8250 = true;
> +
> + if (!memcmp(tb->header.oem_table_id, "ProLiant",
> + ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 1)
> + xgene_8250 = true;
> +
> + return xgene_8250;
> +}
> +
> +int acpi_arch_setup_console(struct acpi_table_spcr *table,
> + char *opts, char *uart, char *iotype,
> + int baud_rate, bool earlycon)
> +{
> + if (table->header.revision < 2) {
> + pr_err("wrong table version\n");
> + return -ENOENT;
> + }
> +
> + switch (table->interface_type) {
> + case ACPI_DBG2_ARM_SBSA_32BIT:
> + snprintf(iotype, ACPI_SPCR_BUF_SIZE, "mmio32");
> + /* fall through */
> + case ACPI_DBG2_ARM_PL011:
> + case ACPI_DBG2_ARM_SBSA_GENERIC:
> + case ACPI_DBG2_BCM2835:
> + snprintf(uart, ACPI_SPCR_BUF_SIZE, "pl011");
> + break;
> + default:
> + if (strlen(uart) == 0)
> + return -ENOENT;
> + }
> +
> + /*
> + * If the E44 erratum is required, then we need to tell the pl011
> + * driver to implement the work-around.
> + *
> + * The global variable is used by the probe function when it
> + * creates the UARTs, whether or not they're used as a console.
> + *
> + * If the user specifies "traditional" earlycon, the qdf2400_e44
> + * console name matches the EARLYCON_DECLARE() statement, and
> + * SPCR is not used. Parameter "earlycon" is false.
> + *
> + * If the user specifies "SPCR" earlycon, then we need to update
> + * the console name so that it also says "qdf2400_e44". Parameter
> + * "earlycon" is true.
> + *
> + * For consistency, if we change the console name, then we do it
> + * for everyone, not just earlycon.
> + */
> + if (qdf2400_erratum_44_present(&table->header)) {
> + qdf2400_e44_present = true;
> + if (earlycon)
> + snprintf(uart, ACPI_SPCR_BUF_SIZE, "qdf2400_e44");
> + }
> +
> + if (xgene_8250_erratum_present(table)) {
> + snprintf(iotype, ACPI_SPCR_BUF_SIZE, "mmio32");
> +
> + /* for xgene v1 and v2 we don't know the clock rate of the
> + * UART so don't attempt to change to the baud rate state
> + * in the table because driver cannot calculate the dividers
> + */
> + snprintf(opts, ACPI_SPCR_OPTS_SIZE, "%s,%s,0x%llx", uart,
> + iotype, table->serial_port.address);
> + } else {
> + snprintf(opts, ACPI_SPCR_OPTS_SIZE, "%s,%s,0x%llx,%d", uart,
> + iotype, table->serial_port.address, baud_rate);
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(acpi_arch_setup_console);
> +
> /*
> * acpi_boot_table_init() called from setup_arch(), always.
> * 1. find RSDP and get its address, and then find XSDT
> @@ -230,10 +351,11 @@ void __init acpi_boot_table_init(void)
>
> done:
> if (acpi_disabled) {
> - if (earlycon_init_is_deferred)
> + if (console_acpi_spcr_enable)
> early_init_dt_scan_chosen_stdout();
> } else {
> - parse_spcr(earlycon_init_is_deferred);
> + /* Always enable the ACPI SPCR console */
> + acpi_parse_spcr(console_acpi_spcr_enable);
> if (IS_ENABLED(CONFIG_ACPI_BGRT))
> acpi_table_parse(ACPI_SIG_BGRT, acpi_parse_bgrt);
> }
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 46505396869e..9ae98eeada76 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -79,7 +79,12 @@ config ACPI_DEBUGGER_USER
> endif
>
> config ACPI_SPCR_TABLE
> - bool
> + bool "ACPI Serial Port Console Redirection Support"
> + default y if ARM64
> + help
> + Enable support for Serial Port Console Redirection (SPCR) Table.
> + This table provides information about the configuration of the
> + earlycon console.
>
> config ACPI_LPIT
> bool
> diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
> index 324b35bfe781..f4bb8110e404 100644
> --- a/drivers/acpi/spcr.c
> +++ b/drivers/acpi/spcr.c
> @@ -16,65 +16,18 @@
> #include <linux/kernel.h>
> #include <linux/serial_core.h>
>
> -/*
> - * Erratum 44 for QDF2432v1 and QDF2400v1 SoCs describes the BUSY bit as
> - * occasionally getting stuck as 1. To avoid the potential for a hang, check
> - * TXFE == 0 instead of BUSY == 1. This may not be suitable for all UART
> - * implementations, so only do so if an affected platform is detected in
> - * parse_spcr().
> - */
> -bool qdf2400_e44_present;
> -EXPORT_SYMBOL(qdf2400_e44_present);
> -
> -/*
> - * Some Qualcomm Datacenter Technologies SoCs have a defective UART BUSY bit.
> - * Detect them by examining the OEM fields in the SPCR header, similiar to PCI
> - * quirk detection in pci_mcfg.c.
> - */
> -static bool qdf2400_erratum_44_present(struct acpi_table_header *h)
> -{
> - if (memcmp(h->oem_id, "QCOM ", ACPI_OEM_ID_SIZE))
> - return false;
> -
> - if (!memcmp(h->oem_table_id, "QDF2432 ", ACPI_OEM_TABLE_ID_SIZE))
> - return true;
> -
> - if (!memcmp(h->oem_table_id, "QDF2400 ", ACPI_OEM_TABLE_ID_SIZE) &&
> - h->oem_revision == 1)
> - return true;
> -
> - return false;
> -}
> -
> -/*
> - * APM X-Gene v1 and v2 UART hardware is an 16550 like device but has its
> - * register aligned to 32-bit. In addition, the BIOS also encoded the
> - * access width to be 8 bits. This function detects this errata condition.
> - */
> -static bool xgene_8250_erratum_present(struct acpi_table_spcr *tb)
> +int __weak acpi_arch_setup_console(struct acpi_table_spcr *table,
> + char *opts, char *uart, char *iotype,
> + int baud_rate, bool earlycon)
> {
> - bool xgene_8250 = false;
> -
> - if (tb->interface_type != ACPI_DBG2_16550_COMPATIBLE)
> - return false;
> -
> - if (memcmp(tb->header.oem_id, "APMC0D", ACPI_OEM_ID_SIZE) &&
> - memcmp(tb->header.oem_id, "HPE ", ACPI_OEM_ID_SIZE))
> - return false;
> -
> - if (!memcmp(tb->header.oem_table_id, "XGENESPC",
> - ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 0)
> - xgene_8250 = true;
> -
> - if (!memcmp(tb->header.oem_table_id, "ProLiant",
> - ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 1)
> - xgene_8250 = true;
> -
> - return xgene_8250;
> + snprintf(opts, ACPI_SPCR_OPTS_SIZE, "%s,%s,0x%llx,%d", uart, iotype,
> + table->serial_port.address, baud_rate);
> + return 0;
> }
>
> +bool console_acpi_spcr_enable __initdata;
> /**
> - * parse_spcr() - parse ACPI SPCR table and add preferred console
> + * acpi_parse_spcr() - parse ACPI SPCR table and add preferred console
> *
> * @earlycon: set up earlycon for the console specified by the table
> *
> @@ -86,13 +39,13 @@ static bool xgene_8250_erratum_present(struct acpi_table_spcr *tb)
> * from arch initialization code as soon as the DT/ACPI decision is made.
> *
> */
> -int __init parse_spcr(bool earlycon)
> +int __init acpi_parse_spcr(bool earlycon)
> {
> - static char opts[64];
> + static char opts[ACPI_SPCR_OPTS_SIZE];
> + static char uart[ACPI_SPCR_BUF_SIZE];
> + static char iotype[ACPI_SPCR_BUF_SIZE];
> struct acpi_table_spcr *table;
> acpi_status status;
> - char *uart;
> - char *iotype;
> int baud_rate;
> int err;
>
> @@ -105,48 +58,6 @@ int __init parse_spcr(bool earlycon)
> if (ACPI_FAILURE(status))
> return -ENOENT;
>
> - if (table->header.revision < 2) {
> - err = -ENOENT;
> - pr_err("wrong table version\n");
> - goto done;
> - }
> -
> - if (table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) {
> - switch (ACPI_ACCESS_BIT_WIDTH((
> - table->serial_port.access_width))) {
> - default:
> - pr_err("Unexpected SPCR Access Width. Defaulting to byte size\n");
> - case 8:
> - iotype = "mmio";
> - break;
> - case 16:
> - iotype = "mmio16";
> - break;
> - case 32:
> - iotype = "mmio32";
> - break;
> - }
> - } else
> - iotype = "io";
> -
> - switch (table->interface_type) {
> - case ACPI_DBG2_ARM_SBSA_32BIT:
> - iotype = "mmio32";
> - /* fall through */
> - case ACPI_DBG2_ARM_PL011:
> - case ACPI_DBG2_ARM_SBSA_GENERIC:
> - case ACPI_DBG2_BCM2835:
> - uart = "pl011";
> - break;
> - case ACPI_DBG2_16550_COMPATIBLE:
> - case ACPI_DBG2_16550_SUBSET:
> - uart = "uart";
> - break;
> - default:
> - err = -ENOENT;
> - goto done;
> - }
> -
> switch (table->baud_rate) {
> case 3:
> baud_rate = 9600;
> @@ -165,43 +76,36 @@ int __init parse_spcr(bool earlycon)
> goto done;
> }
>
> - /*
> - * If the E44 erratum is required, then we need to tell the pl011
> - * driver to implement the work-around.
> - *
> - * The global variable is used by the probe function when it
> - * creates the UARTs, whether or not they're used as a console.
> - *
> - * If the user specifies "traditional" earlycon, the qdf2400_e44
> - * console name matches the EARLYCON_DECLARE() statement, and
> - * SPCR is not used. Parameter "earlycon" is false.
> - *
> - * If the user specifies "SPCR" earlycon, then we need to update
> - * the console name so that it also says "qdf2400_e44". Parameter
> - * "earlycon" is true.
> - *
> - * For consistency, if we change the console name, then we do it
> - * for everyone, not just earlycon.
> - */
> - if (qdf2400_erratum_44_present(&table->header)) {
> - qdf2400_e44_present = true;
> - if (earlycon)
> - uart = "qdf2400_e44";
> + switch (table->interface_type) {
> + case ACPI_DBG2_16550_COMPATIBLE:
> + case ACPI_DBG2_16550_SUBSET:
> + snprintf(uart, ACPI_SPCR_BUF_SIZE, "uart");
> + break;
> + default:
> + break;
> }
>
> - if (xgene_8250_erratum_present(table)) {
> - iotype = "mmio32";
> + if (table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) {
> + u8 width = ACPI_ACCESS_BIT_WIDTH((
> + table->serial_port.access_width));
> + switch (width) {
> + default:
> + pr_err("Unexpected SPCR Access Width. Defaulting to byte size\n");
> + case 8:
> + snprintf(iotype, ACPI_SPCR_BUF_SIZE, "mmio");
> + break;
> + case 16:
> + case 32:
> + snprintf(iotype, ACPI_SPCR_BUF_SIZE, "mmio%d", width);
> + break;
> + }
> + } else
> + snprintf(iotype, ACPI_SPCR_BUF_SIZE, "io");
>
> - /* for xgene v1 and v2 we don't know the clock rate of the
> - * UART so don't attempt to change to the baud rate state
> - * in the table because driver cannot calculate the dividers
> - */
> - snprintf(opts, sizeof(opts), "%s,%s,0x%llx", uart, iotype,
> - table->serial_port.address);
> - } else {
> - snprintf(opts, sizeof(opts), "%s,%s,0x%llx,%d", uart, iotype,
> - table->serial_port.address, baud_rate);
> - }
> + err = acpi_arch_setup_console(table, opts, uart, iotype, baud_rate,
> + earlycon);
> + if (err)
> + goto done;
>
> pr_info("console: %s\n", opts);
>
> @@ -209,7 +113,6 @@ int __init parse_spcr(bool earlycon)
> setup_earlycon(opts);
>
> err = add_preferred_console(uart, 0, opts + strlen(uart) + 1);
> -
> done:
> acpi_put_table((struct acpi_table_header *)table);
> return err;
> diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
> index 4c8b80f1c688..b22afb62c7a3 100644
> --- a/drivers/tty/serial/earlycon.c
> +++ b/drivers/tty/serial/earlycon.c
> @@ -196,26 +196,15 @@ int __init setup_earlycon(char *buf)
> return -ENOENT;
> }
>
> -/*
> - * When CONFIG_ACPI_SPCR_TABLE is defined, "earlycon" without parameters in
> - * command line does not start DT earlycon immediately, instead it defers
> - * starting it until DT/ACPI decision is made. At that time if ACPI is enabled
> - * call parse_spcr(), else call early_init_dt_scan_chosen_stdout()
> - */
> -bool earlycon_init_is_deferred __initdata;
> -
> /* early_param wrapper for setup_earlycon() */
> static int __init param_setup_earlycon(char *buf)
> {
> int err;
>
> - /*
> - * Just 'earlycon' is a valid param for devicetree earlycons;
> - * don't generate a warning from parse_early_params() in that case
> - */
> + /* Just 'earlycon' is a valid param for devicetree and ACPI SPCR. */
> if (!buf || !buf[0]) {
> if (IS_ENABLED(CONFIG_ACPI_SPCR_TABLE)) {
> - earlycon_init_is_deferred = true;
> + console_acpi_spcr_enable = true;
> return 0;
> } else if (!buf) {
> return early_init_dt_scan_chosen_stdout();
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index dc1ebfeeb5ec..875d7327d91c 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -1241,10 +1241,17 @@ static inline bool acpi_has_watchdog(void) { return false; }
> #endif
>
> #ifdef CONFIG_ACPI_SPCR_TABLE
> +#define ACPI_SPCR_OPTS_SIZE 64
> +#define ACPI_SPCR_BUF_SIZE 32
> extern bool qdf2400_e44_present;
> -int parse_spcr(bool earlycon);
> +extern bool console_acpi_spcr_enable __initdata;
> +extern int acpi_arch_setup_console(struct acpi_table_spcr *table,
> + char *opts, char *uart, char *iotype,
> + int baud_rate, bool earlycon);
> +int acpi_parse_spcr(bool earlycon);
> #else
> -static inline int parse_spcr(bool earlycon) { return 0; }
> +static const bool console_acpi_spcr_enable;
> +static inline int acpi_parse_spcr(bool earlycon) { return 0; }
> #endif
>
> #if IS_ENABLED(CONFIG_ACPI_GENERIC_GSI)
> diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
> index 37b044e78333..abfffb4b1c37 100644
> --- a/include/linux/serial_core.h
> +++ b/include/linux/serial_core.h
> @@ -376,10 +376,8 @@ extern int of_setup_earlycon(const struct earlycon_id *match,
> const char *options);
>
> #ifdef CONFIG_SERIAL_EARLYCON
> -extern bool earlycon_init_is_deferred __initdata;
> int setup_earlycon(char *buf);
> #else
> -static const bool earlycon_init_is_deferred;
> static inline int setup_earlycon(char *buf) { return 0; }
> #endif
>
>
^ permalink raw reply
* [PATCH V7 0/7] dmaengine: qcom_hidma: add support for bugfixed HW
From: Sinan Kaya @ 2017-12-13 0:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0ijQFO_PuwhBRrKovo4EW9Dck9fiT38wiCw6P5hHUjNuw@mail.gmail.com>
On 12/12/2017 7:36 AM, Rafael J. Wysocki wrote:
> On Tue, Dec 12, 2017 at 6:38 AM, Vinod Koul <vinod.koul@intel.com> wrote:
>> On Thu, Dec 07, 2017 at 04:10:24PM -0500, Sinan Kaya wrote:
>>> Introduce new ACPI and OF device ids for thw HW along with the helper
>>> functions.
>>>
>>> Changes from v6:
>>> * add const to the device callback parameter in fwnode.
>>> * reorganize the callbacks in the code
>>> * rename get_match_data() as device_get_match_data()
>>> * place pointer checks into acpi_get_match_data()
>>
>> This fails for me at 3rd patch. I am on -rc1 is there a dependency?
>
> There shouldn't be any.
>
> According to git, all changes to the files touched by the [3/7] are in
> -rc1 already.
>
Let me know if you were able to resolve the conflict. I can rebase against
a development tree if you can point me to there.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH V3 09/29] drm/i915: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-13 0:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513087456.3809.17.camel@linux.intel.com>
On 12/12/2017 9:04 AM, Joonas Lahtinen wrote:
> Hi,
>
> I sent this individual i915 patch to our CI, and it is passing on all platforms:
>
> https://patchwork.freedesktop.org/series/34822/
>
> Is it ok if I merge this to drm-tip already?
As long as you have this change in your tree, it should be safe.
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/include/linux/pci.h?id=7912af5c835bd86f2b0347a480e0f40e2fab30d0
>
> Regards, Joonas
>
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH] pinctrl: meson-axg: adjust spicc pin naming
From: Linus Walleij @ 2017-12-12 23:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171208152909.15632-1-yixun.lan@amlogic.com>
On Fri, Dec 8, 2017 at 4:29 PM, Yixun Lan <yixun.lan@amlogic.com> wrote:
> According to datasheet, we should use numbers for the pin naming
> instead of letters. The patch here try to fix this to keep
> the consistency.
>
> This patch should not bring any functional change.
>
> Fixes: 83c566806a68 ("pinctrl: meson-axg: Add new pinctrl driver for Meson AXG SoC")
> Suggested-by: Kevin Hilman <khilman@baylibre.com>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v5 4/9] drivers: base cacheinfo: Add support for ACPI based firmware tables
From: Rafael J. Wysocki @ 2017-12-12 23:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fdb60100-3973-b9e3-487a-882836f8751e@arm.com>
On Wed, Dec 13, 2017 at 12:37 AM, Jeremy Linton <jeremy.linton@arm.com> wrote:
> On 12/12/2017 05:02 PM, Rafael J. Wysocki wrote:
>>
>> On Tue, Dec 12, 2017 at 11:55 PM, Jeremy Linton <jeremy.linton@arm.com>
>> wrote:
>>>
>>> Hi,
>>>
>>>
>>> On 12/12/2017 11:25 AM, Rafael J. Wysocki wrote:
>>>>
>>>>
>>
>> [cut]
>
>
> (trimming list)
>
>
>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> What about converting this to using struct fwnode instead of adding
>>>>>> fields to it?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I didn't really want to add another field here, but I've also pointed
>>>>> out
>>>>> how I thought converting it to a fwnode wasn't a good choice.
>>>>>
>>>>> https://lkml.org/lkml/2017/11/20/502
>>>>>
>>>>> Mostly because IMHO its even more misleading (lacking any
>>>>> fwnode_operations)
>>>>> than misusing the of_node as a void *.
>>>>
>>>>
>>>>
>>>> I'm not sure what you mean.
>>>
>>>
>>>
>>> Converting the DT drivers/cacheinfo.c code to use a fwnode_handle is
>>> straightforward. But IMHO it doesn't solve the readability problem of
>>> either
>>> casting the ACPI/PPTT token directly to the resulting fwnode_handle *, or
>>> alternatively an actual fwnode_handle with bogus fwnode_operations to
>>> wrap
>>> that token.
>>
>>
>> I'm not talking about that at all.
>>
>>>>
>>>> Anyway, the idea is to have one pointer in there instead of two that
>>>> cannot be used at the same time and there's no reason why of_node
>>>> should be special.
>>>
>>>
>>>
>>> Avoid two pointers for size, or readability? Because the last
>>> version had a union with of_node, which isn't strictly necessary as I can
>>> just cast the pptt token to of_node. There is exactly one line of code
>>> after
>>> that which uses the token and it doesn't care about type.
>>
>>
>> So call this field "token" or similar. Don't call it "of_node" and
>> don't introduce another "firmware_node" thing in addition to that.
>> That just is a mess, sorry.
>
>
> I sort of agree, I think I can just change the whole of_node to a generic
> 'void *firmware_unique' which works fine for the PPTT code, it should also
> work for the DT code in cache_leaves_are_shared().
>
> The slight gocha is there is a bit of DT code which initially runs earlier
> that uses of_node as an indirect parameter to a couple functions (by just
> passing the cacheinfo). Let me see if I can tweak that a bit.
>
> Frankly, If I understood completely all the *priv cases I suspect it might
> be possible to collapse *of_node into that as well. That is as long as no
> one decides to flush out DT on x86, or PPTT on x86.
I'm not aware of any plans to go in that direction.
Anyway, that would be a worry of whoever wanted to do that. No need
to worry about it upfront.
^ permalink raw reply
* [PATCH v2 07/19] arm64: insn: Add encoder for bitwise operations using litterals
From: Peter Maydell @ 2017-12-12 23:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5A3020DA.8010309@arm.com>
On 12 December 2017 at 18:32, James Morse <james.morse@arm.com> wrote:
> As this is over my head, I've been pushing random encodings through gas/objdump
> and then tracing them through here.... can this encode 0xf80000000fffffff?
>
> gas thinks this is legal:
> | 0: 92458000 and x0, x0, #0xf80000000fffffff
>
> I make that N=1, S=0x20, R=0x05.
> (I'm still working out what 'S' means)
This comment from QEMU (describing the decode direction, ie
immn,imms,immr => immediate) might assist:
/* The bit patterns we create here are 64 bit patterns which
* are vectors of identical elements of size e = 2, 4, 8, 16, 32 or
* 64 bits each. Each element contains the same value: a run
* of between 1 and e-1 non-zero bits, rotated within the
* element by between 0 and e-1 bits.
*
* The element size and run length are encoded into immn (1 bit)
* and imms (6 bits) as follows:
* 64 bit elements: immn = 1, imms = <length of run - 1>
* 32 bit elements: immn = 0, imms = 0 : <length of run - 1>
* 16 bit elements: immn = 0, imms = 10 : <length of run - 1>
* 8 bit elements: immn = 0, imms = 110 : <length of run - 1>
* 4 bit elements: immn = 0, imms = 1110 : <length of run - 1>
* 2 bit elements: immn = 0, imms = 11110 : <length of run - 1>
* Notice that immn = 0, imms = 11111x is the only combination
* not covered by one of the above options; this is reserved.
* Further, <length of run - 1> all-ones is a reserved pattern.
*
* In all cases the rotation is by immr % e (and immr is 6 bits).
*/
so N=1 S=0x20 means run length 33, element size 64 (and
indeed your immediate has a run of 33 set bits).
(The Arm ARM pseudocode is confusing here because it merges
the handling of logical-immediates and bitfield instructions
together, which is nice if you're a hardware engineer. For
software you're much better off keeping the two separate.)
thanks
-- PMM
^ permalink raw reply
* [PATCH v5 4/9] drivers: base cacheinfo: Add support for ACPI based firmware tables
From: Jeremy Linton @ 2017-12-12 23:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0gnWn_05XN7r+Mwwgc0ca5vx8wgAQ1A8aAwOPvc9H899Q@mail.gmail.com>
On 12/12/2017 05:02 PM, Rafael J. Wysocki wrote:
> On Tue, Dec 12, 2017 at 11:55 PM, Jeremy Linton <jeremy.linton@arm.com> wrote:
>> Hi,
>>
>>
>> On 12/12/2017 11:25 AM, Rafael J. Wysocki wrote:
>>>
>
> [cut]
(trimming list)
>
>>>>>
>>>>>
>>>>>
>>>>> What about converting this to using struct fwnode instead of adding
>>>>> fields to it?
>>>>
>>>>
>>>>
>>>> I didn't really want to add another field here, but I've also pointed out
>>>> how I thought converting it to a fwnode wasn't a good choice.
>>>>
>>>> https://lkml.org/lkml/2017/11/20/502
>>>>
>>>> Mostly because IMHO its even more misleading (lacking any
>>>> fwnode_operations)
>>>> than misusing the of_node as a void *.
>>>
>>>
>>> I'm not sure what you mean.
>>
>>
>> Converting the DT drivers/cacheinfo.c code to use a fwnode_handle is
>> straightforward. But IMHO it doesn't solve the readability problem of either
>> casting the ACPI/PPTT token directly to the resulting fwnode_handle *, or
>> alternatively an actual fwnode_handle with bogus fwnode_operations to wrap
>> that token.
>
> I'm not talking about that at all.
>
>>>
>>> Anyway, the idea is to have one pointer in there instead of two that
>>> cannot be used at the same time and there's no reason why of_node
>>> should be special.
>>
>>
>> Avoid two pointers for size, or readability? Because the last
>> version had a union with of_node, which isn't strictly necessary as I can
>> just cast the pptt token to of_node. There is exactly one line of code after
>> that which uses the token and it doesn't care about type.
>
> So call this field "token" or similar. Don't call it "of_node" and
> don't introduce another "firmware_node" thing in addition to that.
> That just is a mess, sorry.
I sort of agree, I think I can just change the whole of_node to a
generic 'void *firmware_unique' which works fine for the PPTT code, it
should also work for the DT code in cache_leaves_are_shared().
The slight gocha is there is a bit of DT code which initially runs
earlier that uses of_node as an indirect parameter to a couple functions
(by just passing the cacheinfo). Let me see if I can tweak that a bit.
Frankly, If I understood completely all the *priv cases I suspect it
might be possible to collapse *of_node into that as well. That is as
long as no one decides to flush out DT on x86, or PPTT on x86.
^ permalink raw reply
* [RFC PATCH][resend] pciehp: fix a race between pciehp and removing operations by sysfs
From: Bjorn Helgaas @ 2017-12-12 23:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <55cc79f2-cece-c84b-5c95-050a954d3669@huawei.com>
On Tue, Dec 12, 2017 at 07:30:31PM +0800, Xiongfeng Wang wrote:
> This patch seems to introduce another issue. pciehp_power_thread() use
> 'container_of' to get the 'slot' according to 'work_struct'.
> If the 'slot' has been freed before that, there will be an issue.
1) This claims to be a resend, but I don't see any previous patches
with this subject or from this email address. Maybe the previous
posting didn't make it to the list because it ran afoul of the
mailing list guidelines at
http://vger.kernel.org/majordomo-info.html#taboo?
2) Please also use the Linux convention of putting your response
*below* the question.
3) Since you say your patch introduces another issue, I'll drop the
patch for now, and you can post a revised version when it's ready.
> On 2017/12/12 16:29, Xiongfeng Wang wrote:
> > When the Attention button on a PCIE slot is pressed, 5 seconds later,
> > pciehp_power_thread() will be scheduled on slot->wq. This function will
> > get a global mutex lock 'pci_rescan_remove_lock' in
> > pciehp_unconfigure_device().
> >
> > At the same time, we remove the pcie port by sysfs, which results in
> > pci_stop_and_remove_bus_device_locked() called. This function will get
> > the global mutex lock 'pci_rescan_remove_lock', and then release the
> > struct 'ctrl', which will wait until the work_struct on slot->wq is
> > finished.
> >
> > If pci_stop_and_remove_bus_device_locked() got the mutex lock, and
> > before it drains workqueue slot->wq, pciehp_power_thread() is scheduled
> > on slot->wq and tries to get the mutex lock. Then
> > pci_stop_and_remove_bus_device_locked() tries to drain workqueue
> > slot->wq and wait until work struct 'pciehp_power_thread()' is finished.
> > Then a hung_task happens.
> >
> > This patch solve this problem by schedule 'pciehp_power_thread()' on a
> > system workqueue instead of slot->wq.
> >
> > The Call Trace we got is as following.
> >
> > INFO: task kworker/0:2:4413 blocked for more than 120 seconds.
> > Tainted: P W O 4.12.0-rc1 #1
> > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > kworker/0:2 D 0 4413 2 0x00000000
> > Workqueue: pciehp-0 pciehp_power_thread
> > Call trace:
> > [<ffff0000080861d4>] __switch_to+0x94/0xa8
> > [<ffff000008bea9c0>] __schedule+0x1b0/0x708
> > [<ffff000008beaf58>] schedule+0x40/0xa4
> > [<ffff000008beb33c>] schedule_preempt_disabled+0x28/0x40
> > [<ffff000008bec1dc>] __mutex_lock.isra.8+0x148/0x50c
> > [<ffff000008bec5c4>] __mutex_lock_slowpath+0x24/0x30
> > [<ffff000008bec618>] mutex_lock+0x48/0x54
> > [<ffff0000084d8188>] pci_lock_rescan_remove+0x20/0x28
> > [<ffff0000084f87c0>] pciehp_unconfigure_device+0x54/0x1cc
> > [<ffff0000084f8260>] pciehp_disable_slot+0x4c/0xbc
> > [<ffff0000084f8370>] pciehp_power_thread+0xa0/0xb8
> > [<ffff0000080e9ce8>] process_one_work+0x13c/0x3f8
> > [<ffff0000080ea004>] worker_thread+0x60/0x3e4
> > [<ffff0000080f0814>] kthread+0x10c/0x138
> > [<ffff0000080836c0>] ret_from_fork+0x10/0x50
> > INFO: task bash:31732 blocked for more than 120 seconds.
> > Tainted: P W O 4.12.0-rc1 #1
> > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > bash D 0 31732 1 0x00000009
> > Call trace:
> > [<ffff0000080861d4>] __switch_to+0x94/0xa8
> > [<ffff000008bea9c0>] __schedule+0x1b0/0x708
> > [<ffff000008beaf58>] schedule+0x40/0xa4
> > [<ffff000008bee7b4>] schedule_timeout+0x1a0/0x340
> > [<ffff000008bebb88>] wait_for_common+0x108/0x1bc
> > [<ffff000008bebc64>] wait_for_completion+0x28/0x34
> > [<ffff0000080e7594>] flush_workqueue+0x130/0x488
> > [<ffff0000080e79b0>] drain_workqueue+0xc4/0x164
> > [<ffff0000080ec3cc>] destroy_workqueue+0x28/0x1f4
> > [<ffff0000084fa094>] pciehp_release_ctrl+0x34/0xe0
> > [<ffff0000084f75b0>] pciehp_remove+0x30/0x3c
> > [<ffff0000084f24d8>] pcie_port_remove_service+0x3c/0x54
> > [<ffff00000876b1e4>] device_release_driver_internal+0x150/0x1d0
> > [<ffff00000876b28c>] device_release_driver+0x28/0x34
> > [<ffff00000876a018>] bus_remove_device+0xe0/0x11c
> > [<ffff000008766348>] device_del+0x200/0x304
> > [<ffff00000876646c>] device_unregister+0x20/0x38
> > [<ffff0000084f2560>] remove_iter+0x44/0x54
> > [<ffff000008765230>] device_for_each_child+0x4c/0x90
> > [<ffff0000084f2c98>] pcie_port_device_remove+0x2c/0x48
> > [<ffff0000084f2f48>] pcie_portdrv_remove+0x60/0x6c
> > [<ffff0000084e3de4>] pci_device_remove+0x48/0x110
> > [<ffff00000876b1e4>] device_release_driver_internal+0x150/0x1d0
> > [<ffff00000876b28c>] device_release_driver+0x28/0x34
> > [<ffff0000084db028>] pci_stop_bus_device+0x9c/0xac
> > [<ffff0000084db190>] pci_stop_and_remove_bus_device_locked+0x24/0x3c
> > [<ffff0000084e5eb0>] remove_store+0x74/0x80
> > [<ffff000008764680>] dev_attr_store+0x44/0x5c
> > [<ffff0000082e7e1c>] sysfs_kf_write+0x5c/0x74
> > [<ffff0000082e7014>] kernfs_fop_write+0xcc/0x1dc
> > [<ffff0000082602e0>] __vfs_write+0x48/0x13c
> > [<ffff00000826174c>] vfs_write+0xa8/0x198
> > [<ffff000008262ce8>] SyS_write+0x54/0xb0
> > [<ffff000008083730>] el0_svc_naked+0x24/0x28
> >
> > Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
> > ---
> > drivers/pci/hotplug/pciehp_ctrl.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/pci/hotplug/pciehp_ctrl.c b/drivers/pci/hotplug/pciehp_ctrl.c
> > index 83f3d4a..9d39d85 100644
> > --- a/drivers/pci/hotplug/pciehp_ctrl.c
> > +++ b/drivers/pci/hotplug/pciehp_ctrl.c
> > @@ -221,7 +221,7 @@ static void pciehp_queue_power_work(struct slot *p_slot, int req)
> > info->p_slot = p_slot;
> > INIT_WORK(&info->work, pciehp_power_thread);
> > info->req = req;
> > - queue_work(p_slot->wq, &info->work);
> > + schedule_work(&info->work);
> > }
> >
> > void pciehp_queue_pushbutton_work(struct work_struct *work)
> >
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* How to debug "insecure W+X mapping"?
From: Laura Abbott @ 2017-12-12 23:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bff5a2b3-0d93-5f55-c129-4b14a5a09b45@codeaurora.org>
On 12/12/2017 02:57 PM, Timur Tabi wrote:
> We have a 4.10-based kernel that occasionally displays an insecure W+X mapping (courtesy of CONFIG_DEBUG_WX):
>
> [??? 7.151680] arm64/mm: Found insecure W+X mapping at address 0000345a049d2000/0x345a049d2000
> ...
> [??? 7.435481] Checked W+X mappings: FAILED, 4 W+X pages found, 0 non-UXN pages found
>
> The number of actual W+X pages varies, e.g. sometimes it says 6 pages.
>
> How do I go about debugging this? How do I identify the source of 0000345a049d2000?
>
That's a funny address. The check was written to scan the init_mm
page table but that's not a kernel address on arm64. It almost looks
like something set up a userspace mapping very early in the boot process?
I'd start by dumping the physical address at that address to
see if that gives a suggestion where the mapping came from.
Thanks,
Laura
^ permalink raw reply
* [PATCH 3/6] pinctrl: stm32: Add STM32MP157 MPU support
From: Rob Herring @ 2017-12-12 23:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512742277-28205-4-git-send-email-ludovic.Barre@st.com>
On Fri, Dec 08, 2017 at 03:11:14PM +0100, Ludovic Barre wrote:
> From: Ludovic Barre <ludovic.barre@st.com>
>
> This driver consists of 2 controllers due to a hole in mapping:
> -1 controller for GPIO bankA to K.
> -1 controller for GPIO bankZ.
>
> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
> ---
> .../bindings/pinctrl/st,stm32-pinctrl.txt | 2 +
Reviewed-by: Rob Herring <robh@kernel.org>
> drivers/pinctrl/stm32/Kconfig | 6 +
> drivers/pinctrl/stm32/Makefile | 1 +
> drivers/pinctrl/stm32/pinctrl-stm32mp157.c | 2188 ++++++++++++++++++++
> 4 files changed, 2197 insertions(+)
> create mode 100644 drivers/pinctrl/stm32/pinctrl-stm32mp157.c
^ permalink raw reply
* [PATCH 2/6] ARM: stm32: add initial support for STM32MP157
From: Rob Herring @ 2017-12-12 23:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512742277-28205-3-git-send-email-ludovic.Barre@st.com>
On Fri, Dec 08, 2017 at 03:11:13PM +0100, Ludovic Barre wrote:
> From: Ludovic Barre <ludovic.barre@st.com>
>
> This patch adds initial support of STM32MP157 microprocessor (MPU)
> based on Arm Cortex-A7. Under new ARCH_STM32_MPU flag we select the
> needed Cortex-A infrastructure (like gic, timer,...)
>
> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
> ---
> Documentation/arm/stm32/stm32mp157-overview.txt | 12 ++++++++++++
> Documentation/devicetree/bindings/arm/stm32.txt | 1 +
Please split bindings to separate patches.
> arch/arm/mach-stm32/Kconfig | 22 ++++++++++++++++++++--
> arch/arm/mach-stm32/Makefile | 1 +
> arch/arm/mach-stm32/board-mpu-dt.c | 16 ++++++++++++++++
> 5 files changed, 50 insertions(+), 2 deletions(-)
> create mode 100644 Documentation/arm/stm32/stm32mp157-overview.txt
> create mode 100644 arch/arm/mach-stm32/board-mpu-dt.c
>
> diff --git a/Documentation/arm/stm32/stm32mp157-overview.txt b/Documentation/arm/stm32/stm32mp157-overview.txt
> new file mode 100644
> index 0000000..8a3e7cb
> --- /dev/null
> +++ b/Documentation/arm/stm32/stm32mp157-overview.txt
I think new documentation files should be rst format and fit into the
built documentation. We don't have an SoC description doc for most SoCs.
> @@ -0,0 +1,12 @@
> + STM32MP157 Overview
> + ===================
> +
> + Introduction
> + ------------
> + The STM32MP157 is a Cortex-A MPU aimed at various applications.
> + It features:
> + - Dual core Cortex-A7 application core
> + - 2D/3D image composition with GPU
> + - Standard memories interface support
> + - Standard connectivity, widely inherited from the STM32 MCU family
> + - Comprehensive security support
Perhaps make this part of the kconfig entry help.
> diff --git a/Documentation/devicetree/bindings/arm/stm32.txt b/Documentation/devicetree/bindings/arm/stm32.txt
> index 05762b0..6808ed9 100644
> --- a/Documentation/devicetree/bindings/arm/stm32.txt
> +++ b/Documentation/devicetree/bindings/arm/stm32.txt
> @@ -7,3 +7,4 @@ using one of the following compatible strings:
> st,stm32f469
> st,stm32f746
> st,stm32h743
> + st,stm32mp157
> diff --git a/arch/arm/mach-stm32/Kconfig b/arch/arm/mach-stm32/Kconfig
> index c8059ea..2b227c7 100644
> --- a/arch/arm/mach-stm32/Kconfig
> +++ b/arch/arm/mach-stm32/Kconfig
> @@ -1,12 +1,12 @@
> menuconfig ARCH_STM32
> - bool "STMicrolectronics STM32 family" if ARM_SINGLE_ARMV7M
> + bool "STMicrolectronics STM32 family" if ARM_SINGLE_ARMV7M || ARCH_MULTI_V7
> select ARCH_HAS_RESET_CONTROLLER
> select CLKSRC_STM32
> select PINCTRL
> select RESET_CONTROLLER
> select STM32_EXTI
> help
> - Support for STMicroelectronics STM32 MCU family
> + Support for STMicroelectronics STM32 MCU/MPU family
>
> if ARCH_STM32
>
> @@ -40,4 +40,22 @@ config MACH_STM32H743
>
> endif
>
> +if ARCH_MULTI_V7
> +
> +config ARCH_STM32_MPU
> + bool "STMicrolectronics STM32 MPU"
> + default y
> + select ARM_GIC
> + select HAVE_ARM_ARCH_TIMER
> + select ARM_PSCI
> + help
> + Support for STMicroelectronics STM32 Microprocessors.
> +
> +config MACH_STM32MP157
Is this actually used?
> + bool "STMicrolectronics STM32MP157"
> + depends on ARCH_STM32_MPU
> + default y
> +
> +endif
> +
> endif
^ permalink raw reply
* [PATCH] ARM: pxa/lubbock: add GPIO driver for LUB_MISC_WR register
From: Russell King - ARM Linux @ 2017-12-12 23:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <874lovg095.fsf@belgarion.home>
On Tue, Dec 12, 2017 at 09:27:34PM +0100, Robert Jarzmik wrote:
> Russell King <rmk+kernel@armlinux.org.uk> writes:
>
> > Add a gpio driver for the lubbock miscellaneous write IO register so we
> > can take advantage of subsystems modelled around gpiolib, rather than
> > having to provide platform specific callbacks.
> >
> > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
>
> Hi Russell and Linux,
>
> It looks certainly good to me. It's unfortunate in the current status of
> linux-next I have, gpio-reg.c seems broken (that one is for Linus in [1] and
> [2]), and therefore I can't test it live.
It won't do much on its own without some patches to make use of the new
GPIOs... but it will be used as the direct register write becomes a
call to gpio-reg's ->set_multiple() method.
Further patches will be switching various bits over to using gpiod
stuff for some sa11x0/pxa bits, and on some platforms completely
eliminating the legacy "board control register" manipulations and
hacks spread around the kernel tree.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH 1/1] dt-bindings: arm: document supported STM32 SoC family
From: Rob Herring @ 2017-12-12 23:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212210348.proilmqmxf4yl5jn@rob-hp-laptop>
On Tue, Dec 12, 2017 at 03:03:48PM -0600, Rob Herring wrote:
> On Fri, Dec 08, 2017 at 02:56:34PM +0100, Ludovic Barre wrote:
> > From: Ludovic Barre <ludovic.barre@st.com>
> >
> > This adds a list of supported STM32 SoC bindings.
> >
> > Signed-off-by: Gwenael Treuveur <gwenael.treuveur@st.com>
> > Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
> > ---
> > Documentation/devicetree/bindings/arm/stm32.txt | 9 +++++++++
> > 1 file changed, 9 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/arm/stm32.txt
>
> Applied, thanks.
Now dropped as this will conflict with your other series. Send this with
the other series or indicate who should apply.
Reviewed-by: Rob Herring <robh@kernel.org>
Rob
^ permalink raw reply
* [PATCH] ARM: pxa/lubbock: add GPIO driver for LUB_MISC_WR register
From: Linus Walleij @ 2017-12-12 23:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1eOTFj-0008MB-Fj@rmk-PC.armlinux.org.uk>
On Mon, Dec 11, 2017 at 7:56 PM, Russell King
<rmk+kernel@armlinux.org.uk> wrote:
> Add a gpio driver for the lubbock miscellaneous write IO register so we
> can take advantage of subsystems modelled around gpiolib, rather than
> having to provide platform specific callbacks.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM: pxa/lubbock: add GPIO driver for LUB_MISC_WR register
From: Linus Walleij @ 2017-12-12 23:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <874lovg095.fsf@belgarion.home>
On Tue, Dec 12, 2017 at 9:27 PM, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> Russell King <rmk+kernel@armlinux.org.uk> writes:
>
>> Add a gpio driver for the lubbock miscellaneous write IO register so we
>> can take advantage of subsystems modelled around gpiolib, rather than
>> having to provide platform specific callbacks.
>>
>> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
>
> Hi Russell and Linux,
>
> It looks certainly good to me. It's unfortunate in the current status of
> linux-next I have, gpio-reg.c seems broken (that one is for Linus in [1] and
> [2]), and therefore I can't test it live.
OK I have applied a patch fixing it, sorry for not preparing the trees and
pushing it out quicker :(
> Nonetheless, do you want me to carry it through the pxa tree or do you want to
> keep it through your tree ?
By all means carry it in the PXA tree.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v5 4/9] drivers: base cacheinfo: Add support for ACPI based firmware tables
From: Rafael J. Wysocki @ 2017-12-12 23:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9bb1c58a-8d48-9952-e292-60b2bcb87a51@arm.com>
On Tue, Dec 12, 2017 at 11:55 PM, Jeremy Linton <jeremy.linton@arm.com> wrote:
> Hi,
>
>
> On 12/12/2017 11:25 AM, Rafael J. Wysocki wrote:
>>
[cut]
>>>>
>>>>
>>>>
>>>> What about converting this to using struct fwnode instead of adding
>>>> fields to it?
>>>
>>>
>>>
>>> I didn't really want to add another field here, but I've also pointed out
>>> how I thought converting it to a fwnode wasn't a good choice.
>>>
>>> https://lkml.org/lkml/2017/11/20/502
>>>
>>> Mostly because IMHO its even more misleading (lacking any
>>> fwnode_operations)
>>> than misusing the of_node as a void *.
>>
>>
>> I'm not sure what you mean.
>
>
> Converting the DT drivers/cacheinfo.c code to use a fwnode_handle is
> straightforward. But IMHO it doesn't solve the readability problem of either
> casting the ACPI/PPTT token directly to the resulting fwnode_handle *, or
> alternatively an actual fwnode_handle with bogus fwnode_operations to wrap
> that token.
I'm not talking about that at all.
>>
>> Anyway, the idea is to have one pointer in there instead of two that
>> cannot be used at the same time and there's no reason why of_node
>> should be special.
>
>
> Avoid two pointers for size, or readability? Because the last
> version had a union with of_node, which isn't strictly necessary as I can
> just cast the pptt token to of_node. There is exactly one line of code after
> that which uses the token and it doesn't care about type.
So call this field "token" or similar. Don't call it "of_node" and
don't introduce another "firmware_node" thing in addition to that.
That just is a mess, sorry.
Thanks,
Rafael
^ permalink raw reply
* How to debug "insecure W+X mapping"?
From: Timur Tabi @ 2017-12-12 22:57 UTC (permalink / raw)
To: linux-arm-kernel
We have a 4.10-based kernel that occasionally displays an insecure W+X
mapping (courtesy of CONFIG_DEBUG_WX):
[ 7.151680] arm64/mm: Found insecure W+X mapping at address
0000345a049d2000/0x345a049d2000
...
[ 7.435481] Checked W+X mappings: FAILED, 4 W+X pages found, 0
non-UXN pages found
The number of actual W+X pages varies, e.g. sometimes it says 6 pages.
How do I go about debugging this? How do I identify the source of
0000345a049d2000?
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox