On 15/08/2019 07:06, Felipe Balbi wrote:
Hi,
Vicente Bergas writes:
On Wednesday, August 14, 2019 3:12:26 PM CEST, Robin Murphy wrote:
On 14/08/2019 13:53, Vicente Bergas wrote:
On Monday, July 22, 2019 4:31:27 PM CEST, Vicente Bergas wrote: ...
This particular change looks like it&#
On 11/08/2019 09:05, Christoph Hellwig wrote:
We still treat devices without a DMA mask as defaulting to 32-bits for
both mask, but a few releases ago we've started warning about such
cases, as they require special cases to work around this sloppyness.
Add a dma_mask field to struct platform_obje
On 14/08/2019 13:53, Vicente Bergas wrote:
On Monday, July 22, 2019 4:31:27 PM CEST, Vicente Bergas wrote:
Hi, i have been running linux on rk3399 booted with kexec fine until 5.2
From 5.2 onwards, there are memory corruption issues as reported here:
http://lkml.iu.edu/hypermail/linux/kernel/190
On 2019-08-08 11:07 am, Greg KH wrote:
On Thu, Aug 08, 2019 at 10:46:24AM +0100, Robin Murphy wrote:
On 2019-08-08 9:58 am, Greg KH wrote:
On Thu, Aug 08, 2019 at 10:46:36AM +0200, yvahkhfo.1df7f...@hashmail.org wrote:
Hello linux-usb and linux-arm.
Ccing security@ because "the kerne
On 2019-08-08 9:58 am, Greg KH wrote:
On Thu, Aug 08, 2019 at 10:46:36AM +0200, yvahkhfo.1df7f...@hashmail.org wrote:
Hello linux-usb and linux-arm.
Ccing security@ because "the kernel dma code is mapping randomish
kernel/user mem to a user process" seems to have security implications
even thou
artman
Cc: Heikki Krogerus
Cc: Jason Gunthorpe
Cc: linux-usb@vger.kernel.org
Cc: "Rafael J. Wysocki"
Cc: Greg Kroah-Hartman
Cc: Ulf Hansson
Cc: Joe Perches
Cc: Mathieu Poirier
Cc: Will Deacon
Cc: Robin Murphy
Cc: Joerg Roedel
Signed-off-by: Suzuki K Poulose
---
+Fredrik, Juergen
On 14/05/2019 15:38, laurentiu.tu...@nxp.com wrote:
From: Laurentiu Tudor
For HCs that have local memory, replace the current DMA API usage
with a genalloc generic allocator to manage the mappings for these
devices.
This is in preparation for dropping the existing "coherent"
On 01/02/2019 08:47, Christoph Hellwig wrote:
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Hmm, as far as I'm aware these are PIO chips wi
On 01/02/2019 08:47, Christoph Hellwig wrote:
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Also use the proper Kconfig symbol to check for
On 15/03/18 07:58, Christoph Hellwig wrote:
On Wed, Mar 14, 2018 at 05:43:46PM +, Robin Murphy wrote:
Looking back I don't really understand why we even indirect the "classic"
per-device dma_declare_coherent_memory use case through the DMA API.
It certainly makes sense fo
On 12/03/18 10:41, Roger Quadros wrote:
[...]
@@ -0,0 +1,75 @@
+USB Connector
+=
+
+USB connector node represents physical USB connector. It should be
+a child of USB interface controller.
+
+Required properties:
+- compatible: describes type of the connector, must be one of:
+"us
On 13/03/18 13:17, Christoph Hellwig wrote:
On Tue, Mar 13, 2018 at 12:11:49PM +, Robin Murphy wrote:
Taking a step back, though, provided the original rationale about
dma_declare_coherent_memory() is still valid, I wonder if we should simply
permit the USB code to call dma_{alloc,free
On 11/03/18 18:01, Fredrik Noring wrote:
Hi Christoph,
The point is that you should always use a pool, period.
dma_alloc*/dma_free* are fundamentally expensive operations on my
architectures, so if you call them from a fast path you are doing
something wrong.
The author's comment in commit b3
On 06/03/18 01:57, Rob Herring wrote:
On Thu, Mar 01, 2018 at 10:51:38AM +0100, Amelie Delaunay wrote:
On some boards, especially when vbus supply requires large current,
and the charge pump on the PHY isn't enough, an external vbus power switch
per port may be used.
Add portN_vbus-supply proper
Hi Amelie,
Just a couple of drive-by coding style comments...
On 23/02/18 13:46, Amelie Delaunay wrote:
On some boards, especially when vbus supply requires large current,
and the charge pump on the PHY isn't enough, an external vbus power switch
may be used.
Add support for optional external v
possible to configure out, so it does seem
like a reasonable feature to assume. Maybe we could have something like
asm-generic/no-io.h to provide an "unimplemented" version of those
interfaces.
Anyway, for this series:
Acked-by: Robin Murphy
Thanks,
Robin.
This series is against
Hi Geert,
On 06/02/18 10:14, Geert Uytterhoeven wrote:
Add dummies for dma{,m}_pool_{create,destroy,alloc,free}(), to allow
compile-testing if NO_DMA=y.
This prevents the following from showing up later:
ERROR: "dma_pool_destroy" [drivers/usb/mtu3/mtu3.ko] undefined!
ERROR: "dma_pool
On 16/10/17 12:54, Hao Wei Tee wrote:
> On 12/10/2017 21:36, Mathias Nyman wrote:
>> You could try booting with xhci_hcd.dyndbg=+p added to the kernel command
>> line.
>
> I can't find anything relevant... Hmm.
Is your VL805 on the motherboard or an add-on card? One other possibly
important diff
Hi Marek,
On 13/10/17 09:15, Marek Szyprowski wrote:
> Hi Robin,
>
> On 2017-10-11 15:56, Robin Murphy wrote:
>> xHCI requires that data buffers do not cross 64KB boundaries (and are
>> thus at most 64KB long as well) - whilst xhci_queue_{bulk,isoc}_tx()
>> already spl
m, so that most producers like the block layer and the DMA
mapping implementations can lay things out correctly to begin with.
Signed-off-by: Robin Murphy
---
drivers/usb/host/xhci.c | 4
drivers/usb/host/xhci.h | 3 +++
2 files changed, 7 insertions(+)
diff --git a/drivers/usb/host/xhc
investigation reveals that we can avoid such
cross-page reads by not using the last few TRBs in a segment; to that
end, factor out the implicit index of the end-of-segemnt link TRB, and
implement a quirk to move it slightly further forward when necessary.
Signed-off-by: Robin Murphy
---
drivers/usb/host
On 10/10/17 16:51, David Laight wrote:
> From: Robin Murphy
>> Sent: 10 October 2017 16:25
> ...
>>> That could 'just' be the hardware doing a 'readahead' of the ring.
>>> Somewhat annoying if it is doing that across page boundaries.
>>
>
On 10/10/17 15:24, David Laight wrote:
> From: Mathias Nyman
>> Sent: 10 October 2017 15:13
> ...
>> [ 428.409645] print_req_error: I/O error, dev sdb, sector 128
>> [ 428.426612] arm-smmu 2b50.iommu: Unhandled context fault: fsr=0x8,
>> iova=0xff0b1000,
>> fsynr=0x183, cb=0
>>
>> a ring seg
On 09/10/17 16:49, Robin Murphy wrote:
> On 09/10/17 10:22, Mathias Nyman wrote:
>> On 08.10.2017 17:03, Hao Wei Tee wrote:
>>> Hi,
>>>
>>> I've been having DMA read faults with my VL805 xHCI controller when
>>> the Intel IOMMU
>>>
earlier thread here [2] about a similar/the same(?) device, but
>> that doesn't
>> seem to have worked.
>>
>> Help, please. I have no idea how to debug this further.
>>
>
> Could it maybe be related to a iommu/vt-d: Fix scatterlist offset
> handling fix
On 06/10/17 13:14, Robin Murphy wrote:
> Hi Will,
>
> On 06/10/17 01:19, Will Trives wrote:
>> Hello,
>>
>> Just reporting that it looks like this patch may fix the error (so
>> people having issues with VIA controller hosts may also want to try it):
>&g
Hi Will,
On 06/10/17 01:19, Will Trives wrote:
> Hello,
>
> Just reporting that it looks like this patch may fix the error (so
> people having issues with VIA controller hosts may also want to try it):
>
> https://lists.linuxfoundation.org/pipermail/iommu/2017-September/024371.html
>
> It appea
On 19/09/17 18:40, Krzysztof Kozlowski wrote:
> On Mon, Sep 18, 2017 at 12:02:13PM +0200, Andrzej Pietrasiewicz wrote:
>> Odroid XU4 board does not enumerate SuperSpeed devices.
>> This patch makes exynos5 series chips use USB SUSPHY quirk,
>> which solves the problem.
>>
>> Signed-off-by: Andrzej
;
>>> Fix this, and similar future problems, by simply skipping USB devices
>>> when dma_configure() is called during probe.
>>>
>>> Fixes: 09515ef5ddad ("of/acpi: Configure dma operations at probe time for
>>> platform/amba/pci bus devices")
t; probed.
>
> Fix this, and similar future problems, by simply skipping USB devices
> when dma_configure() is called during probe.
>
> Fixes: 09515ef5ddad ("of/acpi: Configure dma operations at probe time for
> platform/amba/pci bus devices")
> Cc: stable#
gt; dwc2 3f98.usb: Cannot do DMA to address 0x3a166a00
>
> Fix this, and similar future problems, by simply skipping USB devices
> when dma_configure() is called during probe.
>
> Fixes: 09515ef5ddad ("of/acpi: Configure dma operations at probe time for
On 02/08/17 12:10, Stefan Wahren wrote:
> Am 02.08.2017 um 09:03 schrieb Hans Verkuil:
>> When testing with my Raspberry Pi 3 and the 4.13-rcX mainline kernel
>> I discovered that there was no ethernet. After bisecting I got to commit
>> 2bf69867 ('USB: of: fix root-hub device-tree node handling').
Hi Stefan,
On 25/07/17 06:19, Stefan Wahren wrote:
>>> With arm64 4.13-rc1 I get no eth0 device on Pi3 (openSUSE Tumbleweed).
>>> The v4.13-rc1 DT works okay with a 4.12 kernel.
>>>
>>> Possibly related:
>>>
>>> [ 15.916350] OF: /soc/usb@7e98: could not get #phy-cells for /phy
>>>
>>> [ 16
On 10/03/17 15:35, David Laight wrote:
> From: Robin Murphy
>> Sent: 10 March 2017 15:23
> ...
>>>> So you have 128MB (max) of system memory that has cpu physical
>>>> addresses 0x8000 upwards.
>>>> I'd expect it all to be accessible from
On 10/03/17 15:05, Mason wrote:
> On 10/03/2017 15:06, David Laight wrote:
>
>> Robin Murphy wrote:
>>
>>> On 09/03/17 23:43, Mason wrote:
>>>
>>>> I think I'm making progress, in that I now have a better
>>>> idea of what I
On 09/03/17 23:43, Mason wrote:
> On 08/03/2017 16:17, Bjorn Helgaas wrote:
> [snip excellent in-depth overview]
>
> I think I'm making progress, in that I now have a better
> idea of what I don't understand. So I'm able to ask
> (hopefully) less vague questions.
>
> Take the USB3 PCIe adapter I'
[+linux-pci, just in case]
On 06/03/17 12:42, Mason wrote:
> On 03/03/2017 20:02, Robin Murphy wrote:
>
>> On 03/03/17 17:15, Mason wrote:
>>
>>>>> [1.264893] Unable to handle kernel paging request at virtual address
>>>>> d08664f4
>&g
On 03/03/17 17:15, Mason wrote:
[...]
>>> [1.264893] Unable to handle kernel paging request at virtual address
>>> d08664f4
Note that that's a reasonable approximation of a vmalloc address...
>>> [1.272248] pgd = c0004000
>>> [1.275060] [d08664f4] *pgd=8f804811, *pte=, *ppte=
On 27/09/16 17:13, Hanjun Guo wrote:
> On 09/27/2016 05:07 PM, Sudeep Holla wrote:
>>
>>
>> On 27/09/16 09:55, Sajjan, Vikas C wrote:
>>> Hi Sudeep,
>>>
>>> -Original Message-
>>> From: Sudeep Holla [mailto:sudeep.ho...@arm.com]
>>> Sent: Tuesday, September 27, 2016 2:21 PM
>>> To: Vikas Sa
On 07/09/16 10:55, Peter Chen wrote:
[...]
>> Regarding the DMA configuration that you mention in ci_hdrc_add_device(),
>> I think we should replace
>>
>> pdev->dev.dma_mask = dev->dma_mask;
>> pdev->dev.dma_parms = dev->dma_parms;
>> dma_set_coherent_mask(&pdev->dev, dev->
On 02/09/16 11:53, Felipe Balbi wrote:
>
> Hi,
>
> Arnd Bergmann writes:
>> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
>>>
>>> Hi Felipe and Arnd,
>>>
>>> It has been a while since the last response to this discussion, but we
>>> haven't reached an agreement yet! Can we get to
41 matches
Mail list logo
