On 2021-03-16 15:38, Christoph Hellwig wrote:
[...]
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index f1e38526d5bd40..996dfdf9d375dd 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3
On 2021-03-31 16:32, Will Deacon wrote:
On Wed, Mar 31, 2021 at 02:09:37PM +0100, Robin Murphy wrote:
On 2021-03-31 12:49, Will Deacon wrote:
On Tue, Mar 30, 2021 at 05:28:19PM +0100, Robin Murphy wrote:
On 2021-03-30 14:58, Will Deacon wrote:
On Tue, Mar 30, 2021 at 02:19:38PM +0100, Robin
On 2021-03-31 12:49, Will Deacon wrote:
On Tue, Mar 30, 2021 at 05:28:19PM +0100, Robin Murphy wrote:
On 2021-03-30 14:58, Will Deacon wrote:
On Tue, Mar 30, 2021 at 02:19:38PM +0100, Robin Murphy wrote:
On 2021-03-30 14:11, Will Deacon wrote:
On Tue, Mar 16, 2021 at 04:38:22PM +0100
On 2021-03-30 14:58, Will Deacon wrote:
On Tue, Mar 30, 2021 at 02:19:38PM +0100, Robin Murphy wrote:
On 2021-03-30 14:11, Will Deacon wrote:
On Tue, Mar 16, 2021 at 04:38:22PM +0100, Christoph Hellwig wrote:
From: Robin Murphy
Instead make the global iommu_dma_strict paramete in iommu.c
On 2021-03-30 14:11, Will Deacon wrote:
On Tue, Mar 16, 2021 at 04:38:22PM +0100, Christoph Hellwig wrote:
From: Robin Murphy
Instead make the global iommu_dma_strict paramete in iommu.c canonical by
exporting helpers to get and set it and use those directly in the drivers.
This make sure
On 2021-03-15 08:33, Christoph Hellwig wrote:
On Fri, Mar 12, 2021 at 04:18:24PM +, Robin Murphy wrote:
Let me know what you think of the version here:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/iommu-cleanup
I'll happily switch the patch to you as the auth
On 2021-03-11 08:26, Christoph Hellwig wrote:
On Wed, Mar 10, 2021 at 06:39:57PM +, Robin Murphy wrote:
Actually... Just mirroring the iommu_dma_strict value into
struct iommu_domain should solve all of that with very little
boilerplate code.
Yes, my initial thought was to directly
On 2021-03-10 09:25, Christoph Hellwig wrote:
On Wed, Mar 10, 2021 at 10:15:01AM +0100, Christoph Hellwig wrote:
On Thu, Mar 04, 2021 at 03:25:27PM +, Robin Murphy wrote:
On 2021-03-01 08:42, Christoph Hellwig wrote:
Use explicit methods for setting and querying the information instead
On 2021-03-01 08:42, Christoph Hellwig wrote:
Signed-off-by: Christoph Hellwig
Moreso than the previous patch, where the feature is at least relatively
generic (note that there's a bunch of in-flight development around
DOMAIN_ATTR_NESTING), I'm really not convinced that it's beneficial to
b
On 2021-03-01 08:42, Christoph Hellwig wrote:
Use explicit methods for setting and querying the information instead.
Now that everyone's using iommu-dma, is there any point in bouncing this
through the drivers at all? Seems like it would make more sense for the
x86 drivers to reflect their pr
On 2020-11-04 14:15, Markus Bauer wrote:
Remove error messages that might confuse users when error is just -517 /
-EPROBE_DEFER.
[...]
imx-dwmac 30bf.ethernet: Cannot register the MDIO bus
imx-dwmac 30bf.ethernet: stmmac_dvr_probe: MDIO bus (id: 0) registration
failed
[...]
FYI we ha
On 2020-09-15 16:51, Christoph Hellwig wrote:
[...]
+These APIs allow to allocate pages in the kernel direct mapping that are
+guaranteed to be DMA addressable. This means that unlike dma_alloc_coherent,
+virt_to_page can be called on the resulting address, and the resulting
Nit: if we explici
On 2020-09-09 21:06, Joe Perches wrote:
fallthrough to a separate case/default label break; isn't very readable.
Convert pseudo-keyword fallthrough; statements to a simple break; when
the next label is case or default and the only statement in the next
label block is break;
Found using:
$ grep
On 2020-08-19 13:49, Tomasz Figa wrote:
On Wed, Aug 19, 2020 at 1:51 PM Robin Murphy wrote:
Hi Tomasz,
On 2020-08-19 12:16, Tomasz Figa wrote:
Hi Christoph,
On Wed, Aug 19, 2020 at 8:56 AM Christoph Hellwig wrote:
The V4L2-FLAG-MEMORY-NON-CONSISTENT flag is entirely unused,
Could you
Hi Tomasz,
On 2020-08-19 12:16, Tomasz Figa wrote:
Hi Christoph,
On Wed, Aug 19, 2020 at 8:56 AM Christoph Hellwig wrote:
The V4L2-FLAG-MEMORY-NON-CONSISTENT flag is entirely unused,
Could you explain what makes you think it's unused? It's a feature of
the UAPI generally supported by the v
On 2020-07-08 07:50, Christoph Hellwig wrote:
On Mon, Jun 29, 2020 at 04:41:16PM +0100, Robin Murphy wrote:
On 2020-06-28 18:16, Bj�rn T�pel wrote:
On 2020-06-27 09:04, Christoph Hellwig wrote:
On Sat, Jun 27, 2020 at 01:00:19AM +0200, Daniel Borkmann wrote:
Given there is roughly a ~5
On 2020-07-06 20:59, Jonathan Lemon wrote:
On Wed, Jul 01, 2020 at 10:46:40AM +0100, Robin Murphy wrote:
On 2020-06-30 20:08, Jonathan Lemon wrote:
On Mon, Jun 29, 2020 at 02:15:16PM +0100, Robin Murphy wrote:
On 2020-06-27 08:02, Christoph Hellwig wrote:
On Fri, Jun 26, 2020 at 01:54:12PM
On 2020-07-07 04:44, Andy Duan wrote:
Hi mm experts,
From: Kegl Rohit Sent: Monday, July 6, 2020 10:18 PM
So you would also say a single dma_sync_single_for_cpu is enough.
You are right it would be great if some mm expert could have a look at it. If
any corruption could happen.
Kegl want to
On 2020-06-30 20:08, Jonathan Lemon wrote:
On Mon, Jun 29, 2020 at 02:15:16PM +0100, Robin Murphy wrote:
On 2020-06-27 08:02, Christoph Hellwig wrote:
On Fri, Jun 26, 2020 at 01:54:12PM -0700, Jonathan Lemon wrote:
On Fri, Jun 26, 2020 at 09:47:25AM +0200, Christoph Hellwig wrote:
Note that
On 2020-06-28 18:16, Björn Töpel wrote:
On 2020-06-27 09:04, Christoph Hellwig wrote:
On Sat, Jun 27, 2020 at 01:00:19AM +0200, Daniel Borkmann wrote:
Given there is roughly a ~5 weeks window at max where this removal could
still be applied in the worst case, could we come up with a fix /
pro
On 2020-06-27 08:02, Christoph Hellwig wrote:
On Fri, Jun 26, 2020 at 01:54:12PM -0700, Jonathan Lemon wrote:
On Fri, Jun 26, 2020 at 09:47:25AM +0200, Christoph Hellwig wrote:
Note that this is somewhat urgent, as various of the APIs that the code
is abusing are slated to go away for Linux 5.
On 2020-06-24 17:50, Russell King - ARM Linux admin wrote:
On Wed, Jun 24, 2020 at 09:06:28AM -0700, Florian Fainelli wrote:
On 6/24/2020 6:48 AM, Bartosz Golaszewski wrote:
I didn't expect to open such a can of worms...
This has evolved into several new concepts being proposed vs my
use-case
On 16/08/2019 09:15, Shaokun Zhang wrote:
Hi Will,
On 2019/8/16 0:46, Will Deacon wrote:
On Thu, May 16, 2019 at 11:14:35AM +0800, Zhangshaokun wrote:
On 2019/5/15 17:47, Will Deacon wrote:
On Mon, Apr 15, 2019 at 07:18:22PM +0100, Robin Murphy wrote:
On 12/04/2019 10:52, Will Deacon wrote
On 15/05/2019 12:13, David Laight wrote:
From: Robin Murphy
Sent: 15 May 2019 11:58
To: David Laight; 'Will Deacon'
Cc: Zhangshaokun; Ard Biesheuvel; linux-arm-ker...@lists.infradead.org;
netdev@vger.kernel.org;
ilias.apalodi...@linaro.org; huanglingyan (A); steve.cap...@arm.com
S
On 15/05/2019 10:47, Will Deacon wrote:
On Mon, Apr 15, 2019 at 07:18:22PM +0100, Robin Murphy wrote:
On 12/04/2019 10:52, Will Deacon wrote:
I'm waiting for Robin to come back with numbers for a C implementation.
Robin -- did you get anywhere with that?
Still not what I would call fin
On 15/05/2019 11:15, David Laight wrote:
...
ptr = (u64 *)(buff - offset);
shift = offset * 8;
/*
* Head: zero out any excess leading bytes. Shifting back by the same
* amount should be at least as fast as any other way of handling the
* odd/ev
On 12/04/2019 10:52, Will Deacon wrote:
On Fri, Apr 12, 2019 at 10:31:16AM +0800, Zhangshaokun wrote:
On 2019/2/19 7:08, Ard Biesheuvel wrote:
It turns out that the IP checksumming code is still exercised often,
even though one might expect that modern NICs with checksum offload
have no use for
Hi Ard,
On 28/02/2019 14:16, Ard Biesheuvel wrote:
(+ Catalin)
On Tue, 19 Feb 2019 at 16:08, Ilias Apalodimas
wrote:
On Tue, Feb 19, 2019 at 12:08:42AM +0100, Ard Biesheuvel wrote:
It turns out that the IP checksumming code is still exercised often,
even though one might expect that modern
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 30/11/2018 17:54, Qian Cai wrote:
The amount of DMA mappings from Hisilicon HNS ethernet devices is huge,
so it could trigger "DMA-API: debugging out of memory - disabling".
hnae_get_handle [1]
hnae_init_queue
hnae_init_ring
hnae_alloc_buffers [2]
debug_dma_map_page
On 30/11/2018 08:42, Christoph Hellwig wrote:
On Thu, Nov 29, 2018 at 10:54:56PM -0500, Qian Cai wrote:
/* allow architectures to override this if absolutely required */
#ifndef PREALLOC_DMA_DEBUG_ENTRIES
+/* amount of DMA mappings on this driver is huge. */
+#ifdef HNS_ENET
+#define PREALLO
On Sat, 26 May 2018 00:33:05 +0530
Jassi Brar wrote:
> On 25 May 2018 at 18:20, Ard Biesheuvel
> wrote:
> > The netsec network controller IP can drive 64 address bits for DMA,
> > and the DMA mask is set accordingly in the driver. However, the
> > SynQuacer SoC, which is the only silicon incorpo
rates this IP, this is a reasonable
approach that can be backported to -stable and buys us some time to come
up with a proper fix going forward.
It's a little bit of a dodge, but until another SoC comes along with
different requirements I agree it's the reasonable thing to do.
Revie
On 16/04/18 09:50, Christoph Hellwig wrote:
We can rely on the dma-mapping code to handle any DMA limits that is
bigger than the ISA DMA mask for us (either using an iommu or swiotlb),
so remove setting the block layer bounce limit for anything but bouncing
for highmem pages.
Signed-off-by: Chri
On 06/04/18 12:14, Vadim Lomovtsev wrote:
From: Vadim Lomovtsev
It is too expensive to pass u64 values via linked list, instead
allocate array for them by overall number of mac addresses from netdev.
This eventually removes multiple kmalloc() calls, aviod memory
fragmentation and allow to put
, the whole qtnf_pcie_init_dma_mask() function is nothing more
than a rather long-winded implementation of dma_set_mask_and_coherent(),
so let's just use that directly.
Signed-off-by: Robin Murphy
---
.../net/wireless/quantenna/qtnfmac/pearl/pcie.c| 28 +-
1 file
On 14/07/17 13:07, Arnd Bergmann wrote:
> gcc warns that the temporary buffer might be too small here:
>
> drivers/net/ethernet/cavium/thunder/thunder_bgx.c: In function 'bgx_probe':
> drivers/net/ethernet/cavium/thunder/thunder_bgx.c:1020:16: error: '%d'
> directive writing between 1 and 10 byte
in the device specific structure for that, so we only
> need to modify that.
>
> Fixes: fb52728a9294 ("dpaa_eth: reuse the dma_ops provided by the FMan MAC
> device")
> Signed-off-by: Arnd Bergmann
Acked-by: Robin Murphy
Assuming all the DPAA subcomponents have the
On 10/07/17 15:56, Christoph Hellwig wrote:
> This looks reasonable to me, I'd be happy to pick it up. Can you send
> it as a series with the reverts?
The fact remains that the FSL driver is still doing the wrong thing
though - set_dma_ops(dev1, get_dma_ops(dev2)) is just a hack which
happens to
Hi Christoph,
On 20/06/17 13:41, Christoph Hellwig wrote:
> On Fri, Jun 16, 2017 at 08:10:15PM +0200, Christoph Hellwig wrote:
>> I plan to create a new dma-mapping tree to collect all this work.
>> Any volunteers for co-maintainers, especially from the iommu gang?
>
> Ok, I've created the new tr
context. The rest is just proactively
blatting address arguments with "arbitrary definitely-invalid value",
which is more paranoia than anything else (and arguably unnecessary).
It's not the biggest deal, though, so either way:
Reviewed-by: Robin Murphy
> Signed-off-by: Christoph
On 08/06/17 14:25, Christoph Hellwig wrote:
> The dma alloc interface returns an error by return NULL, and the
> mapping interfaces rely on the mapping_error method, which the dummy
> ops already implement correctly.
>
> Thus remove the DMA_ERROR_CODE define.
Reviewed-by: Robin Mu
Hi Christoph,
On 08/06/17 14:25, Christoph Hellwig wrote:
> DMA_ERROR_CODE is not a public API and will go away soon. dma dma-iommu
> driver already implements a proper ->mapping_error method, so it's only
> using the value internally. Add a new local define using the value
> that arm64 which is
On 17/03/17 04:42, Subash Abhinov Kasiviswanathan wrote:
> Android devices use multiple ip[6]tables for statistics, UID matching
> and other functionality. Perf output indicated that ip6_do_table
> was taking a considerable amount of CPU and more that ip_do_table
> for an equivalent rate. ipv6_mask
On 13/03/17 17:39, Mason wrote:
> On 13/03/2017 18:12, Robin Murphy wrote:
>
>> On 13/03/17 16:10, Mason wrote:
>>
>>> There are two revisions of our PCI Express controller.
>>>
>>> Rev 1 did not support the following features:
>>>
>>&g
On 13/03/17 16:10, Mason wrote:
> Hello,
>
> There are two revisions of our PCI Express controller.
>
> Rev 1 did not support the following features:
>
> 1) legacy PCI interrupt delivery (INTx signals)
> 2) I/O address space
>
> Internally, someone stated that such missing support would pre
On 07/03/17 15:04, Radoslaw Biernacki wrote:
> From: Radoslaw Biernacki
>
> PCI reset quirk is needed for Cavium Function NIC since it does not
> handle a function level reset.
> This cause problems when VNIC is used from userspace by vfio.
> If application (or VM) does not stop the VNIC queues,
On 06/03/17 12:57, Sunil Kovvuri wrote:
>>>
>>> We are seeing a 0.75Mpps drop with IP forwarding rate due to that.
>>> Hence I have restricted calling DMA interfaces to only when IOMMU is
>>> enabled.
>>
>> What's 0.07Mpps as a percentage of baseline? On a correctly configured
>> coherent arm64 sy
On 04/03/17 05:54, Sunil Kovvuri wrote:
> On Fri, Mar 3, 2017 at 11:26 PM, David Miller wrote:
>> From: sunil.kovv...@gmail.com
>> Date: Fri, 3 Mar 2017 16:17:47 +0530
>>
>>> @@ -1643,6 +1650,9 @@ static int nicvf_probe(struct pci_dev *pdev, const
>>> struct pci_device_id *ent)
>>> if (!pa
Hi all,
We're seeing a new boot-time crash[1] on SMSC911x hardware from this
patch in today's HEAD (as cafe8df8b9bc)...
On 01/02/17 02:46, Florian Fainelli wrote:
> From: Mao Wenan
>
> There is currently no reference count being held on the PHY driver,
> which makes it possible to remove the PH
On 03/02/17 15:02, Thomas Petazzoni wrote:
> Hello,
>
> On Fri, 3 Feb 2017 14:05:13 +0000, Robin Murphy wrote:
>
>>> So do you have a better suggestion? The descriptors only have enough
>>> space to store a 40-bit virtual address, which is not enough to fit the
On 03/02/17 13:24, Thomas Petazzoni wrote:
> Hello,
>
> On Fri, 6 Jan 2017 14:44:56 +0000, Robin Murphy wrote:
>
>>>> +#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
>>>> + dma_addr_t dma_addr =
>>>> + rx_des
On 18/01/17 14:45, Mark Rutland wrote:
> On Wed, Jan 18, 2017 at 03:03:57PM +0100, Mason wrote:
>> Hello,
>>
>> When my system boots up, eth0 is given a seemingly random MAC address.
>>
>> [0.950734] nb8800 26000.ethernet eth0: MAC address ba:de:d6:38:b8:38
>> [0.957334] nb8800 26000.ethern
On 06/01/17 14:29, Russell King - ARM Linux wrote:
> On Wed, Dec 28, 2016 at 05:46:21PM +0100, Thomas Petazzoni wrote:
>> This commit adds the definition of the PPv2.2 HW descriptors, adjusts
>> the mvpp2_tx_desc and mvpp2_rx_desc structures accordingly, and adapts
>> the accessors to work on both
Hi Jeremy,
On 12/08/15 23:06, Jeremy Linton wrote:
[...]
+static void *device_get_mac_addr(struct device *dev,
+const char *name, char *addr,
+int alen)
+{
+ int ret = device_property_read_u8_array(dev, name, addr, alen);
+
+
56 matches
Mail list logo
