* [PATCH] arm: ftrace: Adds support for CONFIG_DYNAMIC_FTRACE_WITH_REGS
From: Jean-Jacques Hiblot @ 2017-01-12 14:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112001957.GA5458@nuc>
2017-01-12 1:19 GMT+01:00 Abel Vesa <abelvesa@gmail.com>:
> On Tue, Jan 10, 2017 at 04:51:12PM +0100, Petr Mladek wrote:
>> On Thu 2016-12-08 22:46:55, Abel Vesa wrote:
>> > On Thu, Dec 08, 2016 at 09:46:35PM +0000, Abel Vesa wrote:
>> > > From: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
>> > >
>> > > From: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
>> >
>> > >From statement twice in the commit message. Will resend.
>> > >
>> > > The DYNAMIC_FTRACE_WITH_REGS configuration makes it possible for a ftrace
>> > > operation to specify if registers need to saved/restored by the ftrace handler.
>> > > This is needed by kgraft and possibly other ftrace-based tools, and the ARM
>> > > architecture is currently lacking this feature. It would also be the first step
>> > > to support the "Kprobes-on-ftrace" optimization on ARM.
>> > >
>> > > This patch introduces a new ftrace handler that stores the registers on the
>> > > stack before calling the next stage. The registers are restored from the stack
>> > > before going back to the instrumented function.
>> > >
>> > > A side-effect of this patch is to activate the support for ftrace_modify_call()
>> > > as it defines ARCH_SUPPORTS_FTRACE_OPS for the ARM architecture
>> > >
>> > > Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
>> > > Signed-off-by: Abel Vesa <abelvesa@linux.com>
>> > > ---
>> > > arch/arm/Kconfig | 2 ++
>> > > arch/arm/include/asm/ftrace.h | 4 +++
>> > > arch/arm/kernel/entry-ftrace.S | 78 ++++++++++++++++++++++++++++++++++++++++++
>> > > arch/arm/kernel/ftrace.c | 33 ++++++++++++++++++
>> > > 4 files changed, 117 insertions(+)
>> > >
>> > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> > > index b5d529f..87f1a9f 100644
>> > > --- a/arch/arm/Kconfig
>> > > +++ b/arch/arm/Kconfig
>> > > @@ -50,6 +50,7 @@ config ARM
>> > > select HAVE_DMA_API_DEBUG
>> > > select HAVE_DMA_CONTIGUOUS if MMU
>> > > select HAVE_DYNAMIC_FTRACE if (!XIP_KERNEL) && !CPU_ENDIAN_BE32 && MMU
>> > > + select HAVE_DYNAMIC_FTRACE_WITH_REGS if HAVE_DYNAMIC_FTRACE
>> > > select HAVE_EFFICIENT_UNALIGNED_ACCESS if (CPU_V6 || CPU_V6K || CPU_V7) && MMU
>> > > select HAVE_EXIT_THREAD
>> > > select HAVE_FTRACE_MCOUNT_RECORD if (!XIP_KERNEL)
>> > > @@ -90,6 +91,7 @@ config ARM
>> > > select PERF_USE_VMALLOC
>> > > select RTC_LIB
>> > > select SYS_SUPPORTS_APM_EMULATION
>> > > + select FRAME_POINTER if DYNAMIC_FTRACE_WITH_REGS && FUNCTION_GRAPH_TRACER
> Hi Petr,
>>
>> FRAME_POINTER is not for free. It takes space on the stack. Also there
>> is a performance penalty. Do we really need to depend on it? If so,
>> it might be worth a note in the commit message.
>
FRAME_POINTER is not needed. the dependency is wrong and should be removed.
The code must be modified to not use fp register:
--- a/arch/arm/kernel/entry-ftrace.S
+++ b/arch/arm/kernel/entry-ftrace.S
@@ -130,7 +130,8 @@ ftrace_graph_regs_call:
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
.macro __ftrace_graph_regs_caller
- sub r0, fp, #4 @ lr of instrumented
routine (parent)
+ add r0, sp, #64 @ r0 is now a pointer to lr of
+ @ instrumented routine
@ called from __ftrace_regs_caller
ldr r1, [sp, #56] @ instrumented routine (func)
@@ -139,8 +140,9 @@ ftrace_graph_regs_call:
mov r2, fp @ frame pointer
bl prepare_ftrace_return
- ldr lr, [fp, #-4] @ restore lr from the stack
- ldmia sp, {r0-r11, ip, sp} @ restore r0 through sp
+ ldr lr, [sp, #64] @ get the previous LR value from stack
+ ldmia sp, {r0-r11, ip, sp} @ pop the saved registers INCLUDING
+ @ the stack pointer
ret ip
.endm
#endif
Jean-Jacques
> I was trying to create my own patch when I found this work done by
> Jean-Jacques, so I haven't looked specifically for the FRAME_POINTER
> part. I looked now at it and you seem to be right, FRAME_POINTER is
> not needed.
>
> I will get rid of the FRAME_POINTER part, change the authorship and
> send it again in the following days.
>>
>> I made only a quick look at the patch. It looks reasonable. But I do
>> not have enough knowledge about the arm architecture, assembly, and
>> ftrace-specifics. Also I cannot test it easily. So issues might
>> be hidden to my eyes.
>>
>> Best Regards,
>> Petr
> Thanks,
> Abel
^ permalink raw reply
* [PATCH v5 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma
From: Appana Durga Kedareswara Rao @ 2017-01-12 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110062620.GZ3573@localhost>
Hi Vinod,
Thanks for the review...
>
> On Sat, Jan 07, 2017 at 12:15:29PM +0530, Kedareswara rao Appana wrote:
> > When VDMA is configured for more than one frame in the h/w for example
> > h/w is configured for n number of frames and user Submits n number of
> > frames and triggered the DMA using issue_pending API.
>
> title case in middle if sentence, no commas, can you make it easier to read
> please..
Ok sure will fix commit message in the next version.
>
> > In the current driver flow we are submitting one frame at a time but
> > we should submit all the n number of frames at one time as the h/w Is
> > configured for n number of frames.
>
> s/Is/is
Ok sure will fix in the next version....
Regards,
Kedar.
^ permalink raw reply
* [PATCH v5 3/3] dmaengine: xilinx_dma: Fix race condition in the driver for multiple descriptor scenario
From: Appana Durga Kedareswara Rao @ 2017-01-12 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110084917.GA3573@localhost>
Hi Vinod,
Thanks for the review...
> On Sat, Jan 07, 2017 at 12:15:30PM +0530, Kedareswara rao Appana wrote:
> > When driver is handling AXI DMA SoftIP When user submits multiple
> > descriptors back to back on the S2MM(recv) side with the current
> > driver flow the last buffer descriptor next bd points to a invalid
> > location resulting the invalid data or errors in the DMA engine.
>
> Can you rephrase this, it a bit hard to understand.
When DMA is receiving packets h/w expects the descriptors
Should be in the form of a ring (I mean h/w buffer descriptor
Next descriptor field should always point to valid address
So that when DMA engine go and fetch that next descriptor it always
Sees a valid address).
But with the current driver implementation when user queues
Multiple descriptors the last descriptor next descriptor field
Pointing to an invalid location causing data corruption or
Errors from the DMA h/w engine...
To avoid this issue creating a Buffer descriptor Chain during
Channel allocation and using those buffer descriptors for processing
User requested data.
Please let me know if the above explanation is not clear will explain in detail....
>
> >
> > This patch fixes this issue by creating a BD Chain during
>
> whats a BD?
Buffer descriptor.
>
> > channel allocation itself and use those BD's.
> >
> > Signed-off-by: Kedareswara rao Appana <appanad@xilinx.com>
> > ---
> >
> > drivers/dma/xilinx/xilinx_dma.c | 133
> > +++++++++++++++++++++++++---------------
> > 1 file changed, 83 insertions(+), 50 deletions(-)
> >
> > diff --git a/drivers/dma/xilinx/xilinx_dma.c
> > b/drivers/dma/xilinx/xilinx_dma.c index 0e9c02e..af2159d 100644
> > --- a/drivers/dma/xilinx/xilinx_dma.c
> > +++ b/drivers/dma/xilinx/xilinx_dma.c
> > @@ -163,6 +163,7 @@
> > #define XILINX_DMA_BD_SOP BIT(27)
> > #define XILINX_DMA_BD_EOP BIT(26)
> > #define XILINX_DMA_COALESCE_MAX 255
> > +#define XILINX_DMA_NUM_DESCS 255
>
> why 255?
It is not an h/w limitation
Allocating 255 descriptors (Each descriptor is capable of sending 7MB data)
So roughly using allocated descriptors DMA engine can transfer 1GB data
And in the driver we are reusing the allocated descriptors when they are free.
Regards,
Kedar.
^ permalink raw reply
* [PATCH] usb: dwc3: exynos: Remove MODULE_ALIAS()
From: Javier Martinez Canillas @ 2017-01-12 13:59 UTC (permalink / raw)
To: linux-arm-kernel
Exynos is DT-only, so there's no need for a platform MODALIAS.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
drivers/usb/dwc3/dwc3-exynos.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index e27899bb5706..2e555a69c8ab 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -288,7 +288,6 @@ static struct platform_driver dwc3_exynos_driver = {
module_platform_driver(dwc3_exynos_driver);
-MODULE_ALIAS("platform:exynos-dwc3");
MODULE_AUTHOR("Anton Tikhomirov <av.tikhomirov@samsung.com>");
MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("DesignWare USB3 EXYNOS Glue Layer");
--
2.7.4
^ permalink raw reply related
* [PATCH v8 2/5] i2c: Add STM32F4 I2C driver
From: M'boumba Cedric Madianga @ 2017-01-12 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112120309.fmrt2lwz3vklqmti@pengutronix.de>
2017-01-12 13:03 GMT+01:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> Hello Cedric,
>
> On Thu, Jan 12, 2017 at 12:23:12PM +0100, M'boumba Cedric Madianga wrote:
>> 2017-01-11 16:39 GMT+01:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
>> > On Wed, Jan 11, 2017 at 02:58:44PM +0100, M'boumba Cedric Madianga wrote:
>> >> 2017-01-11 9:22 GMT+01:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
>> >> > This is surprising. I didn't recheck the manual, but that looks very
>> >> > uncomfortable.
>> >>
>> >> I agree but this exactly the hardware way of working described in the
>> >> reference manual.
>> >
>> > IMHO that's a hw bug. This makes it for example impossible to implement
>> > SMBus block transfers (I think).
>>
>> This is not correct.
>> Setting STOP/START bit does not mean the the pulse will be sent right now.
>> Here we have just to prepare the hardware for the 2 next pulse but the
>> STOP/START/ACK pulse will be generated at the right time as required
>> by I2C specification.
>> So SMBus block transfer will be possible.
>
> A block transfer consists of a byte that specifies the count of bytes
> yet to come. So the device sends for example:
>
> 0x01 0xab
>
> So when you read the 1 in the first byte it's already too late to set
> STOP to get it after the 2nd byte.
>
> Not sure I got all the required details right, though.
Ok I understand your use case but I always think that the harware manages it.
If I take the above example, the I2C SMBus block read transaction will
be as below:
S Addr Wr [A] Comm [A]
S Addr Rd [A] [Count] A [Data1] A [Data2] NA P
The first message is a single byte-transmission so there is no problem.
The second message is a N-byte reception with N = 3
When the I2C controller has finished to send the device address (S
Addr Rd), the ADDR flag is set and an interrupt is raised.
In the routine that handles ADDR event, we set ACK bit in order to
generate ACK pulse as soon as a data byte is received in the shift
register and then we clear the ADDR flag.
Please note that the SCL line is stretched low until ADDR flag is cleared.
So, as far I understand, the device could not sent any data as long as
the SCL line is stretched low. Right ?
Then, as soon as the SCL line is high, the device could send the first
data byte (Count).
When this byte is received in the shift register, an ACK is
automatically generated as defined during adress match phase and the
data byte is pushed in DR (data register).
Then, an interrupt is raised as RXNE (RX not empty) flag is set.
In the routine that handles RXNE event, as N=3, we just clear all
buffer interrupts in order to avoid another system preemption due to
RXNE event but we does not read the data in DR.
After receiving the ACK, the device could send the second data byte (Data1).
When this byte is received in the shift register, an ACK is
automatically generated.
As the first data byte has not been read yet in DR, the BTF (Byte
Transfer Finihed) flag is set and an interrupt is raised.
So, in that case, the SCL line is also streched low as long as the
data register has not been read.
In the routine that handle BTF event, we enable NACK in order to
generate this pulse as soon as the last data byte will be received and
then we read DR register ([Count])
At this moment, SCL line is released and the device could send the
last data byte.
After receiving the ACK, the device could send the third and last data
byte (Data2)
When this byte is received in the shift register, a NACK is
automatically generated as we enable it as explained above.
As the second data byte (Data1) has not been read yet in DR, the BTF
flag is set again and an interrupt is raised.
The SCL line is stretched low and in that way we could set the STOP
bit to generate this pulse.
Then we run 2 consecutives read of DR to retrieve [Data1] and [Data2]
and to set SCL high.
So, thanks to SCL stretching, it seems that NA and P will be generated
at the right time.
Please let me know if it is not correct.
Best regards,
Cedric
^ permalink raw reply
* [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()
From: Robin Murphy @ 2017-01-12 13:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3273119.LjYLKcrNcz@wuerfel>
On 12/01/17 13:25, Arnd Bergmann wrote:
> On Thursday, January 12, 2017 12:16:24 PM CET Will Deacon wrote:
>> On Thu, Jan 12, 2017 at 08:52:51AM +0300, Nikita Yushchenko wrote:
>>>>> diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
>>>>> index 5ac373c..480b644 100644
>>>>> --- a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
>>>>> +++ b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
>>>>> @@ -540,7 +540,7 @@ int fsl_mc_device_add(struct dprc_obj_desc *obj_desc,
>>>>>
>>>>> /* Objects are coherent, unless 'no shareability' flag set. */
>>>>> if (!(obj_desc->flags & DPRC_OBJ_FLAG_NO_MEM_SHAREABILITY))
>>>>> - arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true);
>>>>> + arch_setup_dma_ops(&mc_dev->dev, 0, 0, false, NULL, true);
>>>>>
>>>>> /*
>>>>> * The device-specific probe callback will get invoked by device_add()
>>>>
>>>> Why are these actually calling arch_setup_dma_ops() here in the first
>>>> place? Are these all devices that are DMA masters without an OF node?
>>>
>>> I don't know, but that's a different topic. This patch just adds
>>> argument and sets it to false everywhere but in the location when range
>>> should be definitely enforced.
>>
>> I also wouldn't lose any sleep over a staging driver.
>
> I think this is in the process of being moved out of staging, and
> my question was about the other two as well:
The fsl-mc is actually a sort-of-bus-controller probing and configuring
its (directly DMA-capable) child devices, so is in fact legitimate here.
> drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
That one is completely bogus, and should just go away.
> drivers/iommu/rockchip-iommu.c
That one is part of some ugly trickery involving creating a fake device
to represent multiple separate IOMMU devices. The driver could probably
be reworked to not need it (the Exynos IOMMU handles a similar situation
without such tricks), but it's non-trivial.
Robin.
>
> Arnd
>
^ permalink raw reply
* [PATCH] PCI:MSI Return -ENOSPC when requested vectors is not enough
From: Christoph Hellwig @ 2017-01-12 13:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111181853.GA14532@bhelgaas-glaptop.roam.corp.google.com>
On Wed, Jan 11, 2017 at 12:18:53PM -0600, Bjorn Helgaas wrote:
> Unless Christoph objects, I'll apply this, but I don't understand the
> situation with 17a51f12cfbd. That commit doesn't check for EINVAL or
> ENOSPC so I don't know what the connection with this patch is.
I don't think that commit is the culprit.
> I know Christoph said he changed something in ahci to treat all errors
> the same, but I don't know where that is, either.
"ahci: always fall back to single-MSI mode"
^ permalink raw reply
* [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()
From: Nikita Yushchenko @ 2017-01-12 13:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3013606.q8hexDUEqF@wuerfel>
>>>> Hmm, I think when the dma-ranges are missing, we should either enforce
>>>> a 32-bit mask, or disallow DMA completely. It's probably too late for
>>>> the latter, I wish we had done this earlier in order to force everyone
>>>> on ARM64 to have a valid dma-ranges property for any DMA master.
>>>
>>> This can be done over time.
>>>
>>> However the very idea of this version of patch is - keep working pieces
>>> as-is, thus for now setting enforce_range to false in case of no defined
>>> dma-ranges is intentional.
>>
>> What we can do is - check bus width (as it is defined in DT) and set
>> enforce_range to true if bus is 32-bit
>>
>>> What I should re-check is - does rcar dtsi set dma-ranges, and add it if
>>> it does not.
>>
>> It does not, will have to add.
>>
>> In DT bus is defined as 64-bit. But looks like physically it is 32-bit.
>> Maybe DT needs fixing.
>
> I think we always assumed that the lack of a dma-ranges property
> implied a 32-bit width, as that is the safe fallback as well as the
> most common case.
Yes we assumed that, but that was combined with blindly accepting wider
dma_mask per driver's request. Later is being changed.
> AFAICT, this means you are actually fine on rcar, and all other
> platforms will keep working as we enforce it, but might get slowed
> down if they relied on the unintended behavior of allowing 64-bit
> DMA.
Yesterday Robin raised issue that a change starting to enforce default
dma_mask will break existing setups - i.e. those that depend in 64bit
DMA being implicitly supported without manually declaring such support.
In reply to that, I suggested this version of patchset that should keep
existing behavior by default.
I'm fine with both approaches regarding behavior on hw that I don't have
- but I'm not in position to make any decisions on that.
^ permalink raw reply
* [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()
From: Arnd Bergmann @ 2017-01-12 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7d7dc402-e527-c581-0b1c-37713759db31@cogentembedded.com>
On Thursday, January 12, 2017 9:33:32 AM CET Nikita Yushchenko wrote:
> >> Hmm, I think when the dma-ranges are missing, we should either enforce
> >> a 32-bit mask, or disallow DMA completely. It's probably too late for
> >> the latter, I wish we had done this earlier in order to force everyone
> >> on ARM64 to have a valid dma-ranges property for any DMA master.
> >
> > This can be done over time.
> >
> > However the very idea of this version of patch is - keep working pieces
> > as-is, thus for now setting enforce_range to false in case of no defined
> > dma-ranges is intentional.
>
> What we can do is - check bus width (as it is defined in DT) and set
> enforce_range to true if bus is 32-bit
>
> > What I should re-check is - does rcar dtsi set dma-ranges, and add it if
> > it does not.
>
> It does not, will have to add.
>
> In DT bus is defined as 64-bit. But looks like physically it is 32-bit.
> Maybe DT needs fixing.
I think we always assumed that the lack of a dma-ranges property
implied a 32-bit width, as that is the safe fallback as well as the
most common case.
AFAICT, this means you are actually fine on rcar, and all other
platforms will keep working as we enforce it, but might get slowed
down if they relied on the unintended behavior of allowing 64-bit
DMA.
Arnd
^ permalink raw reply
* [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()
From: Arnd Bergmann @ 2017-01-12 13:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112121623.GH1771@arm.com>
On Thursday, January 12, 2017 12:16:24 PM CET Will Deacon wrote:
> On Thu, Jan 12, 2017 at 08:52:51AM +0300, Nikita Yushchenko wrote:
> > >> diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
> > >> index 5ac373c..480b644 100644
> > >> --- a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
> > >> +++ b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
> > >> @@ -540,7 +540,7 @@ int fsl_mc_device_add(struct dprc_obj_desc *obj_desc,
> > >>
> > >> /* Objects are coherent, unless 'no shareability' flag set. */
> > >> if (!(obj_desc->flags & DPRC_OBJ_FLAG_NO_MEM_SHAREABILITY))
> > >> - arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true);
> > >> + arch_setup_dma_ops(&mc_dev->dev, 0, 0, false, NULL, true);
> > >>
> > >> /*
> > >> * The device-specific probe callback will get invoked by device_add()
> > >
> > > Why are these actually calling arch_setup_dma_ops() here in the first
> > > place? Are these all devices that are DMA masters without an OF node?
> >
> > I don't know, but that's a different topic. This patch just adds
> > argument and sets it to false everywhere but in the location when range
> > should be definitely enforced.
>
> I also wouldn't lose any sleep over a staging driver.
I think this is in the process of being moved out of staging, and
my question was about the other two as well:
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
drivers/iommu/rockchip-iommu.c
Arnd
^ permalink raw reply
* [PATCH 1/2][UPDATE] of: base: add support to get the number of cache levels
From: Rob Herring @ 2017-01-12 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484049616-22388-1-git-send-email-sudeep.holla@arm.com>
On Tue, Jan 10, 2017 at 6:00 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> It is useful to have helper function just to get the number of cache
> levels for a given logical cpu. This patch adds the support for the
> same.
>
> It will be used on ARM64 platform where the device tree provides the
> information for the additional non-architected/transparent/external
> last level caches that are not integrated with the processors.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> drivers/of/base.c | 23 +++++++++++++++++++++++
> include/linux/of.h | 1 +
> 2 files changed, 24 insertions(+)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index d4bea3c797d6..80e557eca858 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -25,6 +25,7 @@
> #include <linux/cpu.h>
> #include <linux/module.h>
> #include <linux/of.h>
> +#include <linux/of_device.h>
> #include <linux/of_graph.h>
> #include <linux/spinlock.h>
> #include <linux/slab.h>
> @@ -2268,6 +2269,28 @@ struct device_node *of_find_next_cache_node(const struct device_node *np)
> }
>
> /**
> + * of_count_cache_levels - Find the total number of cache levels for the
> + * given logical cpu
> + *
> + * @cpu: cpu number(logical index) for which cache levels is being counted
> + *
> + * Returns the total number of cache levels for the given logical cpu
> + */
> +int of_count_cache_levels(unsigned int cpu)
> +{
> + int level = 0;
> + struct device_node *np = of_cpu_device_node_get(cpu);
> +
> + while (np) {
> + level++;
This will return 1 if you have a cpu node and no cache nodes. Are you
assuming the cpu has a cache?
Perhaps you should just find the last level cache node and then just
read "cache-level".
Rob
^ permalink raw reply
* [PATCH v7 0/4] arm64: arch_timer: Add workaround for hisilicon-161601 erratum
From: Ding Tianhong @ 2017-01-12 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ff9c81c2-90ef-a5c2-6f0b-c6cf5d0d11a9@arm.com>
On 2017/1/12 17:11, Marc Zyngier wrote:
> On 12/01/17 04:23, Ding Tianhong wrote:
>> Hi Marc:
>>
>> How about this v7, if any suggestions very grateful.
>
> It's been less than 5 days since you posted this. I'll get to it once I
> finish reviewing all the other patches that are sitting in the queue
> right before yours.
>
Ok and sorry for the noisy.
Thanks
Ding
> Thanks,
>
> M.
>
^ permalink raw reply
* CONFIG_PCIEASPM breaks PCIe on Marvell Armada 385 machine
From: Uwe Kleine-König @ 2017-01-12 13:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111220235.GP14532@bhelgaas-glaptop.roam.corp.google.com>
On 01/11/2017 11:02 PM, Bjorn Helgaas wrote:
> Hi Uwe,
>
> On Wed, Jan 11, 2017 at 08:49:46PM +0100, Uwe Kleine-K?nig wrote:
>> Hello,
>>
>> on an Marvell Armada 385 based machine (Turris Omnia) with 4.9 the
>> ath10k driver fails to bind to the matching hardware if CONFIG_PCIEASPM
>> is enabled:
>>
>> [...]
> We have several open issues related to ASPM:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=102311 ASPM: ASMEDA asm1062 not working
> https://bugzilla.kernel.org/show_bug.cgi?id=187731 Null pointer dereference in ASPM
> https://bugzilla.kernel.org/show_bug.cgi?id=189951 Enabling ASPM causes NIC performance issue
> https://bugzilla.kernel.org/show_bug.cgi?id=60111 NULL pointer deref in ASPM alloc_pcie_link_state()
>
> I don't recognize yours as being one of these. Can you open a new
> issue and attach the complete dmesg log and "lspci -vv" output?
Done: https://bugzilla.kernel.org/show_bug.cgi?id=192441
> Is this a regression?
As written in the bug report this also happens on 4.7.
Best regards
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170112/d9f681f1/attachment.sig>
^ permalink raw reply
* NVMe vs DMA addressing limitations
From: Christoph Hellwig @ 2017-01-12 13:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3306663.hKmLLq1hhl@wuerfel>
On Thu, Jan 12, 2017 at 12:56:07PM +0100, Arnd Bergmann wrote:
> That is an interesting question: We actually have the
> "DMA_ATTR_NO_KERNEL_MAPPING" for this case, and ARM implements
> it in the coherent interface, so that might be a good fit.
Yes. my WIP HMB patch uses DMA_ATTR_NO_KERNEL_MAPPING, although I'm
workin on x86 at the moment where it's a no-op.
> Implementing it in the streaming API makes no sense since we
> already have a kernel mapping here, but using a normal allocation
> (possibly with DMA_ATTR_NON_CONSISTENT or DMA_ATTR_SKIP_CPU_SYNC,
> need to check) might help on other architectures that have
> limited amounts of coherent memory and no CMA.
Though about that - but in the end DMA_ATTR_NO_KERNEL_MAPPING implies
those, so instead of using lots of flags in driver I'd rather fix
up more dma_ops implementations to take advantage of
DMA_ATTR_NO_KERNEL_MAPPING.
^ permalink raw reply
* [GIT PULL] Ux500 development for v4.11
From: Linus Walleij @ 2017-01-12 13:06 UTC (permalink / raw)
To: linux-arm-kernel
Hi ARM SoC folks,
here is a set of two patches ready to be queued for v4.11 already.
Please pull them to a suitable branch on the ARM SoC tree.
Yours,
Linus Walleij
The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git
tags/ux500-dev-for-armsoc
for you to fetch changes up to f3c05596344fa09074220513583bc5d6ff2d5c43:
ARM: ux500: remove duplicated include from cpu-db8500.c (2017-01-12
14:02:34 +0100)
----------------------------------------------------------------
Some two collected patches simplifying some Ux500
stuff.
----------------------------------------------------------------
Linus Walleij (1):
ARM: ux500: simplify secondary boot
Wei Yongjun (1):
ARM: ux500: remove duplicated include from cpu-db8500.c
arch/arm/mach-ux500/cpu-db8500.c | 1 -
arch/arm/mach-ux500/platsmp.c | 45 +++++++++++++++++-----------------------
2 files changed, 19 insertions(+), 27 deletions(-)
^ permalink raw reply
* [GIT PULL] Ux500 PM fix from Arnd
From: Linus Walleij @ 2017-01-12 13:01 UTC (permalink / raw)
To: linux-arm-kernel
Hi ARM SoC folks,
this was forgotten on my fixes branch, sorry. Please pull it
in for fixes in the ARM SoC tree.
Yours,
Linus Walleij
The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git
tags/ux500-fix-for-armsoc
for you to fetch changes up to f0e8faa7a5e894b0fc99d24be1b18685a92ea466:
ARM: ux500: fix prcmu_is_cpu_in_wfi() calculation (2017-01-12 13:25:39 +0100)
----------------------------------------------------------------
A single PM fix from Arnd
----------------------------------------------------------------
Arnd Bergmann (1):
ARM: ux500: fix prcmu_is_cpu_in_wfi() calculation
arch/arm/mach-ux500/pm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
^ permalink raw reply
* [kvm-unit-tests PATCH 1/6] libcflat: add PRI(dux)32 format types
From: Alex Bennée @ 2017-01-12 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4286b719-ff75-d2cd-68b5-cb9d9bb89553@redhat.com>
Paolo Bonzini <pbonzini@redhat.com> writes:
> On 11/01/2017 17:28, Alex Benn?e wrote:
>> So we can have portable formatting of uint32_t types. However there is
>> a catch. Different compilers can use legally subtly different types
>> though so we need to probe the compiler defined intdef.h first.
>
> Interesting, what platform has long uint32_t? I thought the issue was
> whether 64-bit is long or "long long".
I haven't run into that one. This came up with the arm-none-eabi-gcc on
my overdrive01 box. According to the toolchain guys there is no particular
reason a 32bit compiler can't use long for its natural word length.
The native compiler on Debian armhf doesn't do this but the
arm-none-eabi-gcc compilers on both 64bit and 32bit Debian need this.
>
> Paolo
>
>> Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
>> ---
>> Makefile | 1 +
>> configure | 13 +++++++++++++
>> lib/libcflat.h | 9 +++++++++
>> 3 files changed, 23 insertions(+)
>>
>> diff --git a/Makefile b/Makefile
>> index a32333b..9822d9a 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -55,6 +55,7 @@ CFLAGS += $(fomit_frame_pointer)
>> CFLAGS += $(fno_stack_protector)
>> CFLAGS += $(fno_stack_protector_all)
>> CFLAGS += $(wno_frame_address)
>> +CFLAGS += $(if $(U32_LONG_FMT),-D__U32_LONG_FMT__,)
>>
>> CXXFLAGS += $(CFLAGS)
>>
>> diff --git a/configure b/configure
>> index 995c8fa..127868c 100755
>> --- a/configure
>> +++ b/configure
>> @@ -109,6 +109,18 @@ if [ -f $testdir/run ]; then
>> ln -fs $testdir/run $testdir-run
>> fi
>>
>> +# check if uint32_t needs a long format modifier
>> +cat << EOF > lib_test.c
>> +#include <inttypes.h>
>> +EOF
>> +
>> +$cross_prefix$cc lib_test.c -E | grep "typedef" | grep "long" | grep "uint32_t" &> /dev/null
>> +exit=$?
>> +if [ $exit -eq 0 ]; then
>> + u32_long=true
>> +fi
>> +rm -f lib_test.c
>> +
>> # check for dependent 32 bit libraries
>> if [ "$arch" != "arm" ]; then
>> cat << EOF > lib_test.c
>> @@ -155,4 +167,5 @@ TEST_DIR=$testdir
>> FIRMWARE=$firmware
>> ENDIAN=$endian
>> PRETTY_PRINT_STACKS=$pretty_print_stacks
>> +U32_LONG_FMT=$u32_long
>> EOF
>> diff --git a/lib/libcflat.h b/lib/libcflat.h
>> index 380395f..e80fc50 100644
>> --- a/lib/libcflat.h
>> +++ b/lib/libcflat.h
>> @@ -58,12 +58,21 @@ typedef _Bool bool;
>> #define true 1
>>
>> #if __SIZEOF_LONG__ == 8
>> +# define __PRI32_PREFIX
>> # define __PRI64_PREFIX "l"
>> # define __PRIPTR_PREFIX "l"
>> #else
>> +#if defined(__U32_LONG_FMT__)
>> +# define __PRI32_PREFIX "l"
>> +#else
>> +# define __PRI32_PREFIX
>> +#endif
>> # define __PRI64_PREFIX "ll"
>> # define __PRIPTR_PREFIX
>> #endif
>> +#define PRId32 __PRI32_PREFIX "d"
>> +#define PRIu32 __PRI32_PREFIX "u"
>> +#define PRIx32 __PRI32_PREFIX "x"
>> #define PRId64 __PRI64_PREFIX "d"
>> #define PRIu64 __PRI64_PREFIX "u"
>> #define PRIx64 __PRI64_PREFIX "x"
>>
--
Alex Benn?e
^ permalink raw reply
* [kvm-unit-tests PATCH 2/6] lib/pci: fix BAR format strings
From: Paolo Bonzini @ 2017-01-12 12:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111162841.15569-3-alex.bennee@linaro.org>
On 11/01/2017 17:28, Alex Benn?e wrote:
> Using %x as a format string is not portable across 32/64 bit builds.
> Use explicit PRIx32 format strings like the 64 bit version above.
>
> Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
> ---
> lib/pci.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lib/pci.c b/lib/pci.c
> index 6416191..597d8f2 100644
> --- a/lib/pci.c
> +++ b/lib/pci.c
> @@ -67,7 +67,7 @@ bool pci_setup_msi(struct pci_dev *dev, uint64_t msi_addr, uint32_t msi_data)
> pci_config_writel(addr, offset + PCI_MSI_DATA_32, msi_data);
> printf("MSI: dev 0x%x init 32bit address: ", addr);
> }
> - printf("addr=0x%lx, data=0x%x\n", msi_addr, msi_data);
> + printf("addr=0x%" PRIx64 ", data=0x%" PRIx32 "\n", msi_addr, msi_data);
Applying only the %lx -> %"PRIx64" change for now (though it's also in
Andrew's 32-bit compilation fixes patch).
Paolo
>
> msi_control |= PCI_MSI_FLAGS_ENABLE;
> pci_config_writew(addr, offset + PCI_MSI_FLAGS, msi_control);
> @@ -237,7 +237,7 @@ void pci_bar_print(struct pci_dev *dev, int bar_num)
> printf("BAR#%d,%d [%" PRIx64 "-%" PRIx64 " ",
> bar_num, bar_num + 1, start, end);
> } else {
> - printf("BAR#%d [%02x-%02x ",
> + printf("BAR#%d [%" PRIx32 "-%" PRIx32 " ",
> bar_num, (uint32_t)start, (uint32_t)end);
> }
>
>
^ permalink raw reply
* [kvm-unit-tests PATCH 4/6] docs: mention checkpatch in the README
From: Alex Bennée @ 2017-01-12 12:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <322298cd-aefa-e945-d3f4-1237767a06ef@redhat.com>
Paolo Bonzini <pbonzini@redhat.com> writes:
> On 11/01/2017 17:28, Alex Benn?e wrote:
>> Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
>> ---
>> README.md | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/README.md b/README.md
>> index 5027b62..9462824 100644
>> --- a/README.md
>> +++ b/README.md
>> @@ -79,3 +79,4 @@ You can add the following to .git/config to do this automatically for you:
>> [format]
>> subjectprefix = kvm-unit-tests PATCH
>>
>> +Please run the kernel's ./scripts/checkpatch.pl on new patches
>
> Does it really work well on kvm-unit-tests?
Well I keep getting pulled up on kernel coding style on my reviews so if
we mean it we should enforce it.
--
Alex Benn?e
^ permalink raw reply
* [kvm-unit-tests PATCH 6/6] run_tests: allow passing of options to QEMU
From: Paolo Bonzini @ 2017-01-12 12:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111162841.15569-7-alex.bennee@linaro.org>
On 11/01/2017 17:28, Alex Benn?e wrote:
> This allows additional options to be passed to QEMU. It follows the
> convention of passing parameters after a -- to the child process. In
> my case I'm using it to toggle MTTCG on an off:
>
> ./run_tests.sh -- --accel tcg,thread=multi
>
> Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
>
> ---
> v1
> - changes from -o to --
> - fixed whitespace damage
> ---
> README.md | 6 ++++++
> run_tests.sh | 13 +++++++++++--
> scripts/functions.bash | 7 ++++---
> 3 files changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/README.md b/README.md
> index fa3a445..1bd6dcb 100644
> --- a/README.md
> +++ b/README.md
> @@ -55,6 +55,12 @@ To extend or disable the timeouts:
>
> TIMEOUT=0 ./run_tests.sh
>
> +Any arguments past the end-of-arguments marker (--) is passed on down
> +to the QEMU invocation. This can of course be combined with the other
> +modifiers:
> +
> + ACCEL=tcg ./run_tests.sh -v -- --accel tcg,thread=multi
> +
> # Contributing
>
> ## Directory structure
> diff --git a/run_tests.sh b/run_tests.sh
> index 254129d..3270fba 100755
> --- a/run_tests.sh
> +++ b/run_tests.sh
> @@ -13,7 +13,7 @@ function usage()
> {
> cat <<EOF
>
> -Usage: $0 [-g group] [-h] [-v]
> +Usage: $0 [-g group] [-h] [-v] [-- QEMU options]
>
> -g: Only execute tests in the given group
> -h: Output this help text
> @@ -22,6 +22,8 @@ Usage: $0 [-g group] [-h] [-v]
> Set the environment variable QEMU=/path/to/qemu-system-ARCH to
> specify the appropriate qemu binary for ARCH-run.
>
> +All options specified after -- are passed on to QEMU.
> +
> EOF
> }
>
> @@ -29,6 +31,7 @@ RUNTIME_arch_run="./$TEST_DIR/run"
> source scripts/runtime.bash
>
> while getopts "g:hv" opt; do
> +
> case $opt in
> g)
> only_group=$OPTARG
> @@ -46,6 +49,12 @@ while getopts "g:hv" opt; do
> esac
> done
>
> +# Any options left for QEMU?
> +shift $((OPTIND-1))
> +if [ "$#" -gt 0 ]; then
> + extra_opts="$@"
> +fi
> +
> RUNTIME_log_stderr () { cat >> test.log; }
> RUNTIME_log_stdout () {
> if [ "$PRETTY_PRINT_STACKS" = "yes" ]; then
> @@ -59,4 +68,4 @@ RUNTIME_log_stdout () {
> config=$TEST_DIR/unittests.cfg
> rm -f test.log
> printf "BUILD_HEAD=$(cat build-head)\n\n" > test.log
> -for_each_unittest $config run
> +for_each_unittest $config run "$extra_opts"
> diff --git a/scripts/functions.bash b/scripts/functions.bash
> index ee9143c..60fbc6a 100644
> --- a/scripts/functions.bash
> +++ b/scripts/functions.bash
> @@ -3,10 +3,11 @@ function for_each_unittest()
> {
> local unittests="$1"
> local cmd="$2"
> + local extra_opts=$3
> local testname
> local smp
> local kernel
> - local opts
> + local opts=$extra_opts
> local groups
> local arch
> local check
> @@ -21,7 +22,7 @@ function for_each_unittest()
> testname=${BASH_REMATCH[1]}
> smp=1
> kernel=""
> - opts=""
> + opts=$extra_opts
> groups=""
> arch=""
> check=""
> @@ -32,7 +33,7 @@ function for_each_unittest()
> elif [[ $line =~ ^smp\ *=\ *(.*)$ ]]; then
> smp=${BASH_REMATCH[1]}
> elif [[ $line =~ ^extra_params\ *=\ *(.*)$ ]]; then
> - opts=${BASH_REMATCH[1]}
> + opts="$opts ${BASH_REMATCH[1]}"
> elif [[ $line =~ ^groups\ *=\ *(.*)$ ]]; then
> groups=${BASH_REMATCH[1]}
> elif [[ $line =~ ^arch\ *=\ *(.*)$ ]]; then
>
Great idea!
Paolo
^ permalink raw reply
* [kvm-unit-tests PATCH 4/6] docs: mention checkpatch in the README
From: Paolo Bonzini @ 2017-01-12 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111162841.15569-5-alex.bennee@linaro.org>
On 11/01/2017 17:28, Alex Benn?e wrote:
> Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
> ---
> README.md | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/README.md b/README.md
> index 5027b62..9462824 100644
> --- a/README.md
> +++ b/README.md
> @@ -79,3 +79,4 @@ You can add the following to .git/config to do this automatically for you:
> [format]
> subjectprefix = kvm-unit-tests PATCH
>
> +Please run the kernel's ./scripts/checkpatch.pl on new patches
Does it really work well on kvm-unit-tests?
Paolo
^ permalink raw reply
* [kvm-unit-tests PATCH 1/6] libcflat: add PRI(dux)32 format types
From: Paolo Bonzini @ 2017-01-12 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111162841.15569-2-alex.bennee@linaro.org>
On 11/01/2017 17:28, Alex Benn?e wrote:
> So we can have portable formatting of uint32_t types. However there is
> a catch. Different compilers can use legally subtly different types
> though so we need to probe the compiler defined intdef.h first.
Interesting, what platform has long uint32_t? I thought the issue was
whether 64-bit is long or "long long".
Paolo
> Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
> ---
> Makefile | 1 +
> configure | 13 +++++++++++++
> lib/libcflat.h | 9 +++++++++
> 3 files changed, 23 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index a32333b..9822d9a 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -55,6 +55,7 @@ CFLAGS += $(fomit_frame_pointer)
> CFLAGS += $(fno_stack_protector)
> CFLAGS += $(fno_stack_protector_all)
> CFLAGS += $(wno_frame_address)
> +CFLAGS += $(if $(U32_LONG_FMT),-D__U32_LONG_FMT__,)
>
> CXXFLAGS += $(CFLAGS)
>
> diff --git a/configure b/configure
> index 995c8fa..127868c 100755
> --- a/configure
> +++ b/configure
> @@ -109,6 +109,18 @@ if [ -f $testdir/run ]; then
> ln -fs $testdir/run $testdir-run
> fi
>
> +# check if uint32_t needs a long format modifier
> +cat << EOF > lib_test.c
> +#include <inttypes.h>
> +EOF
> +
> +$cross_prefix$cc lib_test.c -E | grep "typedef" | grep "long" | grep "uint32_t" &> /dev/null
> +exit=$?
> +if [ $exit -eq 0 ]; then
> + u32_long=true
> +fi
> +rm -f lib_test.c
> +
> # check for dependent 32 bit libraries
> if [ "$arch" != "arm" ]; then
> cat << EOF > lib_test.c
> @@ -155,4 +167,5 @@ TEST_DIR=$testdir
> FIRMWARE=$firmware
> ENDIAN=$endian
> PRETTY_PRINT_STACKS=$pretty_print_stacks
> +U32_LONG_FMT=$u32_long
> EOF
> diff --git a/lib/libcflat.h b/lib/libcflat.h
> index 380395f..e80fc50 100644
> --- a/lib/libcflat.h
> +++ b/lib/libcflat.h
> @@ -58,12 +58,21 @@ typedef _Bool bool;
> #define true 1
>
> #if __SIZEOF_LONG__ == 8
> +# define __PRI32_PREFIX
> # define __PRI64_PREFIX "l"
> # define __PRIPTR_PREFIX "l"
> #else
> +#if defined(__U32_LONG_FMT__)
> +# define __PRI32_PREFIX "l"
> +#else
> +# define __PRI32_PREFIX
> +#endif
> # define __PRI64_PREFIX "ll"
> # define __PRIPTR_PREFIX
> #endif
> +#define PRId32 __PRI32_PREFIX "d"
> +#define PRIu32 __PRI32_PREFIX "u"
> +#define PRIx32 __PRI32_PREFIX "x"
> #define PRId64 __PRI64_PREFIX "d"
> #define PRIu64 __PRI64_PREFIX "u"
> #define PRIx64 __PRI64_PREFIX "x"
>
^ permalink raw reply
* [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()
From: Will Deacon @ 2017-01-12 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <764334db-3400-58c6-cc4b-3f7ce66daa27@cogentembedded.com>
On Thu, Jan 12, 2017 at 08:52:51AM +0300, Nikita Yushchenko wrote:
> >> diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
> >> index 5ac373c..480b644 100644
> >> --- a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
> >> +++ b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
> >> @@ -540,7 +540,7 @@ int fsl_mc_device_add(struct dprc_obj_desc *obj_desc,
> >>
> >> /* Objects are coherent, unless 'no shareability' flag set. */
> >> if (!(obj_desc->flags & DPRC_OBJ_FLAG_NO_MEM_SHAREABILITY))
> >> - arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true);
> >> + arch_setup_dma_ops(&mc_dev->dev, 0, 0, false, NULL, true);
> >>
> >> /*
> >> * The device-specific probe callback will get invoked by device_add()
> >
> > Why are these actually calling arch_setup_dma_ops() here in the first
> > place? Are these all devices that are DMA masters without an OF node?
>
> I don't know, but that's a different topic. This patch just adds
> argument and sets it to false everywhere but in the location when range
> should be definitely enforced.
I also wouldn't lose any sleep over a staging driver.
Will
^ permalink raw reply
* [PATCH 56/62] watchdog: tangox_wdt: Convert to use device managed functions
From: Marc Gonzalez @ 2017-01-12 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <yw1xlgugldws.fsf@unicorn.mansr.com>
On 12/01/2017 12:24, M?ns Rullg?rd wrote:
> Marc Gonzalez writes:
>
>>> So far we have a claim that a cast to a void * may somehow be different
>>> to a cast to a different pointer, if used as function argument, and that
>>> the behavior with such a cast may be undefined. In other words, you claim
>>> that a function implemented as, say,
>>>
>>> void func(int *var) {}
>>>
>>> might result in undefined behavior if some header file declares it as
>>>
>>> void func(void *);
>>>
>>> and it is called as
>>>
>>> int var;
>>>
>>> func(&var);
>>>
>>> That seems really far fetched to me.
>>
>> Thanks for giving me an opportunity to play the language lawyer :-)
>>
>> C99 6.3.2.3 sub-clause 8 states:
>>
>> "A pointer to a function of one type may be converted to a pointer to
>> a function of another type and back again; the result shall compare
>> equal to the original pointer. If a converted pointer is used to call
>> a function whose type is not compatible with the pointed-to type, the
>> behavior is undefined."
>>
>> So, the behavior is undefined, not when you cast clk_disable_unprepare,
>> but when clk_disable_unprepare is later called through the devres->action
>> function pointer.
>
> Only if the function types are incompatible. C99 6.7.5.3 subclause 15:
>
> For two function types to be compatible, both shall specify compatible
> return types. Moreover, the parameter type lists, if both are
> present, shall agree in the number of parameters and in use of the
> ellipsis terminator; corresponding parameters shall have compatible
> types.
>
> The question then is whether pointer to void and pointer to struct clk
> are compatible types.
6.2.7 Compatible type and composite type
sub-clause 1
"Two types have compatible type if their types are the same. Additional rules for
determining whether two types are compatible are described in 6.7.2 for type specifiers,
in 6.7.3 for type qualifiers, and in 6.7.5 for declarators."
6.7.5.1 Pointer declarators
sub-clause 2
"For two pointer types to be compatible, both shall be identically qualified and both shall
be pointers to compatible types."
I don't think void and struct clk are compatible types.
AFAIU, conversion and compatibility are two separate subjects.
Regards.
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: juno: Adds missing CoreSight STM component.
From: Sudeep Holla @ 2017-01-12 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DB6PR0802MB2198449A31AD8624B48045428C790@DB6PR0802MB2198.eurprd08.prod.outlook.com>
On 12/01/17 11:24, Mike Leach wrote:
> Hi Sudeep,
>
> I'm fine with that - less duplication the better.
>
> I've not played with .dts files much to I hadn't realised that type
> of construction was possible.
>
OK I spent some time and I think we can do the same for other coresight
components too. I will modify post the series but I need your help to
validate the change running core-sight tests.
--
Regards,
Sudeep
^ 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