* [PATCH V6 06/10] dmaengine: qcom_hidma: bring out interrupt cause
From: Sinan Kaya @ 2016-10-19 17:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476899512-20431-1-git-send-email-okaya@codeaurora.org>
Bring out the interrupt cause to the top level so that MSI interrupts
can be hooked at a later stage.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/dma/qcom/hidma_ll.c | 62 ++++++++++++++++++++++++---------------------
1 file changed, 33 insertions(+), 29 deletions(-)
diff --git a/drivers/dma/qcom/hidma_ll.c b/drivers/dma/qcom/hidma_ll.c
index 29fef4f..6bdea90 100644
--- a/drivers/dma/qcom/hidma_ll.c
+++ b/drivers/dma/qcom/hidma_ll.c
@@ -411,12 +411,24 @@ static int hidma_ll_reset(struct hidma_lldev *lldev)
* requests traditionally to the destination, this concept does not apply
* here for this HW.
*/
-irqreturn_t hidma_ll_inthandler(int chirq, void *arg)
+static void hidma_ll_int_handler_internal(struct hidma_lldev *lldev, int cause)
{
- struct hidma_lldev *lldev = arg;
- u32 status;
- u32 enable;
- u32 cause;
+ if (cause & HIDMA_ERR_INT_MASK) {
+ dev_err(lldev->dev, "error 0x%x, disabling...\n",
+ cause);
+
+ /* Clear out pending interrupts */
+ writel(cause, lldev->evca + HIDMA_EVCA_IRQ_CLR_REG);
+
+ /* No further submissions. */
+ hidma_ll_disable(lldev);
+
+ /* Driver completes the txn and intimates the client.*/
+ hidma_cleanup_pending_tre(lldev, 0xFF,
+ HIDMA_EVRE_STATUS_ERROR);
+
+ return;
+ }
/*
* Fine tuned for this HW...
@@ -425,35 +437,28 @@ irqreturn_t hidma_ll_inthandler(int chirq, void *arg)
* read and write accessors are used for performance reasons due to
* interrupt delivery guarantees. Do not copy this code blindly and
* expect that to work.
+ *
+ * Try to consume as many EVREs as possible.
*/
+ hidma_handle_tre_completion(lldev);
+
+ /* We consumed TREs or there are pending TREs or EVREs. */
+ writel_relaxed(cause, lldev->evca + HIDMA_EVCA_IRQ_CLR_REG);
+}
+
+irqreturn_t hidma_ll_inthandler(int chirq, void *arg)
+{
+ struct hidma_lldev *lldev = arg;
+ u32 status;
+ u32 enable;
+ u32 cause;
+
status = readl_relaxed(lldev->evca + HIDMA_EVCA_IRQ_STAT_REG);
enable = readl_relaxed(lldev->evca + HIDMA_EVCA_IRQ_EN_REG);
cause = status & enable;
while (cause) {
- if (cause & HIDMA_ERR_INT_MASK) {
- dev_err(lldev->dev, "error 0x%x, disabling...\n",
- cause);
-
- /* Clear out pending interrupts */
- writel(cause, lldev->evca + HIDMA_EVCA_IRQ_CLR_REG);
-
- /* No further submissions. */
- hidma_ll_disable(lldev);
-
- /* Driver completes the txn and intimates the client.*/
- hidma_cleanup_pending_tre(lldev, 0xFF,
- HIDMA_EVRE_STATUS_ERROR);
- goto out;
- }
-
- /*
- * Try to consume as many EVREs as possible.
- */
- hidma_handle_tre_completion(lldev);
-
- /* We consumed TREs or there are pending TREs or EVREs. */
- writel_relaxed(cause, lldev->evca + HIDMA_EVCA_IRQ_CLR_REG);
+ hidma_ll_int_handler_internal(lldev, cause);
/*
* Another interrupt might have arrived while we are
@@ -464,7 +469,6 @@ irqreturn_t hidma_ll_inthandler(int chirq, void *arg)
cause = status & enable;
}
-out:
return IRQ_HANDLED;
}
--
1.9.1
^ permalink raw reply related
* [PATCH V6 05/10] dmaengine: qcom_hidma: make pending_tre_count atomic
From: Sinan Kaya @ 2016-10-19 17:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476899512-20431-1-git-send-email-okaya@codeaurora.org>
Getting ready for the MSI interrupts. The pending_tre_count is used
in the interrupt handler to make sure all outstanding requests are
serviced.
The driver will allocate 11 MSI interrupts. Each MSI interrupt can be
assigned to a different CPU. Then, we have a race condition for common
variables as they share the same interrupt handler with a different
cause bit and they can potentially be executed in parallel. Making this
variable atomic so that it can be updated from multiple processor
contexts.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/dma/qcom/hidma.h | 2 +-
drivers/dma/qcom/hidma_dbg.c | 3 ++-
drivers/dma/qcom/hidma_ll.c | 13 ++++++-------
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/dma/qcom/hidma.h b/drivers/dma/qcom/hidma.h
index b4a512f..8318de7 100644
--- a/drivers/dma/qcom/hidma.h
+++ b/drivers/dma/qcom/hidma.h
@@ -58,7 +58,7 @@ struct hidma_lldev {
void __iomem *evca; /* Event Channel address */
struct hidma_tre
**pending_tre_list; /* Pointers to pending TREs */
- s32 pending_tre_count; /* Number of TREs pending */
+ atomic_t pending_tre_count; /* Number of TREs pending */
void *tre_ring; /* TRE ring */
dma_addr_t tre_dma; /* TRE ring to be shared with HW */
diff --git a/drivers/dma/qcom/hidma_dbg.c b/drivers/dma/qcom/hidma_dbg.c
index 3d83b99..3bdcb80 100644
--- a/drivers/dma/qcom/hidma_dbg.c
+++ b/drivers/dma/qcom/hidma_dbg.c
@@ -74,7 +74,8 @@ static void hidma_ll_devstats(struct seq_file *s, void *llhndl)
seq_printf(s, "tre_ring_handle=%pap\n", &lldev->tre_dma);
seq_printf(s, "tre_ring_size = 0x%x\n", lldev->tre_ring_size);
seq_printf(s, "tre_processed_off = 0x%x\n", lldev->tre_processed_off);
- seq_printf(s, "pending_tre_count=%d\n", lldev->pending_tre_count);
+ seq_printf(s, "pending_tre_count=%d\n",
+ atomic_read(&lldev->pending_tre_count));
seq_printf(s, "evca=%p\n", lldev->evca);
seq_printf(s, "evre_ring=%p\n", lldev->evre_ring);
seq_printf(s, "evre_ring_handle=%pap\n", &lldev->evre_dma);
diff --git a/drivers/dma/qcom/hidma_ll.c b/drivers/dma/qcom/hidma_ll.c
index 3224f24..29fef4f 100644
--- a/drivers/dma/qcom/hidma_ll.c
+++ b/drivers/dma/qcom/hidma_ll.c
@@ -218,10 +218,9 @@ static int hidma_post_completed(struct hidma_lldev *lldev, int tre_iterator,
* Keep track of pending TREs that SW is expecting to receive
* from HW. We got one now. Decrement our counter.
*/
- lldev->pending_tre_count--;
- if (lldev->pending_tre_count < 0) {
+ if (atomic_dec_return(&lldev->pending_tre_count) < 0) {
dev_warn(lldev->dev, "tre count mismatch on completion");
- lldev->pending_tre_count = 0;
+ atomic_set(&lldev->pending_tre_count, 0);
}
spin_unlock_irqrestore(&lldev->lock, flags);
@@ -321,7 +320,7 @@ void hidma_cleanup_pending_tre(struct hidma_lldev *lldev, u8 err_info,
u32 tre_read_off;
tre_iterator = lldev->tre_processed_off;
- while (lldev->pending_tre_count) {
+ while (atomic_read(&lldev->pending_tre_count)) {
if (hidma_post_completed(lldev, tre_iterator, err_info,
err_code))
break;
@@ -548,7 +547,7 @@ void hidma_ll_queue_request(struct hidma_lldev *lldev, u32 tre_ch)
tre->err_code = 0;
tre->err_info = 0;
tre->queued = 1;
- lldev->pending_tre_count++;
+ atomic_inc(&lldev->pending_tre_count);
lldev->tre_write_offset = (lldev->tre_write_offset + HIDMA_TRE_SIZE)
% lldev->tre_ring_size;
spin_unlock_irqrestore(&lldev->lock, flags);
@@ -654,7 +653,7 @@ int hidma_ll_setup(struct hidma_lldev *lldev)
u32 val;
u32 nr_tres = lldev->nr_tres;
- lldev->pending_tre_count = 0;
+ atomic_set(&lldev->pending_tre_count, 0);
lldev->tre_processed_off = 0;
lldev->evre_processed_off = 0;
lldev->tre_write_offset = 0;
@@ -816,7 +815,7 @@ int hidma_ll_uninit(struct hidma_lldev *lldev)
tasklet_kill(&lldev->task);
memset(lldev->trepool, 0, required_bytes);
lldev->trepool = NULL;
- lldev->pending_tre_count = 0;
+ atomic_set(&lldev->pending_tre_count, 0);
lldev->tre_write_offset = 0;
rc = hidma_ll_reset(lldev);
--
1.9.1
^ permalink raw reply related
* [PATCH V6 04/10] dmaengine: qcom_hidma: configure DMA and MSI for OF
From: Sinan Kaya @ 2016-10-19 17:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476899512-20431-1-git-send-email-okaya@codeaurora.org>
Configure the DMA bindings for the device tree based firmware.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/dma/qcom/hidma_mgmt.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/qcom/hidma_mgmt.c b/drivers/dma/qcom/hidma_mgmt.c
index 82f36e4..185d29c 100644
--- a/drivers/dma/qcom/hidma_mgmt.c
+++ b/drivers/dma/qcom/hidma_mgmt.c
@@ -375,8 +375,15 @@ static int __init hidma_mgmt_of_populate_channels(struct device_node *np)
ret = PTR_ERR(new_pdev);
goto out;
}
+ of_node_get(child);
+ new_pdev->dev.of_node = child;
of_dma_configure(&new_pdev->dev, child);
-
+ /*
+ * It is assumed that calling of_msi_configure is safe on
+ * platforms with or without MSI support.
+ */
+ of_msi_configure(&new_pdev->dev, child);
+ of_node_put(child);
kfree(res);
res = NULL;
}
--
1.9.1
^ permalink raw reply related
* [PATCH V6 03/10] of: irq: make of_msi_configure accessible from modules
From: Sinan Kaya @ 2016-10-19 17:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476899512-20431-1-git-send-email-okaya@codeaurora.org>
The of_msi_configure routine is only accessible by the built-in
kernel drivers. Export this function so that modules can use it
too.
This function is useful for configuring MSI on child device tree
nodes on hierarchical objects.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/of/irq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 393fea8..3fda9a3 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -697,3 +697,4 @@ void of_msi_configure(struct device *dev, struct device_node *np)
dev_set_msi_domain(dev,
of_msi_get_domain(dev, np, DOMAIN_BUS_PLATFORM_MSI));
}
+EXPORT_SYMBOL_GPL(of_msi_configure);
--
1.9.1
^ permalink raw reply related
* [PATCH V6 02/10] Documentation: DT: qcom_hidma: correct spelling mistakes
From: Sinan Kaya @ 2016-10-19 17:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476899512-20431-1-git-send-email-okaya@codeaurora.org>
Fix the spelling mistakes and extra and statements in the sentences.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
index 2c5e4b8..55492c2 100644
--- a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
+++ b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
@@ -5,13 +5,13 @@ memcpy and memset capabilities. It has been designed for virtualized
environments.
Each HIDMA HW instance consists of multiple DMA channels. These channels
-share the same bandwidth. The bandwidth utilization can be parititioned
+share the same bandwidth. The bandwidth utilization can be partitioned
among channels based on the priority and weight assignments.
There are only two priority levels and 15 weigh assignments possible.
Other parameters here determine how much of the system bus this HIDMA
-instance can use like maximum read/write request and and number of bytes to
+instance can use like maximum read/write request and number of bytes to
read/write in a single burst.
Main node required properties:
--
1.9.1
^ permalink raw reply related
* [PATCH V6 01/10] Documentation: DT: qcom_hidma: update binding for MSI
From: Sinan Kaya @ 2016-10-19 17:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476899512-20431-1-git-send-email-okaya@codeaurora.org>
Adding a new binding for qcom,hidma-1.1 to distinguish HW supporting
MSI interrupts from the older revision.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
index fd5618b..2c5e4b8 100644
--- a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
+++ b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
@@ -47,12 +47,18 @@ When the OS is not in control of the management interface (i.e. it's a guest),
the channel nodes appear on their own, not under a management node.
Required properties:
-- compatible: must contain "qcom,hidma-1.0"
+- compatible: must contain "qcom,hidma-1.0" for initial HW or "qcom,hidma-1.1"
+for MSI capable HW.
- reg: Addresses for the transfer and event channel
- interrupts: Should contain the event interrupt
- desc-count: Number of asynchronous requests this channel can handle
- iommus: required a iommu node
+Optional properties for MSI:
+- msi-parent : See the generic MSI binding described in
+ devicetree/bindings/interrupt-controller/msi.txt for a description of the
+ msi-parent property.
+
Example:
Hypervisor OS configuration:
--
1.9.1
^ permalink raw reply related
* [PATCH V6 00/10] dmaengine: qcom_hidma: add MSI interrupt support
From: Sinan Kaya @ 2016-10-19 17:51 UTC (permalink / raw)
To: linux-arm-kernel
The new version of the HW supports MSI interrupts instead of wired
interrupts. The MSI interrupts are especially useful for the guest machine
execution. The wired interrupts usually trap to the hypervisor and then are
relayed to the actual interrupt.
The MSI interrupts can be directly fed into the interrupt controller.
Adding a new OF compat string (qcom,hidma-1.1) and ACPI string (QCOM8062)
to distinguish newer HW from the older ones.
v6:
* rebase 4.9 kernel
v5:
http://www.spinics.net/lists/arm-kernel/msg537014.html
* dmaengine: qcom_hidma: add MSI support for interrupts
** Return MSI interrupts before calling platform_msi_domain_free_irqs.
Also cleanup MSI interrupts on the error path.
** Free the legacy IRQ only if MSI is disabled
* add dmaengine: qcom_hidma: break completion processing on error
in order to break the completions if an error is observed while servicing
completed work.
* drop dmaengine: qcom_hidma: make error and success path common
as the success path assumes that we'll get the number of notifications for
the
jobs queued. This is not true under error conditions.
* simplify dmaengine: qcom_hidma: protect common data structures. We just
need to protect the TRE processed offset. It is the variable that keeps
track
of outstanding requests.
v4:
http://www.spinics.net/lists/devicetree/msg144563.html
* device tree binding update to refer to msi.txt
v3:
* day 0 fix for when ACPI is not compiled in
* https://www.spinics.net/lists/arm-kernel/msg532179.html
v2:
https://patchwork.kernel.org/patch/9326399/
* Documentation update for DT bindings
* Rebased to slave-next
* Dropped dmaengine: qcom_hidma: eliminate processed variables. Replaced it
with dmaengine: qcom_hidma: protect common data structures
v1:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/444167.html
* initial implementation
Sinan Kaya (10):
Documentation: DT: qcom_hidma: update binding for MSI
Documentation: DT: qcom_hidma: correct spelling mistakes
of: irq: make of_msi_configure accessible from modules
dmaengine: qcom_hidma: configure DMA and MSI for OF
dmaengine: qcom_hidma: make pending_tre_count atomic
dmaengine: qcom_hidma: bring out interrupt cause
dmaengine: qcom_hidma: add a common API to setup the interrupt
dmaengine: qcom_hidma: protect common data structures
dmaengine: qcom_hidma: break completion processing on error
dmaengine: qcom_hidma: add MSI support for interrupts
.../devicetree/bindings/dma/qcom_hidma_mgmt.txt | 12 +-
drivers/dma/qcom/hidma.c | 143 +++++++++++++++++-
drivers/dma/qcom/hidma.h | 6 +-
drivers/dma/qcom/hidma_dbg.c | 3 +-
drivers/dma/qcom/hidma_ll.c | 161 +++++++++++----------
drivers/dma/qcom/hidma_mgmt.c | 9 +-
drivers/of/irq.c | 1 +
7 files changed, 250 insertions(+), 85 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH V5 00/10] dmaengine: qcom_hidma: add MSI interrupt support
From: Sinan Kaya @ 2016-10-19 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019133406.GO2467@localhost>
Hi Vinod,
On 10/19/2016 6:34 AM, Vinod Koul wrote:
> On Fri, Oct 07, 2016 at 01:25:05AM -0400, Sinan Kaya wrote:
>> The new version of the HW supports MSI interrupts instead of wired
>> interrupts. The MSI interrupts are especially useful for the guest machine
>> execution. The wired interrupts usually trap to the hypervisor and then are
>> relayed to the actual interrupt.
>>
>> The MSI interrupts can be directly fed into the interrupt controller.
>>
>> Adding a new OF compat string (qcom,hidma-1.1) and ACPI string (QCOM8062)
>> to distinguish newer HW from the older ones.
>
> I was only able to apply 6 patches in this series. Which tree were these
> generated against?
>
> Please rebase rest..
>
I'll post V6 now with the remaining 4 patches. My tree is as follows.
I'll also repost V2 of the "dmaengine: qcom_hidma: cleanup sysfs entries during remove"
patch with your suggestion.
b8faa2a dmaengine: qcom_hidma: add MSI support for interrupts
54043eb dmaengine: qcom_hidma: break completion processing on error
31c9e2c dmaengine: qcom_hidma: protect common data structures
252ef1f dmaengine: qcom_hidma: add a common API to setup the interrupt
4e6c5ce dmaengine: qcom_hidma: bring out interrupt cause
784851a dmaengine: qcom_hidma: make pending_tre_count atomic
098685b dmaengine: qcom_hidma: configure DMA and MSI for OF
79f97f0 of: irq: make of_msi_configure accessible from modules
81e9b3a Documentation: DT: qcom_hidma: correct spelling mistakes
c55ceac Documentation: DT: qcom_hidma: update binding for MSI
7f3470c dmaengine: qcom_hidma: cleanup sysfs entries during remove
78e5299 dmaengine: qcom_hidma: remove useless debugfs file removal
96633c0 ACPI: platform: setup MSI domain for ACPI based platform device
851aadc irqchip: gicv3-its: platform-msi: scan MADT to create platform msi domain
5a8622e irqchip: gicv3-its: platform-msi: refactor its_pmsi_init() to prepare for ACPI
ca80550 ACPI: platform-msi: retrieve dev id from IORT
b631797 irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare()
1001354 Linux 4.9-rc1
Sinan
--
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/RESEND] clocksource/arm_arch_timer: Map frame with of_io_request_and_map()
From: Stephen Boyd @ 2016-10-19 17:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5807255A.8060906@arm.com>
On 10/19, Marc Zyngier wrote:
> On 19/10/16 00:45, Stephen Boyd wrote:
> > Let's use the of_io_request_and_map() API so that the frame
> > region is protected and shows up in /proc/iomem.
> >
> > Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> > ---
> > drivers/clocksource/arm_arch_timer.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> > index 73c487da6d2a..cbfa3bc5be75 100644
> > --- a/drivers/clocksource/arm_arch_timer.c
> > +++ b/drivers/clocksource/arm_arch_timer.c
> > @@ -964,7 +964,8 @@ static int __init arch_timer_mem_init(struct device_node *np)
> > }
> >
> > ret= -ENXIO;
> > - base = arch_counter_base = of_iomap(best_frame, 0);
> > + base = arch_counter_base = of_io_request_and_map(best_frame, 0,
> > + "arch_mem_timer");
> > if (!base) {
> > pr_err("arch_timer: Can't map frame's registers\n");
> > goto out;
> >
>
> Careful here: of_io_request_and_map() returns an ERR_PTR() on failure,
> while of_iomap just returns NULL. You want to change the error handling
> if you're going down that road.
>
Eek! I was clearing out my pending queue and this one is
especially old so perhaps that function signature changed. Or I
just fail at life. Anyway, thanks!
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 1/2] host: ehci-exynos: Convert to use the SET_SYSTEM_SLEEP_PM_OPS
From: Alan Stern @ 2016-10-19 17:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANAwSgTXo_=buNVnD+UjxYXo=bHbptGj+ZXivBiQA6LK+ZjNLg@mail.gmail.com>
On Wed, 19 Oct 2016, Anand Moon wrote:
> I might be wrong, below is the kconfig option for PM_SLEEP
>
> Symbol: PM_SLEEP [=y]
> Type : boolean
> Defined at kernel/power/Kconfig
> Depends on: SUSPEND [=y] || HIBERNATE_CALLBACKS [=n]
> Selects: PM [=y]
>
> So we cannot set CONFIG_PM_SLEEP=n and CONFIG_PM=y
You have it backward. We cannot set CONFIG_PM_SLEEP=y and CONFIG_PM=n.
But you can have CONFIG_PM_SLEEP=n and CONFIG_PM=y.
Alan Stern
> I observed at many places were either CONFIG_PM or CONFIG_PM_SLEEP are used.
>
> So I would like to use SIMPLE_DEV_PM_OPS macro to set struct
> dev_pm_ops exynos_ohci_pm_ops to correct the code.
>
> Best Regards
> -Anand Moon
>
> >
> >>
> >> CONFIG_PM_SLEEP=n or
> >> # CONFIG_PM_SLEEP is not set
> >>
> >> > 2. What will be the output with !SUSPEND && !HIBERNATE && PM?
> >>
> >> #
> >> # Power management options
> >> #
> >> # CONFIG_SUSPEND is not set
> >> # CONFIG_HIBERNATION is not set
> >> # CONFIG_PM is not set
> >>
> >> When CONFIG_SUSPEND and CONFIG_HIBERNATION are not set
> >> CONFIG_PM is disabled and so is CONFIG_PM_SLEEP.
> >
> > In my config, the CONFIG_PM was enabled thus the code changes the
> > functionality... Maybe this was intented but I really don't get it from
> > the commit message or from your explanations here.
> >
> > Krzysztof
>
>
^ permalink raw reply
* [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags
From: Dave Hansen @ 2016-10-19 17:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019170127.GN24393@dhcp22.suse.cz>
On 10/19/2016 10:01 AM, Michal Hocko wrote:
> The question I had earlier was whether this has to be an explicit FOLL
> flag used by g-u-p users or we can just use it internally when mm !=
> current->mm
The reason I chose not to do that was that deferred work gets run under
a basically random 'current'. If we just use 'mm != current->mm', then
the deferred work will sometimes have pkeys enforced and sometimes not,
basically randomly.
We want to be consistent with whether they are enforced or not, so we
explicitly indicate that by calling the remote variant vs. plain.
^ permalink raw reply
* [PATCH V3 05/10] acpi: apei: handle SEA notification type for ARMv8
From: Abdulhamid, Harb @ 2016-10-19 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57c81498-78f1-8aac-01b1-b5445415d822@linaro.org>
On 10/18/2016 9:04 AM, Hanjun Guo wrote:
> On 2016/10/8 5:31, Tyler Baicar wrote:
>> ARM APEI extension proposal added SEA (Synchrounous External
>> Abort) notification type for ARMv8.
>> Add a new GHES error source handling function for SEA. If an error
>> source's notification type is SEA, then this function can be registered
>> into the SEA exception handler. That way GHES will parse and report
>> SEA exceptions when they occur.
>>
>> Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
>> Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
>> Signed-off-by: Naveen Kaje <nkaje@codeaurora.org>
>> ---
>> arch/arm64/Kconfig | 1 +
>> drivers/acpi/apei/Kconfig | 15 +++++++++
>> drivers/acpi/apei/ghes.c | 83
>> +++++++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 99 insertions(+)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index b380c87..ae34349 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -53,6 +53,7 @@ config ARM64
>> select HANDLE_DOMAIN_IRQ
>> select HARDIRQS_SW_RESEND
>> select HAVE_ACPI_APEI if (ACPI && EFI)
>> + select HAVE_ACPI_APEI_SEA if (ACPI && EFI)
>> select HAVE_ALIGNED_STRUCT_PAGE if SLUB
>> select HAVE_ARCH_AUDITSYSCALL
>> select HAVE_ARCH_BITREVERSE
>> diff --git a/drivers/acpi/apei/Kconfig b/drivers/acpi/apei/Kconfig
>> index b0140c8..fb99c1c 100644
>> --- a/drivers/acpi/apei/Kconfig
>> +++ b/drivers/acpi/apei/Kconfig
>> @@ -4,6 +4,21 @@ config HAVE_ACPI_APEI
>> config HAVE_ACPI_APEI_NMI
>> bool
>>
>> +config HAVE_ACPI_APEI_SEA
>> + bool "APEI Synchronous External Abort logging/recovering support"
>> + depends on ARM64
>> + help
>> + This option should be enabled if the system supports
>> + firmware first handling of SEA (Synchronous External Abort).
>> + SEA happens with certain faults of data abort or instruction
>> + abort synchronous exceptions on ARMv8 systems. If a system
>> + supports firmware first handling of SEA, the platform analyzes
>> + and handles hardware error notifications with SEA, and it may then
>> + form a HW error record for the OS to parse and handle. This
>> + option allows the OS to look for such HW error record, and
>> + take appropriate action.
>
> OK, I can see that it's firmware first handling, so it's triggered
> by firmware to me, correct me if I'm wrong.
Not exactly... the exception itself is *initially* triggered by the
processor itself (e.g. ECC error on a particular load causes a data
abort), but then may be intercepted by firmware (e.g. EL3) to generate
the error record and then be *replayed* back to software (e.g. jump to
appropriate EL and vector that originally caused the exception).
The reason we use the term "platform" here is because platform can be
hardware/firmware, and this can be implemented in different ways
depending on the preference of the platform vendor. This is consistent
with the language in the UEFI/ACPI spec when describing the "thing" that
is not normal software (i.e. OS/Hypervisor).
>
> [...]
>> #ifdef CONFIG_HAVE_ACPI_APEI_NMI
>> /*
>> * printk is not safe in NMI context. So in NMI handler, we allocate
>> @@ -1023,6 +1083,14 @@ static int ghes_probe(struct platform_device
>> *ghes_dev)
>> case ACPI_HEST_NOTIFY_EXTERNAL:
>> case ACPI_HEST_NOTIFY_SCI:
>> break;
>> + case ACPI_HEST_NOTIFY_SEA:
>> + if (!IS_ENABLED(CONFIG_HAVE_ACPI_APEI_SEA)) {
>> + pr_warn(GHES_PFX "Generic hardware error source: %d
>> notified via SEA is not supported\n",
>> + generic->header.source_id);
>> + rc = -ENOTSUPP;
>> + goto err;
>> + }
>> + break;
>> case ACPI_HEST_NOTIFY_NMI:
>> if (!IS_ENABLED(CONFIG_HAVE_ACPI_APEI_NMI)) {
>> pr_warn(GHES_PFX "Generic hardware error source: %d
>> notified via NMI interrupt is not supported!\n",
>> @@ -1034,6 +1102,13 @@ static int ghes_probe(struct platform_device
>> *ghes_dev)
>> pr_warning(GHES_PFX "Generic hardware error source: %d
>> notified via local interrupt is not supported!\n",
>> generic->header.source_id);
>> goto err;
>> + case ACPI_HEST_NOTIFY_GPIO:
>> + case ACPI_HEST_NOTIFY_SEI:
>> + case ACPI_HEST_NOTIFY_GSIV:
>> + pr_warn(GHES_PFX "Generic hardware error source: %d notified
>> via notification type %u is not supported\n",
>> + generic->header.source_id, generic->header.source_id);
>
> Hmm, some platform may trigger a interrupt to OS for firmware handling
> and it's in the ACPI 6.1 spec, is it a limitation now, or we need to
> add code later to support it?
On the current platforms we know of, we only leverage "emulated SCI",
which essentially maps to a GPIO interrupt (via ACPI event - mapped to
particular GPIO). We will need to add support for other options
available in the spec (e.g. GSIV and SEI) later as platforms that use
those notification types become available.
Thanks,
--Harb
--
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 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags
From: Michal Hocko @ 2016-10-19 17:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5807A427.7010200@linux.intel.com>
On Wed 19-10-16 09:49:43, Dave Hansen wrote:
> On 10/19/2016 02:07 AM, Michal Hocko wrote:
> > On Wed 19-10-16 09:58:15, Lorenzo Stoakes wrote:
> >> On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote:
> >>> I am wondering whether we can go further. E.g. it is not really clear to
> >>> me whether we need an explicit FOLL_REMOTE when we can in fact check
> >>> mm != current->mm and imply that. Maybe there are some contexts which
> >>> wouldn't work, I haven't checked.
> >>
> >> This flag is set even when /proc/self/mem is used. I've not looked deeply into
> >> this flag but perhaps accessing your own memory this way can be considered
> >> 'remote' since you're not accessing it directly. On the other hand, perhaps this
> >> is just mistaken in this case?
> >
> > My understanding of the flag is quite limited as well. All I know it is
> > related to protection keys and it is needed to bypass protection check.
> > See arch_vma_access_permitted. See also 1b2ee1266ea6 ("mm/core: Do not
> > enforce PKEY permissions on remote mm access").
>
> Yeah, we need the flag to tell us when PKEYs should be applied or not.
> The current task's PKRU (pkey rights register) should really only be
> used to impact access to the task's memory, but has no bearing on how a
> given task should access remote memory.
The question I had earlier was whether this has to be an explicit FOLL
flag used by g-u-p users or we can just use it internally when mm !=
current->mm
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* [PATCH -next] dmaengine: st_fdma: Fix the error return code in st_fdma_probe()
From: Vinod Koul @ 2016-10-19 17:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476883430-11970-1-git-send-email-weiyj.lk@gmail.com>
On Wed, Oct 19, 2016 at 01:23:50PM +0000, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> In case of error, the function st_slim_rproc_alloc() returns ERR_PTR()
> and never returns NULL. The NULL test in the return value check should
> be replaced with IS_ERR().
>
Applied, thanks
--
~Vinod
^ permalink raw reply
* [PATCH] arm64: Enable HIBERNATION in defconfig
From: Catalin Marinas @ 2016-10-19 16:59 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds CONFIG_HIBERNATION to the arm64 defconfig.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
---
Re-sent post 4.9-rc1 as it was missed during the merging window.
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index dab2cb0c1f1c..4fc5ae07b035 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -82,6 +82,7 @@ CONFIG_KEXEC=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_COMPAT=y
CONFIG_CPU_IDLE=y
+CONFIG_HIBERNATION=y
CONFIG_ARM_CPUIDLE=y
CONFIG_CPU_FREQ=y
CONFIG_CPUFREQ_DT=y
^ permalink raw reply related
* [PATCH V3 05/10] acpi: apei: handle SEA notification type for ARMv8
From: Abdulhamid, Harb @ 2016-10-19 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <496ddac3-a220-fd42-5ca1-3d0fb0238907@linaro.org>
On 10/18/2016 8:44 AM, Hanjun Guo wrote:
> Hi Tyler,
>
> On 2016/10/8 5:31, Tyler Baicar wrote:
>> ARM APEI extension proposal added SEA (Synchrounous External
>> Abort) notification type for ARMv8.
>> Add a new GHES error source handling function for SEA. If an error
>> source's notification type is SEA, then this function can be registered
>> into the SEA exception handler. That way GHES will parse and report
>> SEA exceptions when they occur.
>
> Does this SEA is replayed by the firmware (firmware first handling)
> or directly triggered by the hardware when error is happened?
Architecturally, an SEA must be synchronous and *precise*, so if you
take an SEA on a particular load instruction, firmware/hardware should
not be corrupting the context/state of the PE to allow software to
determine which thread/process encountered the abort. GHES error status
block will be expose to software with information about the type,
severity, physical address impacted.
Generally the error status block is populated by firmware. However, as
long as the above requirement is met, I don't think the spec precludes
error status block being populated by hardware. Those details must be
completely transparent to software.
Finally, to answer your more specific question: If the implementation
of firmware-first involves trapping the SEA in EL3 to do some firmware
first handling, firmware must maintain the context of the offending ELx,
generate an error record, and then "replay" the exception to normal
(non-secure) software at the appropriate vector base address.
Thanks,
Harb
--
--
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 2/3] arm64: mm: Set PSTATE.PAN from the cpu_enable_pan() call
From: Will Deacon @ 2016-10-19 16:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476786468-2173-3-git-send-email-james.morse@arm.com>
On Tue, Oct 18, 2016 at 11:27:47AM +0100, James Morse wrote:
> Commit 338d4f49d6f7 ("arm64: kernel: Add support for Privileged Access
> Never") enabled PAN by enabling the 'SPAN' feature-bit in SCTLR_EL1.
> This means the PSTATE.PAN bit won't be set until the next return to the
> kernel from userspace. On a preemptible kernel we may schedule work that
> accesses userspace on a CPU before it has done this.
>
> Now that cpufeature enable() calls are scheduled via stop_machine(), we
> can set PSTATE.PAN from the cpu_enable_pan() call.
>
> Add WARN_ON_ONCE(in_interrupt()) to check the PSTATE value we updated
> is not immediately discarded.
>
> Reported-by: Tony Thompson <anthony.thompson@arm.com>
> Reported-by: Vladimir Murzin <vladimir.murzin@arm.com>
> Signed-off-by: James Morse <james.morse@arm.com>
>
> ---
> This patch depends on 'arm64: cpufeature: Schedule enable() calls instead
> of calling them via IPI', which doesn't apply to linux-stable versions
> before v4.8.
>
> arch/arm64/mm/fault.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> index 3e9ff9b0c78d..f942ab6cc206 100644
> --- a/arch/arm64/mm/fault.c
> +++ b/arch/arm64/mm/fault.c
> @@ -29,7 +29,9 @@
> #include <linux/sched.h>
> #include <linux/highmem.h>
> #include <linux/perf_event.h>
> +#include <linux/preempt.h>
>
> +#include <asm/bug.h>
> #include <asm/cpufeature.h>
> #include <asm/exception.h>
> #include <asm/debug-monitors.h>
> @@ -672,7 +674,14 @@ NOKPROBE_SYMBOL(do_debug_exception);
> #ifdef CONFIG_ARM64_PAN
> int cpu_enable_pan(void *__unused)
> {
> + /*
> + * We modify PSTATE. This won't work from irq context as the PSTATE
> + * is discared once we return from the exception.
> + */
I fixed the typo in the comment and queued these as fixes. Please take
care of stable once these are in mainline.
Will
^ permalink raw reply
* [PATCH v2] arm64: defconfig: enable EEPROM_AT25 config option
From: Olof Johansson @ 2016-10-19 16:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5740014.mZjAIri61F@wuerfel>
On Wed, Oct 19, 2016 at 1:04 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday, October 18, 2016 3:23:26 PM CEST Scott Branden wrote:
>> I have be.config and le.config that allow you to switch the defconfig
>> between big and little endian. Does this make sense to upstream to
>> arm/configs if you have accepted dram_0x00000000.config?
>
> Yes, they clearly fall into the same category, let's merge those as well.
>
>> Would you also accept this to arm64/configs? We actually use
>> big and little endian on the same SoC more on arm64 platforms. But, in
>> order to boot big endian we need to maintain this outside the kernel
>> right now.
>
> I'm in favor of that, but let's see what the arm64 maintainers think.
Single-line fragments aren't really all that valuable, IMHO. Flipping
just one option is trivial to do without fragments, or when they're
not simple Y/N flips (i.e. like the ram base).
Fragments are mostly useful when you need to flip several options
together to enable some set of functionality.
-Olof
^ permalink raw reply
* [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags
From: Dave Hansen @ 2016-10-19 16:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019090727.GE7517@dhcp22.suse.cz>
On 10/19/2016 02:07 AM, Michal Hocko wrote:
> On Wed 19-10-16 09:58:15, Lorenzo Stoakes wrote:
>> On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote:
>>> I am wondering whether we can go further. E.g. it is not really clear to
>>> me whether we need an explicit FOLL_REMOTE when we can in fact check
>>> mm != current->mm and imply that. Maybe there are some contexts which
>>> wouldn't work, I haven't checked.
>>
>> This flag is set even when /proc/self/mem is used. I've not looked deeply into
>> this flag but perhaps accessing your own memory this way can be considered
>> 'remote' since you're not accessing it directly. On the other hand, perhaps this
>> is just mistaken in this case?
>
> My understanding of the flag is quite limited as well. All I know it is
> related to protection keys and it is needed to bypass protection check.
> See arch_vma_access_permitted. See also 1b2ee1266ea6 ("mm/core: Do not
> enforce PKEY permissions on remote mm access").
Yeah, we need the flag to tell us when PKEYs should be applied or not.
The current task's PKRU (pkey rights register) should really only be
used to impact access to the task's memory, but has no bearing on how a
given task should access remote memory.
^ permalink raw reply
* [PATCH 1/2] host: ehci-exynos: Convert to use the SET_SYSTEM_SLEEP_PM_OPS
From: Anand Moon @ 2016-10-19 16:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161009183933.GA15270@kozik-lap>
Hi Krzysztof,
On 10 October 2016 at 00:09, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Sun, Oct 09, 2016 at 11:57:59PM +0530, Anand Moon wrote:
>> hi Krzysztof,
>>
>> On 9 October 2016 at 22:57, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> > On Sun, Oct 09, 2016 at 10:45:40PM +0530, Anand Moon wrote:
>> >> Hi Krzysztof,
>> >>
>> >> On 9 October 2016 at 22:04, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> >> > On Sun, Oct 09, 2016 at 02:34:14PM +0000, Anand Moon wrote:
>> >> >> Move the ehci-exynos system PM callbacks within #ifdef CONFIG_PM_SLEEP
>> >> >> as to avoid them being build when not used. This also allows us to use the
>> >> >> SET_SYSTEM_SLEEP_PM_OPS macro which simplifies the code.
>> >> >>
>> >> >> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
>> >> >> ---
>> >> >> drivers/usb/host/ehci-exynos.c | 14 ++++++--------
>> >> >> 1 file changed, 6 insertions(+), 8 deletions(-)
>> >> >>
>> >> >> diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
>> >> >> index 42e5b66..1899900 100644
>> >> >> --- a/drivers/usb/host/ehci-exynos.c
>> >> >> +++ b/drivers/usb/host/ehci-exynos.c
>> >> >> @@ -251,7 +251,7 @@ static int exynos_ehci_remove(struct platform_device *pdev)
>> >> >> return 0;
>> >> >> }
>> >> >>
>> >> >> -#ifdef CONFIG_PM
>> >> >> +#ifdef CONFIG_PM_SLEEP
>> >> >
>> >> > Does not look like an equivalent change. How will it behave in a config
>> >> > with !SUSPEND && !HIBERNATE && PM?
>> >> >
>> >>
>> >> [snip]
>> >>
>> >> I just wanted to update suspend and resume callback to use
>> >> SET_SYSTEM_SLEEP_PM_OPS
>> >> as they are define under CONFIG_PM_SLEEP so I update above to avoid
>> >> compilation warning/error.
>> >
>> Apologize: for not understanding your question.
>>
>> > First of all you did not answer to my question, so let me rephrase into
>> > two:
>> > 1. Is the code equivalent?
>>
>> No CONFIG_PM and CONFIG_PM_SLEEP are different options.
>> But I could not disable CONFIG_PM_SLEEP option with either in exynos_defconfig
>
> So the code is not equivalent...
I might be wrong, below is the kconfig option for PM_SLEEP
Symbol: PM_SLEEP [=y]
Type : boolean
Defined at kernel/power/Kconfig
Depends on: SUSPEND [=y] || HIBERNATE_CALLBACKS [=n]
Selects: PM [=y]
So we cannot set CONFIG_PM_SLEEP=n and CONFIG_PM=y
I observed at many places were either CONFIG_PM or CONFIG_PM_SLEEP are used.
So I would like to use SIMPLE_DEV_PM_OPS macro to set struct
dev_pm_ops exynos_ohci_pm_ops to correct the code.
Best Regards
-Anand Moon
>
>>
>> CONFIG_PM_SLEEP=n or
>> # CONFIG_PM_SLEEP is not set
>>
>> > 2. What will be the output with !SUSPEND && !HIBERNATE && PM?
>>
>> #
>> # Power management options
>> #
>> # CONFIG_SUSPEND is not set
>> # CONFIG_HIBERNATION is not set
>> # CONFIG_PM is not set
>>
>> When CONFIG_SUSPEND and CONFIG_HIBERNATION are not set
>> CONFIG_PM is disabled and so is CONFIG_PM_SLEEP.
>
> In my config, the CONFIG_PM was enabled thus the code changes the
> functionality... Maybe this was intented but I really don't get it from
> the commit message or from your explanations here.
>
> Krzysztof
^ permalink raw reply
* [PATCH v5 0/5] Add support for legacy SCPI protocol
From: Kevin Hilman @ 2016-10-19 16:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4aa21ebe-446e-6343-238c-515718cbb162@arm.com>
Sudeep Holla <sudeep.holla@arm.com> writes:
> On 19/10/16 16:59, Kevin Hilman wrote:
[...]
>>
>> Sudeep, will this be an immutable branch? (or could you put a tag at an
>> immutable place on this branch?) I'd like to include this in my amlogic
>> integration branch for broader testing.
>>
>
> If you plan to test SCPI(which is enabled in defconfig), then you need
> all the patches in the branch[1]. I will tag once I get a build success
> from kbuild robot and I do some testing. In short, immutable tag = PR
> tag IMO. The only thing I can drop from the list is DT bindings patch.
>
> Let me know if you are fine using the same tag ? Or you can propose any
> other alternative, I am fine by that too.
I'm currently using your scpi-updates/for-next branch, so a tag at (or
near) there should be fine after you've validated it.
Thanks,
Kevin
^ permalink raw reply
* [arm:for-next 7/8] warning: (ARM && ..) selects GENERIC_CLOCKEVENTS_BROADCAST which has unmet direct dependencies (GENERIC_CLOCKEVENTS)
From: Russell King - ARM Linux @ 2016-10-19 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201610200017.9XQc5RQ5%fengguang.wu@intel.com>
Patch dropped.
On Thu, Oct 20, 2016 at 12:35:22AM +0800, kbuild test robot wrote:
> tree: git://git.armlinux.org.uk/~rmk/linux-arm.git for-next
> head: 4f3ebefbc0ed334491f0b7f1f0154b14c47c0774
> commit: e085002c23dfb35705c630b975827a69ff9aceb6 [7/8] ARM: 8620/1: Kconfig: select GENERIC_CLOCKEVENTS_BROADCAST also on UP
> config: arm-ebsa110_defconfig (attached as .config)
> compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
> wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout e085002c23dfb35705c630b975827a69ff9aceb6
> # save the attached .config to linux build tree
> make.cross ARCH=arm
>
> All error/warnings (new ones prefixed by >>):
>
> warning: (ARM && SOC_AM43XX && MIPS_CPS_CPUIDLE) selects GENERIC_CLOCKEVENTS_BROADCAST which has unmet direct dependencies (GENERIC_CLOCKEVENTS)
> kernel/time/tick-broadcast.c: In function 'tick_broadcast_start_periodic':
> >> kernel/time/tick-broadcast.c:65:3: error: implicit declaration of function 'tick_setup_periodic' [-Werror=implicit-function-declaration]
> tick_setup_periodic(bc, 1);
> ^~~~~~~~~~~~~~~~~~~
> kernel/time/tick-broadcast.c: In function 'tick_check_broadcast_device':
> >> kernel/time/tick-broadcast.c:74:13: error: dereferencing pointer to incomplete type 'struct clock_event_device'
> if ((newdev->features & CLOCK_EVT_FEAT_DUMMY) ||
> ^~
> >> kernel/time/tick-broadcast.c:74:26: error: 'CLOCK_EVT_FEAT_DUMMY' undeclared (first use in this function)
> if ((newdev->features & CLOCK_EVT_FEAT_DUMMY) ||
> ^~~~~~~~~~~~~~~~~~~~
> kernel/time/tick-broadcast.c:74:26: note: each undeclared identifier is reported only once for each function it appears in
> >> kernel/time/tick-broadcast.c:75:26: error: 'CLOCK_EVT_FEAT_PERCPU' undeclared (first use in this function)
> (newdev->features & CLOCK_EVT_FEAT_PERCPU) ||
> ^~~~~~~~~~~~~~~~~~~~~
> >> kernel/time/tick-broadcast.c:76:26: error: 'CLOCK_EVT_FEAT_C3STOP' undeclared (first use in this function)
> (newdev->features & CLOCK_EVT_FEAT_C3STOP))
> ^~~~~~~~~~~~~~~~~~~~~
> >> kernel/time/tick-broadcast.c:80:27: error: 'CLOCK_EVT_FEAT_ONESHOT' undeclared (first use in this function)
> !(newdev->features & CLOCK_EVT_FEAT_ONESHOT))
> ^~~~~~~~~~~~~~~~~~~~~~
> kernel/time/tick-broadcast.c: In function 'tick_install_broadcast_device':
> >> kernel/time/tick-broadcast.c:99:2: error: implicit declaration of function 'clockevents_exchange_device' [-Werror=implicit-function-declaration]
> clockevents_exchange_device(cur, dev);
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> kernel/time/tick-broadcast.c:101:24: error: 'clockevents_handle_noop' undeclared (first use in this function)
> cur->event_handler = clockevents_handle_noop;
> ^~~~~~~~~~~~~~~~~~~~~~~
> kernel/time/tick-broadcast.c:113:22: error: 'CLOCK_EVT_FEAT_ONESHOT' undeclared (first use in this function)
> if (dev->features & CLOCK_EVT_FEAT_ONESHOT)
> ^~~~~~~~~~~~~~~~~~~~~~
> kernel/time/tick-broadcast.c: In function 'tick_broadcast_update_freq':
> >> kernel/time/tick-broadcast.c:131:9: error: implicit declaration of function '__clockevents_update_freq' [-Werror=implicit-function-declaration]
> ret = __clockevents_update_freq(dev, freq);
> ^~~~~~~~~~~~~~~~~~~~~~~~~
> kernel/time/tick-broadcast.c: In function 'tick_device_setup_broadcast_func':
> >> kernel/time/tick-broadcast.c:146:20: error: 'tick_broadcast' undeclared (first use in this function)
> dev->broadcast = tick_broadcast;
> ^~~~~~~~~~~~~~
> kernel/time/tick-broadcast.c: In function 'tick_device_uses_broadcast':
> >> kernel/time/tick-broadcast.c:172:7: error: implicit declaration of function 'tick_device_is_functional' [-Werror=implicit-function-declaration]
> if (!tick_device_is_functional(dev)) {
> ^~~~~~~~~~~~~~~~~~~~~~~~~
> >> kernel/time/tick-broadcast.c:173:24: error: 'tick_handle_periodic' undeclared (first use in this function)
> dev->event_handler = tick_handle_periodic;
> ^~~~~~~~~~~~~~~~~~~~
> kernel/time/tick-broadcast.c:186:25: error: 'CLOCK_EVT_FEAT_C3STOP' undeclared (first use in this function)
> if (!(dev->features & CLOCK_EVT_FEAT_C3STOP))
> ^~~~~~~~~~~~~~~~~~~~~
> >> kernel/time/tick-broadcast.c:219:5: error: implicit declaration of function 'clockevents_shutdown' [-Werror=implicit-function-declaration]
> clockevents_shutdown(bc);
> ^~~~~~~~~~~~~~~~~~~~
> >> kernel/time/tick-broadcast.c:228:31: error: 'CLOCK_EVT_FEAT_HRTIMER' undeclared (first use in this function)
> if (bc && !(bc->features & CLOCK_EVT_FEAT_HRTIMER))
> ^~~~~~~~~~~~~~~~~~~~~~
> kernel/time/tick-broadcast.c: In function 'tick_do_broadcast':
> kernel/time/tick-broadcast.c:284:28: error: 'CLOCK_EVT_FEAT_HRTIMER' undeclared (first use in this function)
> local = !(bc->features & CLOCK_EVT_FEAT_HRTIMER);
> ^~~~~~~~~~~~~~~~~~~~~~
> kernel/time/tick-broadcast.c: In function 'tick_handle_periodic_broadcast':
> >> kernel/time/tick-broadcast.c:321:6: error: implicit declaration of function 'clockevent_state_shutdown' [-Werror=implicit-function-declaration]
> if (clockevent_state_shutdown(tick_broadcast_device.evtdev)) {
> ^~~~~~~~~~~~~~~~~~~~~~~~~
> >> kernel/time/tick-broadcast.c:328:6: error: implicit declaration of function 'clockevent_state_oneshot' [-Werror=implicit-function-declaration]
> if (clockevent_state_oneshot(dev)) {
> ^~~~~~~~~~~~~~~~~~~~~~~~
> In file included from include/linux/rcupdate.h:47:0,
> from include/linux/idr.h:18,
> from include/linux/kernfs.h:14,
> from include/linux/sysfs.h:15,
> from include/linux/kobject.h:21,
> from include/linux/device.h:17,
> from include/linux/node.h:17,
> from include/linux/cpu.h:16,
> from kernel/time/tick-broadcast.c:14:
> >> kernel/time/tick-broadcast.c:329:45: error: 'tick_period' undeclared (first use in this function)
> ktime_t next = ktime_add(dev->next_event, tick_period);
> ^
> include/linux/ktime.h:64:39: note: in definition of macro 'ktime_add'
> ({ (ktime_t){ .tv64 = (lhs).tv64 + (rhs).tv64 }; })
> ^~~
> >> kernel/time/tick-broadcast.c:331:3: error: implicit declaration of function 'clockevents_program_event' [-Werror=implicit-function-declaration]
> clockevents_program_event(dev, next, true);
> ^~~~~~~~~~~~~~~~~~~~~~~~~
> kernel/time/tick-broadcast.c: In function 'tick_broadcast_control':
> kernel/time/tick-broadcast.c:367:32: error: 'CLOCK_EVT_FEAT_C3STOP' undeclared (first use in this function)
> if (!dev || !(dev->features & CLOCK_EVT_FEAT_C3STOP))
> ^~~~~~~~~~~~~~~~~~~~~
> kernel/time/tick-broadcast.c:392:31: error: 'CLOCK_EVT_FEAT_HRTIMER' undeclared (first use in this function)
> if (bc && !(bc->features & CLOCK_EVT_FEAT_HRTIMER) &&
> ^~~~~~~~~~~~~~~~~~~~~~
> kernel/time/tick-broadcast.c: In function 'tick_set_periodic_handler':
> kernel/time/tick-broadcast.c:433:24: error: 'tick_handle_periodic' undeclared (first use in this function)
> dev->event_handler = tick_handle_periodic;
> ^~~~~~~~~~~~~~~~~~~~
> kernel/time/tick-broadcast.c: In function 'tick_resume_broadcast':
> >> kernel/time/tick-broadcast.c:502:3: error: implicit declaration of function 'clockevents_tick_resume' [-Werror=implicit-function-declaration]
> clockevents_tick_resume(bc);
> ^~~~~~~~~~~~~~~~~~~~~~~
> kernel/time/tick-broadcast.c: In function '__tick_broadcast_oneshot_control':
> kernel/time/tick-broadcast.c:988:29: error: 'CLOCK_EVT_FEAT_HRTIMER' undeclared (first use in this function)
> if (!bc || (bc->features & CLOCK_EVT_FEAT_HRTIMER))
> ^~~~~~~~~~~~~~~~~~~~~~
> kernel/time/tick-broadcast.c: In function 'tick_check_broadcast_device':
> >> kernel/time/tick-broadcast.c:84:1: warning: control reaches end of non-void function [-Wreturn-type]
> }
> ^
> cc1: some warnings being treated as errors
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [arm:for-next 7/8] warning: (ARM && ..) selects GENERIC_CLOCKEVENTS_BROADCAST which has unmet direct dependencies (GENERIC_CLOCKEVENTS)
From: kbuild test robot @ 2016-10-19 16:35 UTC (permalink / raw)
To: linux-arm-kernel
tree: git://git.armlinux.org.uk/~rmk/linux-arm.git for-next
head: 4f3ebefbc0ed334491f0b7f1f0154b14c47c0774
commit: e085002c23dfb35705c630b975827a69ff9aceb6 [7/8] ARM: 8620/1: Kconfig: select GENERIC_CLOCKEVENTS_BROADCAST also on UP
config: arm-ebsa110_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout e085002c23dfb35705c630b975827a69ff9aceb6
# save the attached .config to linux build tree
make.cross ARCH=arm
All error/warnings (new ones prefixed by >>):
warning: (ARM && SOC_AM43XX && MIPS_CPS_CPUIDLE) selects GENERIC_CLOCKEVENTS_BROADCAST which has unmet direct dependencies (GENERIC_CLOCKEVENTS)
kernel/time/tick-broadcast.c: In function 'tick_broadcast_start_periodic':
>> kernel/time/tick-broadcast.c:65:3: error: implicit declaration of function 'tick_setup_periodic' [-Werror=implicit-function-declaration]
tick_setup_periodic(bc, 1);
^~~~~~~~~~~~~~~~~~~
kernel/time/tick-broadcast.c: In function 'tick_check_broadcast_device':
>> kernel/time/tick-broadcast.c:74:13: error: dereferencing pointer to incomplete type 'struct clock_event_device'
if ((newdev->features & CLOCK_EVT_FEAT_DUMMY) ||
^~
>> kernel/time/tick-broadcast.c:74:26: error: 'CLOCK_EVT_FEAT_DUMMY' undeclared (first use in this function)
if ((newdev->features & CLOCK_EVT_FEAT_DUMMY) ||
^~~~~~~~~~~~~~~~~~~~
kernel/time/tick-broadcast.c:74:26: note: each undeclared identifier is reported only once for each function it appears in
>> kernel/time/tick-broadcast.c:75:26: error: 'CLOCK_EVT_FEAT_PERCPU' undeclared (first use in this function)
(newdev->features & CLOCK_EVT_FEAT_PERCPU) ||
^~~~~~~~~~~~~~~~~~~~~
>> kernel/time/tick-broadcast.c:76:26: error: 'CLOCK_EVT_FEAT_C3STOP' undeclared (first use in this function)
(newdev->features & CLOCK_EVT_FEAT_C3STOP))
^~~~~~~~~~~~~~~~~~~~~
>> kernel/time/tick-broadcast.c:80:27: error: 'CLOCK_EVT_FEAT_ONESHOT' undeclared (first use in this function)
!(newdev->features & CLOCK_EVT_FEAT_ONESHOT))
^~~~~~~~~~~~~~~~~~~~~~
kernel/time/tick-broadcast.c: In function 'tick_install_broadcast_device':
>> kernel/time/tick-broadcast.c:99:2: error: implicit declaration of function 'clockevents_exchange_device' [-Werror=implicit-function-declaration]
clockevents_exchange_device(cur, dev);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
>> kernel/time/tick-broadcast.c:101:24: error: 'clockevents_handle_noop' undeclared (first use in this function)
cur->event_handler = clockevents_handle_noop;
^~~~~~~~~~~~~~~~~~~~~~~
kernel/time/tick-broadcast.c:113:22: error: 'CLOCK_EVT_FEAT_ONESHOT' undeclared (first use in this function)
if (dev->features & CLOCK_EVT_FEAT_ONESHOT)
^~~~~~~~~~~~~~~~~~~~~~
kernel/time/tick-broadcast.c: In function 'tick_broadcast_update_freq':
>> kernel/time/tick-broadcast.c:131:9: error: implicit declaration of function '__clockevents_update_freq' [-Werror=implicit-function-declaration]
ret = __clockevents_update_freq(dev, freq);
^~~~~~~~~~~~~~~~~~~~~~~~~
kernel/time/tick-broadcast.c: In function 'tick_device_setup_broadcast_func':
>> kernel/time/tick-broadcast.c:146:20: error: 'tick_broadcast' undeclared (first use in this function)
dev->broadcast = tick_broadcast;
^~~~~~~~~~~~~~
kernel/time/tick-broadcast.c: In function 'tick_device_uses_broadcast':
>> kernel/time/tick-broadcast.c:172:7: error: implicit declaration of function 'tick_device_is_functional' [-Werror=implicit-function-declaration]
if (!tick_device_is_functional(dev)) {
^~~~~~~~~~~~~~~~~~~~~~~~~
>> kernel/time/tick-broadcast.c:173:24: error: 'tick_handle_periodic' undeclared (first use in this function)
dev->event_handler = tick_handle_periodic;
^~~~~~~~~~~~~~~~~~~~
kernel/time/tick-broadcast.c:186:25: error: 'CLOCK_EVT_FEAT_C3STOP' undeclared (first use in this function)
if (!(dev->features & CLOCK_EVT_FEAT_C3STOP))
^~~~~~~~~~~~~~~~~~~~~
>> kernel/time/tick-broadcast.c:219:5: error: implicit declaration of function 'clockevents_shutdown' [-Werror=implicit-function-declaration]
clockevents_shutdown(bc);
^~~~~~~~~~~~~~~~~~~~
>> kernel/time/tick-broadcast.c:228:31: error: 'CLOCK_EVT_FEAT_HRTIMER' undeclared (first use in this function)
if (bc && !(bc->features & CLOCK_EVT_FEAT_HRTIMER))
^~~~~~~~~~~~~~~~~~~~~~
kernel/time/tick-broadcast.c: In function 'tick_do_broadcast':
kernel/time/tick-broadcast.c:284:28: error: 'CLOCK_EVT_FEAT_HRTIMER' undeclared (first use in this function)
local = !(bc->features & CLOCK_EVT_FEAT_HRTIMER);
^~~~~~~~~~~~~~~~~~~~~~
kernel/time/tick-broadcast.c: In function 'tick_handle_periodic_broadcast':
>> kernel/time/tick-broadcast.c:321:6: error: implicit declaration of function 'clockevent_state_shutdown' [-Werror=implicit-function-declaration]
if (clockevent_state_shutdown(tick_broadcast_device.evtdev)) {
^~~~~~~~~~~~~~~~~~~~~~~~~
>> kernel/time/tick-broadcast.c:328:6: error: implicit declaration of function 'clockevent_state_oneshot' [-Werror=implicit-function-declaration]
if (clockevent_state_oneshot(dev)) {
^~~~~~~~~~~~~~~~~~~~~~~~
In file included from include/linux/rcupdate.h:47:0,
from include/linux/idr.h:18,
from include/linux/kernfs.h:14,
from include/linux/sysfs.h:15,
from include/linux/kobject.h:21,
from include/linux/device.h:17,
from include/linux/node.h:17,
from include/linux/cpu.h:16,
from kernel/time/tick-broadcast.c:14:
>> kernel/time/tick-broadcast.c:329:45: error: 'tick_period' undeclared (first use in this function)
ktime_t next = ktime_add(dev->next_event, tick_period);
^
include/linux/ktime.h:64:39: note: in definition of macro 'ktime_add'
({ (ktime_t){ .tv64 = (lhs).tv64 + (rhs).tv64 }; })
^~~
>> kernel/time/tick-broadcast.c:331:3: error: implicit declaration of function 'clockevents_program_event' [-Werror=implicit-function-declaration]
clockevents_program_event(dev, next, true);
^~~~~~~~~~~~~~~~~~~~~~~~~
kernel/time/tick-broadcast.c: In function 'tick_broadcast_control':
kernel/time/tick-broadcast.c:367:32: error: 'CLOCK_EVT_FEAT_C3STOP' undeclared (first use in this function)
if (!dev || !(dev->features & CLOCK_EVT_FEAT_C3STOP))
^~~~~~~~~~~~~~~~~~~~~
kernel/time/tick-broadcast.c:392:31: error: 'CLOCK_EVT_FEAT_HRTIMER' undeclared (first use in this function)
if (bc && !(bc->features & CLOCK_EVT_FEAT_HRTIMER) &&
^~~~~~~~~~~~~~~~~~~~~~
kernel/time/tick-broadcast.c: In function 'tick_set_periodic_handler':
kernel/time/tick-broadcast.c:433:24: error: 'tick_handle_periodic' undeclared (first use in this function)
dev->event_handler = tick_handle_periodic;
^~~~~~~~~~~~~~~~~~~~
kernel/time/tick-broadcast.c: In function 'tick_resume_broadcast':
>> kernel/time/tick-broadcast.c:502:3: error: implicit declaration of function 'clockevents_tick_resume' [-Werror=implicit-function-declaration]
clockevents_tick_resume(bc);
^~~~~~~~~~~~~~~~~~~~~~~
kernel/time/tick-broadcast.c: In function '__tick_broadcast_oneshot_control':
kernel/time/tick-broadcast.c:988:29: error: 'CLOCK_EVT_FEAT_HRTIMER' undeclared (first use in this function)
if (!bc || (bc->features & CLOCK_EVT_FEAT_HRTIMER))
^~~~~~~~~~~~~~~~~~~~~~
kernel/time/tick-broadcast.c: In function 'tick_check_broadcast_device':
>> kernel/time/tick-broadcast.c:84:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
cc1: some warnings being treated as errors
---
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: 10679 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161020/f747e3dc/attachment.gz>
^ permalink raw reply
* exynos-drm: display manager fails to start without IOMMU problem
From: Tobias Jakobi @ 2016-10-19 16:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2173cc13-7c77-1a38-501d-2c0f522ff5d5@osg.samsung.com>
Hello Shuah,
just a short note that more misleading comments about default allocation
flags can be found in libdrm.
https://cgit.freedesktop.org/mesa/drm/tree/exynos/exynos_drm.c
See e.g. the comment for exynos_bo_create().
In my opinion, the whole approach to _set_ a bit to get non-contigious
memory is messed up. It would make more sense to me to set a bit to
request an additional property (here "being contiguous") of the memory.
Anyway, clearing up this situation is highly appreciated!
More comments below.
With best wishes,
Tobias
Shuah Khan wrote:
> Restarting the thread with a different subject line:
>
> I haven't given up on this yet. I am still seeing the following failure:
>
> Additional debug messages I added:
> [ 15.287403] exynos_drm_gem_create_ioctl() 1
> [ 15.287419] exynos_drm_gem_create() flags 1
>
> [ 15.311511] [drm:exynos_drm_framebuffer_init] *ERROR* Non-contiguous GEM memory is not supported.
>
> Additional debug message I added:
> [ 15.318981] [drm:exynos_user_fb_create] *ERROR* failed to initialize framebuffer
>
> This is what happens:
>
> 1. exynos_drm_gem_create_ioctl() gets called with EXYNOS_BO_NONCONTIG request
> 2. exynos_drm_gem_create(0 goes ahead and creates the GEM buffers
> 3. exynos_user_fb_create() tries to associate GEM to fb and fails during
> check_fb_gem_memory_type()
>
> At this point, there is no recovery and lightdm fails
>
> xf86-video-armsoc/src/drmmode_exynos/drmmode_exynos.c assumes contiguous
> allocations are not supported in some exynos drm versions: The following
> commit introduced this change:
>
> https://git.linaro.org/arm/xorg/driver/xf86-video-armsoc.git/commitdiff/3be1f6273441fe95dd442f44064387322e16b7e9
>
> excerpts from the diff:- if (create_gem->buf_type == ARMSOC_BO_SCANOUT)
> - create_exynos.flags = EXYNOS_BO_CONTIG;
> - else
> - create_exynos.flags = EXYNOS_BO_NONCONTIG;
> +
> + /* Contiguous allocations are not supported in some exynos drm versions.
> + * When they are supported all allocations are effectively contiguous
> + * anyway, so for simplicity we always request non contiguous buffers.
> + */
> + create_exynos.flags = EXYNOS_BO_NONCONTIG;
>
> There might have been logic on exynos_drm that forced Contig when it coudn't
> support NONCONTIG. At least, that is what this comment suggests. This assumption
> doesn't appear to be a good one and not sure if this change was made to fix a bug.
>
> After the IOMMU support, this assumption is no longer true. Hence, with IOMMU
> support, latest kernels have a mismatch with the installed xf86-video-armsoc
>
> This is what I am running into. This leads to the following question:
>
> 1. How do we ensure exynos_drm kernel changes don't break user-space
> specifically xf86-video-armsoc
> 2. This seems to have gone undetected for a while. I see a change in
> exynos_drm_gem_dumb_create() that is probably addressing this type
> of breakage. Commit 122beea84bb90236b1ae545f08267af58591c21b adds
> handling for IOMMU NONCONTIG case.
I don't think that this commit is related to the issue, since it is only
used for the generic dumb buffer ioctl, while armsoc is using an Exynos
specific ioctl.
So in particular you shouldn't see the issue with
xf86-video-modesetting. Might be worth trying that one out?
>
> Anyway, I am interested in getting the exynos_drm kernel side code
> and xf86-video-armsoc in sync to resolve the issue.
>
> Could you recommend a going forward plan?
>
> I can submit a patch to xf86-video-armsoc. I am also looking ahead to
> see if we can avoid such breaks in the future by keeping kernel and
> xf86-video-armsoc in sync.
>
> thanks,
> -- Shuah
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Build failure with v4.9-rc1 and GCC trunk -- compiler weirdness
From: Will Deacon @ 2016-10-19 16:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+55aFx=ZX=7u07R6zJ7fSw=zSQNaYqVX7R3LQs4riiEf+uA=A@mail.gmail.com>
On Wed, Oct 19, 2016 at 09:01:33AM -0700, Linus Torvalds wrote:
> On Wed, Oct 19, 2016 at 8:56 AM, Markus Trippelsdorf
> <markus@trippelsdorf.de> wrote:
> > On 2016.10.19 at 08:55 -0700, Linus Torvalds wrote:
> >>
> >> Well, in the meantime we apparently have to live with it. Unless Will
> >> is using some unreleased gcc version that nobody else is using and we
> >> can just ignore it?
> >
> > Yes, he is using gcc-7 that is unreleased. (It will be released April
> > next year.)
>
> Ahh, self-built? So it's not part of some experimental ARM distro
> setup and this will be annoying lots of people?
Our friendly compiler guys built it, but it's just a snapshot of trunk,
so it's all heading towards GCC 7.0. AFAIU, the problematic optimisation
is also a mid-end pass, so it would affect other architectures too.
> If so, still think that we could just get rid of the ____ilog2_NaN()
> thing as it's not _that_ important, but it's certainly not very
> high-priority. Will can do it in his tree too for testing, and it can
> remind people to get the gcc problem fixed.
I'm carrying the diff below, which fixes arm64 defconfig, but I'm worried
that we might be relying on this trick elsewhere. The arm __bad_cmpxchg
function, for example.
Will
--->8
diff --git a/include/linux/log2.h b/include/linux/log2.h
index fd7ff3d91e6a..9cf5ad69065d 100644
--- a/include/linux/log2.h
+++ b/include/linux/log2.h
@@ -16,12 +16,6 @@
#include <linux/bitops.h>
/*
- * deal with unrepresentable constant logarithms
- */
-extern __attribute__((const, noreturn))
-int ____ilog2_NaN(void);
-
-/*
* non-constant log of base 2 calculators
* - the arch may override these in asm/bitops.h if they can be implemented
* more efficiently than using fls() and fls64()
@@ -85,7 +79,7 @@ unsigned long __rounddown_pow_of_two(unsigned long n)
#define ilog2(n) \
( \
__builtin_constant_p(n) ? ( \
- (n) < 1 ? ____ilog2_NaN() : \
+ (n) < 1 ? 0 : \
(n) & (1ULL << 63) ? 63 : \
(n) & (1ULL << 62) ? 62 : \
(n) & (1ULL << 61) ? 61 : \
@@ -149,9 +143,7 @@ unsigned long __rounddown_pow_of_two(unsigned long n)
(n) & (1ULL << 3) ? 3 : \
(n) & (1ULL << 2) ? 2 : \
(n) & (1ULL << 1) ? 1 : \
- (n) & (1ULL << 0) ? 0 : \
- ____ilog2_NaN() \
- ) : \
+ 0) : \
(sizeof(n) <= 4) ? \
__ilog2_u32(n) : \
__ilog2_u64(n) \
@@ -194,7 +186,6 @@ unsigned long __rounddown_pow_of_two(unsigned long n)
* @n: parameter
*
* The first few values calculated by this routine:
- * ob2(0) = 0
* ob2(1) = 0
* ob2(2) = 1
* ob2(3) = 2
^ permalink raw reply related
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