Re: [PATCH] dma-debug: hns_enet_drv could use more DMA entries

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

Re: [PATCH] net: netsec: reduce DMA mask to 40 bits

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,

Re: [PATCH] net: netsec: reduce DMA mask to 40 bits

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. Reviewed-by: Robin Murphy

Re: [PATCH 08/12] mmc: reduce use of block bounce buffers

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:

Re: [PATCH v2] net: thunderx: rework mac addresses list to u64 array

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

[PATCH] qtfnmac: Tidy up DMA mask setting

, 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 <robin.mur...@arm.com> --- .../net/wireless/quantenna/qtnfmac/pearl/pcie.c

Re: [PATCH 11/22] net: thunder_bgx: avoid format string overflow warning

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

Re: [PATCH] dpaa_eth: use correct device for DMA mapping API

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 <a...@arndb.de> Acked-by: Robin Murphy <robin.mur...@a

Re: [PATCH/RFC] dma-mapping: Provide dummy set_dma_ops() for NO_DMA=y

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

Re: new dma-mapping tree, was Re: clean up and modularize arch dma_mapping interface V2

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

Re: [PATCH 06/44] iommu/dma: don't rely on DMA_ERROR_CODE

he 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 <robin.mur...@arm.com> > Signed-off-

Re: [PATCH 16/44] arm64: remove DMA_ERROR_CODE

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

Re: [PATCH 06/44] iommu/dma: don't rely on DMA_ERROR_CODE

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

Re: [PATCH net-next] ipv6: Implement optimized IPv6 masked address comparison for ARM64

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.

Re: Legacy features in PCI Express devices

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

Re: Legacy features in PCI Express devices

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

Re: [PATCH] PCI: Add pci reset quirk for Cavium VNIC

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)

Re: [PATCH 1/4] net: thunderx: Fix IOMMU translation faults

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

Re: [PATCH 1/4] net: thunderx: Fix IOMMU translation faults

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

Re: [net] net: phy: Fix lack of reference count on PHY driver

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

Re: [PATCHv2 net-next 05/16] net: mvpp2: introduce PPv2.2 HW descriptors and adapt accessors

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

Re: [PATCHv2 net-next 05/16] net: mvpp2: introduce PPv2.2 HW descriptors and adapt accessors

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

Re: Initializing MAC address at run-time

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

Re: [PATCHv2 net-next 05/16] net: mvpp2: introduce PPv2.2 HW descriptors and adapt accessors

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

Re: [PATCH 1/2] Add a matching set of device_ functions for determining mac/phy

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); + +