Re: [PATCH] dma-mapping: move dma configuration to bus infrastructure

Hi Nipun, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.16-rc5 next-20180313] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci

[RFC PATCH] dma-mapping: platform_dma_configure() can be static

Fixes: 9a019f425175 ("dma-mapping: move dma configuration to bus infrastructure") Signed-off-by: Fengguang Wu --- platform.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/base/platform.c b/drivers/base/platform.c index

Re: [PATCH v2 5/5] iommu/amd - Add a debugfs entry to specify a IOMMU device table entry

On Tue, Mar 13, 2018 at 8:54 PM, Gary R Hook wrote: > On 03/13/2018 12:20 PM, Andy Shevchenko wrote: >>> + } else if (obuf[0] == '0' && obuf[1] == 'x') { >>> + n = sscanf(obuf, "%x", _iommu_devid); >>> + } else { >>> + n = sscanf(obuf,

Re: [PATCH v2 1/5] iommu/amd - Add debugfs support

On Tue, Mar 13, 2018 at 8:54 PM, Gary R Hook wrote: > On 03/13/2018 12:16 PM, Andy Shevchenko wrote: >> On Fri, Mar 9, 2018 at 2:50 AM, Gary R Hook wrote: >>> +#include >>> +#include >>> +#include >> >> >> Keep in order? > What order would that be?

Re: [PATCH v2 5/5] iommu/amd - Add a debugfs entry to specify a IOMMU device table entry

On 03/13/2018 12:20 PM, Andy Shevchenko wrote: + oboff += OSCNPRINTF("%02x:%02x:%x (%u / %04x)\n", + PCI_BUS_NUM(amd_iommu_devid), + PCI_SLOT(amd_iommu_devid), +

Re: [PATCH v2 1/5] iommu/amd - Add debugfs support

On 03/13/2018 12:16 PM, Andy Shevchenko wrote: On Fri, Mar 9, 2018 at 2:50 AM, Gary R Hook wrote: + default n Redundant Roger that. +#include +#include +#include Keep in order? What order would that be? These few needed files are listed in the same order

Re: [PATCH v2 5/5] iommu/amd - Add a debugfs entry to specify a IOMMU device table entry

On Fri, Mar 9, 2018 at 2:51 AM, Gary R Hook wrote: > Initially (at boot) the device table values dumped are all of the > active devices. Add a devid debugfs file to allow the user to select a > single device table entry to dump (active or not). Let any devid value > greater

Re: [PATCH v2 1/5] iommu/amd - Add debugfs support

On Fri, Mar 9, 2018 at 2:50 AM, Gary R Hook wrote: > + default n Redundant > +#include > +#include > +#include Keep in order? > +#include "amd_iommu_proto.h" > +#include "amd_iommu_types.h" > +/* DebugFS helpers */ > +#defineOBUFP (obuf +

Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing

Gentle ping? On Mon, 2018-03-05 at 15:00 +, Dmitry Safonov wrote: > Hi Joerg, > > What do you think about v3? > It looks like, I can solve my softlookups with just a bit more proper > ratelimiting.. > > On Thu, 2018-02-15 at 19:17 +, Dmitry Safonov wrote: > > There is a ratelimit for

RE: [PATCH] dma-mapping: move dma configuration to bus infrastructure

> -Original Message- > From: Robin Murphy [mailto:robin.mur...@arm.com] > Sent: Tuesday, March 13, 2018 17:06 > > On 12/03/18 15:24, Nipun Gupta wrote: > > The change introduces 'dma_configure' & 'dma_deconfigure'as > > bus callback functions so each bus can choose to implement > > its

RE: [PATCH] dma-mapping: move dma configuration to bus infrastructure

> -Original Message- > From: Christoph Hellwig [mailto:h...@lst.de] > Sent: Tuesday, March 13, 2018 13:05 > > +int amba_dma_configure(struct device *dev) > > +{ > > + enum dev_dma_attr attr; > > + int ret = 0; > > + > > + if (dev->of_node) { > > + ret =

Re: [PATCH v9 1/5] driver core: Find an existing link between two devices

Hi Robin, On Tue, Mar 13, 2018 at 6:19 PM, Robin Murphy wrote: > On 13/03/18 09:55, Vivek Gautam wrote: >> >> On Tue, Mar 13, 2018 at 3:10 PM, Rafael J. Wysocki >> wrote: >>> >>> On Tuesday, March 13, 2018 9:55:30 AM CET Vivek Gautam wrote:

Re: WARN_ON(irqs_disabled()) in dma_free_attrs?

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}_from_dev_coherent() directly > here

Re: [PATCH 11/13] dma-direct: handle the memory encryption bit in common code

On Mon, Mar 12, 2018 at 02:48:51PM -0500, Tom Lendacky wrote: > Ok, I found one issue that allows this to work when the IOMMU isn't > enabled (see below). Thanks, folded! > But the bigger issue is when the IOMMU is enabled. The IOMMU code uses > a common mapping routine to create the I/O page

Re: [PATCH v9 1/5] driver core: Find an existing link between two devices

On 13/03/18 09:55, Vivek Gautam wrote: On Tue, Mar 13, 2018 at 3:10 PM, Rafael J. Wysocki wrote: On Tuesday, March 13, 2018 9:55:30 AM CET Vivek Gautam wrote: The lists managing the device-links can be traversed to find the link between two devices. The device_link_add()

Re: WARN_ON(irqs_disabled()) in dma_free_attrs?

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

Re: [PATCH] dma-mapping: move dma configuration to bus infrastructure

On 12/03/18 15:24, Nipun Gupta wrote: The change introduces 'dma_configure' & 'dma_deconfigure'as bus callback functions so each bus can choose to implement its own dma configuration function. This eases the addition of new busses w.r.t. adding the dma configuration functionality. It's

Re: [PATCH v9 1/5] driver core: Find an existing link between two devices

On Tue, Mar 13, 2018 at 7:34 PM, Vivek Gautam wrote: > Hi Tomasz, > > On Tue, Mar 13, 2018 at 3:45 PM, Tomasz Figa wrote: >> Hi Vivek, >> >> Thanks for the patch. >> >> On Tue, Mar 13, 2018 at 5:55 PM, Vivek Gautam >>

Re: [PATCH v9 1/5] driver core: Find an existing link between two devices

Hi Tomasz, On Tue, Mar 13, 2018 at 3:45 PM, Tomasz Figa wrote: > Hi Vivek, > > Thanks for the patch. > > On Tue, Mar 13, 2018 at 5:55 PM, Vivek Gautam > wrote: >> The lists managing the device-links can be traversed to >> find the link between

Re: [PATCH v9 1/5] driver core: Find an existing link between two devices

Hi Vivek, Thanks for the patch. On Tue, Mar 13, 2018 at 5:55 PM, Vivek Gautam wrote: > The lists managing the device-links can be traversed to > find the link between two devices. The device_link_add() APIs > does traverse these lists to check if there's already a

Re: [PATCH v9 1/5] driver core: Find an existing link between two devices

On Tue, Mar 13, 2018 at 2:25 PM, Vivek Gautam wrote: > The lists managing the device-links can be traversed to > find the link between two devices. The device_link_add() APIs > does traverse these lists to check if there's already a link > setup between the two

Re: [PATCH v9 1/5] driver core: Find an existing link between two devices

On Tue, Mar 13, 2018 at 3:10 PM, Rafael J. Wysocki wrote: > On Tuesday, March 13, 2018 9:55:30 AM CET Vivek Gautam wrote: >> The lists managing the device-links can be traversed to >> find the link between two devices. The device_link_add() APIs >> does traverse these lists to

Re: [PATCH v9 1/5] driver core: Find an existing link between two devices

On Tuesday, March 13, 2018 9:55:30 AM CET Vivek Gautam wrote: > The lists managing the device-links can be traversed to > find the link between two devices. The device_link_add() APIs > does traverse these lists to check if there's already a link > setup between the two devices. > So, add a new

[PATCH v9 5/5] iommu/arm-smmu: Add support for qcom,smmu-v2 variant

qcom,smmu-v2 is an arm,smmu-v2 implementation with specific clock and power requirements. This smmu core is used with multiple masters on msm8996, viz. mdss, video, etc. Add bindings for the same. Signed-off-by: Vivek Gautam Reviewed-by: Rob Herring

[PATCH v9 4/5] iommu/arm-smmu: Add the device_link between masters and smmu

From: Sricharan R Finally add the device link between the master device and smmu, so that the smmu gets runtime enabled/disabled only when the master needs it. This is done from add_device callback which gets called once when the master is added to the smmu.

[PATCH v9 2/5] iommu/arm-smmu: Add pm_runtime/sleep ops

From: Sricharan R The smmu needs to be functional only when the respective master's using it are active. The device_link feature helps to track such functional dependencies, so that the iommu gets powered when the master device enables itself using pm_runtime. So by

[PATCH v9 3/5] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device

From: Sricharan R The smmu device probe/remove and add/remove master device callbacks gets called when the smmu is not linked to its master, that is without the context of the master device. So calling runtime apis in those places separately. Signed-off-by: Sricharan R

[PATCH v9 0/5] iommu/arm-smmu: Add runtime pm/sleep support

This series provides the support for turning on the arm-smmu's clocks/power domains using runtime pm. This is done using the recently introduced device links patches, which lets the smmu's runtime to follow the master's runtime pm, so the smmu remains powered only when the masters use it. As not

[PATCH v9 1/5] driver core: Find an existing link between two devices

The lists managing the device-links can be traversed to find the link between two devices. The device_link_add() APIs does traverse these lists to check if there's already a link setup between the two devices. So, add a new APIs, device_link_find(), to find an existing device link between two

Re: [PATCH] dma-mapping: move dma configuration to bus infrastructure

> +int amba_dma_configure(struct device *dev) > +{ > + enum dev_dma_attr attr; > + int ret = 0; > + > + if (dev->of_node) { > + ret = of_dma_configure(dev, dev->of_node); > + } else if (has_acpi_companion(dev)) { > + attr =

Re: [PATCH] dma-mapping: move dma configuration to bus infrastructure

On Tue, Mar 13, 2018 at 04:22:53AM +, Nipun Gupta wrote: > > Isn't this one or the other one but not both? > > > > Something like: > > > > if (dev->of_node) > > of_dma_deconfigure(dev); > > else > > acpi_dma_deconfigure(dev); > > > > should work. > > I understand your point. Seems