Re: [PATCH v3 13/20] mmc: Remove depends on HAS_DMA in case of platform dependency

2018-04-19 Thread Ulf Hansson
On 17 April 2018 at 19:49, Geert Uytterhoeven  wrote:
> Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
> symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
> In most cases this other symbol is an architecture or platform specific
> symbol, or PCI.
>
> Generic symbols and drivers without platform dependencies keep their
> dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
> cannot work anyway.
>
> This simplifies the dependencies, and allows to improve compile-testing.
>
> Signed-off-by: Geert Uytterhoeven 
> Reviewed-by: Mark Brown 
> Acked-by: Robin Murphy 
> Acked-by: Ulf Hansson 

Thanks, applied for next!

Kind regrds
Uffe

> ---
> v3:
>   - Add Acked-by,
>   - Rebase to v4.17-rc1,
>
> v2:
>   - Add Reviewed-by, Acked-by,
>   - Drop RFC state,
>   - Split per subsystem.
> ---
>  drivers/mmc/host/Kconfig | 10 ++
>  1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 9589f9c9046f14b1..3978d0418958bf6b 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -358,7 +358,6 @@ config MMC_MESON_MX_SDIO
> tristate "Amlogic Meson6/Meson8/Meson8b SD/MMC Host Controller 
> support"
> depends on ARCH_MESON || COMPILE_TEST
> depends on COMMON_CLK
> -   depends on HAS_DMA
> depends on OF
> help
>   This selects support for the SD/MMC Host Controller on
> @@ -401,7 +400,6 @@ config MMC_OMAP
>
>  config MMC_OMAP_HS
> tristate "TI OMAP High Speed Multimedia Card Interface support"
> -   depends on HAS_DMA
> depends on ARCH_OMAP2PLUS || ARCH_KEYSTONE || COMPILE_TEST
> help
>   This selects the TI OMAP High Speed Multimedia card Interface.
> @@ -511,7 +509,6 @@ config MMC_DAVINCI
>
>  config MMC_GOLDFISH
> tristate "goldfish qemu Multimedia Card Interface support"
> -   depends on HAS_DMA
> depends on GOLDFISH || COMPILE_TEST
> help
>   This selects the Goldfish Multimedia card Interface emulation
> @@ -605,7 +602,7 @@ config MMC_SDHI
>
>  config MMC_SDHI_SYS_DMAC
> tristate "DMA for SDHI SD/SDIO controllers using SYS-DMAC"
> -   depends on MMC_SDHI && HAS_DMA
> +   depends on MMC_SDHI
> default MMC_SDHI if (SUPERH || ARM)
> help
>   This provides DMA support for SDHI SD/SDIO controllers
> @@ -615,7 +612,7 @@ config MMC_SDHI_SYS_DMAC
>  config MMC_SDHI_INTERNAL_DMAC
> tristate "DMA for SDHI SD/SDIO controllers using on-chip bus 
> mastering"
> depends on ARM64 || COMPILE_TEST
> -   depends on MMC_SDHI && HAS_DMA
> +   depends on MMC_SDHI
> default MMC_SDHI if ARM64
> help
>   This provides DMA support for SDHI SD/SDIO controllers
> @@ -669,7 +666,6 @@ config MMC_CAVIUM_THUNDERX
>
>  config MMC_DW
> tristate "Synopsys DesignWare Memory Card Interface"
> -   depends on HAS_DMA
> depends on ARC || ARM || ARM64 || MIPS || COMPILE_TEST
> help
>   This selects support for the Synopsys DesignWare Mobile Storage IP
> @@ -748,7 +744,6 @@ config MMC_DW_ZX
>
>  config MMC_SH_MMCIF
> tristate "SuperH Internal MMCIF support"
> -   depends on HAS_DMA
> depends on SUPERH || ARCH_RENESAS || COMPILE_TEST
> help
>   This selects the MMC Host Interface controller (MMCIF) found in 
> various
> @@ -868,7 +863,6 @@ config MMC_TOSHIBA_PCI
>  config MMC_BCM2835
> tristate "Broadcom BCM2835 SDHOST MMC Controller support"
> depends on ARCH_BCM2835 || COMPILE_TEST
> -   depends on HAS_DMA
> help
>   This selects the BCM2835 SDHOST MMC controller. If you have
>   a BCM2835 platform with SD or MMC devices, say Y or M here.
> --
> 2.7.4
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] iommu/vt-d: fix usage of force parameter in intel_ir_reconfigure_irte()

2018-04-19 Thread Jag Raman


> On Apr 4, 2018, at 2:06 PM, Jag Raman  wrote:
> 
> 
> 
> On 3/6/2018 5:39 PM, Jagannathan Raman wrote:
>> It was noticed that the IRTE configured for guest OS kernel
>> was over-written while the guest was running. As a result,
>> vt-d Posted Interrupts configured for the guest are not being
>> delivered directly, and instead bounces off the host. Every
>> interrupt delivery takes a VM Exit.
>> It was noticed that the following stack is doing the over-write:
>> [  147.463177]  modify_irte+0x171/0x1f0
>> [  147.463405]  intel_ir_set_affinity+0x5c/0x80
>> [  147.463641]  msi_domain_set_affinity+0x32/0x90
>> [  147.463881]  irq_do_set_affinity+0x37/0xd0
>> [  147.464125]  irq_set_affinity_locked+0x9d/0xb0
>> [  147.464374]  __irq_set_affinity+0x42/0x70
>> [  147.464627]  write_irq_affinity.isra.5+0xe1/0x110
>> [  147.464895]  proc_reg_write+0x38/0x70
>> [  147.465150]  __vfs_write+0x36/0x180
>> [  147.465408]  ? handle_mm_fault+0xdf/0x200
>> [  147.465671]  ? _cond_resched+0x15/0x30
>> [  147.465936]  vfs_write+0xad/0x1a0
>> [  147.466204]  SyS_write+0x52/0xc0
>> [  147.466472]  do_syscall_64+0x74/0x1a0
>> [  147.466744]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
>> reversing the sense of force check in intel_ir_reconfigure_irte()
>> restores proper posted interrupt functionality
>> Signed-off-by: Jagannathan Raman 
>> ---
>>  Hi Thomas,
>>  I noticed that you added intel_ir_reconfigure_irte() with the
>>  following commit:
>>  d491bdff888e ("iommu/vt-d: Reevaluate vector configuration on
>>  activate()")
>>  Could you please confirm the usage of "force" parameter in
>>  intel_ir_reconfigure_irte()?
>>  drivers/iommu/intel_irq_remapping.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> diff --git a/drivers/iommu/intel_irq_remapping.c 
>> b/drivers/iommu/intel_irq_remapping.c
>> index 66f69af..3062a15 100644
>> --- a/drivers/iommu/intel_irq_remapping.c
>> +++ b/drivers/iommu/intel_irq_remapping.c
>> @@ -1136,7 +1136,7 @@ static void intel_ir_reconfigure_irte(struct irq_data 
>> *irqd, bool force)
>>  irte->dest_id = IRTE_DEST(cfg->dest_apicid);
>>  /* Update the hardware only if the interrupt is in remapped mode. */
>> -if (!force || ir_data->irq_2_iommu.mode == IRQ_REMAPPING)
>> +if (force || ir_data->irq_2_iommu.mode == IRQ_REMAPPING)
>>  modify_irte(_data->irq_2_iommu, irte);
>>  }
>>  
> 
> *ping*

*ping*

> ___
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH 24/61] iommu: simplify getting .drvdata

2018-04-19 Thread Wolfram Sang
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.

Signed-off-by: Wolfram Sang 
---

Build tested only. buildbot is happy. Please apply individually.

 drivers/iommu/qcom_iommu.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/qcom_iommu.c b/drivers/iommu/qcom_iommu.c
index 65b9c99707f8..fe88a4880d3a 100644
--- a/drivers/iommu/qcom_iommu.c
+++ b/drivers/iommu/qcom_iommu.c
@@ -885,16 +885,14 @@ static int qcom_iommu_device_remove(struct 
platform_device *pdev)
 
 static int __maybe_unused qcom_iommu_resume(struct device *dev)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct qcom_iommu_dev *qcom_iommu = platform_get_drvdata(pdev);
+   struct qcom_iommu_dev *qcom_iommu = dev_get_drvdata(dev);
 
return qcom_iommu_enable_clocks(qcom_iommu);
 }
 
 static int __maybe_unused qcom_iommu_suspend(struct device *dev)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct qcom_iommu_dev *qcom_iommu = platform_get_drvdata(pdev);
+   struct qcom_iommu_dev *qcom_iommu = dev_get_drvdata(dev);
 
qcom_iommu_disable_clocks(qcom_iommu);
 
-- 
2.11.0

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH 00/61] tree-wide: simplify getting .drvdata

2018-04-19 Thread Wolfram Sang
I got tired of fixing this in Renesas drivers manually, so I took the big
hammer. Remove this cumbersome code pattern which got copy-pasted too much
already:

-   struct platform_device *pdev = to_platform_device(dev);
-   struct ep93xx_keypad *keypad = platform_get_drvdata(pdev);
+   struct ep93xx_keypad *keypad = dev_get_drvdata(dev);

I send this out as one patch per directory per subsystem. I think they should
be applied individually. If you prefer a broken out series per subsystem, I can
provide this as well. Just mail me.

A branch (tested by buildbot; only with all commits squashed into one commit
before) can be found here:

git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git 
coccinelle/get_drvdata

Open for other comments, suggestions, too, of course.

Here is the cocci-script I created (after  iterations by manually checking
samples):

@@
struct device* d;
identifier pdev;
expression *ptr;
@@
(
-   struct platform_device *pdev = to_platform_device(d);
|
-   struct platform_device *pdev;
...
-   pdev = to_platform_device(d);
)
<... when != pdev
-   >dev
+   d
...>

ptr =
-   platform_get_drvdata(pdev)
+   dev_get_drvdata(d)

<... when != pdev
-   >dev
+   d
...>

Kind regards,

   Wolfram


Wolfram Sang (61):
  ARM: plat-samsung: simplify getting .drvdata
  ata: simplify getting .drvdata
  auxdisplay: simplify getting .drvdata
  bus: simplify getting .drvdata
  clk: samsung: simplify getting .drvdata
  crypto: simplify getting .drvdata
  dma: simplify getting .drvdata
  dmaengine: dw: simplify getting .drvdata
  dmaengine: qcom: simplify getting .drvdata
  gpio: simplify getting .drvdata
  gpu: drm: msm: simplify getting .drvdata
  gpu: drm: msm: adreno: simplify getting .drvdata
  gpu: drm: msm: disp: mdp5: simplify getting .drvdata
  gpu: drm: msm: dsi: simplify getting .drvdata
  gpu: drm: omapdrm: displays: simplify getting .drvdata
  gpu: drm: vc4: simplify getting .drvdata
  hid: simplify getting .drvdata
  iio: common: cros_ec_sensors: simplify getting .drvdata
  iio: common: hid-sensors: simplify getting .drvdata
  input: keyboard: simplify getting .drvdata
  input: misc: simplify getting .drvdata
  input: mouse: simplify getting .drvdata
  input: touchscreen: simplify getting .drvdata
  iommu: simplify getting .drvdata
  media: platform: am437x: simplify getting .drvdata
  media: platform: exynos4-is: simplify getting .drvdata
  media: platform: s5p-mfc: simplify getting .drvdata
  mmc: host: simplify getting .drvdata
  mtd: devices: simplify getting .drvdata
  mtd: nand: onenand: simplify getting .drvdata
  net: dsa: simplify getting .drvdata
  net: ethernet: cadence: simplify getting .drvdata
  net: ethernet: davicom: simplify getting .drvdata
  net: ethernet: smsc: simplify getting .drvdata
  net: ethernet: ti: simplify getting .drvdata
  net: ethernet: wiznet: simplify getting .drvdata
  perf: simplify getting .drvdata
  pinctrl: simplify getting .drvdata
  pinctrl: intel: simplify getting .drvdata
  platform: x86: simplify getting .drvdata
  power: supply: simplify getting .drvdata
  ptp: simplify getting .drvdata
  pwm: simplify getting .drvdata
  rtc: simplify getting .drvdata
  slimbus: simplify getting .drvdata
  spi: simplify getting .drvdata
  staging: greybus: simplify getting .drvdata
  staging: iio: adc: simplify getting .drvdata
  staging: nvec: simplify getting .drvdata
  thermal: simplify getting .drvdata
  thermal: int340x_thermal: simplify getting .drvdata
  thermal: st: simplify getting .drvdata
  tty: serial: simplify getting .drvdata
  uio: simplify getting .drvdata
  usb: mtu3: simplify getting .drvdata
  usb: phy: simplify getting .drvdata
  video: fbdev: simplify getting .drvdata
  video: fbdev: omap2: omapfb: displays: simplify getting .drvdata
  watchdog: simplify getting .drvdata
  net: dsa: simplify getting .drvdata
  ASoC: atmel: simplify getting .drvdata

 arch/arm/plat-samsung/adc.c|  3 +-
 drivers/ata/pata_samsung_cf.c  |  8 ++---
 drivers/auxdisplay/arm-charlcd.c   |  6 ++--
 drivers/bus/brcmstb_gisb.c | 12 +++
 drivers/clk/samsung/clk-s3c2410-dclk.c |  6 ++--
 drivers/crypto/exynos-rng.c|  6 ++--
 drivers/crypto/picoxcell_crypto.c  |  6 ++--
 drivers/dma/at_hdmac.c |  9 ++---
 drivers/dma/at_xdmac.c |  9 ++---
 drivers/dma/dw/platform.c  |  6 ++--
 drivers/dma/fsldma.c   |  6 ++--
 drivers/dma/idma64.c   |  6 ++--
 drivers/dma/qcom/hidma.c   |  3 +-
 drivers/dma/qcom/hidma_mgmt_sys.c  |  6 ++--
 drivers/dma/ste_dma40.c| 12 +++
 drivers/dma/txx9dmac.c |  8 ++---
 

[PATCH] iommu/iova: Update cached node pointer when current node fails to get any free IOVA

2018-04-19 Thread Ganapatrao Kulkarni
The performance drop is observed with long hours iperf testing using 40G
cards. This is mainly due to long iterations in finding the free iova
range in 32bit address space.

In current implementation for 64bit PCI devices, there is always first
attempt to allocate iova from 32bit(SAC preferred over DAC) address
range. Once we run out 32bit range, there is allocation from higher range,
however due to cached32_node optimization it does not suppose to be
painful. cached32_node always points to recently allocated 32-bit node.
When address range is full, it will be pointing to last allocated node
(leaf node), so walking rbtree to find the available range is not
expensive affair. However this optimization does not behave well when
one of the middle node is freed. In that case cached32_node is updated
to point to next iova range. The next iova allocation will consume free
range and again update cached32_node to itself. From now on, walking
over 32-bit range is more expensive.

This patch adds fix to update cached node to leaf node when there are no
iova free range left, which avoids unnecessary long iterations.

Signed-off-by: Ganapatrao Kulkarni 
---
 drivers/iommu/iova.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index 83fe262..e6ee2ea 100644
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
@@ -201,6 +201,12 @@ static int __alloc_and_insert_iova_range(struct 
iova_domain *iovad,
} while (curr && new_pfn <= curr_iova->pfn_hi);
 
if (limit_pfn < size || new_pfn < iovad->start_pfn) {
+   /* No more cached node points to free hole, update to leaf node.
+*/
+   struct iova *prev_iova;
+
+   prev_iova = rb_entry(prev, struct iova, node);
+   __cached_rbnode_insert_update(iovad, prev_iova);
spin_unlock_irqrestore(>iova_rbtree_lock, flags);
return -ENOMEM;
}
-- 
2.9.4

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v3 15/20] net: Remove depends on HAS_DMA in case of platform dependency

2018-04-19 Thread Kalle Valo
(adding linux-wireless)

Geert Uytterhoeven  writes:

> Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
> symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
> In most cases this other symbol is an architecture or platform specific
> symbol, or PCI.
>
> Generic symbols and drivers without platform dependencies keep their
> dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
> cannot work anyway.
>
> This simplifies the dependencies, and allows to improve compile-testing.
>
> Signed-off-by: Geert Uytterhoeven 
> Reviewed-by: Mark Brown 
> Acked-by: Robin Murphy 
> ---
> v3:
>   - Rebase to v4.17-rc1,
>   - Drop obsolete note about FSL_FMAN,
>
> v2:
>   - Add Reviewed-by, Acked-by,
>   - Drop RFC state,
>   - Split per subsystem.
> ---
>  drivers/net/ethernet/amd/Kconfig| 2 +-
>  drivers/net/ethernet/apm/xgene-v2/Kconfig   | 1 -
>  drivers/net/ethernet/apm/xgene/Kconfig  | 1 -
>  drivers/net/ethernet/arc/Kconfig| 6 --
>  drivers/net/ethernet/broadcom/Kconfig   | 2 --
>  drivers/net/ethernet/calxeda/Kconfig| 2 +-
>  drivers/net/ethernet/hisilicon/Kconfig  | 2 +-
>  drivers/net/ethernet/marvell/Kconfig| 8 +++-
>  drivers/net/ethernet/mellanox/mlxsw/Kconfig | 2 +-
>  drivers/net/ethernet/renesas/Kconfig| 2 --
>  drivers/net/wireless/broadcom/brcm80211/Kconfig | 1 -
>  drivers/net/wireless/quantenna/qtnfmac/Kconfig  | 2 +-
>  12 files changed, 12 insertions(+), 19 deletions(-)

For wireless:

Acked-by: Kalle Valo 

Leaving the hunks for linux-wireless list to see:

> diff --git a/drivers/net/wireless/broadcom/brcm80211/Kconfig 
> b/drivers/net/wireless/broadcom/brcm80211/Kconfig
> index 9d99eb42d9176f0f..6acba67bca07abd7 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/Kconfig
> +++ b/drivers/net/wireless/broadcom/brcm80211/Kconfig
> @@ -60,7 +60,6 @@ config BRCMFMAC_PCIE
>   bool "PCIE bus interface support for FullMAC driver"
>   depends on BRCMFMAC
>   depends on PCI
> - depends on HAS_DMA
>   select BRCMFMAC_PROTO_MSGBUF
>   select FW_LOADER
>   ---help---
> diff --git a/drivers/net/wireless/quantenna/qtnfmac/Kconfig 
> b/drivers/net/wireless/quantenna/qtnfmac/Kconfig
> index 025fa6018550895a..8d1492a90bd135c0 100644
> --- a/drivers/net/wireless/quantenna/qtnfmac/Kconfig
> +++ b/drivers/net/wireless/quantenna/qtnfmac/Kconfig
> @@ -7,7 +7,7 @@ config QTNFMAC
>  config QTNFMAC_PEARL_PCIE
>   tristate "Quantenna QSR10g PCIe support"
>   default n
> - depends on HAS_DMA && PCI && CFG80211
> + depends on PCI && CFG80211
>   select QTNFMAC
>   select FW_LOADER
>   select CRC32

-- 
Kalle Valo
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu