* [PATCH] usb: dwc3-exynos fix unspecified suspend clk error handling
From: Shuah Khan @ 2017-01-10 14:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2e4a5e53-6603-13b8-0302-dc8093978013@osg.samsung.com>
On 01/10/2017 07:16 AM, Shuah Khan wrote:
> On 01/10/2017 05:05 AM, Bartlomiej Zolnierkiewicz wrote:
>>
>> Hi,
>>
>> On Monday, January 09, 2017 07:21:31 PM Shuah Khan wrote:
>>> Fix dwc3_exynos_probe() to call clk_prepare_enable() only when suspend
>>> clock is specified. Call clk_disable_unprepare() from remove and probe
>>> error path only when susp_clk has been set from remove and probe error
>>> paths.
>>
>> It is legal to call clk_prepare_enable() and clk_disable_unprepare()
>> for NULL clock. Also your patch changes susp_clk handling while
>> leaves axius_clk handling (which also can be NULL) untouched.
>>
>> Do you actually see some runtime problem with the current code?
>>
>> If not then the patch should probably be dropped.
>>
>> Best regards,
>> --
>> Bartlomiej Zolnierkiewicz
>> Samsung R&D Institute Poland
>> Samsung Electronics
>
> Hi Bartlomiej,
>
> I am seeing the "no suspend clk specified" message in dmesg.
> After that it sets the exynos->susp_clk = NULL and starts
> calling clk_prepare_enable(exynos->susp_clk);
>
> That can't be good. If you see the logic right above this
> one for exynos->clk, it returns error and fails the probe.
> This this case it doesn't, but tries to use null susp_clk.
>
> I believe this patch is necessary.
Let me clarify this a bit further. Since we already know
susp_clk is null, with this patch we can avoid extra calls
to clk_prepare_enable() and clk_disable_unprepare().
One can say, it also adds extra checks, hence I will let you
decide one way or the other. :)
thanks,
-- Shuah
>
> thanks,
> -- Shuah
>
>>
>>> Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
>>> ---
>>> drivers/usb/dwc3/dwc3-exynos.c | 10 ++++++----
>>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
>>> index e27899b..f97a3d7 100644
>>> --- a/drivers/usb/dwc3/dwc3-exynos.c
>>> +++ b/drivers/usb/dwc3/dwc3-exynos.c
>>> @@ -131,8 +131,8 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
>>> if (IS_ERR(exynos->susp_clk)) {
>>> dev_info(dev, "no suspend clk specified\n");
>>> exynos->susp_clk = NULL;
>>> - }
>>> - clk_prepare_enable(exynos->susp_clk);
>>> + } else
>>> + clk_prepare_enable(exynos->susp_clk);
>>>
>>> if (of_device_is_compatible(node, "samsung,exynos7-dwusb3")) {
>>> exynos->axius_clk = devm_clk_get(dev, "usbdrd30_axius_clk");
>>> @@ -196,7 +196,8 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
>>> regulator_disable(exynos->vdd33);
>>> err2:
>>> clk_disable_unprepare(exynos->axius_clk);
>>> - clk_disable_unprepare(exynos->susp_clk);
>>> + if (exynos->susp_clk)
>>> + clk_disable_unprepare(exynos->susp_clk);
>>> clk_disable_unprepare(exynos->clk);
>>> return ret;
>>> }
>>> @@ -210,7 +211,8 @@ static int dwc3_exynos_remove(struct platform_device *pdev)
>>> platform_device_unregister(exynos->usb3_phy);
>>>
>>> clk_disable_unprepare(exynos->axius_clk);
>>> - clk_disable_unprepare(exynos->susp_clk);
>>> + if (exynos->susp_clk)
>>> + clk_disable_unprepare(exynos->susp_clk);
>>> clk_disable_unprepare(exynos->clk);
>>>
>>> regulator_disable(exynos->vdd33);
>>
>
^ permalink raw reply
* [PATCH] usb: dwc3-exynos fix unspecified suspend clk error handling
From: Shuah Khan @ 2017-01-10 14:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <82fb5295-6640-7e9e-a42a-4067aa88e5b4@cogentembedded.com>
On 01/10/2017 04:20 AM, Sergei Shtylyov wrote:
> Hello!
>
> On 01/10/2017 05:21 AM, Shuah Khan wrote:
>
>> Fix dwc3_exynos_probe() to call clk_prepare_enable() only when suspend
>> clock is specified. Call clk_disable_unprepare() from remove and probe
>> error path only when susp_clk has been set from remove and probe error
>> paths.
>>
>> Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
>> ---
>> drivers/usb/dwc3/dwc3-exynos.c | 10 ++++++----
>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
>> index e27899b..f97a3d7 100644
>> --- a/drivers/usb/dwc3/dwc3-exynos.c
>> +++ b/drivers/usb/dwc3/dwc3-exynos.c
>> @@ -131,8 +131,8 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
>> if (IS_ERR(exynos->susp_clk)) {
>> dev_info(dev, "no suspend clk specified\n");
>> exynos->susp_clk = NULL;
>> - }
>> - clk_prepare_enable(exynos->susp_clk);
>> + } else
>> + clk_prepare_enable(exynos->susp_clk);
>
> CodingStyle: need {} here as well since another branch has them.
>
> [...]
>
> MBR, Sergei
>
Thanks. There is some concerns whether or not this patch is needed.
If we decide to include the patch, I will send v2 with your comment.
thanks,
-- Shuah
^ permalink raw reply
* [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask
From: Christoph Hellwig @ 2017-01-10 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1988852.3nyUoruEjG@wuerfel>
On Tue, Jan 10, 2017 at 11:47:42AM +0100, Arnd Bergmann wrote:
> I see that we have CONFIG_ARCH_PHYS_ADDR_T_64BIT on a couple of
> 32-bit architectures without swiotlb (arc, arm, some mips32), and
> there are several 64-bit architectures that do not have swiotlb
> (alpha, parisc, s390, sparc). I believe that alpha, s390 and sparc
> always use some form of IOMMU, but the other four apparently don't,
> so we would need to add swiotlb support there to remove all the
> bounce buffering in network and block layers.
mips has lots of weird swiotlb wire-up in it's board code (the swiotlb
arch glue really needs some major cleanup..), as does arm. Not
sure about the others.
Getting rid of highmem bouncing in the block layer will take some time
as various PIO-only drivers rely on it at the moment. These should
all be convertable to kmap that data, but it needs a careful audit
first. For 4.11 I'll plan to switch away from bouncing highmem by
default at least, though and maybe also convert a few PIO drivers.
^ permalink raw reply
* NVMe vs DMA addressing limitations
From: Christoph Hellwig @ 2017-01-10 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4137257.d2v87kqLLv@wuerfel>
On Tue, Jan 10, 2017 at 12:01:05PM +0100, Arnd Bergmann wrote:
> Another workaround me might need is to limit amount of concurrent DMA
> in the NVMe driver based on some platform quirk. The way that NVMe works,
> it can have very large amounts of data that is concurrently mapped into
> the device.
That's not really just NVMe - other storage and network controllers also
can DMA map giant amounts of memory. There are a couple aspects to it:
- dma coherent memoery - right now NVMe doesn't use too much of it,
but upcoming low-end NVMe controllers will soon start to require
fairl large amounts of it for the host memory buffer feature that
allows for DRAM-less controller designs. As an interesting quirk
that is memory only used by the PCIe devices, and never accessed
by the Linux host at all.
- size vs number of the dynamic mapping. We probably want the dma_ops
specify a maximum mapping size for a given device. As long as we
can make progress with a few mappings swiotlb / the iommu can just
fail mapping and the driver will propagate that to the block layer
that throttles I/O.
^ permalink raw reply
* [PATCH v2] arm64: do not set dma masks that device connection can't handle
From: Christoph Hellwig @ 2017-01-10 14:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <07253eaa-5729-0f15-42b6-e8403f1f0412@cogentembedded.com>
On Tue, Jan 10, 2017 at 03:47:25PM +0300, Nikita Yushchenko wrote:
> With this direction, semantics of dma mask becomes even more
> questionable. I'd say dma_mask is candidate for removal (or to move to
> swiotlb's or iommu's local area)
We need the dma mask so that the device can advertise what addresses
the device supports. Many old devices only support 32-bit DMA addressing,
and some less common ones just 24-bit or other weird ones.
^ permalink raw reply
* [PATCH] ARM: imx: hide unused variable in #ifdef
From: Frank Li @ 2017-01-10 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110130154.2994705-1-arnd@arndb.de>
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Tuesday, January 10, 2017 6:19 AM
> To: Shawn Guo <shawnguo@kernel.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>; Arnd Bergmann
> <arnd@arndb.de>; Sascha Hauer <kernel@pengutronix.de>; Fabio Estevam
> <fabio.estevam@nxp.com>; Russell King <linux@armlinux.org.uk>; Frank Li
> <frank.li@nxp.com>; linux-arm-kernel at lists.infradead.org; linux-
> kernel at vger.kernel.org
> Subject: [PATCH] ARM: imx: hide unused variable in #ifdef
>
> A bugfix added a new local variable that is only used inside of an #ifdef
> section, and unused if CONFIG_PERF_EVENTS is disabled:
>
> arch/arm/mach-imx/mmdc.c:63:25: warning: 'cpuhp_mmdc_state' defined
> but not used [-Wunused-variable]
>
> This moves the variable down inside that same ifdef.
>
> Fixes: a051f220d6b9 ("ARM/imx/mmcd: Fix broken cpu hotplug handling")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
Acked-by: Frank Li <Frank.Li@nxp.com>
> arch/arm/mach-imx/mmdc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-imx/mmdc.c b/arch/arm/mach-imx/mmdc.c
> index 699157759120..c03bf28d8bbc 100644
> --- a/arch/arm/mach-imx/mmdc.c
> +++ b/arch/arm/mach-imx/mmdc.c
> @@ -60,7 +60,6 @@
>
> #define to_mmdc_pmu(p) container_of(p, struct mmdc_pmu, pmu)
>
> -static enum cpuhp_state cpuhp_mmdc_state; static int ddr_type;
>
> struct fsl_mmdc_devtype_data {
> @@ -82,6 +81,7 @@ static const struct of_device_id imx_mmdc_dt_ids[] = {
>
> #ifdef CONFIG_PERF_EVENTS
>
> +static enum cpuhp_state cpuhp_mmdc_state;
> static DEFINE_IDA(mmdc_ida);
>
> PMU_EVENT_ATTR_STRING(total-cycles, mmdc_pmu_total_cycles,
> "event=0x00")
> --
> 2.9.0
^ permalink raw reply
* [PATCH] ARM: defconfig: qcom: add APQ8060 DragonBoard devices
From: Andy Gross @ 2017-01-10 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110095521.14146-1-linus.walleij@linaro.org>
On Tue, Jan 10, 2017 at 10:55:21AM +0100, Linus Walleij wrote:
> This default-enables the devices found on the APQ8060 DragonBoard
> in the qcom_defconfig:
>
> - EBI2 bus
> - SMSC911x ethernet
> - LEDs class and PM8058 LEDs driver, trigger and heartbeat
> trigger (so we get heartbeat on the board by default)
> - IIO framework, including the HRTimer trigger, KXSD9
> accelerometer, MPU3050 gyroscope, AK8975 magnetometer and
> BMP085 pressure sensor
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This brings up a point of discussion. Do we even need the qcom_defconfig any
more? Is everyone comfortable with using the multi_v7_defconfig?
Aside from size of the image, i can't think of any other reason to keep around
the separate qcom file.
Regards,
Andy
^ permalink raw reply
* [PATCH] virtio_mmio: Set DMA masks appropriately
From: Michael S. Tsirkin @ 2017-01-10 14:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50defbbe87d75db85a9d22f914258975d661208a.1484051089.git.robin.murphy@arm.com>
On Tue, Jan 10, 2017 at 12:26:01PM +0000, Robin Murphy wrote:
> Once DMA API usage is enabled, it becomes apparent that virtio-mmio is
> inadvertently relying on the default 32-bit DMA mask, which leads to
> problems like rapidly exhausting SWIOTLB bounce buffers.
>
> Ensure that we set the appropriate 64-bit DMA mask whenever possible,
> with the coherent mask suitably limited for the legacy vring as per
> a0be1db4304f ("virtio_pci: Limit DMA mask to 44 bits for legacy virtio
> devices").
>
> Reported-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
> Fixes: b42111382f0e ("virtio_mmio: Use the DMA API if enabled")
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/virtio/virtio_mmio.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
> index 48bfea91dbca..b5c5d49ca598 100644
> --- a/drivers/virtio/virtio_mmio.c
> +++ b/drivers/virtio/virtio_mmio.c
> @@ -59,6 +59,7 @@
> #define pr_fmt(fmt) "virtio-mmio: " fmt
>
> #include <linux/acpi.h>
> +#include <linux/dma-mapping.h>
> #include <linux/highmem.h>
> #include <linux/interrupt.h>
> #include <linux/io.h>
> @@ -497,6 +498,7 @@ static int virtio_mmio_probe(struct platform_device *pdev)
> struct virtio_mmio_device *vm_dev;
> struct resource *mem;
> unsigned long magic;
> + int rc;
>
> mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!mem)
> @@ -548,6 +550,14 @@ static int virtio_mmio_probe(struct platform_device *pdev)
> if (vm_dev->version == 1)
> writel(PAGE_SIZE, vm_dev->base + VIRTIO_MMIO_GUEST_PAGE_SIZE);
>
> + rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
> + if (rc)
> + rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
> + else if (vm_dev->version == 1)
> + dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32 + PAGE_SHIFT));
That's a very convoluted way to do this, for version 1 you
set coherent mask to 64 then override it.
why not
if (vm_dev->version == 1) {
dma_set_mask
dma_set_coherent_mask
} else {
dma_set_mask_and_coherent
}
if (rc)
dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
> + if (rc)
> + dev_warn(&pdev->dev, "Failed to enable 64-bit or 32-bit DMA. Trying to continue, but this might not work.\n");
> +
is there a chance it actually still might work?
> platform_set_drvdata(pdev, vm_dev);
>
> return register_virtio_device(&vm_dev->vdev);
> --
> 2.10.2.dirty
^ permalink raw reply
* [PATCH v2] arm64: do not set dma masks that device connection can't handle
From: Christoph Hellwig @ 2017-01-10 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <11daacde-5399-039f-80a3-01d7bd13e9e8@arm.com>
On Tue, Jan 10, 2017 at 01:25:12PM +0000, Robin Murphy wrote:
> We still need a way for drivers to communicate a device's probed
> addressing capability to SWIOTLB, so there's always going to have to be
> *some* sort of public interface. Personally, the change in semantics I'd
> like to see is to make dma_set_mask() only fail if DMA is entirely
> disallowed - in the normal case it would always succeed, but the DMA API
> implementation would be permitted to set a smaller mask than requested
> (this is effectively what the x86 IOMMU ops do already).
Yes, this sounds reasonable.
> The significant
> work that would require, though, is changing all the drivers currently
> using this sort of pattern:
>
> if (!dma_set_mask(dev, DMA_BIT_MASK(64))
> /* put device into 64-bit mode */
> else if (!dma_set_mask(dev, DMA_BIT_MASK(32))
> /* put device into 32-bit mode */
> else
> /* error */
While we have this pattern in a lot of places it's already rather
pointless on most architectures as the first dma_set_mask call
won't ever fail for the most common dma_ops implementations.
> to something like this:
>
> if (!dma_set_mask(dev, DMA_BIT_MASK(64))
> /* error */
> if (dma_get_mask(dev) > DMA_BIT_MASK(32))
> /* put device into 64-bit mode */
> else
> /* put device into 32-bit mode */
>
> Which would be a pretty major job.
I don't think it's too bad. Also for many modern devices there is no
need to put the device into a specific mode. It's mostly a historic
issue from the PCI/PCI-X days with the less efficient DAC addressing
scheme.
^ permalink raw reply
* [PATCH v6 05/14] ACPI: platform-msi: retrieve dev id from IORT
From: Lorenzo Pieralisi @ 2017-01-10 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <237ca4dc-07ce-0104-27f2-5437b7c7718e@linaro.org>
On Tue, Jan 10, 2017 at 09:39:39PM +0800, Hanjun Guo wrote:
[...]
> >What you can do is create a wrapper, say iort_node_map_platform_id()
> >(whose signature is equivalent to iort_node_map_rid() minus rid_in)
> >that carries out the two steps outlined above.
> >
> >To do that I suggest the following:
> >
> >(1) I send a patch to "fix" iort_node_get_id() (ie index issue you
> > reported)
>
> I prepared two simple patches, one is for fix the indentation and
> the other is adding the missing kernel-doc comment, how about
> sending the out for 4.10-rcx?
For me it is fine depending on how Rafael wants to handle them,
ie if he can batch those with the eg iort_node_get_id() fix I have
just sent:
https://patchwork.kernel.org/patch/9507041/
> >(2) We remove type_mask handling from iort_node_get_id()
>
> iort_node_get_id() for now only supports id single mappings,
> Do we need to extend it for multi id mappings? seems Sinan's
> platform have such cases.
I am not really sure I understand what you mean here.
> >(3) We create iort_node_map_platform_id() that (pseudo-code, I can
> > write the patch if it is clearer):
> >
> >struct acpi_iort_node *iort_node_map_platform_id(u8 type_mask, int index,
> > ...)
> >{
> > u32 id, id_out;
> > struct acpi_iort_node *parent = iort_node_get_id(&id, index);
> >
> > if (!parent)
> > return NULL;
> >
> > /* we should probably rename iort_node_map_rid() too */
> > if (!(IORT_TYPE_MASK(parent->type) & type_mask)
> > parent = iort_node_map_rid(parent, id, &id_out, type_mask);
> >
> > return parent;
> >}
> >
> >(4) we update current iort_node_get_id() users and move them over
> > to iort_node_map_platform_id()
>
> I think we need to prepare one patch for the above steps, or it
> have functional changes for iort_node_get_id(), for example we
> removed the type_mask handling from iort_node_get_id() and it
> will break the case for SMMU if we only have requester id entries.
If the question is "should we apply this change as a single logical
patch" the answer is yes, it looks a simple one to me (basically
it implies writing the function above and update the iort_node_get_id()
existing callers with it). Does this answer your question ?
Thanks !
Lorenzo
^ permalink raw reply
* [PATCH v2] arm64: do not set dma masks that device connection can't handle
From: Christoph Hellwig @ 2017-01-10 14:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6116278.nQQUSuo3l4@wuerfel>
On Tue, Jan 10, 2017 at 02:42:23PM +0100, Arnd Bergmann wrote:
> It's a much rarer problem for the IOMMU case though, because it only
> impacts devices that are restricted to addressing of less than 32-bits.
>
> If you have an IOMMU enabled, the dma-mapping interface does not care
> if the device can do wider than 32 bit addressing, as it will never
> hand out IOVAs above 0xffffffff.
That's absolutely not the case. IOMMUs can and do generate addresses
larger than 32-bit. Also various platforms have modes where an IOMMU
can be used when <= 32-bit addresses are used and bypassed if full 64-bit
addressing is supported and I/O isolation is not explicitly requested.
^ permalink raw reply
* [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask
From: Arnd Bergmann @ 2017-01-10 15:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110144453.GA27156@lst.de>
On Tuesday, January 10, 2017 3:44:53 PM CET Christoph Hellwig wrote:
> On Tue, Jan 10, 2017 at 11:47:42AM +0100, Arnd Bergmann wrote:
> > I see that we have CONFIG_ARCH_PHYS_ADDR_T_64BIT on a couple of
> > 32-bit architectures without swiotlb (arc, arm, some mips32), and
> > there are several 64-bit architectures that do not have swiotlb
> > (alpha, parisc, s390, sparc). I believe that alpha, s390 and sparc
> > always use some form of IOMMU, but the other four apparently don't,
> > so we would need to add swiotlb support there to remove all the
> > bounce buffering in network and block layers.
>
> mips has lots of weird swiotlb wire-up in it's board code (the swiotlb
> arch glue really needs some major cleanup..),
My reading of the MIPS code was that only the 64-bit platforms use it,
but there are a number of 32-bit platforms that have 64-bit physical
addresses and don't.
> as does arm. Not sure about the others.
32-bit ARM doesn't actually use SWIOTLB at all, despite selecting it
in Kconfig. I think Xen uses it for its own purposes, but nothing
else does.
Most ARM platforms can't actually have RAM beyond 4GB, and the ones
that do have it tend to also come with an IOMMU, but I remember
at least BCM53xx actually needing swiotlb on some chip revisions
that are widely used and that cannot DMA to the second memory bank
from PCI (!).
Arnd
^ permalink raw reply
* NVMe vs DMA addressing limitations
From: Arnd Bergmann @ 2017-01-10 15:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110144839.GB27156@lst.de>
On Tuesday, January 10, 2017 3:48:39 PM CET Christoph Hellwig wrote:
> On Tue, Jan 10, 2017 at 12:01:05PM +0100, Arnd Bergmann wrote:
> > Another workaround me might need is to limit amount of concurrent DMA
> > in the NVMe driver based on some platform quirk. The way that NVMe works,
> > it can have very large amounts of data that is concurrently mapped into
> > the device.
>
> That's not really just NVMe - other storage and network controllers also
> can DMA map giant amounts of memory. There are a couple aspects to it:
>
> - dma coherent memoery - right now NVMe doesn't use too much of it,
> but upcoming low-end NVMe controllers will soon start to require
> fairl large amounts of it for the host memory buffer feature that
> allows for DRAM-less controller designs. As an interesting quirk
> that is memory only used by the PCIe devices, and never accessed
> by the Linux host at all.
Right, that is going to become interesting, as some platforms are
very limited with their coherent allocations.
> - size vs number of the dynamic mapping. We probably want the dma_ops
> specify a maximum mapping size for a given device. As long as we
> can make progress with a few mappings swiotlb / the iommu can just
> fail mapping and the driver will propagate that to the block layer
> that throttles I/O.
Good idea.
Arnd
^ permalink raw reply
* [PATCH v2] arm64: do not set dma masks that device connection can't handle
From: Arnd Bergmann @ 2017-01-10 15:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5c5cd4fd-4854-a2dd-10b6-9cc98e63a85c@arm.com>
On Tuesday, January 10, 2017 2:16:57 PM CET Robin Murphy wrote:
> On 10/01/17 13:42, Arnd Bergmann wrote:
> > On Tuesday, January 10, 2017 1:25:12 PM CET Robin Murphy wrote:
> >> On 10/01/17 12:47, Nikita Yushchenko wrote:
> >>>> The point here is that an IOMMU doesn't solve your issue, and the
> >>>> IOMMU-backed DMA ops need the same treatment. In light of that, it really
> >>>> feels to me like the DMA masks should be restricted in of_dma_configure
> >>>> so that the parent mask is taken into account there, rather than hook
> >>>> into each set of DMA ops to intercept set_dma_mask. We'd still need to
> >>>> do something to stop dma_set_mask widening the mask if it was restricted
> >>>> by of_dma_configure, but I think Robin (cc'd) was playing with that.
> >>>
> >>> What issue "IOMMU doesn't solve"?
> >>>
> >>> Issue I'm trying to address is - inconsistency within swiotlb
> >>> dma_map_ops, where (1) any wide mask is silently accepted, but (2) then
> >>> mask is used to decide if bounce buffers are needed or not. This
> >>> inconsistency causes NVMe+R-Car cobmo not working (and breaking memory
> >>> instead).
> >>
> >> The fundamental underlying problem is the "any wide mask is silently
> >> accepted" part, and that applies equally to IOMMU ops as well.
> >
> > It's a much rarer problem for the IOMMU case though, because it only
> > impacts devices that are restricted to addressing of less than 32-bits.
> >
> > If you have an IOMMU enabled, the dma-mapping interface does not care
> > if the device can do wider than 32 bit addressing, as it will never
> > hand out IOVAs above 0xffffffff.
>
> I can assure you that it will - we constrain allocations to the
> intersection of the IOMMU domain aperture (normally the IOMMU's physical
> input address width) and the given device's DMA mask. If both of those
> are >32 bits then >32-bit IOVAs will fall out. For the arm64/common
> implementation I have prototyped a copy of the x86 optimisation which
> always first tries to get 32-bit IOVAs for PCI devices, but even then it
> can start returning higher addresses if the 32-bit space fills up.
Ok, got it. I have to admit that most of my knowledge about the internals
of IOMMUs is from PowerPC of a few years ago, which couldn't do this at
all. I agree that we need to do the same thing on swiotlb and iommu then.
> >> The thread Will linked to describes that equivalent version of your
> >> problem - the IOMMU gives the device 48-bit addresses which get
> >> erroneously truncated because it doesn't know that only 42 bits are
> >> actually wired up. That situation still requires the device's DMA mask
> >> to correctly describe its addressing capability just as yours does.
> >
> > That problem should only impact virtual machines which have a guest
> > bus address space covering more than 42 bits of physical RAM, whereas
> > the problem we have with swiotlb is for the dma-mapping interface.
> >
> I actually have a third variation of this problem involving a PCI root
> complex which *could* drive full-width (40-bit) addresses, but won't,
> due to the way its PCI<->AXI interface is programmed. That would require
> even more complicated dma-ranges handling to describe the windows of
> valid physical addresses which it *will* pass, so I'm not pressing the
> issue - let's just get the basic DMA mask case fixed first.
Can you describe this a little more? We should at least try to not
make it harder to solve the next problem while solving this one,
so I'd like to understand the exact limitation you are hitting there.
Arnd
^ permalink raw reply
* [PATCH v6 0/2] Support for Axentia TSE-850
From: Alexandre Belloni @ 2017-01-10 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484054314-6244-1-git-send-email-peda@axentia.se>
On 10/01/2017 at 14:18:32 +0100, Peter Rosin wrote :
> Hi!
>
> changes v5 -> v6
> - drop the &main clock-frequency
> - add some text to the commit messages
> - make config additions modules
>
> changes v4 -> v5
> - comment from Rob about the memory node made me look closer and
> the memory size is actually updated by the bootloader, and that
> hid the fact that the entry was always faulty. This version
> specifies the correct memory size from the start, which is 64MB.
> - ack from Rob
>
> changes v3 -> v4
> - rename files arch/arm/boot/dts/axentia-* to .../at91-*
> - remove bootargs from at91-tse850-3.dts
> - depend on the atmel ssc to register as a sound dai by itself
> - bump copyright years
>
> changes v2 -> v3
> - document the new compatible strings prefixed with "axentia,".
>
> changes v1 -> v2
> - squash the fixup into the correct patch, sorry for the noise.
>
> After finally having all essintial drivers upstreamed I would
> like to have the dts and the defconfig also upstreamed.
>
> The atmel-ssc/sound-dai change depends on a change that has been
> sitting in the ASoC tree since mid-december, and I have been waiting
> for it to hit linux-next before sending this, but it seems to take
> longer than I anticipated. So, since I do not want this to in
> turn miss the next merge window because of that wait I therefore
> request that this is taken now even though it doesn't really work
> w/o the ASoC "topic/atmel" branch as of 2016-12-15 [1]. It of course
> builds cleanly even w/o those ASoC changes. That effectively means
> that noone besides me should notice the inconsistency (I currently
> have all affected devices under my control).
>
> Cheers,
> peda
>
> [1] http://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/log/?h=topic/atmel
>
> Peter Rosin (2):
> ARM: dts: at91: add devicetree for the Axentia TSE-850
> ARM: sama5_defconfig: add support for the Axentia TSE-850 board
>
> Documentation/devicetree/bindings/arm/axentia.txt | 19 ++
> MAINTAINERS | 8 +
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/at91-linea.dtsi | 49 ++++
> arch/arm/boot/dts/at91-tse850-3.dts | 274 ++++++++++++++++++++++
> arch/arm/configs/sama5_defconfig | 7 +-
> 6 files changed, 357 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/arm/axentia.txt
> create mode 100644 arch/arm/boot/dts/at91-linea.dtsi
> create mode 100644 arch/arm/boot/dts/at91-tse850-3.dts
>
Both applied, thanks!
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [kvm-unit-tests PATCH v7 04/11] libcflat: add PRI(dux)32 format types
From: Alex Bennée @ 2017-01-10 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124161033.11456-5-alex.bennee@linaro.org>
Alex Benn?e <alex.bennee@linaro.org> writes:
> So we can have portable formatting of uint32_t types.
>
> Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
> ---
> lib/libcflat.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/lib/libcflat.h b/lib/libcflat.h
> index bdcc561..6dab5be 100644
> --- a/lib/libcflat.h
> +++ b/lib/libcflat.h
> @@ -55,12 +55,17 @@ typedef _Bool bool;
> #define true 1
>
> #if __SIZEOF_LONG__ == 8
> +# define __PRI32_PREFIX
> # define __PRI64_PREFIX "l"
> # define __PRIPTR_PREFIX "l"
> #else
> +# define __PRI32_PREFIX "l"
OK this is bogus, but the failure is because of where we get uint32_t
from (hint using arm32 compiler on a arm64 system) so I got:
lib/pci.c:71:9: error: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'uint32_t {aka long unsigned int}' [-Werro\
r=format=]
Which makes me think we should be more careful about including system
headers in kvm-unit-tests (done in 75e777a0).
--
Alex Benn?e
^ permalink raw reply
* [kvm-unit-tests PATCH v7 04/11] libcflat: add PRI(dux)32 format types
From: Alex Bennée @ 2017-01-10 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87r34b2b3a.fsf@linaro.org>
Alex Benn?e <alex.bennee@linaro.org> writes:
> Alex Benn?e <alex.bennee@linaro.org> writes:
>
>> So we can have portable formatting of uint32_t types.
>>
>> Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
>> ---
>> lib/libcflat.h | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/lib/libcflat.h b/lib/libcflat.h
>> index bdcc561..6dab5be 100644
>> --- a/lib/libcflat.h
>> +++ b/lib/libcflat.h
>> @@ -55,12 +55,17 @@ typedef _Bool bool;
>> #define true 1
>>
>> #if __SIZEOF_LONG__ == 8
>> +# define __PRI32_PREFIX
>> # define __PRI64_PREFIX "l"
>> # define __PRIPTR_PREFIX "l"
>> #else
>> +# define __PRI32_PREFIX "l"
>
> OK this is bogus, but the failure is because of where we get uint32_t
> from (hint using arm32 compiler on a arm64 system) so I got:
>
> lib/pci.c:71:9: error: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'uint32_t {aka long unsigned int}' [-Werro\
> r=format=]
>
> Which makes me think we should be more careful about including system
> headers in kvm-unit-tests (done in 75e777a0).
Hmm it turns out my compiler is d.r.t as far as it is concerned:
# 34 "/usr/lib/gcc/arm-none-eabi/5.4.1/include/stdint-gcc.h" 3 4
typedef signed char int8_t;
typedef short int int16_t;
typedef long int int32_t;
typedef long long int int64_t;
typedef unsigned char uint8_t;
typedef short unsigned int uint16_t;
typedef long unsigned int uint32_t;
--
Alex Benn?e
^ permalink raw reply
* [RESEND 3/3] ARM: davinci_all_defconfig: enable iio and ADS7950
From: David Lechner @ 2017-01-10 15:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <03501962-eb4a-6936-15dd-ed59c73f9cd9@ti.com>
On 01/10/2017 03:27 AM, Sekhar Nori wrote:
> On Monday 09 January 2017 09:41 PM, David Lechner wrote:
>> This enables the iio subsystem and the TI ADS7950 driver. This is used by
>> LEGO MINDSTORMS EV3, which has an ADS7957 chip.
>>
>> Signed-off-by: David Lechner <david@lechnology.com>
>> ---
>> arch/arm/configs/davinci_all_defconfig | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
>> index 2b1967a..a899876 100644
>> --- a/arch/arm/configs/davinci_all_defconfig
>> +++ b/arch/arm/configs/davinci_all_defconfig
>> @@ -200,6 +200,13 @@ CONFIG_TI_EDMA=y
>> CONFIG_MEMORY=y
>> CONFIG_TI_AEMIF=m
>> CONFIG_DA8XX_DDRCTL=y
>> +CONFIG_IIO=m
>> +CONFIG_IIO_BUFFER_CB=m
>> +CONFIG_IIO_SW_DEVICE=m
>> +CONFIG_IIO_SW_TRIGGER=m
>> +CONFIG_TI_ADS7950=m
>> +CONFIG_IIO_HRTIMER_TRIGGER=m
>> +CONFIG_IIO_SYSFS_TRIGGER=m
>
> Hmm, there are some other comments I gave on the previous version I
> don't see addressed. Can you please fix those or respond to those comments?
Oops, I missed the other comments. I will fix it.
>
> Thanks,
> Sekhar
>
^ permalink raw reply
* [PATCH 1/1] MMC: meson: avoid possible NULL dereference
From: Ulf Hansson @ 2017-01-10 15:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <m237gwcec4.fsf@baylibre.com>
On 6 January 2017 at 18:01, Kevin Hilman <khilman@baylibre.com> wrote:
> Heinrich Schuchardt <xypron.glpk@gmx.de> writes:
>
>> No actual segmentation faults were observed but the coding is
>> at least inconsistent.
>>
>> irqreturn_t meson_mmc_irq():
>>
>> We should not dereference host before checking it.
>>
>> meson_mmc_irq_thread():
>>
>> If cmd or mrq are NULL we should not dereference them after
>> writing a warning.
>>
>> Fixes: 51c5d8447bd7 MMC: meson: initial support for GX platforms
>> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>
> Acked-by: Kevin Hilman <khilman@baylibre.com>
>
> Ulf, I assume you can pick this up directly for v4.10-rc?
Thanks, applied for fixes!
Kind regards
Uffe
>
> Thanks,
>
> Kevin
>
>> ---
>> drivers/mmc/host/meson-gx-mmc.c | 8 +++++---
>> 1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
>> index b352760c041e..09739352834c 100644
>> --- a/drivers/mmc/host/meson-gx-mmc.c
>> +++ b/drivers/mmc/host/meson-gx-mmc.c
>> @@ -578,13 +578,15 @@ static irqreturn_t meson_mmc_irq(int irq, void *dev_id)
>> {
>> struct meson_host *host = dev_id;
>> struct mmc_request *mrq;
>> - struct mmc_command *cmd = host->cmd;
>> + struct mmc_command *cmd;
>> u32 irq_en, status, raw_status;
>> irqreturn_t ret = IRQ_HANDLED;
>>
>> if (WARN_ON(!host))
>> return IRQ_NONE;
>>
>> + cmd = host->cmd;
>> +
>> mrq = host->mrq;
>>
>> if (WARN_ON(!mrq))
>> @@ -670,10 +672,10 @@ static irqreturn_t meson_mmc_irq_thread(int irq, void *dev_id)
>> int ret = IRQ_HANDLED;
>>
>> if (WARN_ON(!mrq))
>> - ret = IRQ_NONE;
>> + return IRQ_NONE;
>>
>> if (WARN_ON(!cmd))
>> - ret = IRQ_NONE;
>> + return IRQ_NONE;
>>
>> data = cmd->data;
>> if (data) {
^ permalink raw reply
* [PATCH 0/2] mmc: sdhci-iproc: Improve bcm2835 performance
From: Ulf Hansson @ 2017-01-10 15:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483111474-29907-1-git-send-email-stefan.wahren@i2se.com>
On 30 December 2016 at 16:24, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> The sdhci-iproc waste a lot performance potential on bcm2835 because of
> missing capabilities in the platform data. This patch series tries to fix
> this.
>
> Raspberry Pi Zero with a class 10 sdhc card
>
> Before:
> dd if=/dev/zero conv=fdatasync of=test bs=8k count=10000
> 81920000 Bytes (82 MB), 11,0044 s, 7,4 MB/s
>
> sudo dd if=/dev/mmcblk0p1 of=/dev/null
> 62914560 Bytes (63 MB), 5,83784 s, 10,8 MB/s
>
> After:
> dd if=/dev/zero conv=fdatasync of=test bs=8k count=10000
> 81920000 Bytes (82 MB), 9,76938 s, 8,4 MB/s
>
> sudo dd if=/dev/mmcblk0p1 of=/dev/null
> 62914560 Bytes (63 MB), 4,73651 s, 13,3 MB/s
>
> Raspberry Pi Compute Module
>
> Before:
> dd if=/dev/zero conv=fdatasync of=test bs=8k count=10000
> 81920000 Bytes (82 MB), 27,4257 s, 3,0 MB/s
>
> sudo dd if=/dev/mmcblk0p1 of=/dev/null
> 66060288 Bytes (66 MB), 21,4365 s, 3,1 MB/s
>
> After:
> dd if=/dev/zero conv=fdatasync of=test bs=8k count=10000
> 81920000 Bytes (82 MB), 7,19661 s, 11,4 MB/s
>
> sudo dd if=/dev/mmcblk0p1 of=/dev/null
> 66060288 Bytes (66 MB), 4,76453 s, 13,9 MB/s
>
> Any tests with a Raspberry Pi 3 (SD and Wifi over SDIO) are welcome.
>
> Stefan Wahren (2):
> mmc: sdhci-iproc: Apply caps from bcm2835-mmc driver
> mmc: sdhci-iproc: Increase max_blk_size for bcm2835
>
> drivers/mmc/host/sdhci-iproc.c | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> --
> 1.7.9.5
>
Thanks, applied for next!
Kind regards
Uffe
^ permalink raw reply
* [PATCH v7 01/19] iommu/dma: Implement PCI allocation optimisation
From: Robin Murphy @ 2017-01-10 15:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483969570-3154-2-git-send-email-eric.auger@redhat.com>
On 09/01/17 13:45, Eric Auger wrote:
> From: Robin Murphy <robin.murphy@arm.com>
>
> Whilst PCI devices may have 64-bit DMA masks, they still benefit from
> using 32-bit addresses wherever possible in order to avoid DAC (PCI) or
> longer address packets (PCIe), which may incur a performance overhead.
> Implement the same optimisation as other allocators by trying to get a
> 32-bit address first, only falling back to the full mask if that fails.
Oops, this was just some development work which got promoted to my misc
branch for safe keeping; it really has nothing to do with this series.
I'd managed to overlook that one of the __alloc_iova() conflicts hit the
MSI cookie patch, sorry. Things are now in a more appropriate order in
my tree.
Robin.
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/iommu/dma-iommu.c | 21 +++++++++++++++------
> 1 file changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index 2db0d64..a59ca47 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -204,19 +204,28 @@ int dma_direction_to_prot(enum dma_data_direction dir, bool coherent)
> }
>
> static struct iova *__alloc_iova(struct iommu_domain *domain, size_t size,
> - dma_addr_t dma_limit)
> + dma_addr_t dma_limit, struct device *dev)
> {
> struct iova_domain *iovad = cookie_iovad(domain);
> unsigned long shift = iova_shift(iovad);
> unsigned long length = iova_align(iovad, size) >> shift;
> + struct iova *iova = NULL;
>
> if (domain->geometry.force_aperture)
> dma_limit = min(dma_limit, domain->geometry.aperture_end);
> +
> + /* Try to get PCI devices a SAC address */
> + if (dma_limit > DMA_BIT_MASK(32) && dev_is_pci(dev))
> + iova = alloc_iova(iovad, length, DMA_BIT_MASK(32) >> shift,
> + true);
> /*
> * Enforce size-alignment to be safe - there could perhaps be an
> * attribute to control this per-device, or at least per-domain...
> */
> - return alloc_iova(iovad, length, dma_limit >> shift, true);
> + if (!iova)
> + iova = alloc_iova(iovad, length, dma_limit >> shift, true);
> +
> + return iova;
> }
>
> /* The IOVA allocator knows what we mapped, so just unmap whatever that was */
> @@ -369,7 +378,7 @@ struct page **iommu_dma_alloc(struct device *dev, size_t size, gfp_t gfp,
> if (!pages)
> return NULL;
>
> - iova = __alloc_iova(domain, size, dev->coherent_dma_mask);
> + iova = __alloc_iova(domain, size, dev->coherent_dma_mask, dev);
> if (!iova)
> goto out_free_pages;
>
> @@ -440,7 +449,7 @@ static dma_addr_t __iommu_dma_map(struct device *dev, phys_addr_t phys,
> struct iova_domain *iovad = cookie_iovad(domain);
> size_t iova_off = iova_offset(iovad, phys);
> size_t len = iova_align(iovad, size + iova_off);
> - struct iova *iova = __alloc_iova(domain, len, dma_get_mask(dev));
> + struct iova *iova = __alloc_iova(domain, len, dma_get_mask(dev), dev);
>
> if (!iova)
> return DMA_ERROR_CODE;
> @@ -598,7 +607,7 @@ int iommu_dma_map_sg(struct device *dev, struct scatterlist *sg,
> prev = s;
> }
>
> - iova = __alloc_iova(domain, iova_len, dma_get_mask(dev));
> + iova = __alloc_iova(domain, iova_len, dma_get_mask(dev), dev);
> if (!iova)
> goto out_restore_sg;
>
> @@ -675,7 +684,7 @@ static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
> if (!msi_page)
> return NULL;
>
> - iova = __alloc_iova(domain, iovad->granule, dma_get_mask(dev));
> + iova = __alloc_iova(domain, iovad->granule, dma_get_mask(dev), dev);
> if (!iova)
> goto out_free_page;
>
>
^ permalink raw reply
* [PATCH v2 3/5] ARM: davinci_all_defconfig: enable iio and ADS7950
From: David Lechner @ 2017-01-10 15:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cb9455bc-2658-9826-823b-2aa845237fed@ti.com>
On 01/09/2017 06:29 AM, Sekhar Nori wrote:
> On Friday 06 January 2017 10:03 AM, David Lechner wrote:
>> This enables the iio subsystem and the TI ADS7950 driver. This is used by
>> LEGO MINDSTORMS EV3, which has an ADS7957 chip.
>
> Can you add your sign-off?
>
>> ---
>>
>> The CONFIG_TI_ADS7950 driver is currently in iio/testing, so some coordination
>> may be needed before picking up this patch.
>>
>> arch/arm/configs/davinci_all_defconfig | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
>> index 2b1967a..a899876 100644
>> --- a/arch/arm/configs/davinci_all_defconfig
>> +++ b/arch/arm/configs/davinci_all_defconfig
>> @@ -200,6 +200,13 @@ CONFIG_TI_EDMA=y
>> CONFIG_MEMORY=y
>> CONFIG_TI_AEMIF=m
>> CONFIG_DA8XX_DDRCTL=y
>> +CONFIG_IIO=m
>> +CONFIG_IIO_BUFFER_CB=m
>> +CONFIG_IIO_SW_DEVICE=m
>> +CONFIG_IIO_SW_TRIGGER=m
>
>> +CONFIG_TI_ADS7950=m
>
> Can you separate this from rest of the patch. I would like to enable
> this option only after I can find the symbol in linux-next.
Will resend without CONFIG_TI_ADS7950
>
>> +CONFIG_IIO_HRTIMER_TRIGGER=m
>> +CONFIG_IIO_SYSFS_TRIGGER=m
>
> Need CONFIG_IIO_TRIGGER=y also for these two options to take effect.
CONFIG_IIO_TRIGGER is selected by IIO_TRIGGERED_BUFFER [=m] && IIO [=m]
&& IIO_BUFFER [=y], so save_defconfig does not pick it up.
>
> Thanks,
> Sekhar
>
^ permalink raw reply
* [PATCH] arm: ftrace: Adds support for CONFIG_DYNAMIC_FTRACE_WITH_REGS
From: Petr Mladek @ 2017-01-10 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161208224655.GA6319@gce>
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
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.
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
^ permalink raw reply
* [PATCH] virtio_mmio: Set DMA masks appropriately
From: Robin Murphy @ 2017-01-10 15:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110165221-mutt-send-email-mst@kernel.org>
On 10/01/17 14:54, Michael S. Tsirkin wrote:
> On Tue, Jan 10, 2017 at 12:26:01PM +0000, Robin Murphy wrote:
>> Once DMA API usage is enabled, it becomes apparent that virtio-mmio is
>> inadvertently relying on the default 32-bit DMA mask, which leads to
>> problems like rapidly exhausting SWIOTLB bounce buffers.
>>
>> Ensure that we set the appropriate 64-bit DMA mask whenever possible,
>> with the coherent mask suitably limited for the legacy vring as per
>> a0be1db4304f ("virtio_pci: Limit DMA mask to 44 bits for legacy virtio
>> devices").
>>
>> Reported-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
>> Fixes: b42111382f0e ("virtio_mmio: Use the DMA API if enabled")
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>> drivers/virtio/virtio_mmio.c | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
>> index 48bfea91dbca..b5c5d49ca598 100644
>> --- a/drivers/virtio/virtio_mmio.c
>> +++ b/drivers/virtio/virtio_mmio.c
>> @@ -59,6 +59,7 @@
>> #define pr_fmt(fmt) "virtio-mmio: " fmt
>>
>> #include <linux/acpi.h>
>> +#include <linux/dma-mapping.h>
>> #include <linux/highmem.h>
>> #include <linux/interrupt.h>
>> #include <linux/io.h>
>> @@ -497,6 +498,7 @@ static int virtio_mmio_probe(struct platform_device *pdev)
>> struct virtio_mmio_device *vm_dev;
>> struct resource *mem;
>> unsigned long magic;
>> + int rc;
>>
>> mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> if (!mem)
>> @@ -548,6 +550,14 @@ static int virtio_mmio_probe(struct platform_device *pdev)
>> if (vm_dev->version == 1)
>> writel(PAGE_SIZE, vm_dev->base + VIRTIO_MMIO_GUEST_PAGE_SIZE);
>>
>> + rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
>> + if (rc)
>> + rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
>> + else if (vm_dev->version == 1)
>> + dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32 + PAGE_SHIFT));
>
> That's a very convoluted way to do this, for version 1 you
> set coherent mask to 64 then override it.
> why not
>
> if (vm_dev->version == 1) {
> dma_set_mask
> dma_set_coherent_mask
> } else {
> dma_set_mask_and_coherent
> }
>
> if (rc)
> dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
Purely because it's fewer lines of code - if you'd prefer separate
legacy vs. modern flows for clarity that's fine by me.
>> + if (rc)
>> + dev_warn(&pdev->dev, "Failed to enable 64-bit or 32-bit DMA. Trying to continue, but this might not work.\n");
>> +
>
> is there a chance it actually still might work?
If we're not actually using the DMA API, we may still get away with it,
otherwise it's a fairly sure bet that the subsequent dma_map/dma_alloc
calls will fail and we'll get nowhere. If I change this to be a probe
failure condition (and correspondingly in the PCI drivers too), would
you rather that be predicated on vring_use_dma_api(), or always (given
the TODO in virtio_ring.c)?
Robin.
>> platform_set_drvdata(pdev, vm_dev);
>>
>> return register_virtio_device(&vm_dev->vdev);
>> --
>> 2.10.2.dirty
^ permalink raw reply
* [PATCH v7 00/19] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions
From: Auger Eric @ 2017-01-10 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110140924.GC1318@8bytes.org>
Hi all,
On 10/01/2017 15:09, Joerg Roedel wrote:
> On Mon, Jan 09, 2017 at 01:45:51PM +0000, Eric Auger wrote:
>> Eric Auger (17):
>> iommu: Rename iommu_dm_regions into iommu_resv_regions
>> iommu: Add a new type field in iommu_resv_region
>> iommu: iommu_alloc_resv_region
>> iommu: Only map direct mapped regions
>> iommu: iommu_get_group_resv_regions
>> iommu: Implement reserved_regions iommu-group sysfs file
>> iommu/vt-d: Implement reserved region get/put callbacks
>> iommu/amd: Declare MSI and HT regions as reserved IOVA regions
>> iommu/arm-smmu: Implement reserved region get/put callbacks
>> iommu/arm-smmu-v3: Implement reserved region get/put callbacks
>
> IOMMU patches look good, what is the plan to merge this? I'd like to
> take the IOMMU patches and can provide a branch for someone else to base
> the rest on.
I will respin asap taking into account Marc's nits, Robin's update. Also
I would like to do one change in
[PATCH v7 08/19] iommu: Implement reserved_regions iommu-group sysfs file
I will send a separate email.
Thanks
Eric
>
>
> Joerg
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" 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
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