Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed

[Neo Jia]

On Mon, Jul 04, 2016 at 02:39:22PM +0800, Xiao Guangrong wrote:
> 
> 
> On 06/30/2016 09:01 PM, Paolo Bonzini wrote:
> >The vGPU folks would like to trap the first access to a BAR by setting
> >vm_ops on the VMAs produced by mmap-ing a VFIO device.  The fault handler
> >then can use remap_pfn_range to place some non-reserved pages in the VMA.
> 
> Why does it require fetching the pfn when the fault is triggered rather
> than when mmap() is called?

Hi Guangrong,

as such mapping information between virtual mmio to physical mmio is only 
available 
at runtime.

> 
> Why the memory mapped by this mmap() is not a portion of MMIO from
> underlayer physical device? If it is a valid system memory, is this interface
> really needed to implemented in vfio? (you at least need to set VM_MIXEDMAP
> if it mixed system memory with MMIO)
> 

It actually is a portion of the physical mmio which is set by vfio mmap.

> IIUC, the kernel assumes that VM_PFNMAP is a continuous memory, e.g, like
> current KVM and vaddr_get_pfn() in vfio, but it seems nvdia's patchset
> breaks this semantic as ops->validate_map_request() can adjust the physical
> address arbitrarily. (again, the name 'validate' should be changed to match
> the thing as it is really doing)

The vgpu api will allow you to adjust the target mmio address and the size via 
validate_map_request, but it is still physical contiguous as .

Thanks,
Neo

> 
> 

[PATCH 1/1] firmware: arm_scpi: add missing of_node_put after calling of_parse_phandle

[Peter Chen]

of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Besides, of_address_to_resource always returns -EINVAL for error, delete
the assignment for ret.

Signed-off-by: Peter Chen 
---
 drivers/firmware/arm_scpi.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
index 7e3e595..fbf10d1 100644
--- a/drivers/firmware/arm_scpi.c
+++ b/drivers/firmware/arm_scpi.c
@@ -683,9 +683,10 @@ static int scpi_probe(struct platform_device *pdev)
struct mbox_client *cl = &pchan->cl;
struct device_node *shmem = of_parse_phandle(np, "shmem", idx);
 
-   if (of_address_to_resource(shmem, 0, &res)) {
+   ret = of_address_to_resource(shmem, 0, &res);
+   of_node_put(shmem);
+   if (ret) {
dev_err(dev, "failed to get SCPI payload mem 
resource\n");
-   ret = -EINVAL;
goto err;
}
 
-- 
1.9.1

Re: linux-next: build failure after merge of the lightnvm tree

[Matias Bjørling]

On 07/04/2016 06:31 AM, Stephen Rothwell wrote:

Hi Matias,

On Thu, 30 Jun 2016 12:56:35 +1000 Stephen Rothwell  
wrote:


After merging the lightnvm tree, today's linux-next build (x86_64
allmodconfig) failed like this:

ERROR: "nvm_alloc_dev" [drivers/nvme/host/nvme-core.ko] undefined!
ERROR: "nvm_alloc_dev" [drivers/block/null_blk.ko] undefined!

Caused by commit

   3daf1adc80a8 ("lightnvm: let drivers control the lifetime of nvm_dev")

I have used the lightnvm tree from next-20160629 for today.


I am still getting this error.



Hi Stephen,

Sorry for the delay. The patch is removed for now.

Re: [PATCH v4 2/5]nbd: fix might_sleep warning on socket shutdown

[Pranay Srivastava]

On Thu, Jun 30, 2016 at 4:32 PM, Pranay Kr. Srivastava
 wrote:
> spinlocked ranges should be small and not contain calls into huge
> subfunctions. Fix my mistake and just get the pointer to the socket
> instead of doing everything with spinlock held.
>
> Reported-by: Mikulas Patocka 
> Signed-off-by: Markus Pargmann 
>
> Changelog:
> Pranay Kr. Srivastava:
>
> 1) Use spin_lock instead of irq version for sock_shutdown.
>
> 2) Use system work queue to actually trigger the shutdown of
> socket. This solves the issue when kernel_sendmsg is currently
> blocked while a timeout occurs.
>
> Signed-off-by: Pranay Kr. Srivastava 
> ---
>  drivers/block/nbd.c | 57 
> +
>  1 file changed, 36 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
> index 766c401..e362d44 100644
> --- a/drivers/block/nbd.c
> +++ b/drivers/block/nbd.c
> @@ -39,6 +39,7 @@
>  #include 
>
>  #include 
> +#include 
>
>  struct nbd_device {
> u32 flags;
> @@ -69,6 +70,8 @@ struct nbd_device {
>  #if IS_ENABLED(CONFIG_DEBUG_FS)
> struct dentry *dbg_dir;
>  #endif
> +   /* This is specifically for calling sock_shutdown, for now. */
> +   struct work_struct ws_shutdown;
>  };
>
>  #if IS_ENABLED(CONFIG_DEBUG_FS)
> @@ -95,6 +98,8 @@ static int max_part;
>   */
>  static DEFINE_SPINLOCK(nbd_lock);
>
> +static void nbd_ws_func_shutdown(struct work_struct *);
> +
>  static inline struct device *nbd_to_dev(struct nbd_device *nbd)
>  {
> return disk_to_dev(nbd->disk);
> @@ -172,39 +177,36 @@ static void nbd_end_request(struct nbd_device *nbd, 
> struct request *req)
>   */
>  static void sock_shutdown(struct nbd_device *nbd)
>  {
> -   spin_lock_irq(&nbd->sock_lock);
> -
> -   if (!nbd->sock) {
> -   spin_unlock_irq(&nbd->sock_lock);
> -   return;
> -   }
> +   struct socket *sock;
>
> -   dev_warn(disk_to_dev(nbd->disk), "shutting down socket\n");
> -   kernel_sock_shutdown(nbd->sock, SHUT_RDWR);
> -   sockfd_put(nbd->sock);
> +   spin_lock(&nbd->sock_lock);
> +   sock = nbd->sock;
> nbd->sock = NULL;
> -   spin_unlock_irq(&nbd->sock_lock);
> +   spin_unlock(&nbd->sock_lock);
> +
> +   if (!sock)
> +   return;
>
> del_timer(&nbd->timeout_timer);
> +   dev_warn(disk_to_dev(nbd->disk), "shutting down socket\n");
> +   kernel_sock_shutdown(sock, SHUT_RDWR);
> +   sockfd_put(sock);
>  }
>
>  static void nbd_xmit_timeout(unsigned long arg)
>  {
> struct nbd_device *nbd = (struct nbd_device *)arg;
> -   unsigned long flags;
>
> if (list_empty(&nbd->queue_head))
> return;
>
> -   spin_lock_irqsave(&nbd->sock_lock, flags);
> -
> nbd->timedout = true;
> -
> -   if (nbd->sock)
> -   kernel_sock_shutdown(nbd->sock, SHUT_RDWR);
> -
> -   spin_unlock_irqrestore(&nbd->sock_lock, flags);
> -
> +   /*
> +* Make sure sender thread sees nbd->timedout.
> +*/
> +   smp_wmb();
> +   schedule_work(&nbd->ws_shutdown);
> +   wake_up(&nbd->waiting_wq);
> dev_err(nbd_to_dev(nbd), "Connection timed out, shutting down 
> connection\n");
>  }
>
> @@ -588,7 +590,11 @@ static int nbd_thread_send(void *data)
> spin_unlock_irq(&nbd->queue_lock);
>
> /* handle request */
> -   nbd_handle_req(nbd, req);
> +   if (nbd->timedout) {
> +   req->errors++;
> +   nbd_end_request(nbd, req);
> +   } else
> +   nbd_handle_req(nbd, req);
> }
>
> nbd->task_send = NULL;
> @@ -663,6 +669,7 @@ static void nbd_reset(struct nbd_device *nbd)
> set_capacity(nbd->disk, 0);
> nbd->flags = 0;
> nbd->xmit_timeout = 0;
> +   INIT_WORK(&nbd->ws_shutdown, nbd_ws_func_shutdown);
> queue_flag_clear_unlocked(QUEUE_FLAG_DISCARD, nbd->disk->queue);
> del_timer_sync(&nbd->timeout_timer);
>  }
> @@ -797,11 +804,11 @@ static int __nbd_ioctl(struct block_device *bdev, 
> struct nbd_device *nbd,
> error = nbd_thread_recv(nbd, bdev);
> nbd_dev_dbg_close(nbd);
> kthread_stop(thread);
> +   sock_shutdown(nbd);
>
> mutex_lock(&nbd->tx_lock);
> nbd->task_recv = NULL;
>
> -   sock_shutdown(nbd);
> nbd_clear_que(nbd);
> kill_bdev(bdev);
> nbd_bdev_reset(bdev);
> @@ -857,6 +864,14 @@ static const struct block_device_operations nbd_fops = {
> .compat_ioctl = nbd_ioctl,
>  };
>
> +static void nbd_ws_func_shutdown(struct work_struct *ws_nbd)
> +{
> +   struct nbd_device *nbd_dev = container_of(ws_nbd, struct nbd_device,
> +   ws_shutdown);
> +
> +   sock_shutdown(nbd_dev);
> +}
> +
>  #if IS_ENABLED(CONFIG_DEBUG_FS)
>
>  static i

[alsa-devel] [PATCH] ASoC: bt-sco: add config prompt

[Garlic Tseng]

Add config prompt for bt-sco codec driver

Signed-off-by: Garlic Tseng 
---
 sound/soc/codecs/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index f2f8603..1cd6ab3 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -383,7 +383,7 @@ config SND_SOC_ALC5632
tristate
 
 config SND_SOC_BT_SCO
-   tristate
+   tristate "Dummy BT SCO codec driver"
 
 config SND_SOC_CQ0093VC
tristate
-- 
1.9.1

Re: [RESEND PATCH v2 0/5] ir-rx51 driver fixes

[Tony Lindgren]

* Tony Lindgren  [160622 21:47]:
> * Ivaylo Dimitrov  [160622 12:25]:
> > ir-rx51 is a driver for Nokia N900 IR transmitter. The current series
> > fixes the remaining problems in the driver:
> 
> Thanks for updating these.
> 
> Trierry, care to ack the PWM patch?
> 
> Mauro, do you want me to set up an immutable branch with all
> these against v4.7-rc1 that we can all merge as needed?
> 
> If you want to set up the branch instead, please feel free
> to add my ack.

OK so no comments from Mauro, so I've applied these with
Thierry's ack and pushed out into omap-for-v4.8/legacy branch.

Regards,

Tony

Re: [PATCH 1/1]ext4: Fix WARN_ON_ONCE when marking buffer dirty

[Pranay Srivastava]

On Thu, Jun 30, 2016 at 4:42 PM, Pranay Kr. Srivastava
 wrote:
> Signed-off-by: Pranay Kr. Srivastava 
> ---
>  fs/ext4/super.c | 30 --
>  1 file changed, 16 insertions(+), 14 deletions(-)
>
> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> index 3822a5a..8f10715 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -4327,20 +4327,6 @@ static int ext4_commit_super(struct super_block *sb, 
> int sync)
>
> if (!sbh || block_device_ejected(sb))
> return error;
> -   if (buffer_write_io_error(sbh)) {
> -   /*
> -* Oh, dear.  A previous attempt to write the
> -* superblock failed.  This could happen because the
> -* USB device was yanked out.  Or it could happen to
> -* be a transient write error and maybe the block will
> -* be remapped.  Nothing we can do but to retry the
> -* write and hope for the best.
> -*/
> -   ext4_msg(sb, KERN_ERR, "previous I/O error to "
> -  "superblock detected");
> -   clear_buffer_write_io_error(sbh);
> -   set_buffer_uptodate(sbh);
> -   }
> /*
>  * If the file system is mounted read-only, don't update the
>  * superblock write time.  This avoids updating the superblock
> @@ -4371,7 +4357,23 @@ static int ext4_commit_super(struct super_block *sb, 
> int sync)
> &EXT4_SB(sb)->s_freeinodes_counter));
> BUFFER_TRACE(sbh, "marking dirty");
> ext4_superblock_csum_set(sb);
> +   lock_buffer(sbh);
> +   if (buffer_write_io_error(sbh)) {
> +   /*
> +* Oh, dear.  A previous attempt to write the
> +* superblock failed.  This could happen because the
> +* USB device was yanked out.  Or it could happen to
> +* be a transient write error and maybe the block will
> +* be remapped.  Nothing we can do but to retry the
> +* write and hope for the best.
> +*/
> +   ext4_msg(sb, KERN_ERR, "previous I/O error to "
> +  "superblock detected");
> +   clear_buffer_write_io_error(sbh);
> +   set_buffer_uptodate(sbh);
> +   }
> mark_buffer_dirty(sbh);
> +   unlock_buffer(sbh);
> if (sync) {
> error = __sync_dirty_buffer(sbh,
> test_opt(sb, BARRIER) ? WRITE_FUA : WRITE_SYNC);
> --
> 1.9.1
>

Can this be reviewed as well please.


-- 
---P.K.S

[PATCH 1/1] gpu: drm: arcpgu_drv: add missing of_node_put after calling of_parse_phandle

[Peter Chen]

of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Signed-off-by: Peter Chen 
---
 drivers/gpu/drm/arc/arcpgu_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index 76e187a..b2c3c3b 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -155,6 +155,7 @@ static int arcpgu_load(struct drm_device *drm)
}
 
ret = arcpgu_drm_hdmi_init(drm, encoder_node);
+   of_node_put(encoder_node);
if (ret < 0)
return ret;
 
-- 
1.9.1

Re: [PATCH v4 14/22] sh: SH7751 core dtsi

[Geert Uytterhoeven]

Hi Sato-san,

On Wed, Jun 29, 2016 at 3:40 PM, Yoshinori Sato
 wrote:
> --- /dev/null
> +++ b/include/dt-bindings/clock/renesas-sh7750.h
> @@ -0,0 +1,26 @@
> +/*
> + * Copyright (C) 2016 Yoshinori Sato
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +#ifndef __DT_BINDINGS_CLOCK_RENESAS_SH7750_H__
> +#define __DT_BINDINGS_CLOCK_RENESAS_SH7750_H__
> +
> +#define SH7750_CLK_SCI 0
> +#define SH7750_CLK_RTC 1
> +#define SH7750_CLK_TMU02
> +#define SH7750_CLK_TMU13
> +#define SH7750_CLK_TMU24
> +#define SH7750_CLK_SCIF5
> +#define SH7750_CLK_DMAC6
> +#define SH7750_CLK_UBC 7
> +#define SH7750_CLK_SQ  8
> +#define SH7750_CLK_INTC 9
> +#define SH7750_CLK_TMU310
> +#define SH7750_CLK_TMU411
> +#define SH7750_CLK_PCIC12

Looking at the table in drivers/clk/sh/clk-sh7750cpg.c, SH7750_CLK_CORE seems
to be missing?

> +
> +#endif /* __DT_BINDINGS_CLOCK_RENESAS_CPG_MSSR_H__ */

Relic from the Renesas CPG/MSSR driver.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH v2] thermal: hwmon: EXPORT_SYMBOL_GPL for thermal hwmon sysfs

[Kuninori Morimoto]

From: Kuninori Morimoto 

thermal_add_hwmon_sysfs()/thermal_remove_hwmon_sysfs() need
EXPORT_SYMBOL_GPL(). Otherwise we will have ERROR

>> ERROR: "thermal_remove_hwmon_sysfs" [drivers/thermal/rcar_thermal.ko] 
>> undefined!
>> ERROR: "thermal_add_hwmon_sysfs" [drivers/thermal/rcar_thermal.ko] undefined!

Signed-off-by: Kuninori Morimoto 
---
v1 -> v2

 - EXPORT_SYMBOL -> EXPORT_SYMBOL_GPL

 drivers/thermal/thermal_hwmon.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/thermal/thermal_hwmon.c b/drivers/thermal/thermal_hwmon.c
index 06fd2ed9..c41c774 100644
--- a/drivers/thermal/thermal_hwmon.c
+++ b/drivers/thermal/thermal_hwmon.c
@@ -232,6 +232,7 @@ int thermal_add_hwmon_sysfs(struct thermal_zone_device *tz)
 
return result;
 }
+EXPORT_SYMBOL_GPL(thermal_add_hwmon_sysfs);
 
 void thermal_remove_hwmon_sysfs(struct thermal_zone_device *tz)
 {
@@ -270,3 +271,4 @@ void thermal_remove_hwmon_sysfs(struct thermal_zone_device 
*tz)
hwmon_device_unregister(hwmon->device);
kfree(hwmon);
 }
+EXPORT_SYMBOL_GPL(thermal_remove_hwmon_sysfs);
-- 
1.9.1

[PATCH 1/1] gpu: drm: exynos_hdmi: add missing of_node_put after calling of_parse_phandle

[Peter Chen]

of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Signed-off-by: Peter Chen 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 58de5a4..e9591c7 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1828,6 +1828,7 @@ static int hdmi_probe(struct platform_device *pdev)
DRM_ERROR("Failed to find ddc node in device tree\n");
return -ENODEV;
}
+   of_node_put(dev->of_node);
 
 out_get_ddc_adpt:
hdata->ddc_adpt = of_find_i2c_adapter_by_node(ddc_node);
@@ -1846,6 +1847,7 @@ out_get_ddc_adpt:
ret = -ENODEV;
goto err_ddc;
}
+   of_node_put(dev->of_node);
 
 out_get_phy_port:
if (hdata->drv_data->is_apb_phy) {
-- 
1.9.1

Re: Applied "ASoC: rockchip-max98090: Fix NULL pointer dereference while accessing to jack." to the asoc tree

[Enric Balletbo Serra]

Hi Mark,

2016-05-10 20:50 GMT+02:00 Mark Brown :
> The patch
>
>ASoC: rockchip-max98090: Fix NULL pointer dereference while accessing to 
> jack.
>
> has been applied to the asoc tree at
>
>git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
>
> All being well this means that it will be integrated into the linux-next
> tree (usually sometime in the next 24 hours) and sent to Linus during
> the next merge window (or sooner if it is a bug fix), however if
> problems are discovered then the patch may be dropped or reverted.
>

I just saw that these patches and the others in the patch series were
not applied yet. As are fixes and were accepted since middle May, I
expected see the patches merged in this release cycle, but we're at
rc6 so I suppose I'll need to wait to see them merged for 4.8 merge
window. Please can you coordinate with Heiko and make sure that these
patches were merged before he merges the patches to enable the audio
on Veyron? Otherwise we will break Veyron support for a while. I'd
really like have audio working on Veyron.

Thanks,
  Enric


> You may get further e-mails resulting from automated or manual testing
> and review of the tree, please engage with people reporting problems and
> send followup patches addressing any issues that are reported if needed.
>
> If any updates are required or you are submitting further changes they
> should be sent as incremental updates against current git, existing
> patches will not be replaced.
>
> Please add any relevant lists and maintainers to the CCs when replying
> to this mail.
>
> Thanks,
> Mark
>
> From af637e3adaf538288cbb3e6a2d9a4059853fc15a Mon Sep 17 00:00:00 2001
> From: Enric Balletbo i Serra 
> Date: Mon, 9 May 2016 12:46:31 +0200
> Subject: [PATCH] ASoC: rockchip-max98090: Fix NULL pointer dereference while
>  accessing to jack.
>
> Commit f2ed6b07645e ("ASoC: Make aux_dev more like a generic
> component") caused a regression on this driver, since now a
> kernel oops is seen when rockchip-mac98090 driver is loaded.
>
> That commit changed the probing of aux_devs before checking
> new DAI links, so for this driver rk_98090_headset_init is
> called before rk_init and then the kernel oops due a NULL
> pointer dereference inside rk_98090_headset_init function
> since there is a call that tries to access the jack pointer
> which has not been allocated yet.
>
> This is the call chain that causes the crash:
>
>  rk_98090_headset_init
>-> ts3a227e_enable_jack_detect
>   -> snd_jack_set_key
>  rk_init
>-> snd_soc_card_jack_new
>
> This patch moves the new jack object creation from rk_init
> to rk_98090_headset_init function making sure the jack is
> created before is accessed.
>
> Signed-off-by: Enric Balletbo i Serra 
> Signed-off-by: Mark Brown 
> ---
>  sound/soc/rockchip/rockchip_max98090.c | 50 
> ++
>  1 file changed, 27 insertions(+), 23 deletions(-)
>
> diff --git a/sound/soc/rockchip/rockchip_max98090.c 
> b/sound/soc/rockchip/rockchip_max98090.c
> index 543610282cdb..abb64a553967 100644
> --- a/sound/soc/rockchip/rockchip_max98090.c
> +++ b/sound/soc/rockchip/rockchip_max98090.c
> @@ -114,43 +114,27 @@ static int rk_aif1_hw_params(struct snd_pcm_substream 
> *substream,
> return ret;
>  }
>
> -static int rk_init(struct snd_soc_pcm_runtime *runtime)
> -{
> -   /* Enable Headset and 4 Buttons Jack detection */
> -   return snd_soc_card_jack_new(runtime->card, "Headset Jack",
> -  SND_JACK_HEADSET |
> -  SND_JACK_BTN_0 | SND_JACK_BTN_1 |
> -  SND_JACK_BTN_2 | SND_JACK_BTN_3,
> -  &headset_jack,
> -  headset_jack_pins,
> -  ARRAY_SIZE(headset_jack_pins));
> -}
> -
> -static int rk_98090_headset_init(struct snd_soc_component *component)
> -{
> -   return ts3a227e_enable_jack_detect(component, &headset_jack);
> -}
> -
>  static struct snd_soc_ops rk_aif1_ops = {
> .hw_params = rk_aif1_hw_params,
>  };
>
> -static struct snd_soc_aux_dev rk_98090_headset_dev = {
> -   .name = "Headset Chip",
> -   .init = rk_98090_headset_init,
> -};
> -
>  static struct snd_soc_dai_link rk_dailink = {
> .name = "max98090",
> .stream_name = "Audio",
> .codec_dai_name = "HiFi",
> -   .init = rk_init,
> .ops = &rk_aif1_ops,
> /* set max98090 as slave */
> .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
> SND_SOC_DAIFMT_CBS_CFS,
>  };
>
> +static int rk_98090_headset_init(struct snd_soc_component *component);
> +
> +static struct snd_soc_aux_dev rk_98090_headset_dev = {
> +   .name = "Headset Chip",
> +   .init = rk_98090_headset_init,
> +};
> +
>  static struct snd_soc_card snd_soc_card_rk = {
> .name = "ROCKCHIP-I2S",
> .owner = THIS_MODULE,
> @@ -166,6 +150,26 @@ static struct snd_soc_card snd_soc_car

Re: [PATCH] ARM: multi_v7_defconfig: add ACT8945A

[Nicolas Ferre]

Le 01/07/2016 22:26, Alexandre Belloni a écrit :
> ACT8945A is the PMIC present on the sama5d2 Xplained.
> 
> Signed-off-by: Alexandre Belloni 

Acked-by: Nicolas Ferre 

> ---
>  arch/arm/configs/multi_v7_defconfig | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/configs/multi_v7_defconfig 
> b/arch/arm/configs/multi_v7_defconfig
> index 8f857564657f..94c22b05e744 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -403,6 +403,7 @@ CONFIG_GPIO_PALMAS=y
>  CONFIG_GPIO_SYSCON=y
>  CONFIG_GPIO_TPS6586X=y
>  CONFIG_GPIO_TPS65910=y
> +CONFIG_BATTERY_ACT8945A=y
>  CONFIG_BATTERY_SBS=y
>  CONFIG_BATTERY_MAX17040=m
>  CONFIG_BATTERY_MAX17042=m
> @@ -448,6 +449,7 @@ CONFIG_MESON_WATCHDOG=y
>  CONFIG_DW_WATCHDOG=y
>  CONFIG_DIGICOLOR_WATCHDOG=y
>  CONFIG_BCM2835_WDT=y
> +CONFIG_MFD_ACT8945A=y
>  CONFIG_MFD_AS3711=y
>  CONFIG_MFD_AS3722=y
>  CONFIG_MFD_ATMEL_FLEXCOM=y
> @@ -477,6 +479,7 @@ CONFIG_MFD_TPS65217=y
>  CONFIG_MFD_TPS65218=y
>  CONFIG_MFD_TPS6586X=y
>  CONFIG_MFD_TPS65910=y
> +CONFIG_REGULATOR_ACT8945A=y
>  CONFIG_REGULATOR_AB8500=y
>  CONFIG_REGULATOR_ACT8865=y
>  CONFIG_REGULATOR_AS3711=y
> 


-- 
Nicolas Ferre

Re: [PATCH 3/3] mm/page_owner: track page free call chain

[Joonsoo Kim]

On Mon, Jul 04, 2016 at 02:45:24PM +0900, Sergey Senozhatsky wrote:
> On (07/04/16 14:29), Joonsoo Kim wrote:
> > > > On Sun, Jul 03, 2016 at 01:16:56AM +0900, Sergey Senozhatsky wrote:
> > > > > Introduce PAGE_OWNER_TRACK_FREE config option to extend page owner 
> > > > > with
> > > > > free_pages() tracking functionality. This adds to the 
> > > > > dump_page_owner()
> > > > > output an additional backtrace, that tells us what path has freed the
> > > > > page.
> > > > 
> > > > Hmm... Do you have other ideas to use this feature? Following example is
> > > > just to detect use-after-free and we have other good tools for it
> > > > (KASAN or DEBUG_PAGEALLOC) so I'm not sure whether it's useful or not.
> > > 
> > > there is no kasan for ARM32, for example (apart from the fact that
> > > it's really hard to use kasan sometimes due to its cpu cycles and
> > > memory requirements).
> > 
> > Hmm... for debugging purpose, KASAN provides many more things so IMO it's
> > better to implement/support KASAN in ARM32 rather than expand
> > PAGE_OWNER for free.
> > 
> 
> hm, the last time I checked kasan didn't catch that extra put_page() on

Indeed. It seems that kasan only catch double-free of slab object.

> x86_64. AFAIK, kasan on ARM32 is a bit hard to do properly
> http://www.serverphorums.com/read.php?12,1206479,1281087#msg-1281087

Okay.

> I've played with kasan on arm32 (an internal custom version)... and
> extended page_owner turned out to be *incomparably* easier and faster
> to use (especially paired with stackdepot).

Okay.

> 
> > > educate me, will DEBUG_PAGEALLOC tell us what path has triggered the
> > > extra put_page()? hm... does ARM32 provide ARCH_SUPPORTS_DEBUG_PAGEALLOC?
> > 
> > Hmm... Now, I notice that PAGE_OWNER_TRACK_FREE will detect
> > double-free rather than use-after-free.
> 
> well, yes. current hits bad_page(), page_owner helps to find out who
> stole and spoiled it from under current.
> 
> CPU a CPU b
> 
>   alloc_page()
>   put_page() << legitimate
>   alloc_page()
> err:
>   put_page() << legitimate, again.
>  << but is actually buggy.
> 
>   put_page() << double 
> free. but we need
>  << to report 
> put_page() from
>  << CPU a.

Okay. I think that this patch make finding offending user easier
but it looks like it is a partial solution to detect double-free.
See following example.

CPU a   CPU b

alloc_page()
put_page() << legitimate
alloc_page()
err:
put_page() << legitimate, again.
   << but is actually buggy.

alloc_page()

put_page() <<
legitimate,
again.
put_page() << Will report the bug and
page_owner have legitimate call stack.

In kasan, quarantine is used to provide some delay for real free and
it makes use-after-free detection more robust. Double-free also can be
benefit from it. Anyway, I will not object more since it looks
the simplest way to improve doublue-free detection for the page
at least for now.

Thanks.

Re: [PATCH 2/3] iio: adc: add support for Allwinner SoCs ADC

[Quentin Schulz]

On 03/07/2016 17:43, Guenter Roeck wrote:
> On 07/03/2016 04:54 AM, Jonathan Cameron wrote:
>> On 28/06/16 09:18, Quentin Schulz wrote:
>>> The Allwinner SoCs all have an ADC that can also act as a touchscreen
>>> controller and a thermal sensor. This patch adds the ADC driver which is
>>> based on the MFD for the same SoCs ADC.
>>>
>>> This also registers the thermal adc channel in the iio map array so
>>> iio_hwmon could use it without modifying the Device Tree.
>>>
>>> This driver probes on three different platform_device_id to take into
>>> account slight differences between Allwinner SoCs ADCs.
>>>
>>> Signed-off-by: Quentin Schulz 
>> Hi Quentin.
>>
>> I'm a bit in two minds about some of this.  That temperature sensor is
>> so obviously meant for hwmon purposes, I'm tempted to suggest it might
>> actually make sense to put it directly in hwmon rather than using the
>> bridge.  That obviously makes it less flexible in some ways (i.e. for
>> use within the thermal subsystem at some point).
>>
>> Guenter, what do you think?
>>
> 
> With the upcoming new hwmon API, thermal registration is handled in the
> hwmon core, so that should not be an issue. Besides, other hwmon sensors
> already register with the thermal subsystem as well.
> 
> This is difficult to evaluate without datasheet; I am not sure if
> the chip supports limits or trip points. If it supports trip points,
> thermal may be a better target.
> 
> Overall it does look like the temperature sensor would warrant
> a separate driver. Only question is thermal or hwmon.
> 
> Guenter

Actually, the publicly available documentation for the temperature
sensor is almost inexistent. We only have the registers for it. For most
of the work on temperature sensor, it has been taken from the current
driver (sun4i-ts in input/touschreen) from Hans de Goede.

You can find the documentation here:
http://dl.linux-sunxi.org/A10/A10%20User%20manual%20V1.50.pdf
http://dl.linux-sunxi.org/A13/A13%20User%20Manual%20V1.30.pdf
http://dl.linux-sunxi.org/A31/A31%20User%20Manual%20V1.20.pdf

The ADC is either called TP controller, Touch Panel controller or GPADC.
The temperature sensor's registers are only defined in the User Manual
of the A10 (first link).

Nothing to be found for limits or trip points I think.

Quentin

>> I'm guessing detailed docs for this part aren't avaiable publicly? :(
>>
>> So the rest of my comments are kind of predicated on me having roughtly
>> understood how this device works from the structure of the driver.
>>
>> The temperature sensor is really effectively as separate ADC?
>> The main interest in this is for key detection?
>>
>> Anyhow, if the data flow for the temperatures sensor is not synced with
>> the other ADC channels, adding buffered (pushed) output from the
>> driver in
>> future will be fiddly and with a 250Hz device you'll probably want it.
>> Basically IIO buffered supports assumes each iio device will sample data
>> at a particular frequency. If channels are not synchronized in that
>> fashion
>> then you have to register multiple devices or only pick a subset of
>> channels
>> to export.
>>
>> For the key detection you have already observed that IIO needs some
>> additions to be able to have consumers of what we term 'events' e.g.
>> threshold
>> interrupts.
>>
>> Looking at the lradc-keys driver in tree, it looks like we only really
>> have
>> really simple threshold interrups - configured to detect a very low
>> voltage?
>> + only one per channel.
>>
>> So not too nasty a case, but you are right some work is needed in IIO as
>> we simply don't have a means of passing these on as yet or configuring
>> them
>> from in kernel consumers.
>> If we take the easy route and don't demux incoming events then it
>> shouldn't
>> be too hard to add (demux can follow later).  Hence any client device
>> can try
>> to enable events it wants, but may get events that other client
>> devices wanted
>> as well.
>>
>> Config interface should be much the same as the write support for
>> channels.
>> Data flow marginally harder, but pretty much a list of callbacks within
>> iio_push_event.
>>
>> Not trivial, but not too tricky either.
>>
>> The events subsystem has a few 'limitations' we need to address long term
>> but as this is in kernel interface only, we can do this now and fix stuff
>> up in future without any ABI breakage. (limitations are things like only
>> one event of a given type and direction per channel - main challenge on
>> that is finding a way of doing it without abi breakage).
>>
>> Anyhow, sounds fun - wish I had the time to do it myself!
>>
>> Otherwise, your remove is never going to work as indio_dev is always
>> NULL.
>>
>> Jonathan
>>
>>> ---
>>>   drivers/iio/adc/Kconfig   |  12 ++
>>>   drivers/iio/adc/Makefile  |   1 +
>>>   drivers/iio/adc/sunxi-gpadc-iio.c | 371
>>> ++
>>>   3 files changed, 384 insertions(+)
>>>   create mode 100644 drivers/iio/adc/sunxi-gpadc-iio.c

[PATCH] ARM: defconfig/at91: Add Bosch M_CAN driver

[Wenyou Yang]

Add CONFIG_CAN_M_CAN=y option to enable Bosch M_CAN device driver.

Signed-off-by: Wenyou Yang 
---

 arch/arm/configs/sama5_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/sama5_defconfig b/arch/arm/configs/sama5_defconfig
index 9cb1a85..dcde44ff 100644
--- a/arch/arm/configs/sama5_defconfig
+++ b/arch/arm/configs/sama5_defconfig
@@ -52,6 +52,7 @@ CONFIG_IP_PNP_RARP=y
 CONFIG_IPV6_SIT_6RD=y
 CONFIG_CAN=y
 CONFIG_CAN_AT91=y
+CONFIG_CAN_M_CAN=y
 CONFIG_CFG80211=y
 CONFIG_MAC80211=y
 CONFIG_MAC80211_LEDS=y
-- 
2.7.4

Re: [PATCH 1/5] lockdep: Implement bitlock map allocator

[Byungchul Park]

On Fri, Jul 01, 2016 at 09:53:12AM +0200, Peter Zijlstra wrote:
> On Fri, Jul 01, 2016 at 09:24:44AM +0900, Byungchul Park wrote:
> > On Thu, Jun 30, 2016 at 02:59:19PM +0200, Peter Zijlstra wrote:
> > > On Mon, Jun 20, 2016 at 01:55:11PM +0900, Byungchul Park wrote:
> > > 
> > > > +struct bitlock_map {
> > > > +   struct hlist_node   hash_entry;
> > > > +   unsigned long   bitaddr; /* ID */
> > > > +   struct lockdep_map  map;
> > > > +   int ref; /* reference count */
> > > > +};
> > > 
> > > So this is effectively bigger than just adding a struct lockdep_map into
> > > whatever structure holds the bit spinlock to begin with.
> > > 
> > > What is the gain?
> > 
> > 1. I don't want to make being aware of lockdep essential to user of
> >bit-base lock, like spin lock, mutex, semaphore ans so on. In other
> >words, I want to make it work transparently.
> 
> I want to discourage the use of bitlocks, they stink.

I agree it has some problems. But someone who are sensive to memory
consumption still need to use bit-based lock. Right?

I can stop this proposal because it's meaningless if bit-based lock can be
removed entirely since any requirement for bit-based lock does not exist
at all. But IMHO, it's worthy if the requirement be.

> bitlocks must by their constraint be a test-and-set lock, with all the
> known problems those have. It also means they're a royal pain for -rt.

I also think it's better to use rather spinlock in most cases unless memory
consumption is critical problem. But in the case memory consumption is
critical... what can we do?

> Yes, there are a number of places we use them, but people should think
> very carefully before they use them and consider all these issues. But
> the problem seems to be that people aren't even aware there's problems.
> 
> > 2. Bit-base lock can be used with any data type which can be seperately,
> >not within a structure. I mean sometimes it can be ugly to pack the
> >lock bit and lockdep_map instance explicitly.
> 
> Yuck, people do this?
> 
> > 3. I think this is more general approach because _any_ random bit in 
> >memory can be used as a lock. Do we need to restrict where the bit
> >is so that we can place lockdep_map explicitly around the bit?
> 
> Again, yuck!

You mean we should never provide lockdep checking mechanism tranparently,
but the user of bit-based lock must add lockdep_map manually, case by
case. Right? Do I understand correctly? If so, I wonder why?

> > > > +static inline unsigned long get_bitaddr(int bitnum, unsigned long 
> > > > *addr)
> > > > +{
> > > > +   return (unsigned long)((char *)addr + bitnum);
> > > > +}
> > > 
> > > And given you keep these lockdep_map thingies out-of-line, the original
> > > structure remains dense and thus the above munging can easily result in
> > > collisions.
> > 
> > I am sorry. I don't understand what you said exactly. 
> 
> 
> #define FOO_FLAG_LOCK 8
> 
> struct foo {
>   struct hlist_bl_head head;
>   unsigned long flags;
> };
> 
> struct foo bar[];
> 
> 
> That structure has 2 bitlocks in, one at:
> 
>   0 bytes + 0 bits
>   8 bytes + 8 bits
> 
> In this case:
> 
>   get_bitaddr(8, &bar[0].flags) == get_bitaddr(0, &bar[1].head)
> 
> Which is a collision and fail, because they're two different lock
> classes.

OOPS! What a fool I was. That's my mistake. I can fix it. Sorry.

Re: [PATCH] perf/core: Fix the mask in perf_output_sample_regs

[Yury Norov]

On Sun, Jul 03, 2016 at 11:31:58PM +0530, Madhavan Srinivasan wrote:
> When decoding the perf_regs mask in perf_output_sample_regs(),
> we loop through the mask using find_first_bit and find_next_bit functions.
> While the exisitng code works fine in most of the case,
> the logic is broken for 32bit kernel (Big Endian).
> When reading u64 mask using (u32 *)(&val)[0], find_*_bit() assumes it gets
> lower 32bits of u64 but instead gets upper 32bits which is wrong.
> Proposed fix is to swap the words of the u64 to handle this case.
> This is _not_ endianness swap.


In fact, it's broken for 32-bit LE as well if mask is zero and next
word on stack is not zero. The rest is OK.

Reviewed-by: Yury Norov 

> 
> Suggested-by: Yury Norov 
> Cc: Yury Norov 
> Cc: Peter Zijlstra 
> Cc: Ingo Molnar 
> Cc: Arnaldo Carvalho de Melo 
> Cc: Alexander Shishkin 
> Cc: Jiri Olsa 
> Cc: Michael Ellerman 
> Signed-off-by: Madhavan Srinivasan 
> ---
>  include/linux/bitmap.h |  2 ++
>  kernel/events/core.c   |  4 +++-
>  lib/bitmap.c   | 19 +++
>  3 files changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
> index e9b0b9ab07e5..d95b422db183 100644
> --- a/include/linux/bitmap.h
> +++ b/include/linux/bitmap.h
> @@ -188,6 +188,8 @@ extern int bitmap_print_to_pagebuf(bool list, char *buf,
>  #define small_const_nbits(nbits) \
>   (__builtin_constant_p(nbits) && (nbits) <= BITS_PER_LONG)
>  
> +extern void bitmap_from_u64(unsigned long *dst, u64 mask);
> +
>  static inline void bitmap_zero(unsigned long *dst, unsigned int nbits)
>  {
>   if (small_const_nbits(nbits))
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 9c51ec3f0f44..613fec95ea4c 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -5205,8 +5205,10 @@ perf_output_sample_regs(struct perf_output_handle 
> *handle,
>   struct pt_regs *regs, u64 mask)
>  {
>   int bit;
> + DECLARE_BITMAP(_mask, 64);
>  
> - for_each_set_bit(bit, (const unsigned long *) &mask,
> + bitmap_from_u64(_mask, mask);
> + for_each_set_bit(bit, _mask,
>sizeof(mask) * BITS_PER_BYTE) {
>   u64 val;
>  
> diff --git a/lib/bitmap.c b/lib/bitmap.c
> index c66da508cbf7..522f1b4c6078 100644
> --- a/lib/bitmap.c
> +++ b/lib/bitmap.c
> @@ -1170,3 +1170,22 @@ void bitmap_copy_le(unsigned long *dst, const unsigned 
> long *src, unsigned int n
>  }
>  EXPORT_SYMBOL(bitmap_copy_le);
>  #endif
> +
> +/*
> + * bitmap_from_u64 - Check and swap words within u64.
> + *  @mask: source bitmap
> + *  @dst:  destination bitmap
> + *
> + * In 32bit Big Endian kernel, when using (u32 *)(&val)[*]
> + * to read u64 mask, we will get wrong word.
> + * That is "(u32 *)(&val)[0]" gets upper 32 bits,
> + * but expected could be lower 32bits of u64.
> + */
> +void bitmap_from_u64(unsigned long *dst, u64 mask)
> +{
> + dst[0] = mask & ULONG_MAX;
> +
> + if (sizeof(mask) > sizeof(unsigned long))
> + dst[1] = mask >> 32;
> +}
> +EXPORT_SYMBOL(bitmap_from_u64);
> -- 
> 1.9.1

Re: [PATCH] Exchange the Assignments of `MEMORYs' and `CFGs/IOs' in Designware PCIe Driver

[dongbo (E)]

On 2016/7/3 23:27, Pratyush Anand wrote:
> On Tue, Jun 28, 2016 at 1:42 PM, dongbo (E)  wrote:
>>
>> From: Dong Bo 
>>
>> In designware PCIe driver, the iatu0 is used for both CFG and IO accesses.
>> When sending CFGs to peripherals (e.g. lspci), iatu0 frequently switches
>> between CFG and IO alternatively.
>>
>> A MEMORY probably be sent as an IOs by mistake. Considering the following
>> configurations:
>> MEMORY  ->  BASE_ADDR: 0xb410, LIMIT: 0xb4100FFF, TYPE=mem
>> CFG ->  BASE_ADDR: 0xb400, LIMIT: 0xb4000FFF, TYPE=cfg
>> IO  ->  BASE_ADDR: 0x, LIMIT: 0xFFFE, TYPE=io
>>
>> Suppose PCIe has just completed a CFG access, to switch back to IO, it set
>> the BASE_ADDR to 0x, LIMIT 0xFFFE and TYPE to io. When another
>> CFG comes, the BASE_ADDR is set to 0xb400 to switch to CFG. At this
>> moment, a MEMORY access shows up, since it matches with iatu0
>> (due to 0xb400 <= MEMORY BASE_ADDR <= MEMORY LIMIE <= 0xFFF), it
>> is treated as an IO access by mistake, then sent to perpheral.
>>
>> This patch fixes the problem by exchanging the assignments of `MEMORYs'
>> and `CFGs/IOs', which assigning MEMEORYs to iatu0, CFGs and IOs to iatu1.
> 
> 
> Had a re-thought on it. While it will fix wrong memory access in your
> case, it can still cause issues with IO access for some other
> platform.
> 
> Can you please test [1] and check it that works for you. You will need
> to define num-viewport in your device tree file.
> 
> ~Pratyush
> 
> [1] 
> https://github.com/pratyushanand/linux/commit/131b83ea7db0834d77ee5df65c6696bccbf8a1ce
> 
> .
> 

Checked, it works for us.

I think it would be better to exchange the assignments of MEMORYs and
CFGs/IOs when num_viewports <= 2, cause it fixes wrong memory access.

As you mentioned, other corner point for failure is still there while
there are only two viewports. It seems that there is not a perfect
solution.

Best Regards
Dong Bo

Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed

[Paolo Bonzini]

On 04/07/2016 08:39, Xiao Guangrong wrote:
> Why the memory mapped by this mmap() is not a portion of MMIO from
> underlayer physical device? If it is a valid system memory, is this
> interface
> really needed to implemented in vfio? (you at least need to set VM_MIXEDMAP
> if it mixed system memory with MMIO)

The KVM code does not care if VM_MIXEDMAP is set or not, it works in
either case.

Paolo

> IIUC, the kernel assumes that VM_PFNMAP is a continuous memory, e.g, like
> current KVM and vaddr_get_pfn() in vfio, but it seems nvdia's patchset
> breaks this semantic as ops->validate_map_request() can adjust the physical
> address arbitrarily. (again, the name 'validate' should be changed to match
> the thing as it is really doing)
> 
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

NFS4 Client hangs when copying large files as of kernel version 4.4

[Bünnemann , Thomas]

NFS4 Client hangs when copying large files as of kernel version 4.4 

Full description of the problem/report: 
When doing simple copy-jobs with large files (f.ex. partition Images > 4
GByte filesize) the file transfer stalls after about 2 -16 GByte has passed
to the NFS-client.
No problems using kernel-versions up to kernel 4.2. 

Autonegotiated NFS-mount-values are still the same between 4.2 and
4.4/4.7rc5

server:/informatik/ab on /informatik/ab type nfs4
(rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,
port=0,timeo=600,retrans=2,sec=krb5,clientaddr=134.100.9.19,local_lock=none,
addr=XXX.XXX.XXX.XXX)

Keywords (i.e., modules, networking, kernel): 

Kernel version (from /proc/version): 
Linux version 4.7.0-040700rc5-generic (kernel@tangerine) (gcc version 5.4.0
20160609 (Ubuntu 5.4.0-4ubuntu1) ) #201606262232 SMP Mon Jun 27 02:34:07 UTC
2016


A small shell script or example program which triggers the problem: 
/informatik/ab/backup/ contains 8 files - each about 4Gbyte in size, simple
command:
'cp /informatik/ab/backup/*.ghs /tmp'


Regards,

Thomas Bünnemann
Universität Hamburg, FB Informatik
Rechenzentrum
Vogt-Kölln-Str. 30
22527 Hamburg

Tel.: ++49 40 42883-2278
Fax: ++49 40 42883-2241



smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed

[Xiao Guangrong]

On 07/04/2016 03:03 PM, Neo Jia wrote:

On Mon, Jul 04, 2016 at 02:39:22PM +0800, Xiao Guangrong wrote:



On 06/30/2016 09:01 PM, Paolo Bonzini wrote:

The vGPU folks would like to trap the first access to a BAR by setting
vm_ops on the VMAs produced by mmap-ing a VFIO device.  The fault handler
then can use remap_pfn_range to place some non-reserved pages in the VMA.


Why does it require fetching the pfn when the fault is triggered rather
than when mmap() is called?


Hi Guangrong,

as such mapping information between virtual mmio to physical mmio is only 
available
at runtime.


Sorry, i do not know what the different between mmap() and the time VM actually
accesses the memory for your case. Could you please more detail?





Why the memory mapped by this mmap() is not a portion of MMIO from
underlayer physical device? If it is a valid system memory, is this interface
really needed to implemented in vfio? (you at least need to set VM_MIXEDMAP
if it mixed system memory with MMIO)



It actually is a portion of the physical mmio which is set by vfio mmap.


So i do not think we need to care its refcount, i,e, we can consider it as 
reserved_pfn,
Paolo?




IIUC, the kernel assumes that VM_PFNMAP is a continuous memory, e.g, like
current KVM and vaddr_get_pfn() in vfio, but it seems nvdia's patchset
breaks this semantic as ops->validate_map_request() can adjust the physical
address arbitrarily. (again, the name 'validate' should be changed to match
the thing as it is really doing)


The vgpu api will allow you to adjust the target mmio address and the size via
validate_map_request, but it is still physical contiguous as .


Okay, the interface confused us, maybe this interface need to be cooked to 
reflect
to this fact.

Thanks!

Re: [PATCH v003] Added support for gcc version >= 6

[Peter Oberparleiter]

On 01.07.2016 18:26, Joe Perches wrote:
> On Fri, 2016-07-01 at 15:09 +0200, Florian Meier wrote:
>> Added support for gcc version >= 6 in gcov.
> 
> It's important to mention the subsystem in the patch subject
> 
> e.g. "Subject: [PATCH V3] gcov: Support gcc version >= 6"

Thanks for pointing this out - I completely missed that this was lost
between v2 and v3 of the patch. Should we re-post or can this be fixed
another way?

-- 
Peter Oberparleiter
Linux on z Systems Development - IBM Germany

RE: [PATCH 2/7] arm: mach-shmobile: pm-rmobile: add missing of_node_put after calling of_parse_phandle

[Peter Chen]

 
>On Fri, Jul 1, 2016 at 11:41 AM, Peter Chen  wrote:
>> of_node_put needs to be called when the device node which is got from
>> of_parse_phandle has finished using.
>>
>> Cc: Simon Horman 
>> Cc: Magnus Damm 
>> Signed-off-by: Peter Chen 
>
>NAKed-by: Geert Uytterhoeven 
>
>> --- a/arch/arm/mach-shmobile/pm-rmobile.c
>> +++ b/arch/arm/mach-shmobile/pm-rmobile.c
>> @@ -209,6 +209,7 @@ static void __init add_special_pd(struct device_node *np,
>enum pd_types type)
>> special_pds[num_special_pds].pd = pd;
>
>The pd pointer is stored in the line above, and released later in 
>put_special_pds().
>
>> special_pds[num_special_pds].type = type;
>> num_special_pds++;
>> +   of_node_put(pd);
>
>Hence it must not be released here, as that would cause a double release when
>put_special_pds() is executed.
>

Thanks, Geert, it is my careless.

Please forget this patch.

Peter

Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed

[Xiao Guangrong]

On 07/04/2016 03:38 PM, Paolo Bonzini wrote:



On 04/07/2016 08:39, Xiao Guangrong wrote:

Why the memory mapped by this mmap() is not a portion of MMIO from
underlayer physical device? If it is a valid system memory, is this
interface
really needed to implemented in vfio? (you at least need to set VM_MIXEDMAP
if it mixed system memory with MMIO)


The KVM code does not care if VM_MIXEDMAP is set or not, it works in
either case.


Yes, it is. I mean nvdia's vfio patchset should use VM_MIXEDMAP if the memory
is mixed. :)

[patch] drm/tegra: sor: Double free on error

[Dan Carpenter]

"brick" is allocated with devm_kzalloc() so freeing it with kfree()
leads to a double free.  We can just delete it.

Fixes: a7ba8310c7f5 ('drm/tegra: sor: Implement sor1_brick clock')
Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 8425eda..e750ced 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -345,7 +345,6 @@ static struct clk *tegra_clk_sor_brick_register(struct 
tegra_sor *sor,
 {
struct tegra_clk_sor_brick *brick;
struct clk_init_data init;
-   struct clk *clk;
 
brick = devm_kzalloc(sor->dev, sizeof(*brick), GFP_KERNEL);
if (!brick)
@@ -361,11 +360,7 @@ static struct clk *tegra_clk_sor_brick_register(struct 
tegra_sor *sor,
 
brick->hw.init = &init;
 
-   clk = devm_clk_register(sor->dev, &brick->hw);
-   if (IS_ERR(clk))
-   kfree(brick);
-
-   return clk;
+   return devm_clk_register(sor->dev, &brick->hw);
 }
 
 static int tegra_sor_dp_train_fast(struct tegra_sor *sor,

[PATCH 1/1] gpn: drm: fsl_tcon: add missing of_node_put after calling of_parse_phandle

[Peter Chen]

of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using, but current code only
calls it at error path, fix it by adding it at correct code path.

Signed-off-by: Peter Chen 
---
 drivers/gpu/drm/fsl-dcu/fsl_tcon.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_tcon.c 
b/drivers/gpu/drm/fsl-dcu/fsl_tcon.c
index bbe34f1..bca09ea 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_tcon.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_tcon.c
@@ -92,6 +92,7 @@ struct fsl_tcon *fsl_tcon_init(struct device *dev)
goto err_node_put;
}
 
+   of_node_put(np);
clk_prepare_enable(tcon->ipg_clk);
 
dev_info(dev, "Using TCON in bypass mode\n");
-- 
1.9.1

Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed

[Paolo Bonzini]

On 04/07/2016 09:37, Xiao Guangrong wrote:
>>>
>>
>> It actually is a portion of the physical mmio which is set by vfio mmap.
> 
> So i do not think we need to care its refcount, i,e, we can consider it
> as reserved_pfn,
> Paolo?

nVidia provided me (offlist) with a simple patch that modified VFIO to
exhibit the problem, and it didn't use reserved PFNs.  This is why the
commit message for the patch is not entirely accurate.

But apart from this, it's much more obvious to consider the refcount.
The x86 MMU code doesn't care if the page is reserved or not;
mmu_set_spte does a kvm_release_pfn_clean, hence it makes sense for
hva_to_pfn_remapped to try doing a get_page (via kvm_get_pfn) after
invoking the fault handler, just like the get_user_pages family of
function does.

Paolo

Re: [PATCH] clkdev: add devm_of_clk_get()

[Arnd Bergmann]

On Monday, July 4, 2016 1:04:30 AM CEST Kuninori Morimoto wrote:
> @@ -501,6 +503,11 @@ static inline struct clk *of_clk_get(struct device_node 
> *np, int index)
>  {
> return ERR_PTR(-ENOENT);
>  }
> +struct clk *devm_of_clk_get(struct device *dev,
> +   struct device_node *np, int index)
> +{
> +   return ERR_PTR(-ENOENT);
> +}
>  static inline struct clk *of_clk_get_by_name(struct device_node *np,
>  const char *name)
>  {
> -- 
> 

This is missing "static inline" as found by the bot.

Arnd

Re: [PATCH 3/3] mm/page_owner: track page free call chain

[Sergey Senozhatsky]

On (07/04/16 16:29), Joonsoo Kim wrote:
[..]
> > well, yes. current hits bad_page(), page_owner helps to find out who
> > stole and spoiled it from under current.
> > 
> > CPU a   CPU b
> > 
> > alloc_page()
> > put_page() << legitimate
> > alloc_page()
> > err:
> > put_page() << legitimate, again.
> ><< but is actually buggy.
> > 
> > put_page() << double 
> > free. but we need
> ><< to report 
> > put_page() from
> ><< CPU a.
> 
> Okay. I think that this patch make finding offending user easier
> but it looks like it is a partial solution to detect double-free.
> See following example.
> 
> CPU a CPU b
> 
>   alloc_page()
>   put_page() << legitimate
>   alloc_page()
> err:
>   put_page() << legitimate, again.
>  << but is actually buggy.
> 
>   alloc_page()
> 
>   put_page() <<
>   legitimate,
>   again.
>   put_page() << Will report the bug and
>   page_owner have legitimate call stack.

good case. I think it will report "put_page()" from CPU b (the path that
actually dropped page refcount to zero and freed it), and alloc_page()
from CPU a. _might_ sound like a clue.

I agree, there are cases when this approach will not work out perfectly.
tracing refcount modification is probably the only reliable solution,
but given that sometimes it's unclear how to reproduce the bug, one can
end up looking at tons of traces.

> In kasan, quarantine is used to provide some delay for real free and
> it makes use-after-free detection more robust. Double-free also can be
> benefit from it. Anyway, I will not object more since it looks
> the simplest way to improve doublue-free detection for the page
> at least for now.

thanks!

there are things in the patch (it's an RFC after all) that I don't like.
in particular, I cut the corner in __dump_page_owner(). it now shows the
same text for both _ALLOC and _FREE handlers. I didn't want to add
additional ->order to page_ext. I can update the text to, e.g.
page allocated via order ...page_ext->order
and
page freed, WAS allocated via order ...   page_ext->order

or extend page_ext and keep alloc and free ->order separately.
do you have any preferences here?

-ss

Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed

[Neo Jia]

On Mon, Jul 04, 2016 at 03:37:35PM +0800, Xiao Guangrong wrote:
> 
> 
> On 07/04/2016 03:03 PM, Neo Jia wrote:
> >On Mon, Jul 04, 2016 at 02:39:22PM +0800, Xiao Guangrong wrote:
> >>
> >>
> >>On 06/30/2016 09:01 PM, Paolo Bonzini wrote:
> >>>The vGPU folks would like to trap the first access to a BAR by setting
> >>>vm_ops on the VMAs produced by mmap-ing a VFIO device.  The fault handler
> >>>then can use remap_pfn_range to place some non-reserved pages in the VMA.
> >>
> >>Why does it require fetching the pfn when the fault is triggered rather
> >>than when mmap() is called?
> >
> >Hi Guangrong,
> >
> >as such mapping information between virtual mmio to physical mmio is only 
> >available
> >at runtime.
> 
> Sorry, i do not know what the different between mmap() and the time VM 
> actually
> accesses the memory for your case. Could you please more detail?

Hi Guangrong,

Sure. The mmap() gets called by qemu or any VFIO API userspace consumer when
setting up the virtual mmio, at that moment nobody has any knowledge about how
the physical mmio gets virtualized.

When the vm (or application if we don't want to limit ourselves to vmm term)
starts, the virtual and physical mmio gets mapped by mpci kernel module with the
help from vendor supplied mediated host driver according to the hw resource
assigned to this vm / application.

> 
> >
> >>
> >>Why the memory mapped by this mmap() is not a portion of MMIO from
> >>underlayer physical device? If it is a valid system memory, is this 
> >>interface
> >>really needed to implemented in vfio? (you at least need to set VM_MIXEDMAP
> >>if it mixed system memory with MMIO)
> >>
> >
> >It actually is a portion of the physical mmio which is set by vfio mmap.
> 
> So i do not think we need to care its refcount, i,e, we can consider it as 
> reserved_pfn,
> Paolo?
> 
> >
> >>IIUC, the kernel assumes that VM_PFNMAP is a continuous memory, e.g, like
> >>current KVM and vaddr_get_pfn() in vfio, but it seems nvdia's patchset
> >>breaks this semantic as ops->validate_map_request() can adjust the physical
> >>address arbitrarily. (again, the name 'validate' should be changed to match
> >>the thing as it is really doing)
> >
> >The vgpu api will allow you to adjust the target mmio address and the size 
> >via
> >validate_map_request, but it is still physical contiguous as  >size>.
> 
> Okay, the interface confused us, maybe this interface need to be cooked to 
> reflect
> to this fact.

Sure. We can address this in the RFC mediated device thread.

Thanks,
Neo

> 
> Thanks!
> 

Re: [PATCH] phy: fix error handling

[Kishon Vijay Abraham I]

Hi,

On Monday 04 July 2016 02:38 AM, Christophe JAILLET wrote:
> I will resubmit in the coming days.
> 
>return PTR_ERR(phy->clk);
> should also be updated.

while at that, also fix your $subject to something like
"phy: sun9i-usb: fix error handling"

Thanks
Kishon

> 
> Best regards,
> CJ
> 
> Le 03/07/2016 à 07:55, Christophe JAILLET a écrit :
>> This is likely that checking 'phy->hsic_clk' instead of 'phy->clk' is
>> expected here.
>>
>> Signed-off-by: Christophe JAILLET 
>> ---
>>   drivers/phy/phy-sun9i-usb.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/phy/phy-sun9i-usb.c b/drivers/phy/phy-sun9i-usb.c
>> index ac4f31a..ff99eba 100644
>> --- a/drivers/phy/phy-sun9i-usb.c
>> +++ b/drivers/phy/phy-sun9i-usb.c
>> @@ -141,7 +141,7 @@ static int sun9i_usb_phy_probe(struct platform_device 
>> *pdev)
>>   }
>> phy->hsic_clk = devm_clk_get(dev, "hsic_12M");
>> -if (IS_ERR(phy->clk)) {
>> +if (IS_ERR(phy->hsic_clk)) {
>>   dev_err(dev, "failed to get hsic_12M clock\n");
>>   return PTR_ERR(phy->clk);
>>   }
> 
> 

Re: [PATCH v003] Added support for gcc version >= 6

[Florian Meier]

I'll repost it, that's the easiest fix.

On 4 July 2016 at 09:43, Peter Oberparleiter  wrote:
> On 01.07.2016 18:26, Joe Perches wrote:
>> On Fri, 2016-07-01 at 15:09 +0200, Florian Meier wrote:
>>> Added support for gcc version >= 6 in gcov.
>>
>> It's important to mention the subsystem in the patch subject
>>
>> e.g. "Subject: [PATCH V3] gcov: Support gcc version >= 6"
>
> Thanks for pointing this out - I completely missed that this was lost
> between v2 and v3 of the patch. Should we re-post or can this be fixed
> another way?
>
> --
> Peter Oberparleiter
> Linux on z Systems Development - IBM Germany
>

Re: [PATCH] relay: Add global mode support for buffer-only channels

[Chris Wilson]

On Sun, Jul 03, 2016 at 09:45:27PM +0530, akash.g...@intel.com wrote:
> From: Akash Goel 
> 
> The following patch added support to use channels with no associated files.
>   relay: add buffer-only channels; useful for early logging
> This is useful when the exact location of relay file is not known or the
> the parent directory of relay file is not available, while creating the
> channel and the logging has to start right from the boot.
> 
> But there was no provision to use global mode with buffer-only channels,
> which is added by this patch, without modifying the interface where initially
> there will be a dummy invocation of create_buf_file callback through which
> kernel client can convey the need of a global buffer.
> 
> For the use case where drivers/kernel clients want a simple interface for the
> userspace, which enables them to capture data/logs from relay file in order &
> without any post processing, support of Global buffer mode is warranted.
> 
> Cc: Eduard - Gabriel Munteanu 
> Cc: Tom Zanussi 
> Cc: Chris Wilson 
> Signed-off-by: Akash Goel 
> ---
>  kernel/relay.c | 32 
>  1 file changed, 32 insertions(+)
> 
> diff --git a/kernel/relay.c b/kernel/relay.c
> index 04d7cf3..b267384 100644
> --- a/kernel/relay.c
> +++ b/kernel/relay.c
> @@ -451,6 +451,16 @@ static struct rchan_buf *relay_open_buf(struct rchan 
> *chan, unsigned int cpu)
>   if (!dentry)
>   goto free_buf;
>   relay_set_buf_dentry(buf, dentry);
> + } else {

The trailing block can be replaced with:

/* Only retrieve global info, nothing more, nothing less */

> + dentry = chan->cb->create_buf_file(NULL, NULL,
> + S_IRUSR, buf,
> + &chan->is_global);

Watch alignment, align to the opening bracket.

> + if (WARN_ON(dentry))
> + goto free_buf;
>   }
>  
>   buf->cpu = cpu;
> @@ -666,6 +676,27 @@ int relay_late_setup_files(struct rchan *chan,
>   }
>   chan->has_base_filename = 1;
>   chan->parent = parent;
> +
> + if (chan->is_global) {
> + if (unlikely(!chan->buf[0])) {

if (WARN_ON_ONCE(!chan->buf[0])) {

> + WARN_ONCE(1, KERN_ERR "CPU 0 has no buffer!\n");

The WARN includes the unlikely and the message here isn't any more
informative than the line itself, plus has the erroneous KERN_ERR

> + mutex_unlock(&relay_channels_mutex);
> + return -EINVAL;
> +}
> +
> + dentry = relay_create_buf_file(chan, chan->buf[0], 0);
> +
> + if (unlikely(!dentry))
> + err = -EINVAL;
> + else if (WARN_ON(!chan->is_global))

?

> + err = -EINVAL;
> + else
> + relay_set_buf_dentry(chan->buf[0], dentry);
> +
> + mutex_unlock(&relay_channels_mutex);
> + return err;

This could be written:

if (chan->is_global) {
err = -EINVAL;
if (!WARN_ON_ONCE(!chan->buf[0])) {
dentry = relay_create_buf_file(chan, chan->buf[0], 0))
if (dentry) {
relay_set_buf_dentry(chan->buf[0], dentry);
err = 0;
}
}
mutex_unlock();
return err;
}

for a single exit/unlock path in this block.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [PATCH v4 5/5] ARM: dts: mt2701: add iommu/smi dtsi node for mt2701

[Matthias Brugger]

On 04/07/16 03:32, Honghui Zhang wrote:

On Sun, 2016-07-03 at 21:12 +0200, Matthias Brugger wrote:


On 07/03/2016 08:24 AM, Matthias Brugger wrote:



On 06/08/2016 11:51 AM, honghui.zh...@mediatek.com wrote:

From: Honghui Zhang 

Add the dtsi node of iommu and smi for mt2701.

Signed-off-by: Honghui Zhang 
---
  arch/arm/boot/dts/mt2701.dtsi | 51
+++
  1 file changed, 51 insertions(+)



Applied,


Please resend the patch including the infracfg and mmsys node.



Hi, Matthias,

Please hold this one.
This one is based on CCF "arm: dts: mt2701: Add clock controller device
nodes"[1] and power domain patch "Mediatek MT2701 SCPSYS power domain
support v7"[2],
But these two patchset are still being reviewed now.

Do you think it's better that I send this one later after ccf and power
domain patch got merged? I will send this patch later if it's OK with
you.



Sounds good.

Thanks a lot,
Matthias


Thanks.
[1] https://patchwork.kernel.org/patch/9109081
[2]
http://lists.infradead.org/pipermail/linux-mediatek/2016-May/005429.html


Regards,
Matthias



Thanks.


diff --git a/arch/arm/boot/dts/mt2701.dtsi
b/arch/arm/boot/dts/mt2701.dtsi
index 42d5a37..363de0d 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -16,6 +16,7 @@
  #include 
  #include 
  #include 
+#include 
  #include "skeleton64.dtsi"
  #include "mt2701-pinfunc.h"

@@ -160,6 +161,16 @@
  clock-names = "system-clk", "rtc-clk";
  };

+smi_common: smi@1000c000 {
+compatible = "mediatek,mt2701-smi-common";
+reg = <0 0x1000c000 0 0x1000>;
+clocks = <&infracfg CLK_INFRA_SMI>,
+ <&mmsys CLK_MM_SMI_COMMON>,
+ <&infracfg CLK_INFRA_SMI>;
+clock-names = "apb", "smi", "async";
+power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>;
+};
+
  sysirq: interrupt-controller@10200100 {
  compatible = "mediatek,mt2701-sysirq",
   "mediatek,mt6577-sysirq";
@@ -169,6 +180,16 @@
  reg = <0 0x10200100 0 0x1c>;
  };

+iommu: mmsys_iommu@10205000 {
+compatible = "mediatek,mt2701-m4u";
+reg = <0 0x10205000 0 0x1000>;
+interrupts = ;
+clocks = <&infracfg CLK_INFRA_M4U>;
+clock-names = "bclk";
+mediatek,larbs = <&larb0 &larb1 &larb2>;
+#iommu-cells = <1>;
+};
+
  apmixedsys: syscon@10209000 {
  compatible = "mediatek,mt2701-apmixedsys", "syscon";
  reg = <0 0x10209000 0 0x1000>;
@@ -234,6 +255,16 @@
  status = "disabled";
  };

+larb0: larb@1401 {
+compatible = "mediatek,mt2701-smi-larb";
+reg = <0 0x1401 0 0x1000>;
+mediatek,smi = <&smi_common>;
+clocks = <&mmsys CLK_MM_SMI_LARB0>,
+ <&mmsys CLK_MM_SMI_LARB0>;
+clock-names = "apb", "smi";
+power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>;
+};
+
  imgsys: syscon@1500 {
  compatible = "mediatek,mt2701-imgsys", "syscon";
  reg = <0 0x1500 0 0x1000>;
@@ -241,6 +272,16 @@
  status = "disabled";
  };

+larb2: larb@15001000 {
+compatible = "mediatek,mt2701-smi-larb";
+reg = <0 0x15001000 0 0x1000>;
+mediatek,smi = <&smi_common>;
+clocks = <&imgsys CLK_IMG_SMI_COMM>,
+ <&imgsys CLK_IMG_SMI_COMM>;
+clock-names = "apb", "smi";
+power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>;
+};
+
  vdecsys: syscon@1600 {
  compatible = "mediatek,mt2701-vdecsys", "syscon";
  reg = <0 0x1600 0 0x1000>;
@@ -248,6 +289,16 @@
  status = "disabled";
  };

+larb1: larb@1601 {
+compatible = "mediatek,mt2701-smi-larb";
+reg = <0 0x1601 0 0x1000>;
+mediatek,smi = <&smi_common>;
+clocks = <&vdecsys CLK_VDEC_CKGEN>,
+ <&vdecsys CLK_VDEC_LARB>;
+clock-names = "apb", "smi";
+power-domains = <&scpsys MT2701_POWER_DOMAIN_VDEC>;
+};
+
  hifsys: syscon@1a00 {
  compatible = "mediatek,mt2701-hifsys", "syscon";
  reg = <0 0x1a00 0 0x1000>;

Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed

[Xiao Guangrong]

On 07/04/2016 03:48 PM, Paolo Bonzini wrote:



On 04/07/2016 09:37, Xiao Guangrong wrote:




It actually is a portion of the physical mmio which is set by vfio mmap.


So i do not think we need to care its refcount, i,e, we can consider it
as reserved_pfn,
Paolo?


nVidia provided me (offlist) with a simple patch that modified VFIO to
exhibit the problem, and it didn't use reserved PFNs.  This is why the
commit message for the patch is not entirely accurate.



It's clear now.


But apart from this, it's much more obvious to consider the refcount.
The x86 MMU code doesn't care if the page is reserved or not;
mmu_set_spte does a kvm_release_pfn_clean, hence it makes sense for
hva_to_pfn_remapped to try doing a get_page (via kvm_get_pfn) after
invoking the fault handler, just like the get_user_pages family of
function does.


Well,  it's little strange as you always try to get refcont
for a PFNMAP region without MIXEDMAP which indicates all the memory
in this region is no 'struct page' backend.

But it works as kvm_{get, release}_* have already been aware of
reserved_pfn, so i am okay with it..

Re: [PATCH] clkdev: add devm_of_clk_get()

[Kuninori Morimoto]

Hi Arnd

> > @@ -501,6 +503,11 @@ static inline struct clk *of_clk_get(struct 
> > device_node *np, int index)
> >  {
> > return ERR_PTR(-ENOENT);
> >  }
> > +struct clk *devm_of_clk_get(struct device *dev,
> > +   struct device_node *np, int index)
> > +{
> > +   return ERR_PTR(-ENOENT);
> > +}
> >  static inline struct clk *of_clk_get_by_name(struct device_node *np,
> >  const char *name)
> >  {
> > -- 
> > 
> 
> This is missing "static inline" as found by the bot.

Thanks.
I have already posted v2 patch.

Re: [PATCH 00/31] Move LRU page reclaim from zones to nodes v8

[Minchan Kim]

On Mon, Jul 04, 2016 at 05:34:05AM +0100, Mel Gorman wrote:
> On Mon, Jul 04, 2016 at 10:37:03AM +0900, Minchan Kim wrote:
> > > The reason we have zone-based reclaim is that we used to have
> > > large highmem zones in common configurations and it was necessary
> > > to quickly find ZONE_NORMAL pages for reclaim. Today, this is much
> > > less of a concern as machines with lots of memory will (or should) use
> > > 64-bit kernels. Combinations of 32-bit hardware and 64-bit hardware are
> > > rare. Machines that do use highmem should have relatively low 
> > > highmem:lowmem
> > > ratios than we worried about in the past.
> > 
> > Hello Mel,
> > 
> > I agree the direction absolutely. However, I have a concern on highmem
> > system as you already mentioned.
> > 
> > Embedded products still use 2 ~ 3 ratio (highmem:lowmem).
> > In such system, LRU churning by skipping other zone pages frequently
> > might be significant for the performance.
> > 
> > How big ratio between highmem:lowmem do you think a problem?
> > 
> 
> That's a "how long is a piece of string" type question.  The ratio does
> not matter as much as whether the workload is both under memory pressure
> and requires large amounts of lowmem pages. Even on systems with very high
> ratios, it may not be a problem if HIGHPTE is enabled.

As well page table, pgd/kernelstack/zbud/slab and so on, every kernel
allocations wanted to mask __GFP_HIGHMEM off would be a problem in
32bit system.

It also depends on that how many drivers needed lowmem only we have
in the system.

I don't know how many such driver in the world. When I simply do grep,
I found several cases which mask __GFP_HIGHMEM off and among them,
I guess DRM might be a popular for us. However, it might be really rare
usecase among various i915 usecases.

> 
> > > 
> > > Conceptually, moving to node LRUs should be easier to understand. The
> > > page allocator plays fewer tricks to game reclaim and reclaim behaves
> > > similarly on all nodes. 
> > > 
> > > The series has been tested on a 16 core UMA machine and a 2-socket 48
> > > core NUMA machine. The UMA results are presented in most cases as the NUMA
> > > machine behaved similarly.
> > 
> > I guess you would already test below with various highmem system(e.g.,
> > 2:1, 3:1, 4:1 and so on). If you have, could you mind sharing it?
> > 
> 
> I haven't that data, the baseline distribution used doesn't even have
> 32-bit support. Even if it was, the results may not be that interesting.
> The workloads used were not necessarily going to trigger lowmem pressure
> as HIGHPTE was set on the 32-bit configs.

That means we didn't test this on 32-bit with highmem.

I'm not sure it's really too rare case to spend a time for testing.
In fact, I really want to test all series to our production system
which is 32bit and highmem but as we know well, most of embedded
system kernel is rather old so backporting needs lots of time and
care. However, if we miss testing in those system at the moment,
we will be suprised after 1~2 years.

I don't know what kinds of benchmark can we can check it so I cannot
insist on it but you might know it.

Okay, do you have any idea to fix it if we see such regression report
in 32-bit system in future?

Re: [PATCH 11/13] blk-mq: allow the driver to pass in an affinity mask

[Alexander Gordeev]

On Tue, Jun 14, 2016 at 09:59:04PM +0200, Christoph Hellwig wrote:
> +static int blk_mq_create_mq_map(struct blk_mq_tag_set *set,
> + const struct cpumask *affinity_mask)
> +{
> + int queue = -1, cpu = 0;
> +
> + set->mq_map = kzalloc_node(sizeof(*set->mq_map) * nr_cpu_ids,
> + GFP_KERNEL, set->numa_node);
> + if (!set->mq_map)
> + return -ENOMEM;
> +
> + if (!affinity_mask)
> + return 0;   /* map all cpus to queue 0 */
> +
> + /* If cpus are offline, map them to first hctx */
> + for_each_online_cpu(cpu) {
> + if (cpumask_test_cpu(cpu, affinity_mask))
> + queue++;

CPUs missing in an affinity mask are mapped to hctxs. Is that intended?

> + if (queue > 0)

Why this check?

> + set->mq_map[cpu] = queue;
> + }
> +
> + return 0;
> +}
> +

Build regressions/improvements in v4.7-rc6

[Geert Uytterhoeven]

Below is the list of build error/warning regressions/improvements in
v4.7-rc6[1] compared to v4.6[2].

Summarized:
  - build errors: +10/-7
  - build warnings: +1320/-1154

JFYI, when comparing v4.7-rc6[1] to v4.7-rc5[3], the summaries are:
  - build errors: +3/-2
  - build warnings: +691/-871

Note that there may be false regressions, as some logs are incomplete.
Still, they're build errors/warnings.

As I haven't mastered kup yet, there's no verbose summary at
http://www.kernel.org/pub/linux/kernel/people/geert/linux-log/v4.7-rc6.summary.gz

Happy fixing! ;-)

Thanks to the linux-next team for providing the build service.

[1] http://kisskb.ellerman.id.au/kisskb/head/10562/ (260 out of 263 configs)
[2] http://kisskb.ellerman.id.au/kisskb/head/10344/ (all 263 configs)
[3] http://kisskb.ellerman.id.au/kisskb/head/10532/ (260 out of 263 configs)


*** ERRORS ***

10 error regressions:
  + /home/kisskb/slave/src/drivers/vhost/vhost.c: error: call to 
'__compiletime_assert_844' declared with attribute error: BUILD_BUG_ON failed: 
__alignof__ *vq->avail > VRING_AVAIL_ALIGN_SIZE:  => 844:3
  + /tmp/cc6CV1oe.s: Error: pcrel too far BFD_RELOC_BFIN_10:  => 889
  + error: relocation truncated to fit: R_PPC64_REL24 against symbol 
`.cancel_work_sync' defined in .text section in kernel/built-in.o:  => 
(.text+0x1ffbedc)
  + error: relocation truncated to fit: R_PPC64_REL24 against symbol 
`.queue_work_on' defined in .text section in kernel/built-in.o:  => 
(.text+0x1ffa54c), (.text+0x1ffaa94)
  + error: sdio.c: relocation truncated to fit: R_PPC64_REL24 against symbol 
`._raw_spin_lock_irqsave' defined in .spinlock.text section in 
kernel/built-in.o:  => (.text+0x1ffbad8)
  + error: sdio.c: relocation truncated to fit: R_PPC64_REL24 against symbol 
`._raw_spin_unlock_irqrestore' defined in .spinlock.text section in 
kernel/built-in.o:  => (.text+0x1ffbb24)
  + error: sdio.c: relocation truncated to fit: R_PPC64_REL24 against symbol 
`.kfree_skb' defined in .text section in net/built-in.o:  => (.text+0x1ff8fb0)
  + error: sdio.c: relocation truncated to fit: R_PPC64_REL24 against symbol 
`.kthread_stop' defined in .text section in kernel/built-in.o:  => 
(.text+0x1ffb608)
  + error: sdio.c: relocation truncated to fit: R_PPC64_REL24 against symbol 
`.skb_pull' defined in .text section in net/built-in.o:  => (.text+0x1ffa8d4), 
(.text+0x1ff9208)
  + error: sdio.c: relocation truncated to fit: R_PPC64_REL24 against symbol 
`.skb_push' defined in .text section in net/built-in.o:  => (.text+0x1ffa83c)

7 error improvements:
  - /home/kisskb/slave/src/arch/sh/mm/cache-sh4.c: error: 'cached_to_uncached' 
undeclared (first use in this function): 99:17 => 
  - /home/kisskb/slave/src/arch/sh/mm/cache-sh4.c: error: implicit declaration 
of function 'cpu_context' [-Werror=implicit-function-declaration]: 192:2 => 
  - /tmp/ccSuvE7E.s: Error: pcrel too far BFD_RELOC_BFIN_10: 889 => 
  - error: hns_dsaf_main.c: relocation truncated to fit: R_PPC64_REL24 against 
symbol `.eeh_check_failure' defined in .text section in 
arch/powerpc/kernel/built-in.o: (.text+0x1ffaca4), (.text+0x1ffa59c), 
(.text+0x1ffb134), (.text+0x1ffaeec), (.text+0x1ffaa5c), (.text+0x1ffa8a8), 
(.text+0x1ffa6f8) => 
  - error: hns_dsaf_main.c: relocation truncated to fit: R_PPC64_REL24 against 
symbol `_restgpr0_18' defined in .text.save.restore section in 
arch/powerpc/lib/built-in.o: (.text+0x1ff9314) => 
  - error: hns_dsaf_main.c: relocation truncated to fit: R_PPC64_REL24 against 
symbol `_savegpr0_27' defined in .text.save.restore section in 
arch/powerpc/lib/built-in.o: (.text+0x1ffb284) => 
  - error: relocation truncated to fit: R_PPC64_REL24 against symbol 
`_savegpr0_28' defined in .text.save.restore section in 
arch/powerpc/lib/built-in.o: (.text+0x1ff7890) => 


*** WARNINGS ***

1320 warning regressions:

[Deleted 1191 lines about "warning: -ffunction-sections disabled; it makes 
profiling impossible [enabled by default]" on parisc-allmodconfig]

  + /home/kisskb/slave/src/arch/powerpc/include/asm/io.h: warning: 'px_cmd' may 
be used uninitialized in this function [-Wmaybe-uninitialized]:  => 163:2
  + /home/kisskb/slave/src/arch/powerpc/include/asm/io.h: warning: 'px_is' may 
be used uninitialized in this function [-Wmaybe-uninitialized]:  => 163:2
  + /home/kisskb/slave/src/arch/x86/platform/olpc/olpc-xo15-sci.c: warning: 
'xo15_sci_resume' defined but not used [-Wunused-function]:  => 199:12
  + /home/kisskb/slave/src/crypto/algif_aead.c: warning: 'outlen' may be used 
uninitialized in this function [-Wuninitialized]:  => 534:2
  + /home/kisskb/slave/src/drivers/bluetooth/btwilink.c: warning: overflow in 
implicit constant conversion [-Woverflow]:  => 174:3
  + /home/kisskb/slave/src/drivers/char/hw_random/stm32-rng.c: warning: 'sr' 
may be used uninitialized in this function [-Wuninitialized]:  => 82:6
  + /home/kisskb/slave/src/drivers/gpio/gpio-stmpe.c: warning: 'stmpe_gpio_irq' 
uses dynamic stack allocation [enabled by default]:  => 331:1
  

Re: [PATCH] regulator: core: Assign bool value to variable has_full_constraints

[Mark Brown]

On Mon, Jul 04, 2016 at 10:05:25AM +0800, Baoquan He wrote:

> In commit 21cf891a (regulator: Make regulator_has_full_constraints a bool)
> type of variable has_full_constraints is changed to bool, so assign 'true'
> to has_full_constraints here.

There is no need to make changes like this, C has full support for using
integers in a boolean context - using true here would've been just as
meaningful with an integer variable and using a number for a boolean
variable is fully equivalent.


signature.asc
Description: PGP signature

Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed

[Paolo Bonzini]

On 04/07/2016 09:59, Xiao Guangrong wrote:
> 
>> But apart from this, it's much more obvious to consider the refcount.
>> The x86 MMU code doesn't care if the page is reserved or not;
>> mmu_set_spte does a kvm_release_pfn_clean, hence it makes sense for
>> hva_to_pfn_remapped to try doing a get_page (via kvm_get_pfn) after
>> invoking the fault handler, just like the get_user_pages family of
>> function does.
> 
> Well,  it's little strange as you always try to get refcont
> for a PFNMAP region without MIXEDMAP which indicates all the memory
> in this region is no 'struct page' backend.

Fair enough, I can modify the comment.

/*
 * In case the VMA has VM_MIXEDMAP set, whoever called remap_pfn_range
 * is also going to call e.g. unmap_mapping_range before the underlying
 * non-reserved pages are freed, which will then call our MMU notifier.
 * We still have to get a reference here to the page, because the 
callers
 * of *hva_to_pfn* and *gfn_to_pfn* ultimately end up doing a
 * kvm_release_pfn_clean on the returned pfn.  If the pfn is
 * reserved, the kvm_get_pfn/kvm_release_pfn_clean pair will simply
 * do nothing.
 */

Paolo

> But it works as kvm_{get, release}_* have already been aware of
> reserved_pfn, so i am okay with it..

Re: [PATCH v11 00/22] Add HiSilicon RoCE driver

[oulijun]

在 2016/7/2 20:58, Leon Romanovsky 写道:
> On Sat, Jul 02, 2016 at 05:39:02PM +0800, Lijun Ou wrote:
> 
> This v11
>>  28 files changed, 10626 insertions(+), 1 deletion(-)
> 
> First version
>>  27 files changed, 11670 insertions(+), 11 deletions(-)
> 
> 1K LOC less, we are moving in right direction.
> 
Good, Thank you very much！
Thank you for more suggestions.

Thanks
Lijun Ou

[PATCH v004] gcov: Added support for gcc version >= 6

[Florian Meier]

Added support for gcc version >= 6 in gcov.

Signed-off-by: Florian Meier 
---
 kernel/gcov/gcc_4_7.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/gcov/gcc_4_7.c b/kernel/gcov/gcc_4_7.c
index e25e92f..6a5c239 100644
--- a/kernel/gcov/gcc_4_7.c
+++ b/kernel/gcov/gcc_4_7.c
@@ -18,7 +18,7 @@
 #include 
 #include "gcov.h"
 
-#if __GNUC__ == 5 && __GNUC_MINOR__ >= 1
+#if (__GNUC__ > 5) || (__GNUC__ == 5 && __GNUC_MINOR__ >= 1)
 #define GCOV_COUNTERS  10
 #elif __GNUC__ == 4 && __GNUC_MINOR__ >= 9
 #define GCOV_COUNTERS  9
-- 
2.9.0

Re: [RFC] block: fix blk_queue_split() resource exhaustion

[Lars Ellenberg]

On Sat, Jul 02, 2016 at 06:28:29PM +0800, Ming Lei wrote:
> The idea looks good, but not sure it can cover all cases of
> dm over brbd or brbd over dm and maintaining two lists
> becomes too complicated.
> 
> One clean solution may be to convert the loop of generic_make_request()
> into the following way:
> 
> do {
> struct bio *splitted, *remainder = NULL;
> struct request_queue *q = bdev_get_queue(bio->bi_bdev);
> 
> blk_queue_split(q, &bio, &remainder, q->bio_split);
> 
> ret = q->make_request_fn(q, bio);
> 
> if (remainder)
>  bio_list_add(current->bio_list, remainder);
> bio = bio_list_pop(current->bio_list);
> } while (bio)

Not good enough.

Consider DRBD on device-mapper on device-mapper on scsi,
or insert multipath and / or md raid into the stack.
The iterative call to q->make_request_fn() in the second iteration
may queue bios after the remainder.

Goal was to first process all "deeper level" bios
before processing the remainder.

You can achieve this by doing last-in-first-out on bio_list,
or by using two lists, as I suggested in the original post.

Lars

Re: Build regressions/improvements in v4.7-rc6

[Geert Uytterhoeven]

On Mon, Jul 4, 2016 at 10:12 AM, Geert Uytterhoeven
 wrote:
> JFYI, when comparing v4.7-rc6[1] to v4.7-rc5[3], the summaries are:
>   - build errors: +3/-2

  + /home/kisskb/slave/src/drivers/vhost/vhost.c: error: call to
'__compiletime_assert_844' declared with attribute error: BUILD_BUG_ON
failed: __alignof__ *vq->avail > VRING_AVAIL_ALIGN_SIZE:  => 844:3

arm-randconfig

> [1] http://kisskb.ellerman.id.au/kisskb/head/10562/ (260 out of 263 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/head/10532/ (260 out of 263 configs)

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed

[Xiao Guangrong]

On 07/04/2016 03:53 PM, Neo Jia wrote:

On Mon, Jul 04, 2016 at 03:37:35PM +0800, Xiao Guangrong wrote:



On 07/04/2016 03:03 PM, Neo Jia wrote:

On Mon, Jul 04, 2016 at 02:39:22PM +0800, Xiao Guangrong wrote:



On 06/30/2016 09:01 PM, Paolo Bonzini wrote:

The vGPU folks would like to trap the first access to a BAR by setting
vm_ops on the VMAs produced by mmap-ing a VFIO device.  The fault handler
then can use remap_pfn_range to place some non-reserved pages in the VMA.


Why does it require fetching the pfn when the fault is triggered rather
than when mmap() is called?


Hi Guangrong,

as such mapping information between virtual mmio to physical mmio is only 
available
at runtime.


Sorry, i do not know what the different between mmap() and the time VM actually
accesses the memory for your case. Could you please more detail?


Hi Guangrong,

Sure. The mmap() gets called by qemu or any VFIO API userspace consumer when
setting up the virtual mmio, at that moment nobody has any knowledge about how
the physical mmio gets virtualized.

When the vm (or application if we don't want to limit ourselves to vmm term)
starts, the virtual and physical mmio gets mapped by mpci kernel module with the
help from vendor supplied mediated host driver according to the hw resource
assigned to this vm / application.


Thanks for your expiation.

It sounds like a strategy of resource allocation, you delay the allocation 
until VM really
accesses it, right?

Re: clk: Per controller locks (prepare & enable)

[Krzysztof Kozlowski]

On 06/30/2016 06:22 PM, Javier Martinez Canillas wrote:
>> Question:
>> What do you think about it? I know that talk is cheap and code looks
>> better but before starting the work I would like to hear some
>> comments/opinions/ideas.
>>
> 
> The problem is that the enable and prepare operations are propagated to
> the parents, so what the locks want to protecting is really a sub-tree
> of the clock tree. They currently protect the whole clock hierarchy to
> make sure that the changes in the clock tree are atomically.

Although there is a hierarchy between clocks from different controllers
but still these are all clocks controllers coming from one hardware
device (like SoC). At least on Exynos, I think there is no real
inter-device dependencies. The deadlock you mentioned (and which I want
to fix) is between:
1. clock in PMIC (the one needed by s3c_rtc_probe()),
2. clock for I2C in SoC (the one needed by regmap_write()),
3. and regmap lock:

What I want to say is that the relationship between clocks even when
crossing clock controller boundaries is still self-contained. It is
simple parent-child relationship so acquiring both
clock-controller-level locks is safe.

Current dead lock looks like, simplifying your code:
A:B:
lock(regmap)
  lock(prepare)
lock(prepare) - wait
  lock(regmap) - wait


When split locks per clock controller this would be:
A:B:
lock(regmap)
  lock(s2mps11)
lock(i2c/exynos)
  lock(regmap) - wait
do the transfer
unlock(i2c/exynos)
unlock(regmap)
  lock(regmap) - acquired
  lock(i2c/exynos)
  do the transfer
  unlock(i2c/exynos)
  unlock(regmap)
  unlock(s2mps11)

I still have to figure out how to properly protect the entire tree
hierarchy. Maybe the global prepare_lock should be used only for that -
for traversing the hierarchy.

> 
> So a clock per controller won't suffice since you can have a parent for
> a clock provided by a different controller and that won't be protected.
> 
> Another option is to have a prepare and enable locks per clock. Since
> the operations are always propagated in the same direction, I think is
> safe to do it.
> 
> But even in the case of a more fine-grained locking, I believe the
> mentioned deadlocks can still happen. For example in 10ff4c5239a1 the
> issue was that the s2mps11 PMIC has both regulators and clocks that are
> controlled via I2C so the regulator and clocks drivers shares the same
> I2C regmap.
> 
> What happened was something like this:
> 
>  CPU0   CPU1
>     
>   regulator_set_voltage()s3c_rtc_probe()
>   regmap_write() clk_prepare()
>   /* regmap->lock was aquired */ /* prepare_lock was aquired */
>   regmap_i2c_write() s2mps11_clk_prepare()
>   i2c_transfer() regmap_write()
>   exynos5_i2c_xfer() /* deadlock due regmap->lock */
>   clk_prepare_enable()
>   clk_prepare_lock()
>   /* prepare_lock was aquired */
> 
> So if for example a per clock lock is used, the deadlock can still happen
> if both the I2C clock and S3C RTC source clock share the same parent in a
> part of the hierarchy. But as you said this is less likely in practice so
> probably is not an issue.

I think these clocks do not share the parent.

Best regards,
Krzysztof

Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed

[Xiao Guangrong]

On 07/04/2016 04:14 PM, Paolo Bonzini wrote:



On 04/07/2016 09:59, Xiao Guangrong wrote:



But apart from this, it's much more obvious to consider the refcount.
The x86 MMU code doesn't care if the page is reserved or not;
mmu_set_spte does a kvm_release_pfn_clean, hence it makes sense for
hva_to_pfn_remapped to try doing a get_page (via kvm_get_pfn) after
invoking the fault handler, just like the get_user_pages family of
function does.


Well,  it's little strange as you always try to get refcont
for a PFNMAP region without MIXEDMAP which indicates all the memory
in this region is no 'struct page' backend.


Fair enough, I can modify the comment.

/*
 * In case the VMA has VM_MIXEDMAP set, whoever called remap_pfn_range
 * is also going to call e.g. unmap_mapping_range before the underlying
 * non-reserved pages are freed, which will then call our MMU notifier.
 * We still have to get a reference here to the page, because the 
callers
 * of *hva_to_pfn* and *gfn_to_pfn* ultimately end up doing a
 * kvm_release_pfn_clean on the returned pfn.  If the pfn is
 * reserved, the kvm_get_pfn/kvm_release_pfn_clean pair will simply
 * do nothing.
 */



Excellent. I like it. :)

Re: [PATCH] ARM: defconfig/at91: Add Bosch M_CAN driver

[Nicolas Ferre]

Le 04/07/2016 09:15, Wenyou Yang a écrit :
> Add CONFIG_CAN_M_CAN=y option to enable Bosch M_CAN device driver.
> 
> Signed-off-by: Wenyou Yang 

Acked-by: Nicolas Ferre 

It seems not present in multi_v7 as well: can you please add it as a module?

Bye,

> ---
> 
>  arch/arm/configs/sama5_defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/configs/sama5_defconfig 
> b/arch/arm/configs/sama5_defconfig
> index 9cb1a85..dcde44ff 100644
> --- a/arch/arm/configs/sama5_defconfig
> +++ b/arch/arm/configs/sama5_defconfig
> @@ -52,6 +52,7 @@ CONFIG_IP_PNP_RARP=y
>  CONFIG_IPV6_SIT_6RD=y
>  CONFIG_CAN=y
>  CONFIG_CAN_AT91=y
> +CONFIG_CAN_M_CAN=y
>  CONFIG_CFG80211=y
>  CONFIG_MAC80211=y
>  CONFIG_MAC80211_LEDS=y
> 


-- 
Nicolas Ferre

Re: [PATCH] regulator: core: Assign bool value to variable has_full_constraints

[Baoquan He]

On 07/04/16 at 10:12am, Mark Brown wrote:
> On Mon, Jul 04, 2016 at 10:05:25AM +0800, Baoquan He wrote:
> 
> > In commit 21cf891a (regulator: Make regulator_has_full_constraints a bool)
> > type of variable has_full_constraints is changed to bool, so assign 'true'
> > to has_full_constraints here.
> 
> There is no need to make changes like this, C has full support for using
> integers in a boolean context - using true here would've been just as
> meaningful with an integer variable and using a number for a boolean
> variable is fully equivalent.

Well, I am fine with it. I am just going through pci/acpi initialization
code because I lack knowledge on them to fix a amd iommu bug. Trying to
post patches when some improvement can be made during this code reading
journey. If then, NACK it.

Thanks
Baoquan

Re: [PATCH 1/2] drm/amdgpu: remove unneeded conversions to bool

[Christian König]

Am 01.07.2016 um 16:22 schrieb Andrew F. Davis:

Found with scripts/coccinelle/misc/boolconv.cocci.

Signed-off-by: Andrew F. Davis 


For both patches Reviewed-by: Christian König .


---
  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |  8 
  drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  |  4 ++--
  drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c |  4 ++--
  drivers/gpu/drm/amd/amdgpu/vi.c| 14 +++---
  4 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index 1a5cbaf..f3c8c37 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -5144,13 +5144,13 @@ static int gfx_v8_0_set_powergating_state(void *handle,
case CHIP_POLARIS11:
if (adev->pg_flags & AMD_PG_SUPPORT_GFX_SMG)
polaris11_enable_gfx_static_mg_power_gating(adev,
-   state == AMD_PG_STATE_GATE ? true : 
false);
+   state == AMD_PG_STATE_GATE);
else if (adev->pg_flags & AMD_PG_SUPPORT_GFX_DMG)
polaris11_enable_gfx_dynamic_mg_power_gating(adev,
-   state == AMD_PG_STATE_GATE ? true : 
false);
+   state == AMD_PG_STATE_GATE);
else
polaris11_enable_gfx_quick_mg_power_gating(adev,
-   state == AMD_PG_STATE_GATE ? true : 
false);
+   state == AMD_PG_STATE_GATE);
break;
default:
break;
@@ -5583,7 +5583,7 @@ static int gfx_v8_0_set_clockgating_state(void *handle,
case CHIP_CARRIZO:
case CHIP_STONEY:
gfx_v8_0_update_gfx_clock_gating(adev,
-state == AMD_CG_STATE_GATE ? 
true : false);
+state == AMD_CG_STATE_GATE);
break;
default:
break;
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
index 9945d5b..6c3c730 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
@@ -1406,9 +1406,9 @@ static int gmc_v8_0_set_clockgating_state(void *handle,
switch (adev->asic_type) {
case CHIP_FIJI:
fiji_update_mc_medium_grain_clock_gating(adev,
-   state == AMD_CG_STATE_GATE ? true : false);
+   state == AMD_CG_STATE_GATE);
fiji_update_mc_light_sleep(adev,
-   state == AMD_CG_STATE_GATE ? true : false);
+   state == AMD_CG_STATE_GATE);
break;
default:
break;
diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c 
b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
index 532ea88..e57cab6 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
@@ -1547,9 +1547,9 @@ static int sdma_v3_0_set_clockgating_state(void *handle,
case CHIP_CARRIZO:
case CHIP_STONEY:
sdma_v3_0_update_sdma_medium_grain_clock_gating(adev,
-   state == AMD_CG_STATE_GATE ? true : false);
+   state == AMD_CG_STATE_GATE);
sdma_v3_0_update_sdma_medium_grain_light_sleep(adev,
-   state == AMD_CG_STATE_GATE ? true : false);
+   state == AMD_CG_STATE_GATE);
break;
default:
break;
diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index a65c960..d3404ef 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -1393,22 +1393,22 @@ static int vi_common_set_clockgating_state(void *handle,
switch (adev->asic_type) {
case CHIP_FIJI:
vi_update_bif_medium_grain_light_sleep(adev,
-   state == AMD_CG_STATE_GATE ? true : false);
+   state == AMD_CG_STATE_GATE);
vi_update_hdp_medium_grain_clock_gating(adev,
-   state == AMD_CG_STATE_GATE ? true : false);
+   state == AMD_CG_STATE_GATE);
vi_update_hdp_light_sleep(adev,
-   state == AMD_CG_STATE_GATE ? true : false);
+   state == AMD_CG_STATE_GATE);
vi_update_rom_medium_grain_clock_gating(adev,
-   state == AMD_CG_STATE_GATE ? true : false);
+   state == AMD_CG_STATE_GATE);
break;
case CHIP_CARRIZO:
case CHIP_STONEY:
vi_update_bif_medium_grain_light_sleep(adev,
-   state == 

Re: [PATCH] regulator: core: Assign bool value to variable has_full_constraints

[Baoquan He]

On 07/04/16 at 10:12am, Mark Brown wrote:
> On Mon, Jul 04, 2016 at 10:05:25AM +0800, Baoquan He wrote:
> 
> > In commit 21cf891a (regulator: Make regulator_has_full_constraints a bool)
> > type of variable has_full_constraints is changed to bool, so assign 'true'
> > to has_full_constraints here.
> 
> There is no need to make changes like this, C has full support for using
> integers in a boolean context - using true here would've been just as
> meaningful with an integer variable and using a number for a boolean
> variable is fully equivalent.

By the way, I still think it makes code more read-able to assign a bool
value to a bool variable. In your words, C truly has full support for
using integers in a boolean context, then commit 21cf891a is not
necessary to be made to change.

Re: [PATCH 11/13] blk-mq: allow the driver to pass in an affinity mask

[Christoph Hellwig]

On Mon, Jul 04, 2016 at 10:15:41AM +0200, Alexander Gordeev wrote:
> On Tue, Jun 14, 2016 at 09:59:04PM +0200, Christoph Hellwig wrote:
> > +static int blk_mq_create_mq_map(struct blk_mq_tag_set *set,
> > +   const struct cpumask *affinity_mask)
> > +{
> > +   int queue = -1, cpu = 0;
> > +
> > +   set->mq_map = kzalloc_node(sizeof(*set->mq_map) * nr_cpu_ids,
> > +   GFP_KERNEL, set->numa_node);
> > +   if (!set->mq_map)
> > +   return -ENOMEM;
> > +
> > +   if (!affinity_mask)
> > +   return 0;   /* map all cpus to queue 0 */
> > +
> > +   /* If cpus are offline, map them to first hctx */
> > +   for_each_online_cpu(cpu) {
> > +   if (cpumask_test_cpu(cpu, affinity_mask))
> > +   queue++;
> 
> CPUs missing in an affinity mask are mapped to hctxs. Is that intended?

Yes - each CPU needs to be mapped to some hctx, otherwise we can't
submit I/O from that CPU.

> > +   if (queue > 0)
> 
> Why this check?
> 
> > +   set->mq_map[cpu] = queue;

mq_map is initialized to zero already, so we don't really need the
assignment for queue 0.  The reason why this check exists is because
we start with queue = -1 and we never want to assignment -1 to mq_map.

[PATCH 01/13] irq/msi: Remove unused MSI_FLAG_IDENTITY_MAP

[Christoph Hellwig]

From: Thomas Gleixner 

No user and we definitely don't want to grow one.

Signed-off-by: Thomas Gleixner 
Reviewed-by: Bart Van Assche 
---
 include/linux/msi.h | 6 ++
 kernel/irq/msi.c| 8 ++--
 2 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/include/linux/msi.h b/include/linux/msi.h
index 8b425c6..c33abfa 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -264,12 +264,10 @@ enum {
 * callbacks.
 */
MSI_FLAG_USE_DEF_CHIP_OPS   = (1 << 1),
-   /* Build identity map between hwirq and irq */
-   MSI_FLAG_IDENTITY_MAP   = (1 << 2),
/* Support multiple PCI MSI interrupts */
-   MSI_FLAG_MULTI_PCI_MSI  = (1 << 3),
+   MSI_FLAG_MULTI_PCI_MSI  = (1 << 2),
/* Support PCI MSIX interrupts */
-   MSI_FLAG_PCI_MSIX   = (1 << 4),
+   MSI_FLAG_PCI_MSIX   = (1 << 3),
 };
 
 int msi_domain_set_affinity(struct irq_data *data, const struct cpumask *mask,
diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
index 38e89ce..eb5bf2b 100644
--- a/kernel/irq/msi.c
+++ b/kernel/irq/msi.c
@@ -324,7 +324,7 @@ int msi_domain_alloc_irqs(struct irq_domain *domain, struct 
device *dev,
struct msi_domain_ops *ops = info->ops;
msi_alloc_info_t arg;
struct msi_desc *desc;
-   int i, ret, virq = -1;
+   int i, ret, virq;
 
ret = msi_domain_prepare_irqs(domain, dev, nvec, &arg);
if (ret)
@@ -332,12 +332,8 @@ int msi_domain_alloc_irqs(struct irq_domain *domain, 
struct device *dev,
 
for_each_msi_entry(desc, dev) {
ops->set_desc(&arg, desc);
-   if (info->flags & MSI_FLAG_IDENTITY_MAP)
-   virq = (int)ops->get_hwirq(info, &arg);
-   else
-   virq = -1;
 
-   virq = __irq_domain_alloc_irqs(domain, virq, desc->nvec_used,
+   virq = __irq_domain_alloc_irqs(domain, -1, desc->nvec_used,
   dev_to_node(dev), &arg, false);
if (virq < 0) {
ret = -ENOSPC;
-- 
2.1.4

[PATCH 02/13] irq: Introduce IRQD_AFFINITY_MANAGED flag

[Christoph Hellwig]

From: Thomas Gleixner 

Interupts marked with this flag are excluded from user space interrupt
affinity changes. Contrary to the IRQ_NO_BALANCING flag, the kernel internal
affinity mechanism is not blocked.

This flag will be used for multi-queue device interrupts.

Signed-off-by: Thomas Gleixner 
---
 include/linux/irq.h|  7 +++
 kernel/irq/internals.h |  2 ++
 kernel/irq/manage.c| 21 ++---
 kernel/irq/proc.c  |  2 +-
 4 files changed, 28 insertions(+), 4 deletions(-)

diff --git a/include/linux/irq.h b/include/linux/irq.h
index 4d758a7..f607481 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -197,6 +197,7 @@ struct irq_data {
  * IRQD_IRQ_INPROGRESS - In progress state of the interrupt
  * IRQD_WAKEUP_ARMED   - Wakeup mode armed
  * IRQD_FORWARDED_TO_VCPU  - The interrupt is forwarded to a VCPU
+ * IRQD_AFFINITY_MANAGED   - Affinity is auto-managed by the kernel
  */
 enum {
IRQD_TRIGGER_MASK   = 0xf,
@@ -212,6 +213,7 @@ enum {
IRQD_IRQ_INPROGRESS = (1 << 18),
IRQD_WAKEUP_ARMED   = (1 << 19),
IRQD_FORWARDED_TO_VCPU  = (1 << 20),
+   IRQD_AFFINITY_MANAGED   = (1 << 21),
 };
 
 #define __irqd_to_state(d) ACCESS_PRIVATE((d)->common, state_use_accessors)
@@ -305,6 +307,11 @@ static inline void irqd_clr_forwarded_to_vcpu(struct 
irq_data *d)
__irqd_to_state(d) &= ~IRQD_FORWARDED_TO_VCPU;
 }
 
+static inline bool irqd_affinity_is_managed(struct irq_data *d)
+{
+   return __irqd_to_state(d) & IRQD_AFFINITY_MANAGED;
+}
+
 #undef __irqd_to_state
 
 static inline irq_hw_number_t irqd_to_hwirq(struct irq_data *d)
diff --git a/kernel/irq/internals.h b/kernel/irq/internals.h
index 09be2c9..b15aa3b 100644
--- a/kernel/irq/internals.h
+++ b/kernel/irq/internals.h
@@ -105,6 +105,8 @@ static inline void unregister_handler_proc(unsigned int irq,
   struct irqaction *action) { }
 #endif
 
+extern bool irq_can_set_affinity_usr(unsigned int irq);
+
 extern int irq_select_affinity_usr(unsigned int irq, struct cpumask *mask);
 
 extern void irq_set_thread_affinity(struct irq_desc *desc);
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index ef0bc02..30658e9 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -115,12 +115,12 @@ EXPORT_SYMBOL(synchronize_irq);
 #ifdef CONFIG_SMP
 cpumask_var_t irq_default_affinity;
 
-static int __irq_can_set_affinity(struct irq_desc *desc)
+static bool __irq_can_set_affinity(struct irq_desc *desc)
 {
if (!desc || !irqd_can_balance(&desc->irq_data) ||
!desc->irq_data.chip || !desc->irq_data.chip->irq_set_affinity)
-   return 0;
-   return 1;
+   return false;
+   return true;
 }
 
 /**
@@ -134,6 +134,21 @@ int irq_can_set_affinity(unsigned int irq)
 }
 
 /**
+ * irq_can_set_affinity_usr - Check if affinity of a irq can be set from user 
space
+ * @irq:   Interrupt to check
+ *
+ * Like irq_can_set_affinity() above, but additionally checks for the
+ * AFFINITY_MANAGED flag.
+ */
+bool irq_can_set_affinity_usr(unsigned int irq)
+{
+   struct irq_desc *desc = irq_to_desc(irq);
+
+   return __irq_can_set_affinity(desc) &&
+   !irqd_affinity_is_managed(&desc->irq_data);
+}
+
+/**
  * irq_set_thread_affinity - Notify irq threads to adjust affinity
  * @desc:  irq descriptor which has affitnity changed
  *
diff --git a/kernel/irq/proc.c b/kernel/irq/proc.c
index 4e1b947..40bdcdc 100644
--- a/kernel/irq/proc.c
+++ b/kernel/irq/proc.c
@@ -96,7 +96,7 @@ static ssize_t write_irq_affinity(int type, struct file *file,
cpumask_var_t new_value;
int err;
 
-   if (!irq_can_set_affinity(irq) || no_irq_affinity)
+   if (!irq_can_set_affinity_usr(irq) || no_irq_affinity)
return -EIO;
 
if (!alloc_cpumask_var(&new_value, GFP_KERNEL))
-- 
2.1.4

[PATCH 04/13] irq: Use affinity hint in irqdesc allocation

[Christoph Hellwig]

Use the affinity hint in the irqdesc allocator. The hint is used to determine
the node for the allocation and to set the affinity of the interrupt.

If multiple interrupts are allocated (multi-MSI) then the allocator iterates
over the cpumask and for each set cpu it allocates on their node and sets the
initial affinity to that cpu.

If a single interrupt is allocated (MSI-X) then the allocator uses the first
cpu in the mask to compute the allocation node and uses the mask for the
initial affinity setting.

Interrupts set up this way are marked with the AFFINITY_MANAGED flag to
prevent userspace from messing with their affinity settings.

Signed-off-by: Thomas Gleixner 
---
 kernel/irq/irqdesc.c | 51 +++
 1 file changed, 39 insertions(+), 12 deletions(-)

diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index b8df4fc..a623b44 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -68,9 +68,13 @@ static int alloc_masks(struct irq_desc *desc, gfp_t gfp, int 
node)
return 0;
 }
 
-static void desc_smp_init(struct irq_desc *desc, int node)
+static void desc_smp_init(struct irq_desc *desc, int node,
+ const struct cpumask *affinity)
 {
-   cpumask_copy(desc->irq_common_data.affinity, irq_default_affinity);
+   if (!affinity)
+   affinity = irq_default_affinity;
+   cpumask_copy(desc->irq_common_data.affinity, affinity);
+
 #ifdef CONFIG_GENERIC_PENDING_IRQ
cpumask_clear(desc->pending_mask);
 #endif
@@ -82,11 +86,12 @@ static void desc_smp_init(struct irq_desc *desc, int node)
 #else
 static inline int
 alloc_masks(struct irq_desc *desc, gfp_t gfp, int node) { return 0; }
-static inline void desc_smp_init(struct irq_desc *desc, int node) { }
+static inline void
+desc_smp_init(struct irq_desc *desc, int node, const struct cpumask *affinity) 
{ }
 #endif
 
 static void desc_set_defaults(unsigned int irq, struct irq_desc *desc, int 
node,
-   struct module *owner)
+ const struct cpumask *affinity, struct module 
*owner)
 {
int cpu;
 
@@ -107,7 +112,7 @@ static void desc_set_defaults(unsigned int irq, struct 
irq_desc *desc, int node,
desc->owner = owner;
for_each_possible_cpu(cpu)
*per_cpu_ptr(desc->kstat_irqs, cpu) = 0;
-   desc_smp_init(desc, node);
+   desc_smp_init(desc, node, affinity);
 }
 
 int nr_irqs = NR_IRQS;
@@ -158,7 +163,9 @@ void irq_unlock_sparse(void)
mutex_unlock(&sparse_irq_lock);
 }
 
-static struct irq_desc *alloc_desc(int irq, int node, struct module *owner)
+static struct irq_desc *alloc_desc(int irq, int node, unsigned int flags,
+  const struct cpumask *affinity,
+  struct module *owner)
 {
struct irq_desc *desc;
gfp_t gfp = GFP_KERNEL;
@@ -178,7 +185,8 @@ static struct irq_desc *alloc_desc(int irq, int node, 
struct module *owner)
lockdep_set_class(&desc->lock, &irq_desc_lock_class);
init_rcu_head(&desc->rcu);
 
-   desc_set_defaults(irq, desc, node, owner);
+   desc_set_defaults(irq, desc, node, affinity, owner);
+   irqd_set(&desc->irq_data, flags);
 
return desc;
 
@@ -225,11 +233,30 @@ static void free_desc(unsigned int irq)
 static int alloc_descs(unsigned int start, unsigned int cnt, int node,
   const struct cpumask *affinity, struct module *owner)
 {
+   const struct cpumask *mask = NULL;
struct irq_desc *desc;
-   int i;
+   unsigned int flags;
+   int i, cpu = -1;
+
+   if (affinity && cpumask_empty(affinity))
+   return -EINVAL;
+
+   flags = affinity ? IRQD_AFFINITY_MANAGED : 0;
 
for (i = 0; i < cnt; i++) {
-   desc = alloc_desc(start + i, node, owner);
+   if (affinity) {
+   cpu = cpumask_next(cpu, affinity);
+   if (cpu >= nr_cpu_ids)
+   cpu = cpumask_first(affinity);
+   node = cpu_to_node(cpu);
+
+   /*
+* For single allocations we use the caller provided
+* mask otherwise we use the mask of the target cpu
+*/
+   mask = cnt == 1 ? affinity : cpumask_of(cpu);
+   }
+   desc = alloc_desc(start + i, node, flags, mask, owner);
if (!desc)
goto err;
mutex_lock(&sparse_irq_lock);
@@ -277,7 +304,7 @@ int __init early_irq_init(void)
nr_irqs = initcnt;
 
for (i = 0; i < initcnt; i++) {
-   desc = alloc_desc(i, node, NULL);
+   desc = alloc_desc(i, node, 0, NULL, NULL);
set_bit(i, allocated_irqs);
irq_insert_desc(i, desc);
}
@@ -311,7 +338,7 @@ int __init early_irq_init(void)

[PATCH 05/13] irq/msi: Make use of affinity aware allocations

[Christoph Hellwig]

From: Thomas Gleixner 

Allow the MSI code to provide affinity hints per MSI descriptor.

Signed-off-by: Thomas Gleixner 
---
 include/linux/msi.h | 2 ++
 kernel/irq/msi.c| 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/linux/msi.h b/include/linux/msi.h
index c33abfa..4f0bfe5 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -47,6 +47,7 @@ struct fsl_mc_msi_desc {
  * @nvec_used: The number of vectors used
  * @dev:   Pointer to the device which uses this descriptor
  * @msg:   The last set MSI message cached for reuse
+ * @affinity:  Optional pointer to a cpu affinity mask for this descriptor
  *
  * @masked:[PCI MSI/X] Mask bits
  * @is_msix:   [PCI MSI/X] True if MSI-X
@@ -67,6 +68,7 @@ struct msi_desc {
unsigned intnvec_used;
struct device   *dev;
struct msi_msg  msg;
+   const struct cpumask*affinity;
 
union {
/* PCI MSI/X specific data */
diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
index 58dbbac..0e2a736 100644
--- a/kernel/irq/msi.c
+++ b/kernel/irq/msi.c
@@ -335,7 +335,7 @@ int msi_domain_alloc_irqs(struct irq_domain *domain, struct 
device *dev,
 
virq = __irq_domain_alloc_irqs(domain, -1, desc->nvec_used,
   dev_to_node(dev), &arg, false,
-  NULL);
+  desc->affinity);
if (virq < 0) {
ret = -ENOSPC;
if (ops->handle_error)
-- 
2.1.4

automatic interrupt affinity for MSI/MSI-X capable devices V3

[Christoph Hellwig]

This series enhances the irq and PCI code to allow spreading around MSI and
MSI-X vectors so that they have per-cpu affinity if possible, or at least
per-node.  For that it takes the algorithm from blk-mq, moves it to
a common place, and makes it available through a vastly simplified PCI
interrupt allocation API.  It then switches blk-mq to be able to pick up
the queue mapping from the device if available, and demonstrates all this
using the NVMe driver.

Compared to the last posting the core IRQ changes are stable and it would
be great to get them merged int the tip tree.  The two PCI patches have
been completely rewritten after feedback from Alexander, while the block
changes have also been stable.

There also is a git tree available at:

   git://git.infradead.org/users/hch/block.git msix-spreading.6

Gitweb:

   
http://git.infradead.org/users/hch/block.git/shortlog/refs/heads/msix-spreading.6

Changes since V2:
 - improve the description of IRQD_AFFINITY_MANAGED
 - update MSI-HOWTO.txt
 - add a PCI_IRQ_NOMSI flag to avoid using MSI vectors
 - add a PCI_IRQ_NOAFFINITY flag to skip auto affinity
 - change the irq_create_affinity_mask calling convention
 - rewrite pci_alloc_irq_vectors to create the affinity mask only after
   we know the final vector count
 - cleanup pci_free_irq_vectors
 - replace pdev->irqs with pdev->msix_vectors and introduce
   a pci_irq_vector helper to get the Linux IRQ numbers

Changes since V1:
 - irq core improvements to properly assign the affinity before
   request_irq (tglx)
 - better handling of the MSI vs MSI-X differences in the low level
   MSI allocator (hch and tglx)
 - various improvements to pci_alloc_irq_vectors (hch)
 - remove blk-mq hardware queue reassigned on hotplug cpu events (hch)
 - forward ported to Jens' current for-next tree (hch)

[PATCH 08/13] pci: spread interrupt vectors in pci_alloc_irq_vectors

[Christoph Hellwig]

Set the affinity_mask in the PCI device before allocating vectors so that
the affinity can be propagated through the MSI descriptor structures to
the core IRQ code.  Add a new helper __pci_enable_msi_range which is
similar to __pci_enable_msix_range introduced in the last patch so that
we can allocate the affinity mask in a self-contained fashion and for the
right number of vectors.

A new PCI_IRQ_NOAFFINITY flag is added to pci_alloc_irq_vectors so that
this function can also be used by drivers that don't wish to use the
automatic affinity assignment.

Signed-off-by: Christoph Hellwig 
---
 Documentation/PCI/MSI-HOWTO.txt |  3 +-
 drivers/pci/msi.c   | 72 ++---
 include/linux/pci.h |  2 ++
 3 files changed, 72 insertions(+), 5 deletions(-)

diff --git a/Documentation/PCI/MSI-HOWTO.txt b/Documentation/PCI/MSI-HOWTO.txt
index 35d1326..dcd3f6d 100644
--- a/Documentation/PCI/MSI-HOWTO.txt
+++ b/Documentation/PCI/MSI-HOWTO.txt
@@ -95,7 +95,8 @@ argument set to this limit, and the PCI core will return 
-ENOSPC if it can't
 meet the minimum number of vectors.
 The flags argument should normally be set to 0, but can be used to
 pass the PCI_IRQ_NOMSI and PCI_IRQ_NOMSIX flag in case a device claims
-to support MSI or MSI-X, but the support is broken.
+to support MSI or MSI-X, but the support is broken, or to PCI_IRQ_NOAFFINITY
+if the driver does not wish to use the automatic affinity assignment feature.
 
 To get the Linux IRQ numbers passed to request_irq and free_irq
 and the vectors use the following function:
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 6b0834d..7f38e07 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -568,6 +568,7 @@ static struct msi_desc *msi_setup_entry(struct pci_dev 
*dev, int nvec)
entry->msi_attrib.multi_cap = (control & PCI_MSI_FLAGS_QMASK) >> 1;
entry->msi_attrib.multiple  = ilog2(__roundup_pow_of_two(nvec));
entry->nvec_used= nvec;
+   entry->affinity = dev->irq_affinity;
 
if (control & PCI_MSI_FLAGS_64BIT)
entry->mask_pos = dev->msi_cap + PCI_MSI_MASK_64;
@@ -679,10 +680,18 @@ static void __iomem *msix_map_region(struct pci_dev *dev, 
unsigned nr_entries)
 static int msix_setup_entries(struct pci_dev *dev, void __iomem *base,
  struct msix_entry *entries, int nvec)
 {
+   const struct cpumask *mask = NULL;
struct msi_desc *entry;
-   int i;
+   int cpu = -1, i;
 
for (i = 0; i < nvec; i++) {
+   if (dev->irq_affinity) {
+   cpu = cpumask_next(cpu, dev->irq_affinity);
+   if (cpu >= nr_cpu_ids)
+   cpu = cpumask_first(dev->irq_affinity);
+   mask = cpumask_of(cpu);
+   }
+
entry = alloc_msi_entry(&dev->dev);
if (!entry) {
if (!i)
@@ -699,6 +708,7 @@ static int msix_setup_entries(struct pci_dev *dev, void 
__iomem *base,
entry->msi_attrib.default_irq   = dev->irq;
entry->mask_base= base;
entry->nvec_used= 1;
+   entry->affinity = mask;
 
list_add_tail(&entry->list, dev_to_msi_list(&dev->dev));
}
@@ -1121,8 +1131,53 @@ int pci_enable_msix_range(struct pci_dev *dev, struct 
msix_entry *entries,
 }
 EXPORT_SYMBOL(pci_enable_msix_range);
 
+static int __pci_enable_msi_range(struct pci_dev *dev, int min_vecs, int 
max_vecs,
+   unsigned int flags)
+{
+   int vecs, ret;
+
+   if (!pci_msi_supported(dev, min_vecs))
+   return -EINVAL;
+
+   vecs = pci_msi_vec_count(dev);
+   if (vecs < 0)
+   return vecs;
+   if (vecs < min_vecs)
+   return -EINVAL;
+   if (vecs > max_vecs)
+   vecs = max_vecs;
+
+retry:
+   if (vecs < min_vecs)
+   return -ENOSPC;
+
+   if (!(flags & PCI_IRQ_NOAFFINITY)) {
+   dev->irq_affinity = irq_create_affinity_mask(&vecs);
+   if (vecs < min_vecs) {
+   ret = -ERANGE;
+   goto out_fail;
+   }
+   }
+
+   ret = msi_capability_init(dev, vecs);
+   if (ret)
+   goto out_fail;
+
+   return vecs;
+
+out_fail:
+   kfree(dev->irq_affinity);
+   if (ret >= 0) {
+   /* retry with the actually supported number of vectors */
+   vecs = ret;
+   goto retry;
+   }
+
+   return ret;
+}
+
 static int __pci_enable_msix_range(struct pci_dev *dev, unsigned int min_vecs,
-   unsigned int max_vecs)
+   unsigned int max_vecs, unsigned int flags)
 {
int vecs = max_vecs, ret, i;
 
@@ -1138,6 +1193,13 @@ retry:
for (i = 0; i < vecs; i++)
dev->msix_vectors[i].e

[PATCH 10/13] blk-mq: only allocate a single mq_map per tag_set

[Christoph Hellwig]

The mapping is identical for all queues in a tag_set, so stop wasting
memory for building multiple.  Note that for now I've kept the mq_map
pointer in the request_queue, but we'll need to investigate if we can
remove it without suffering from the additional indirection.  The same
would apply to the mq_ops pointer as well.

Signed-off-by: Christoph Hellwig 
---
 block/blk-mq.c | 22 ++
 include/linux/blk-mq.h |  1 +
 2 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/block/blk-mq.c b/block/blk-mq.c
index f972d32..622cb22 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -1930,7 +1930,6 @@ void blk_mq_release(struct request_queue *q)
kfree(hctx);
}
 
-   kfree(q->mq_map);
q->mq_map = NULL;
 
kfree(q->queue_hw_ctx);
@@ -2029,9 +2028,7 @@ struct request_queue *blk_mq_init_allocated_queue(struct 
blk_mq_tag_set *set,
if (!q->queue_hw_ctx)
goto err_percpu;
 
-   q->mq_map = blk_mq_make_queue_map(set);
-   if (!q->mq_map)
-   goto err_map;
+   q->mq_map = set->mq_map;
 
blk_mq_realloc_hw_ctxs(set, q);
if (!q->nr_hw_queues)
@@ -2081,8 +2078,6 @@ struct request_queue *blk_mq_init_allocated_queue(struct 
blk_mq_tag_set *set,
return q;
 
 err_hctxs:
-   kfree(q->mq_map);
-err_map:
kfree(q->queue_hw_ctx);
 err_percpu:
free_percpu(q->queue_ctx);
@@ -2304,14 +2299,22 @@ int blk_mq_alloc_tag_set(struct blk_mq_tag_set *set)
if (!set->tags)
return -ENOMEM;
 
+   set->mq_map = blk_mq_make_queue_map(set);
+   if (!set->mq_map)
+   goto out_free_tags;
+
if (blk_mq_alloc_rq_maps(set))
-   goto enomem;
+   goto out_free_mq_map;
 
mutex_init(&set->tag_list_lock);
INIT_LIST_HEAD(&set->tag_list);
 
return 0;
-enomem:
+
+out_free_mq_map:
+   kfree(set->mq_map);
+   set->mq_map = NULL;
+out_free_tags:
kfree(set->tags);
set->tags = NULL;
return -ENOMEM;
@@ -2327,6 +2330,9 @@ void blk_mq_free_tag_set(struct blk_mq_tag_set *set)
blk_mq_free_rq_map(set, set->tags[i], i);
}
 
+   kfree(set->mq_map);
+   set->mq_map = NULL;
+
kfree(set->tags);
set->tags = NULL;
 }
diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
index 2498fdf..0a3b138 100644
--- a/include/linux/blk-mq.h
+++ b/include/linux/blk-mq.h
@@ -65,6 +65,7 @@ struct blk_mq_hw_ctx {
 };
 
 struct blk_mq_tag_set {
+   unsigned int*mq_map;
struct blk_mq_ops   *ops;
unsigned intnr_hw_queues;
unsigned intqueue_depth;/* max hw supported */
-- 
2.1.4

[PATCH 11/13] blk-mq: allow the driver to pass in an affinity mask

[Christoph Hellwig]

Allow drivers to pass in the affinity mask from the generic interrupt
layer, and spread queues based on that.  If the driver doesn't pass in
a mask we will create it using the genirq helper.  As this helper was
modelled after the blk-mq algorithm there should be no change in
behavior.

Signed-off-by: Christoph Hellwig 
---
 block/Makefile |   2 +-
 block/blk-mq-cpumap.c  | 120 -
 block/blk-mq.c |  68 +---
 block/blk-mq.h |   8 
 include/linux/blk-mq.h |   1 +
 5 files changed, 65 insertions(+), 134 deletions(-)
 delete mode 100644 block/blk-mq-cpumap.c

diff --git a/block/Makefile b/block/Makefile
index 9eda232..aeb318d 100644
--- a/block/Makefile
+++ b/block/Makefile
@@ -6,7 +6,7 @@ obj-$(CONFIG_BLOCK) := bio.o elevator.o blk-core.o blk-tag.o 
blk-sysfs.o \
blk-flush.o blk-settings.o blk-ioc.o blk-map.o \
blk-exec.o blk-merge.o blk-softirq.o blk-timeout.o \
blk-lib.o blk-mq.o blk-mq-tag.o \
-   blk-mq-sysfs.o blk-mq-cpu.o blk-mq-cpumap.o ioctl.o \
+   blk-mq-sysfs.o blk-mq-cpu.o ioctl.o \
genhd.o scsi_ioctl.o partition-generic.o ioprio.o \
badblocks.o partitions/
 
diff --git a/block/blk-mq-cpumap.c b/block/blk-mq-cpumap.c
deleted file mode 100644
index d0634bc..000
--- a/block/blk-mq-cpumap.c
+++ /dev/null
@@ -1,120 +0,0 @@
-/*
- * CPU <-> hardware queue mapping helpers
- *
- * Copyright (C) 2013-2014 Jens Axboe
- */
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include "blk.h"
-#include "blk-mq.h"
-
-static int cpu_to_queue_index(unsigned int nr_cpus, unsigned int nr_queues,
- const int cpu)
-{
-   return cpu * nr_queues / nr_cpus;
-}
-
-static int get_first_sibling(unsigned int cpu)
-{
-   unsigned int ret;
-
-   ret = cpumask_first(topology_sibling_cpumask(cpu));
-   if (ret < nr_cpu_ids)
-   return ret;
-
-   return cpu;
-}
-
-int blk_mq_update_queue_map(unsigned int *map, unsigned int nr_queues,
-   const struct cpumask *online_mask)
-{
-   unsigned int i, nr_cpus, nr_uniq_cpus, queue, first_sibling;
-   cpumask_var_t cpus;
-
-   if (!alloc_cpumask_var(&cpus, GFP_ATOMIC))
-   return 1;
-
-   cpumask_clear(cpus);
-   nr_cpus = nr_uniq_cpus = 0;
-   for_each_cpu(i, online_mask) {
-   nr_cpus++;
-   first_sibling = get_first_sibling(i);
-   if (!cpumask_test_cpu(first_sibling, cpus))
-   nr_uniq_cpus++;
-   cpumask_set_cpu(i, cpus);
-   }
-
-   queue = 0;
-   for_each_possible_cpu(i) {
-   if (!cpumask_test_cpu(i, online_mask)) {
-   map[i] = 0;
-   continue;
-   }
-
-   /*
-* Easy case - we have equal or more hardware queues. Or
-* there are no thread siblings to take into account. Do
-* 1:1 if enough, or sequential mapping if less.
-*/
-   if (nr_queues >= nr_cpus || nr_cpus == nr_uniq_cpus) {
-   map[i] = cpu_to_queue_index(nr_cpus, nr_queues, queue);
-   queue++;
-   continue;
-   }
-
-   /*
-* Less then nr_cpus queues, and we have some number of
-* threads per cores. Map sibling threads to the same
-* queue.
-*/
-   first_sibling = get_first_sibling(i);
-   if (first_sibling == i) {
-   map[i] = cpu_to_queue_index(nr_uniq_cpus, nr_queues,
-   queue);
-   queue++;
-   } else
-   map[i] = map[first_sibling];
-   }
-
-   free_cpumask_var(cpus);
-   return 0;
-}
-
-unsigned int *blk_mq_make_queue_map(struct blk_mq_tag_set *set)
-{
-   unsigned int *map;
-
-   /* If cpus are offline, map them to first hctx */
-   map = kzalloc_node(sizeof(*map) * nr_cpu_ids, GFP_KERNEL,
-   set->numa_node);
-   if (!map)
-   return NULL;
-
-   if (!blk_mq_update_queue_map(map, set->nr_hw_queues, cpu_online_mask))
-   return map;
-
-   kfree(map);
-   return NULL;
-}
-
-/*
- * We have no quick way of doing reverse lookups. This is only used at
- * queue init time, so runtime isn't important.
- */
-int blk_mq_hw_queue_to_node(unsigned int *mq_map, unsigned int index)
-{
-   int i;
-
-   for_each_possible_cpu(i) {
-   if (index == mq_map[i])
-   return local_memory_node(cpu_to_node(i));
-   }
-
-   return NUMA_NO_NODE;
-}
diff --git a/block/blk-mq.c b/bloc

[PATCH 06/13] irq: add a helper spread an affinity mask for MSI/MSI-X vectors

[Christoph Hellwig]

This is lifted from the blk-mq code and adopted to use the affinity mask
concept just introduced in the irq handling code.  It tries to keep the
algorithm the same as the one current used by blk-mq, but improvements
like assining vectors on a per-node basis instead of just per sibling
are possible on of this simple move and refactoring.

Signed-off-by: Christoph Hellwig 
---
 include/linux/interrupt.h |  8 +++
 kernel/irq/Makefile   |  1 +
 kernel/irq/affinity.c | 61 +++
 3 files changed, 70 insertions(+)
 create mode 100644 kernel/irq/affinity.c

diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 9fcabeb..b6683f0 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -278,6 +278,8 @@ extern int irq_set_affinity_hint(unsigned int irq, const 
struct cpumask *m);
 extern int
 irq_set_affinity_notifier(unsigned int irq, struct irq_affinity_notify 
*notify);
 
+struct cpumask *irq_create_affinity_mask(unsigned int *nr_vecs);
+
 #else /* CONFIG_SMP */
 
 static inline int irq_set_affinity(unsigned int irq, const struct cpumask *m)
@@ -308,6 +310,12 @@ irq_set_affinity_notifier(unsigned int irq, struct 
irq_affinity_notify *notify)
 {
return 0;
 }
+
+static inline struct cpumask *irq_create_affinity_mask(unsigned int *nr_vecs)
+{
+   *nr_vecs = 1;
+   return NULL;
+}
 #endif /* CONFIG_SMP */
 
 /*
diff --git a/kernel/irq/Makefile b/kernel/irq/Makefile
index 2ee42e9..1d3ee31 100644
--- a/kernel/irq/Makefile
+++ b/kernel/irq/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_GENERIC_IRQ_MIGRATION) += cpuhotplug.o
 obj-$(CONFIG_PM_SLEEP) += pm.o
 obj-$(CONFIG_GENERIC_MSI_IRQ) += msi.o
 obj-$(CONFIG_GENERIC_IRQ_IPI) += ipi.o
+obj-$(CONFIG_SMP) += affinity.o
diff --git a/kernel/irq/affinity.c b/kernel/irq/affinity.c
new file mode 100644
index 000..f689593
--- /dev/null
+++ b/kernel/irq/affinity.c
@@ -0,0 +1,61 @@
+
+#include 
+#include 
+#include 
+#include 
+
+static int get_first_sibling(unsigned int cpu)
+{
+   unsigned int ret;
+
+   ret = cpumask_first(topology_sibling_cpumask(cpu));
+   if (ret < nr_cpu_ids)
+   return ret;
+   return cpu;
+}
+
+/*
+ * Take a map of online CPUs and the number of available interrupt vectors
+ * and generate an output cpumask suitable for spreading MSI/MSI-X vectors
+ * so that they are distributed as good as possible around the CPUs.  If
+ * more vectors than CPUs are available we'll map one to each CPU,
+ * otherwise we map one to the first sibling of each socket.
+ *
+ * If there are more vectors than CPUs we will still only have one bit
+ * set per CPU, but interrupt code will keep on assigning the vectors from
+ * the start of the bitmap until we run out of vectors.
+ */
+struct cpumask *irq_create_affinity_mask(unsigned int *nr_vecs)
+{
+   struct cpumask *affinity_mask;
+   unsigned int max_vecs = *nr_vecs;
+
+   if (max_vecs == 1)
+   return NULL;
+
+   affinity_mask = kzalloc(cpumask_size(), GFP_KERNEL);
+   if (!affinity_mask) {
+   *nr_vecs = 1;
+   return NULL;
+   }
+
+   if (max_vecs >= num_online_cpus()) {
+   cpumask_copy(affinity_mask, cpu_online_mask);
+   *nr_vecs = num_online_cpus();
+   } else {
+   unsigned int vecs = 0, cpu;
+
+   for_each_online_cpu(cpu) {
+   if (cpu == get_first_sibling(cpu)) {
+   cpumask_set_cpu(cpu, affinity_mask);
+   vecs++;
+   }
+
+   if (--max_vecs == 0)
+   break;
+   }
+   *nr_vecs = vecs;
+   }
+
+   return affinity_mask;
+}
-- 
2.1.4

[PATCH 13/13] nvme: remove the post_scan callout

[Christoph Hellwig]

No need now that we don't have to reverse engineer the irq affinity.

Signed-off-by: Christoph Hellwig 
---
 drivers/nvme/host/core.c | 3 ---
 drivers/nvme/host/nvme.h | 1 -
 2 files changed, 4 deletions(-)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 9d7cee4..b100cce 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -1627,9 +1627,6 @@ static void nvme_scan_work(struct work_struct *work)
list_sort(NULL, &ctrl->namespaces, ns_cmp);
mutex_unlock(&ctrl->namespaces_mutex);
kfree(id);
-
-   if (ctrl->ops->post_scan)
-   ctrl->ops->post_scan(ctrl);
 }
 
 void nvme_queue_scan(struct nvme_ctrl *ctrl)
diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
index 282421f..bb343b3 100644
--- a/drivers/nvme/host/nvme.h
+++ b/drivers/nvme/host/nvme.h
@@ -150,7 +150,6 @@ struct nvme_ctrl_ops {
int (*reg_read64)(struct nvme_ctrl *ctrl, u32 off, u64 *val);
int (*reset_ctrl)(struct nvme_ctrl *ctrl);
void (*free_ctrl)(struct nvme_ctrl *ctrl);
-   void (*post_scan)(struct nvme_ctrl *ctrl);
void (*submit_async_event)(struct nvme_ctrl *ctrl, int aer_idx);
 };
 
-- 
2.1.4

[PATCH 09/13] blk-mq: don't redistribute hardware queues on a CPU hotplug event

[Christoph Hellwig]

Currently blk-mq will totally remap hardware context when a CPU hotplug
even happened, which causes major havoc for drivers, as they are never
told about this remapping.  E.g. any carefully sorted out CPU affinity
will just be completely messed up.

The rebuild also doesn't really help for the common case of cpu
hotplug, which is soft onlining / offlining of cpus - in this case we
should just leave the queue and irq mapping as is.  If it actually
worked it would have helped in the case of physical cpu hotplug,
although for that we'd need a way to actually notify the driver.
Note that drivers may already be able to accommodate such a topology
change on their own, e.g. using the reset_controller sysfs file in NVMe
will cause the driver to get things right for this case.

With the rebuild removed we will simplify retain the queue mapping for
a soft offlined CPU that will work when it comes back online, and will
map any newly onlined CPU to queue NULL until the driver initiates
a rebuild of the queue map.

Signed-off-by: Christoph Hellwig 
---
 block/blk-mq.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/block/blk-mq.c b/block/blk-mq.c
index bc7166d..f972d32 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -2114,8 +2114,6 @@ static void blk_mq_queue_reinit(struct request_queue *q,
 
blk_mq_sysfs_unregister(q);
 
-   blk_mq_update_queue_map(q->mq_map, q->nr_hw_queues, online_mask);
-
/*
 * redo blk_mq_init_cpu_queues and blk_mq_init_hw_queues. FIXME: maybe
 * we should change hctx numa_node according to new topology (this
-- 
2.1.4

[PATCH 12/13] nvme: switch to use pci_alloc_irq_vectors

[Christoph Hellwig]

Use the new helper to automatically select the right interrupt type, as
well as to use the automatic interupt affinity assignment.

Signed-off-by: Christoph Hellwig 
---
 drivers/nvme/host/pci.c | 98 ++---
 1 file changed, 27 insertions(+), 71 deletions(-)

diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index dc39924..336a346 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -88,7 +88,6 @@ struct nvme_dev {
unsigned max_qid;
int q_depth;
u32 db_stride;
-   struct msix_entry *entry;
void __iomem *bar;
struct work_struct reset_work;
struct work_struct remove_work;
@@ -201,6 +200,11 @@ static unsigned int nvme_cmd_size(struct nvme_dev *dev)
nvme_iod_alloc_size(dev, NVME_INT_BYTES(dev), NVME_INT_PAGES);
 }
 
+static int nvmeq_irq(struct nvme_queue *nvmeq)
+{
+   return pci_irq_vector(to_pci_dev(nvmeq->dev->dev), nvmeq->cq_vector);
+}
+
 static int nvme_admin_init_hctx(struct blk_mq_hw_ctx *hctx, void *data,
unsigned int hctx_idx)
 {
@@ -954,7 +958,7 @@ static int nvme_suspend_queue(struct nvme_queue *nvmeq)
spin_unlock_irq(&nvmeq->q_lock);
return 1;
}
-   vector = nvmeq->dev->entry[nvmeq->cq_vector].vector;
+   vector = nvmeq_irq(nvmeq);
nvmeq->dev->online_queues--;
nvmeq->cq_vector = -1;
spin_unlock_irq(&nvmeq->q_lock);
@@ -962,7 +966,6 @@ static int nvme_suspend_queue(struct nvme_queue *nvmeq)
if (!nvmeq->qid && nvmeq->dev->ctrl.admin_q)
blk_mq_stop_hw_queues(nvmeq->dev->ctrl.admin_q);
 
-   irq_set_affinity_hint(vector, NULL);
free_irq(vector, nvmeq);
 
return 0;
@@ -1069,15 +1072,14 @@ static struct nvme_queue *nvme_alloc_queue(struct 
nvme_dev *dev, int qid,
return NULL;
 }
 
-static int queue_request_irq(struct nvme_dev *dev, struct nvme_queue *nvmeq,
-   const char *name)
+static int queue_request_irq(struct nvme_queue *nvmeq)
 {
if (use_threaded_interrupts)
-   return request_threaded_irq(dev->entry[nvmeq->cq_vector].vector,
-   nvme_irq_check, nvme_irq, IRQF_SHARED,
-   name, nvmeq);
-   return request_irq(dev->entry[nvmeq->cq_vector].vector, nvme_irq,
-   IRQF_SHARED, name, nvmeq);
+   return request_threaded_irq(nvmeq_irq(nvmeq), nvme_irq_check,
+   nvme_irq, IRQF_SHARED, nvmeq->irqname, nvmeq);
+   else
+   return request_irq(nvmeq_irq(nvmeq), nvme_irq, IRQF_SHARED,
+   nvmeq->irqname, nvmeq);
 }
 
 static void nvme_init_queue(struct nvme_queue *nvmeq, u16 qid)
@@ -1108,7 +1110,7 @@ static int nvme_create_queue(struct nvme_queue *nvmeq, 
int qid)
if (result < 0)
goto release_cq;
 
-   result = queue_request_irq(dev, nvmeq, nvmeq->irqname);
+   result = queue_request_irq(nvmeq);
if (result < 0)
goto release_sq;
 
@@ -1228,7 +1230,7 @@ static int nvme_configure_admin_queue(struct nvme_dev 
*dev)
goto free_nvmeq;
 
nvmeq->cq_vector = 0;
-   result = queue_request_irq(dev, nvmeq, nvmeq->irqname);
+   result = queue_request_irq(nvmeq);
if (result) {
nvmeq->cq_vector = -1;
goto free_nvmeq;
@@ -1376,7 +1378,7 @@ static int nvme_setup_io_queues(struct nvme_dev *dev)
 {
struct nvme_queue *adminq = dev->queues[0];
struct pci_dev *pdev = to_pci_dev(dev->dev);
-   int result, i, vecs, nr_io_queues, size;
+   int result, nr_io_queues, size;
 
nr_io_queues = num_online_cpus();
result = nvme_set_queue_count(&dev->ctrl, &nr_io_queues);
@@ -1411,29 +1413,17 @@ static int nvme_setup_io_queues(struct nvme_dev *dev)
}
 
/* Deregister the admin queue's interrupt */
-   free_irq(dev->entry[0].vector, adminq);
+   free_irq(pci_irq_vector(pdev, 0), adminq);
 
/*
 * If we enable msix early due to not intx, disable it again before
 * setting up the full range we need.
 */
-   if (pdev->msi_enabled)
-   pci_disable_msi(pdev);
-   else if (pdev->msix_enabled)
-   pci_disable_msix(pdev);
-
-   for (i = 0; i < nr_io_queues; i++)
-   dev->entry[i].entry = i;
-   vecs = pci_enable_msix_range(pdev, dev->entry, 1, nr_io_queues);
-   if (vecs < 0) {
-   vecs = pci_enable_msi_range(pdev, 1, min(nr_io_queues, 32));
-   if (vecs < 0) {
-   vecs = 1;
-   } else {
-   for (i = 0; i < vecs; i++)
-   dev->entry[i].vector = i + pdev->irq;
-   }
-   }
+   pci_free_irq_vectors(pdev);
+

Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed

[Neo Jia]

On Mon, Jul 04, 2016 at 04:19:20PM +0800, Xiao Guangrong wrote:
> 
> 
> On 07/04/2016 03:53 PM, Neo Jia wrote:
> >On Mon, Jul 04, 2016 at 03:37:35PM +0800, Xiao Guangrong wrote:
> >>
> >>
> >>On 07/04/2016 03:03 PM, Neo Jia wrote:
> >>>On Mon, Jul 04, 2016 at 02:39:22PM +0800, Xiao Guangrong wrote:
> 
> 
> On 06/30/2016 09:01 PM, Paolo Bonzini wrote:
> >The vGPU folks would like to trap the first access to a BAR by setting
> >vm_ops on the VMAs produced by mmap-ing a VFIO device.  The fault handler
> >then can use remap_pfn_range to place some non-reserved pages in the VMA.
> 
> Why does it require fetching the pfn when the fault is triggered rather
> than when mmap() is called?
> >>>
> >>>Hi Guangrong,
> >>>
> >>>as such mapping information between virtual mmio to physical mmio is only 
> >>>available
> >>>at runtime.
> >>
> >>Sorry, i do not know what the different between mmap() and the time VM 
> >>actually
> >>accesses the memory for your case. Could you please more detail?
> >
> >Hi Guangrong,
> >
> >Sure. The mmap() gets called by qemu or any VFIO API userspace consumer when
> >setting up the virtual mmio, at that moment nobody has any knowledge about 
> >how
> >the physical mmio gets virtualized.
> >
> >When the vm (or application if we don't want to limit ourselves to vmm term)
> >starts, the virtual and physical mmio gets mapped by mpci kernel module with 
> >the
> >help from vendor supplied mediated host driver according to the hw resource
> >assigned to this vm / application.
> 
> Thanks for your expiation.
> 
> It sounds like a strategy of resource allocation, you delay the allocation 
> until VM really
> accesses it, right?

Yes, that is where the fault handler inside mpci code comes to the picture.

Thanks,
Neo

[PATCH 03/13] irq: Add affinity hint to irq allocation

[Christoph Hellwig]

From: Thomas Gleixner 

Add an extra argument to the irq(domain) allocation functions, so we can hand
down affinity hints to the allocator. Thats necessary to implement proper
support for multiqueue devices.

Signed-off-by: Thomas Gleixner 
---
 arch/sparc/kernel/irq_64.c |  2 +-
 arch/x86/kernel/apic/io_apic.c |  5 +++--
 include/linux/irq.h|  4 ++--
 include/linux/irqdomain.h  |  9 ++---
 kernel/irq/ipi.c   |  2 +-
 kernel/irq/irqdesc.c   | 12 
 kernel/irq/irqdomain.c | 22 ++
 kernel/irq/manage.c|  7 ---
 kernel/irq/msi.c   |  3 ++-
 9 files changed, 41 insertions(+), 25 deletions(-)

diff --git a/arch/sparc/kernel/irq_64.c b/arch/sparc/kernel/irq_64.c
index e22416c..34a7930 100644
--- a/arch/sparc/kernel/irq_64.c
+++ b/arch/sparc/kernel/irq_64.c
@@ -242,7 +242,7 @@ unsigned int irq_alloc(unsigned int dev_handle, unsigned 
int dev_ino)
 {
int irq;
 
-   irq = __irq_alloc_descs(-1, 1, 1, numa_node_id(), NULL);
+   irq = __irq_alloc_descs(-1, 1, 1, numa_node_id(), NULL, NULL);
if (irq <= 0)
goto out;
 
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 84e33ff..bca0c81 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -981,7 +981,7 @@ static int alloc_irq_from_domain(struct irq_domain *domain, 
int ioapic, u32 gsi,
 
return __irq_domain_alloc_irqs(domain, irq, 1,
   ioapic_alloc_attr_node(info),
-  info, legacy);
+  info, legacy, NULL);
 }
 
 /*
@@ -1014,7 +1014,8 @@ static int alloc_isa_irq_from_domain(struct irq_domain 
*domain,
  info->ioapic_pin))
return -ENOMEM;
} else {
-   irq = __irq_domain_alloc_irqs(domain, irq, 1, node, info, true);
+   irq = __irq_domain_alloc_irqs(domain, irq, 1, node, info, true,
+ NULL);
if (irq >= 0) {
irq_data = irq_domain_get_irq_data(domain, irq);
data = irq_data->chip_data;
diff --git a/include/linux/irq.h b/include/linux/irq.h
index f607481..39ce46a 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -708,11 +708,11 @@ static inline struct cpumask 
*irq_data_get_affinity_mask(struct irq_data *d)
 unsigned int arch_dynirq_lower_bound(unsigned int from);
 
 int __irq_alloc_descs(int irq, unsigned int from, unsigned int cnt, int node,
-   struct module *owner);
+ struct module *owner, const struct cpumask *affinity);
 
 /* use macros to avoid needing export.h for THIS_MODULE */
 #define irq_alloc_descs(irq, from, cnt, node)  \
-   __irq_alloc_descs(irq, from, cnt, node, THIS_MODULE)
+   __irq_alloc_descs(irq, from, cnt, node, THIS_MODULE, NULL)
 
 #define irq_alloc_desc(node)   \
irq_alloc_descs(-1, 0, 1, node)
diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index f1f36e0..1aee0fb 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -39,6 +39,7 @@ struct irq_domain;
 struct of_device_id;
 struct irq_chip;
 struct irq_data;
+struct cpumask;
 
 /* Number of irqs reserved for a legacy isa controller */
 #define NUM_ISA_INTERRUPTS 16
@@ -217,7 +218,8 @@ extern struct irq_domain *irq_find_matching_fwspec(struct 
irq_fwspec *fwspec,
   enum irq_domain_bus_token 
bus_token);
 extern void irq_set_default_host(struct irq_domain *host);
 extern int irq_domain_alloc_descs(int virq, unsigned int nr_irqs,
- irq_hw_number_t hwirq, int node);
+ irq_hw_number_t hwirq, int node,
+ const struct cpumask *affinity);
 
 static inline struct fwnode_handle *of_node_to_fwnode(struct device_node *node)
 {
@@ -389,7 +391,7 @@ static inline struct irq_domain 
*irq_domain_add_hierarchy(struct irq_domain *par
 
 extern int __irq_domain_alloc_irqs(struct irq_domain *domain, int irq_base,
   unsigned int nr_irqs, int node, void *arg,
-  bool realloc);
+  bool realloc, const struct cpumask 
*affinity);
 extern void irq_domain_free_irqs(unsigned int virq, unsigned int nr_irqs);
 extern void irq_domain_activate_irq(struct irq_data *irq_data);
 extern void irq_domain_deactivate_irq(struct irq_data *irq_data);
@@ -397,7 +399,8 @@ extern void irq_domain_deactivate_irq(struct irq_data 
*irq_data);
 static inline int irq_domain_alloc_irqs(struct irq_domain *domain,
unsigned int nr_irqs, int node, void *arg)
 {
-   return __irq_domain_alloc_irqs(domain, -1, nr_irqs, node, arg, false);
+   return __irq

[PATCH] checkkconfigsymbols.py: add --no-color option

[Andrew Donnellan]

Add a new option, --no-color, to get rid of ANSI colour escape codes in the
output. Useful if redirecting output to a file or piping to another script.

(It should really be --no-colour, but I'll accept US spelling in the name
of consistency with existing usage in the code comments...)

Signed-off-by: Andrew Donnellan 
---
 scripts/checkkconfigsymbols.py | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/scripts/checkkconfigsymbols.py b/scripts/checkkconfigsymbols.py
index df643f6..a9eba02 100755
--- a/scripts/checkkconfigsymbols.py
+++ b/scripts/checkkconfigsymbols.py
@@ -82,6 +82,10 @@ def parse_options():
   default=False,
   help="Reset current Git tree even when it's dirty.")
 
+parser.add_option('', '--no-color', dest='no_color', action='store_true',
+  default=False,
+  help="Don't print colored output.")
+
 (opts, _) = parser.parse_args()
 
 if opts.commit and opts.diff:
@@ -116,6 +120,9 @@ def main():
 """Main function of this module."""
 opts = parse_options()
 
+global no_color
+no_color = opts.no_color
+
 if opts.sim and not opts.commit and not opts.diff:
 sims = find_sims(opts.sim, opts.ignore)
 if sims:
@@ -202,14 +209,14 @@ def yel(string):
 """
 Color %string yellow.
 """
-return "\033[33m%s\033[0m" % string
+return string if no_color else "\033[33m%s\033[0m" % string
 
 
 def red(string):
 """
 Color %string red.
 """
-return "\033[31m%s\033[0m" % string
+return string if no_color else "\033[31m%s\033[0m" % string
 
 
 def execute(cmd):
-- 
Andrew Donnellan  OzLabs, ADL Canberra
andrew.donnel...@au1.ibm.com  IBM Australia Limited

linux-next: Tree for Jul 4

[Stephen Rothwell]

Hi all,

Changes since 20160701:

The powerpc tree still had its build failure for which I applied a fix patch.

The thermal-soc tree gained conflicts against the thermal tree.

The net-next tree gained conflicts against the net tree.

The lightnvm tree still had its build failure so I used the version from
next-20160629.

The kvm tree gained a conflict against the kspp tree.

Non-merge commits (relative to Linus' tree): 6628
 6242 files changed, 303401 insertions(+), 126461 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 236 trees (counting Linus' and 34 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (0b295dd5b8eb Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse)
Merging fixes/master (5edb56491d48 Linux 4.7-rc3)
Merging kbuild-current/rc-fixes (b36fad65d61f kbuild: Initialize exported 
variables)
Merging arc-current/for-curr (9bd54517ee86 arc: unwind: warn only once if 
DW2_UNWIND is disabled)
Merging arm-current/fixes (56530f5d2ddc ARM: 8579/1: mm: Fix definition of 
pmd_mknotpresent)
Merging m68k-current/for-linus (9a6462763b17 m68k/mvme16x: Include generic 
)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (bfa37087aa04 powerpc: Initialise pci_io_base as 
early as possible)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (6b15d6650c53 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging net/master (b291c418172f net: phy: dp83867: Fix initialization of PHYCR 
register)
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (370a8107e788 ipvs: fix bind to link-local mcast IPv6 
address in backup)
Merging wireless-drivers/master (034fdd4a17ff Merge ath-current from ath.git)
Merging mac80211/master (c041778c966c cfg80211: fix proto in 
ieee80211_data_to_8023 for frames without LLC header)
Merging sound-current/for-linus (046e9ceefab9 Merge tag 'asoc-fix-v4.7-rc5' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (ef0dab4aae14 PCI: Fix unaligned accesses in VC 
code)
Merging driver-core.current/driver-core-linus (33688abb2802 Linux 4.7-rc4)
Merging tty.current/tty-linus (5353ed8deede devpts: fix null pointer 
dereference on failed memory allocation)
Merging usb.current/usb-linus (ab2a4bf83902 USB: don't free bandwidth_mutex too 
early)
Merging usb-gadget-fixes/fixes (50c763f8c1ba usb: dwc3: Set the ClearPendIN bit 
on Clear Stall EP command)
Merging usb-serial-fixes/usb-linus (4c2e07c6a29e Linux 4.7-rc5)
Merging usb-chipidea-fixes/ci-for-usb-stable (ea1d39a31d3b usb: common: 
otg-fsm: add license to usb-otg-fsm)
Merging staging.current/staging-linus (d83972213130 Merge tag 
'iio-fixes-for-4.7c' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio 
into staging-linus)
Merging char-misc.current/char-misc-linus (33688abb2802 Linux 4.7-rc4)
Merging input-current/for-linus (caca925fca4f Input: xpad - validate USB 
endpoint count during probe)
Merging crypto-current/master (055ddaace035 crypto: user - re-add size check 
for CRYPTO_MSG_GETALG)
Merging ide/master (1993b176a822 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module in

[PATCH 07/13] pci: Provide sensible irq vector alloc/free routines

[Christoph Hellwig]

Add a function to allocate a range of interrupt vectors, which will
transparently use MSI-X and MSI if available or fallback to legacy
vectors.  The interrupts are available in a core managed array in the
pci_dev structure, and can also be released using a similar function.
A new helper, __pci_enable_msix_range, is introduced to allow allocating
the array of msix descriptors in the core PCIe code at the exact number
of vectors supported by the PCI host complex, and to also help with the
automatic IRQ affinity assignment that will be added in the next commit.

Signed-off-by: Christoph Hellwig 
---
 Documentation/PCI/MSI-HOWTO.txt | 437 
 drivers/pci/msi.c   |  93 +
 include/linux/pci.h |  39 
 3 files changed, 170 insertions(+), 399 deletions(-)

diff --git a/Documentation/PCI/MSI-HOWTO.txt b/Documentation/PCI/MSI-HOWTO.txt
index 1179850..35d1326 100644
--- a/Documentation/PCI/MSI-HOWTO.txt
+++ b/Documentation/PCI/MSI-HOWTO.txt
@@ -82,418 +82,57 @@ Most of the hard work is done for the driver in the PCI 
layer.  It simply
 has to request that the PCI layer set up the MSI capability for this
 device.
 
-4.2.1 pci_enable_msi
+To automatically use MSI or MSI-X interrupt vectors use the following
+function:
 
-int pci_enable_msi(struct pci_dev *dev)
+int pci_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,
+   unsigned int max_vecs, unsigned int flags)
 
-A successful call allocates ONE interrupt to the device, regardless
-of how many MSIs the device supports.  The device is switched from
-pin-based interrupt mode to MSI mode.  The dev->irq number is changed
-to a new number which represents the message signaled interrupt;
-consequently, this function should be called before the driver calls
-request_irq(), because an MSI is delivered via a vector that is
-different from the vector of a pin-based interrupt.
+Which allocates up to max_vecs interrupt vectors for a PCI devices.  Returns
+the number of vectors allocated or a negative error.  If the device has a
+requirements for a minimum number of vectors the driver can pass a min_vecs
+argument set to this limit, and the PCI core will return -ENOSPC if it can't
+meet the minimum number of vectors.
+The flags argument should normally be set to 0, but can be used to
+pass the PCI_IRQ_NOMSI and PCI_IRQ_NOMSIX flag in case a device claims
+to support MSI or MSI-X, but the support is broken.
 
-4.2.2 pci_enable_msi_range
+To get the Linux IRQ numbers passed to request_irq and free_irq
+and the vectors use the following function:
 
-int pci_enable_msi_range(struct pci_dev *dev, int minvec, int maxvec)
+int pci_irq_vector(struct pci_dev *dev, unsigned int nr);
 
-This function allows a device driver to request any number of MSI
-interrupts within specified range from 'minvec' to 'maxvec'.
+Any allocated resources should be freed before removing the device using the
+following function:
 
-If this function returns a positive number it indicates the number of
-MSI interrupts that have been successfully allocated.  In this case
-the device is switched from pin-based interrupt mode to MSI mode and
-updates dev->irq to be the lowest of the new interrupts assigned to it.
-The other interrupts assigned to the device are in the range dev->irq
-to dev->irq + returned value - 1.  Device driver can use the returned
-number of successfully allocated MSI interrupts to further allocate
-and initialize device resources.
+void pci_free_irq_vectors(struct pci_dev *dev)
 
-If this function returns a negative number, it indicates an error and
-the driver should not attempt to request any more MSI interrupts for
-this device.
+If a device supports both MSI-X and MSI capabilities, this API will use
+the MSI-X facilities in preference to the MSI facilities.   MSI-X
+supports any number of interrupts between 1 and 2048. In contrast, MSI
+is restricted to a maximum of 32 interrupts (and must be a power of two).
+In addition, the MSI interrupt vectors must be allocated consecutively,
+so the system might not be able to allocate as many vectors for MSI as
+it could for MSI-X.  On some platforms, MSI interrupts must all be
+targeted at the same set of CPUs whereas MSI-X interrupts can all be
+targeted at different CPUs.
 
-This function should be called before the driver calls request_irq(),
-because MSI interrupts are delivered via vectors that are different
-from the vector of a pin-based interrupt.
+If a device supports neither MSI-X or MSI it will fall back to a single
+legacy IRQ vectors.
 
-It is ideal if drivers can cope with a variable number of MSI interrupts;
-there are many reasons why the platform may not be able to provide the
-exact number that a driver asks for.
+4.3 Legacy MSI / MSI-X APIs
 
-There could be devices that can not operate with just any number of MSI
-interrupts within a range.  See chapter 4.3.1.3 to get the idea how to
-handle such devices for MSI-X - the same logic 

Re: [PATCH v2 7/8] mm/zsmalloc: add __init,__exit attribute

[Sergey Senozhatsky]

On (07/04/16 14:49), Ganesh Mahendran wrote:
[..]
> -static void zs_unregister_cpu_notifier(void)
> +static void __exit zs_unregister_cpu_notifier(void)
>  {

this __exit symbol is called from `__init zs_init()' and thus is
free to crash.

-ss

Re: [PATCH v2 8/8] mm/zsmalloc: use helper to clear page->flags bit

[Sergey Senozhatsky]

On (07/04/16 14:49), Ganesh Mahendran wrote:
> Date: Mon,  4 Jul 2016 14:49:59 +0800
> From: Ganesh Mahendran 
> To: linux-kernel@vger.kernel.org, linux...@kvack.org
> Cc: a...@linux-foundation.org, minc...@kernel.org, ngu...@vflare.org,
>  sergey.senozhatsky.w...@gmail.com, rost...@goodmis.org, mi...@redhat.com,
>  Ganesh Mahendran 
> Subject: [PATCH v2 8/8] mm/zsmalloc: use helper to clear page->flags bit
> X-Mailer: git-send-email 1.9.1
> 
> user ClearPagePrivate/ClearPagePrivate2 helper to clear
> PG_private/PG_private_2 in page->flags
> 
> Signed-off-by: Ganesh Mahendran 
> Acked-by: Minchan Kim 

Reviewed-by: Sergey Senozhatsky 

-ss

> 
> v2: none
> ---
>  mm/zsmalloc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> index 756f839..297f25b 100644
> --- a/mm/zsmalloc.c
> +++ b/mm/zsmalloc.c
> @@ -940,8 +940,8 @@ static void unpin_tag(unsigned long handle)
>  static void reset_page(struct page *page)
>  {
>   __ClearPageMovable(page);
> - clear_bit(PG_private, &page->flags);
> - clear_bit(PG_private_2, &page->flags);
> + ClearPagePrivate(page);
> + ClearPagePrivate2(page);
>   set_page_private(page, 0);
>   page_mapcount_reset(page);
>   ClearPageHugeObject(page);
> -- 
> 1.9.1
> 

Re: [PATCH v3 2/2] pci/aer: interrupt fixup in the quirk

[Dongdong Liu]

Hi Po

I found a problem with the similar patch. as the below log.

[4.287060] pci :80:00.0: quirk_aer_interrupt dev->irq 416
[4.293778] pcieport :80:00.0: pci_device_probe in
[4.299605] pcieport :80:00.0: of_irq_parse_pci() failed with rc=-22
[4.307209] pcieport :80:00.0: init_service_irqs  dev->irq 0

The fucntions are called as below sequence.
1. quirk_aer_interrupt, get the aer dev->irq 416.
2. pci_device_probe->of_irq_parse_pci, of_irq_parse_pci() failed, then dev->irq 
changed to 0.

So this patch could not work with aer.

Thanks
Dongdong
在 2016/6/14 16:24, Po Liu 写道:

On some platforms, root port doesn't support MSI/MSI-X/INTx in RC mode.
When chip support the aer interrupt with none MSI/MSI-X/INTx mode,
maybe there is interrupt line for aer pme etc. Search the interrupt
number in the fdt file. Then fixup the dev->irq with it.

Signed-off-by: Po Liu 
---
changes for V3:
- Move to quirk;
- Only correct the irq in RC mode;

  drivers/pci/quirks.c | 29 +
  1 file changed, 29 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index ee72ebe..8b39cce 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -25,6 +25,7 @@
  #include 
  #include 
  #include 
+#include 
  #include /* isa_dma_bridge_buggy */
  #include "pci.h"

@@ -4419,3 +4420,31 @@ static void quirk_intel_qat_vf_cap(struct pci_dev *pdev)
}
  }
  DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x443, quirk_intel_qat_vf_cap);
+
+/* If root port doesn't support MSI/MSI-X/INTx in RC mode,
+ * but use standalone irq. Read the device tree for the aer
+ * interrupt number.
+ */
+static void quirk_aer_interrupt(struct pci_dev *dev)
+{
+   int ret;
+   u8 header_type;
+   struct device_node *np = NULL;
+
+   /* Only for the RC mode device */
+   pci_read_config_byte(dev, PCI_HEADER_TYPE, &header_type);
+   if ((header_type & 0x7F) != PCI_HEADER_TYPE_BRIDGE)
+   return;
+
+   if (dev->bus->dev.of_node)
+   np = dev->bus->dev.of_node;
+
+   if (IS_ENABLED(CONFIG_OF_IRQ) && np) {
+   ret = of_irq_get_byname(np, "aer");
+   if (ret > 0) {
+   dev->no_msi = 1;
+   dev->irq = ret;
+   }
+   }
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_FREESCALE, PCI_ANY_ID, 
quirk_aer_interrupt);

Re: Applied "ASoC: rockchip-max98090: Fix NULL pointer dereference while accessing to jack." to the asoc tree

[Mark Brown]

On Mon, Jul 04, 2016 at 09:24:12AM +0200, Enric Balletbo Serra wrote:

> I just saw that these patches and the others in the patch series were
> not applied yet. As are fixes and were accepted since middle May, I

No, they are actually applied like the e-mail said - please see my git.

> expected see the patches merged in this release cycle, but we're at

In general if you think a fix needs to go in urgently it's best to
specifically identify this.  If nothing is specifically said and it's
not obviously related to something done recently then the tendency will
be to assume that the issue was recently introduced and is a fix for a
development version.

> rc6 so I suppose I'll need to wait to see them merged for 4.8 merge
> window. Please can you coordinate with Heiko and make sure that these
> patches were merged before he merges the patches to enable the audio
> on Veyron? Otherwise we will break Veyron support for a while. I'd
> really like have audio working on Veyron.

As things stand they'll be merged in the next merge window.  They're
buried in the middle of a branch with other things so I can't just send
the branch as-is.  If these new patches you're talking about are going
to get merged in the merge window as well so we're presumably mostly
fine?


signature.asc
Description: PGP signature

Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed

[Xiao Guangrong]

On 07/04/2016 04:41 PM, Neo Jia wrote:

On Mon, Jul 04, 2016 at 04:19:20PM +0800, Xiao Guangrong wrote:



On 07/04/2016 03:53 PM, Neo Jia wrote:

On Mon, Jul 04, 2016 at 03:37:35PM +0800, Xiao Guangrong wrote:



On 07/04/2016 03:03 PM, Neo Jia wrote:

On Mon, Jul 04, 2016 at 02:39:22PM +0800, Xiao Guangrong wrote:



On 06/30/2016 09:01 PM, Paolo Bonzini wrote:

The vGPU folks would like to trap the first access to a BAR by setting
vm_ops on the VMAs produced by mmap-ing a VFIO device.  The fault handler
then can use remap_pfn_range to place some non-reserved pages in the VMA.


Why does it require fetching the pfn when the fault is triggered rather
than when mmap() is called?


Hi Guangrong,

as such mapping information between virtual mmio to physical mmio is only 
available
at runtime.


Sorry, i do not know what the different between mmap() and the time VM actually
accesses the memory for your case. Could you please more detail?


Hi Guangrong,

Sure. The mmap() gets called by qemu or any VFIO API userspace consumer when
setting up the virtual mmio, at that moment nobody has any knowledge about how
the physical mmio gets virtualized.

When the vm (or application if we don't want to limit ourselves to vmm term)
starts, the virtual and physical mmio gets mapped by mpci kernel module with the
help from vendor supplied mediated host driver according to the hw resource
assigned to this vm / application.


Thanks for your expiation.

It sounds like a strategy of resource allocation, you delay the allocation 
until VM really
accesses it, right?


Yes, that is where the fault handler inside mpci code comes to the picture.



I am not sure this strategy is good. The instance is successfully created, and 
it is started
successful, but the VM is crashed due to the resource of that instance is not 
enough. That sounds
unreasonable.

Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed

[Paolo Bonzini]

On 04/07/2016 10:21, Xiao Guangrong wrote:
>>
>> /*
>>  * In case the VMA has VM_MIXEDMAP set, whoever called
>> remap_pfn_range
>>  * is also going to call e.g. unmap_mapping_range before the
>> underlying
>>  * non-reserved pages are freed, which will then call our MMU
>> notifier.
>>  * We still have to get a reference here to the page, because the
>> callers
>>  * of *hva_to_pfn* and *gfn_to_pfn* ultimately end up doing a
>>  * kvm_release_pfn_clean on the returned pfn.  If the pfn is
>>  * reserved, the kvm_get_pfn/kvm_release_pfn_clean pair will simply
>>  * do nothing.
>>  */
>>
> 
> Excellent. I like it. :)

So is it Reviewed-by Guangrong? :)

Paolo

Re: [PATCH] phy: fix error handling

[Dan Carpenter]

On Mon, Jul 04, 2016 at 01:22:50PM +0530, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Monday 04 July 2016 02:38 AM, Christophe JAILLET wrote:
> > I will resubmit in the coming days.
> > 
> >return PTR_ERR(phy->clk);
> > should also be updated.
> 
> while at that, also fix your $subject to something like
> "phy: sun9i-usb: fix error handling"
> 

Yes.  Also the first patch should have used that same prefix.
9c3b44302636 ('phy: Add driver to support individual USB PHYs on sun9i')

We have this problem quite often, but other subsystems have fixed it
because they start using the correct prefix when the driver is added.
The second patch for this driver had the same issue:
9c3b44302636 ('phy: Add driver to support individual USB PHYs on sun9i')

regards,
dan carpenter

Re: [PATCH] regulator: pwm: Fix regulator ramp delay for continuous mode

[Mark Brown]

On Sat, Jul 02, 2016 at 05:47:52PM +0200, Boris Brezillon wrote:

> I'm waiting for reviews or acks. AFAIR, I addressed all the comments
> Thierry made on my v2, so I guess we're good on the PWM side, but that
> would be good to have a review from Mark now that we agreed on the PWM
> APIs.

I've already have one round of review invalidated by changes in the PWM
bits so I've been deprioritising it until it's clear that the churn
there has stopped.  I understand things are supposed to be quieting down
but I also have a bunch of other things to look at...


signature.asc
Description: PGP signature

[PATCH v2 1/1] gpu: drm: msm_drv: add missing of_node_put after calling of_parse_phandle

[Peter Chen]

of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Signed-off-by: Peter Chen 
---
Changes for v2:
- There are two missings in the code, handle it both in one patch

 drivers/gpu/drm/msm/msm_drv.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 9c65409..46c6037 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -284,6 +284,7 @@ static int msm_init_vram(struct drm_device *dev)
if (node) {
struct resource r;
ret = of_address_to_resource(node, 0, &r);
+   of_node_put(node);
if (ret)
return ret;
size = r.end - r.start;
@@ -819,6 +820,7 @@ static int add_components(struct device *dev, struct 
component_match **matchptr,
break;
 
component_match_add(dev, matchptr, compare_of, node);
+   of_node_put(node);
}
 
return 0;
-- 
1.9.1

Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed

[Xiao Guangrong]

On 07/04/2016 04:45 PM, Xiao Guangrong wrote:



On 07/04/2016 04:41 PM, Neo Jia wrote:

On Mon, Jul 04, 2016 at 04:19:20PM +0800, Xiao Guangrong wrote:



On 07/04/2016 03:53 PM, Neo Jia wrote:

On Mon, Jul 04, 2016 at 03:37:35PM +0800, Xiao Guangrong wrote:



On 07/04/2016 03:03 PM, Neo Jia wrote:

On Mon, Jul 04, 2016 at 02:39:22PM +0800, Xiao Guangrong wrote:



On 06/30/2016 09:01 PM, Paolo Bonzini wrote:

The vGPU folks would like to trap the first access to a BAR by setting
vm_ops on the VMAs produced by mmap-ing a VFIO device.  The fault handler
then can use remap_pfn_range to place some non-reserved pages in the VMA.


Why does it require fetching the pfn when the fault is triggered rather
than when mmap() is called?


Hi Guangrong,

as such mapping information between virtual mmio to physical mmio is only 
available
at runtime.


Sorry, i do not know what the different between mmap() and the time VM actually
accesses the memory for your case. Could you please more detail?


Hi Guangrong,

Sure. The mmap() gets called by qemu or any VFIO API userspace consumer when
setting up the virtual mmio, at that moment nobody has any knowledge about how
the physical mmio gets virtualized.

When the vm (or application if we don't want to limit ourselves to vmm term)
starts, the virtual and physical mmio gets mapped by mpci kernel module with the
help from vendor supplied mediated host driver according to the hw resource
assigned to this vm / application.


Thanks for your expiation.

It sounds like a strategy of resource allocation, you delay the allocation 
until VM really
accesses it, right?


Yes, that is where the fault handler inside mpci code comes to the picture.



I am not sure this strategy is good. The instance is successfully created, and 
it is started
successful, but the VM is crashed due to the resource of that instance is not 
enough. That sounds
unreasonable.



Especially, you can not squeeze this kind of memory to balance the usage 
between all VMs. Does
this strategy still make sense?

Applied "ASoC: bt-sco: add config prompt" to the asoc tree

[Mark Brown]

The patch

   ASoC: bt-sco: add config prompt

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 8b0b50d8a3e3ccfa4632a227102b97994ed95fc0 Mon Sep 17 00:00:00 2001
From: Garlic Tseng 
Date: Mon, 4 Jul 2016 15:06:42 +0800
Subject: [PATCH] ASoC: bt-sco: add config prompt

Add config prompt for bt-sco codec driver

Signed-off-by: Garlic Tseng 
Signed-off-by: Mark Brown 
---
 sound/soc/codecs/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 4d82a58ff6b0..3ba998a79165 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -371,7 +371,7 @@ config SND_SOC_ALC5632
tristate
 
 config SND_SOC_BT_SCO
-   tristate
+   tristate "Dummy BT SCO codec driver"
 
 config SND_SOC_CQ0093VC
tristate
-- 
2.8.1

Re: [PATCH] phy: fix error handling

[Julia Lawall]

On Mon, 4 Jul 2016, Dan Carpenter wrote:

> On Mon, Jul 04, 2016 at 01:22:50PM +0530, Kishon Vijay Abraham I wrote:
> > Hi,
> >
> > On Monday 04 July 2016 02:38 AM, Christophe JAILLET wrote:
> > > I will resubmit in the coming days.
> > >
> > >return PTR_ERR(phy->clk);
> > > should also be updated.
> >
> > while at that, also fix your $subject to something like
> > "phy: sun9i-usb: fix error handling"
> >
>
> Yes.  Also the first patch should have used that same prefix.
> 9c3b44302636 ('phy: Add driver to support individual USB PHYs on sun9i')
>
> We have this problem quite often, but other subsystems have fixed it
> because they start using the correct prefix when the driver is added.
> The second patch for this driver had the same issue:
> 9c3b44302636 ('phy: Add driver to support individual USB PHYs on sun9i')

Is there any hope to some day have a deterministic algorithm?  Something
that get_maintainers could figure out.

julia

Re: [PATCHv3 1/2] usb: USB Type-C connector class

[Oliver Neukum]

On Wed, 2016-06-29 at 14:27 +0300, Heikki Krogerus wrote:

> About the end user of the interface, I think Oliver knows more about
> that. But I would imagine that the use cases will be something like,
> for example, on systems that need prefer sertain roles, perhaps Host
> for example on some server systems, need to have something like a udev
> script to set the preferred role and/or attempt role swap if the other
> role (device) is initially given to a port after connection.

And I would say again that try.SRC and try.SNK need a module parameter
as a later reversal needs a virtual disconnect.

Regards
Oliver

Re: [PATCH] Exchange the Assignments of `MEMORYs' and `CFGs/IOs' in Designware PCIe Driver

[Pratyush Anand]

On Mon, Jul 4, 2016 at 1:06 PM, dongbo (E)  wrote:
> On 2016/7/3 23:27, Pratyush Anand wrote:
>> On Tue, Jun 28, 2016 at 1:42 PM, dongbo (E)  wrote:
>>>
>>> From: Dong Bo 
>>>
>>> In designware PCIe driver, the iatu0 is used for both CFG and IO accesses.
>>> When sending CFGs to peripherals (e.g. lspci), iatu0 frequently switches
>>> between CFG and IO alternatively.
>>>
>>> A MEMORY probably be sent as an IOs by mistake. Considering the following
>>> configurations:
>>> MEMORY  ->  BASE_ADDR: 0xb410, LIMIT: 0xb4100FFF, TYPE=mem
>>> CFG ->  BASE_ADDR: 0xb400, LIMIT: 0xb4000FFF, TYPE=cfg
>>> IO  ->  BASE_ADDR: 0x, LIMIT: 0xFFFE, TYPE=io
>>>
>>> Suppose PCIe has just completed a CFG access, to switch back to IO, it set
>>> the BASE_ADDR to 0x, LIMIT 0xFFFE and TYPE to io. When another
>>> CFG comes, the BASE_ADDR is set to 0xb400 to switch to CFG. At this
>>> moment, a MEMORY access shows up, since it matches with iatu0
>>> (due to 0xb400 <= MEMORY BASE_ADDR <= MEMORY LIMIE <= 0xFFF), it
>>> is treated as an IO access by mistake, then sent to perpheral.
>>>
>>> This patch fixes the problem by exchanging the assignments of `MEMORYs'
>>> and `CFGs/IOs', which assigning MEMEORYs to iatu0, CFGs and IOs to iatu1.
>>
>>
>> Had a re-thought on it. While it will fix wrong memory access in your
>> case, it can still cause issues with IO access for some other
>> platform.
>>
>> Can you please test [1] and check it that works for you. You will need
>> to define num-viewport in your device tree file.
>>
>> ~Pratyush
>>
>> [1] 
>> https://github.com/pratyushanand/linux/commit/131b83ea7db0834d77ee5df65c6696bccbf8a1ce
>>
>> .
>>
>
> Checked, it works for us.

Thanks for testing.

>
> I think it would be better to exchange the assignments of MEMORYs and
> CFGs/IOs when num_viewports <= 2, cause it fixes wrong memory access.

OK.. I think that can be accommodated. I have rebased your patch on
top of mine with some change in commit log.

https://github.com/pratyushanand/linux/commit/6d3805a5e0fbbbd73beba80c2c9151b26399ea67

Will send both of the patches to the list for review.


>
> As you mentioned, other corner point for failure is still there while
> there are only two viewports. It seems that there is not a perfect
> solution.

Yes, unfortunately we will have to live with either remote possibility
of less frequent IO transfer corruption or we can disable IO transfer
for <=2 viewports. IMHO, former is the better way to go with.

~Pratyush

Re: [PATCH v2] sched/deadline: remove useless param from setup_new_dl_entity

[luca abeni]

Hi Juri,

On Wed, 29 Jun 2016 20:07:43 +0100
Juri Lelli  wrote:

> setup_new_dl_entity() takes two parameters, but it only actually uses
> one of them, under a different name, to setup a new dl_entity, after:
> 
>  2f9f3fdc928 "sched/deadline: Remove dl_new from struct
> sched_dl_entity"
> 
> as we currently do
> 
>  setup_new_dl_entity(&p->dl, &p->dl)
> 
> However, before Luca's change we were doing
> 
>  setup_new_dl_entity(dl_se, pi_se)
> 
> in update_dl_entity() for a dl_se->new entity: we were using pi_se's
> parameters (the potential PI donor) for setting up a new entity.
> 
> Restore this behaviour (as we want to correctly initialize parameters
> of a boosted task that enters DEADLINE) by removing the useless second
> parameter of setup_new_dl_entity() and retrieving the top waiter
> directly from inside that function.
I did not have time to test this patch yet, but it still looks good to
me.



Thanks,
Luca


> 
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra 
> Cc: Steven Rostedt 
> Cc: Luca Abeni 
> Signed-off-by: Juri Lelli 
> 
> ---
>  Changes from v1:
>- Steve pointed out that we were actually using the second
> parameter to permorm initialization
>- Luca confirmed that behavior is slightly changed w.r.t. before
> his change
>- changelog updated and original behavior restored
> ---
>  kernel/sched/deadline.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index fcb7f0217ff4..2000ad2294d5 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -346,11 +346,12 @@ static void check_preempt_curr_dl(struct rq
> *rq, struct task_struct *p,
>   * one, and to (try to!) reconcile itself with its own scheduling
>   * parameters.
>   */
> -static inline void setup_new_dl_entity(struct sched_dl_entity *dl_se,
> -struct sched_dl_entity *pi_se)
> +static inline void setup_new_dl_entity(struct sched_dl_entity *dl_se)
>  {
>   struct dl_rq *dl_rq = dl_rq_of_se(dl_se);
>   struct rq *rq = rq_of_dl_rq(dl_rq);
> + struct task_struct *pi_task =
> rt_mutex_get_top_task(dl_task_of(dl_se));
> + struct sched_dl_entity *pi_se = dl_se;
>  
>   WARN_ON(dl_time_before(rq_clock(rq), dl_se->deadline));
>  
> @@ -363,6 +364,13 @@ static inline void setup_new_dl_entity(struct
> sched_dl_entity *dl_se, return;
>  
>   /*
> +  * Use the scheduling parameters of the top pi-waiter task,
> +  * if we have one from which we can inherit a deadline.
> +  */
> + if (pi_task && dl_se->dl_boosted &&
> dl_prio(pi_task->normal_prio))
> + pi_se = &pi_task->dl;
> +
> + /*
>* We use the regular wall clock time to set deadlines in the
>* future; in fact, we must consider execution overheads
> (time
>* spent on hardirq context, etc.).
> @@ -1721,7 +1729,7 @@ static void switched_from_dl(struct rq *rq,
> struct task_struct *p) static void switched_to_dl(struct rq *rq,
> struct task_struct *p) {
>   if (dl_time_before(p->dl.deadline, rq_clock(rq)))
> - setup_new_dl_entity(&p->dl, &p->dl);
> + setup_new_dl_entity(&p->dl);
>  
>   if (task_on_rq_queued(p) && rq->curr != p) {
>  #ifdef CONFIG_SMP

[RFC PATCH v2 0/4] net: ethernet: Add support for gmii2rgmii converter

[Kedareswara rao Appana]

This patch series does the following
---> Add support for gmii2rgmii converter.
---> Add support for gmii2rgmii converter in the macb driver.

The Gigabit Media Independent Interface (GMII) to Reduced Gigabit Media
Independent Interface (RGMII) core provides the RGMII between RGMII-compliant
Ethernet physical media devices (PHY) and the Gigabit Ethernet controller.
This core can be used in all three modes of operation(10/100/1000 Mb/s).
The Management Data Input/Output (MDIO) interface is used to configure the
Speed of operation. This core can switch dynamically between the three
Different speed modes by configuring the conveter register through mdio write.

The conveter sits b/w the MAC and external phy like below

MACB <==> GMII2RGMII <==> RGMII_PHY

MDIO   <> GMII2RGMII
MCAB <===> 
   <> RGMII

Using MAC MDIO bus we can access both the converter and the external PHY.
We need to program the line speed of the converter during run time based
On the external phy negotiated speed.

Kedareswara rao Appana (4):
  Documentation: DT: net: Add Xilinx gmiitorgmii converter device tree
binding documentation
  net: ethernet: xilinx: Add gmii2rgmii converter support
  Documentation: DT: net: Update binding doc for gmiitorgmii conveter
  net: macb: Add gmii2rgmii phy converter support

 Documentation/devicetree/bindings/net/macb.txt |  4 ++
 .../devicetree/bindings/net/xilinx_gmii2rgmii.txt  | 31 +
 drivers/net/ethernet/cadence/macb.c| 21 ++
 drivers/net/ethernet/cadence/macb.h|  1 +
 drivers/net/ethernet/xilinx/Kconfig|  8 +++
 drivers/net/ethernet/xilinx/Makefile   |  1 +
 drivers/net/ethernet/xilinx/xilinx_gmii2rgmii.c| 79 ++
 include/linux/xilinx_gmii2rgmii.h  | 24 +++
 8 files changed, 169 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/xilinx_gmii2rgmii.txt
 create mode 100644 drivers/net/ethernet/xilinx/xilinx_gmii2rgmii.c
 create mode 100644 include/linux/xilinx_gmii2rgmii.h

-- 
2.1.2

[RFC PATCH v2 1/4] Documentation: DT: net: Add Xilinx gmiitorgmii converter device tree binding documentation

[Kedareswara rao Appana]

Device-tree binding documentation for xilinx gmiitorgmii converter.

Signed-off-by: Kedareswara rao Appana 
---
Changes for v2:
--> New patch.

 .../devicetree/bindings/net/xilinx_gmii2rgmii.txt  | 31 ++
 1 file changed, 31 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/xilinx_gmii2rgmii.txt

diff --git a/Documentation/devicetree/bindings/net/xilinx_gmii2rgmii.txt 
b/Documentation/devicetree/bindings/net/xilinx_gmii2rgmii.txt
new file mode 100644
index 000..d11e259
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/xilinx_gmii2rgmii.txt
@@ -0,0 +1,31 @@
+* XILINX GMIITORGMII Converter Driver
+
+The Gigabit Media Independent Interface (GMII) to Reduced Gigabit Media
+Independent Interface (RGMII) core provides the RGMII between RGMII-compliant
+Ethernet physical media devices (PHY) and the Gigabit Ethernet controller.
+This core can be used in all three modes of operation(10/100/1000 Mb/s).
+The Management Data Input/Output (MDIO) interface is used to configure the
+Speed of operation. This core can switch dynamically between the three
+Different speed modes by configuring the conveter register through mdio write.
+
+The MDIO is a bus to which the PHY devices are connected.  For each
+device that exists on this bus, a child node should be created.  See
+the definition of the PHY node in booting-without-of.txt for an example
+of how to define a PHY.
+
+Required properties:
+  - compatible : Should be "xlnx,gmiitorgmii"
+  - reg : The ID number for the phy, usually a small integer
+
+Example:
+   mdio {
+#address-cells = <1>;
+#size-cells = <0>;
+   ethernet-phy@0 {
+   ..
+   };
+gmii_to_rgmii: gmii_to_rgmii@8 {
+compatible = "xlnx,gmiitorgmii";
+reg = <8>;
+};
+};
-- 
2.1.2

[RFC PATCH v2 2/4] net: ethernet: xilinx: Add gmii2rgmii converter support

[Kedareswara rao Appana]

This patch adds support for gmii2rgmii converter.

The GMII to RGMII IP core provides the Reduced Gigabit Media
Independent Interface (RGMII) between Ethernet physical media
Devices and the Gigabit Ethernet controller. This core can
Switch dynamically between the three different speed modes of
Operation by configuring the converter register through mdio write.

MDIO interface is used to set operating speed of Ethernet MAC.

Signed-off-by: Kedareswara rao Appana 
---
Changes for v2:
--> Passed struct xphy pointer directly to the fix_mac_speed
API as suggested by the Florian.
--> Added checks for the phy-node fail case as suggested
by the Florian.

 drivers/net/ethernet/xilinx/Kconfig |  8 +++
 drivers/net/ethernet/xilinx/Makefile|  1 +
 drivers/net/ethernet/xilinx/xilinx_gmii2rgmii.c | 79 +
 include/linux/xilinx_gmii2rgmii.h   | 24 
 4 files changed, 112 insertions(+)
 create mode 100644 drivers/net/ethernet/xilinx/xilinx_gmii2rgmii.c
 create mode 100644 include/linux/xilinx_gmii2rgmii.h

diff --git a/drivers/net/ethernet/xilinx/Kconfig 
b/drivers/net/ethernet/xilinx/Kconfig
index 4f5c024..4b65174 100644
--- a/drivers/net/ethernet/xilinx/Kconfig
+++ b/drivers/net/ethernet/xilinx/Kconfig
@@ -39,4 +39,12 @@ config XILINX_LL_TEMAC
  This driver supports the Xilinx 10/100/1000 LocalLink TEMAC
  core used in Xilinx Spartan and Virtex FPGAs
 
+config XILINX_GMII2RGMII
+   tristate "Xilinx GMII2RGMII converter driver"
+   default y
+   ---help---
+ This driver support xilinx GMII to RGMII IP core it provides
+ the Reduced Gigabit Media Independent Interface(RGMII) between
+ Ethernet physical media devices and the Gigabit Ethernet controller.
+
 endif # NET_VENDOR_XILINX
diff --git a/drivers/net/ethernet/xilinx/Makefile 
b/drivers/net/ethernet/xilinx/Makefile
index 214205e..bca0da0 100644
--- a/drivers/net/ethernet/xilinx/Makefile
+++ b/drivers/net/ethernet/xilinx/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_XILINX_LL_TEMAC) += ll_temac.o
 obj-$(CONFIG_XILINX_EMACLITE) += xilinx_emaclite.o
 xilinx_emac-objs := xilinx_axienet_main.o xilinx_axienet_mdio.o
 obj-$(CONFIG_XILINX_AXI_EMAC) += xilinx_emac.o
+obj-$(CONFIG_XILINX_GMII2RGMII) += xilinx_gmii2rgmii.o
diff --git a/drivers/net/ethernet/xilinx/xilinx_gmii2rgmii.c 
b/drivers/net/ethernet/xilinx/xilinx_gmii2rgmii.c
new file mode 100644
index 000..de3bd89
--- /dev/null
+++ b/drivers/net/ethernet/xilinx/xilinx_gmii2rgmii.c
@@ -0,0 +1,79 @@
+/* Xilinx GMII2RGMII Converter driver
+ *
+ * Copyright (C) 2016 Xilinx, Inc.
+ *
+ * Author: Kedareswara rao Appana 
+ *
+ * Description:
+ * This driver is developed for Xilinx GMII2RGMII Converter
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static void xgmii2rgmii_fix_mac_speed(struct gmii2rgmii *xphy,
+ unsigned int speed)
+{
+   struct phy_device *gmii2rgmii_phydev = xphy->gmii2rgmii_phy_dev;
+   u16 gmii2rgmii_reg = 0;
+
+   switch (speed) {
+   case 1000:
+   gmii2rgmii_reg |= XILINX_GMII2RGMII_SPEED1000;
+   break;
+   case 100:
+   gmii2rgmii_reg |= XILINX_GMII2RGMII_SPEED100;
+   break;
+   default:
+   return;
+   }
+
+   xphy->mdio_write(xphy->mii_bus, gmii2rgmii_phydev->mdio.addr,
+XILINX_GMII2RGMII_REG_NUM,
+gmii2rgmii_reg);
+}
+
+int gmii2rgmii_phyprobe(struct gmii2rgmii *xphy)
+{
+   struct device_node *phy_node;
+   struct phy_device *phydev;
+   struct device_node *np = (struct device_node *)xphy->platform_data;
+
+   phy_node = of_parse_phandle(np, "gmii2rgmii-phy-handle", 0);
+   if (phy_node) {
+   phydev = of_phy_attach(xphy->dev, phy_node, 0, 0);
+   if (!phydev) {
+   netdev_err(xphy->dev,
+  "%s: no gmii to rgmii converter found\n",
+  xphy->dev->name);
+   return -1;
+   }
+   xphy->gmii2rgmii_phy_dev = phydev;
+   xphy->fix_mac_speed = xgmii2rgmii_fix_mac_speed;
+   } else {
+   xphy->gmii2rgmii_phy_dev = 0;
+   xphy->fix_mac_speed = 0;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(gmii2rgmii_phyprobe);
+
+MODULE_DESCRIPTION("Xilinx GMII2RGM

[RFC PATCH v2 4/4] net: macb: Add gmii2rgmii phy converter support

[Kedareswara rao Appana]

This patch adds support for gmii2rgmii phy converter in the macb driver.

The GMII to RGMII IP core provides the Reduced Gigabit Media
Independent Interface (RGMII) between Ethernet physical media
Devices and the Gigabit Ethernet controller. This core can
Switch dynamically between the three different speed modes of
Operation by configuring the converter register through mdio write.

MDIO interface is used to set operating speed of Ethernet MAC.

Signed-off-by: Kedareswara rao Appana 
---
Changes for v2:
---> Moved header file define xilinx_gmii2rgmii.h to macb.c file
as suggested by the Nicolas.
---> Updated the commit meassage as suggested by the Nicolas.
---> Fixed minor coding comments as suggested by the Nicolas.

 drivers/net/ethernet/cadence/macb.c | 21 +
 drivers/net/ethernet/cadence/macb.h |  1 +
 2 files changed, 22 insertions(+)

diff --git a/drivers/net/ethernet/cadence/macb.c 
b/drivers/net/ethernet/cadence/macb.c
index cb07d95..b900eb4 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "macb.h"
 
@@ -257,6 +258,14 @@ static int macb_mdio_write(struct mii_bus *bus, int 
mii_id, int regnum,
return 0;
 }
 
+static inline void macb_hw_fix_mac_speed(struct macb *bp,
+struct phy_device *phydev)
+{
+   if (bp->converter_phy.fix_mac_speed)
+   bp->converter_phy.fix_mac_speed(&bp->converter_phy,
+   phydev->speed);
+}
+
 /**
  * macb_set_tx_clk() - Set a clock to a new frequency
  * @clkPointer to the clock to change
@@ -329,6 +338,7 @@ static void macb_handle_link_change(struct net_device *dev)
reg |= GEM_BIT(GBE);
 
macb_or_gem_writel(bp, NCFGR, reg);
+   macb_hw_fix_mac_speed(bp, phydev);
 
bp->speed = phydev->speed;
bp->duplex = phydev->duplex;
@@ -2886,6 +2896,7 @@ static int macb_probe(struct platform_device *pdev)
int (*init)(struct platform_device *) = macb_init;
struct device_node *np = pdev->dev.of_node;
struct device_node *phy_node;
+   struct device_node *child_node, *np1;
const struct macb_config *macb_config = NULL;
struct clk *pclk, *hclk = NULL, *tx_clk = NULL;
unsigned int queue_mask, num_queues;
@@ -3011,6 +3022,16 @@ static int macb_probe(struct platform_device *pdev)
goto err_out_free_netdev;
 
phydev = bp->phy_dev;
+   child_node = of_get_next_child(np, NULL);
+   for_each_child_of_node(child_node, np1) {
+   if (of_device_is_compatible(np1, "xlnx,gmiitorgmii")) {
+   bp->converter_phy.dev = dev;
+   bp->converter_phy.mii_bus = bp->mii_bus;
+   bp->converter_phy.mdio_write = macb_mdio_write;
+   bp->converter_phy.platform_data = bp->pdev->dev.of_node;
+   gmii2rgmii_phyprobe(&bp->converter_phy);
+   }
+   }
 
netif_carrier_off(dev);
 
diff --git a/drivers/net/ethernet/cadence/macb.h 
b/drivers/net/ethernet/cadence/macb.h
index 8a13824..414005c 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -846,6 +846,7 @@ struct macb {
unsigned intjumbo_max_len;
 
u32 wol;
+   struct  gmii2rgmii  converter_phy;
 };
 
 static inline bool macb_is_gem(struct macb *bp)
-- 
2.1.2

[RFC PATCH v2 3/4] Documentation: DT: net: Update binding doc for gmiitorgmii conveter

[Kedareswara rao Appana]

This patch updates the macb device-tree binding doc for adding
Support for gmiitorgmii converter support.

Signed-off-by: Kedareswara rao Appana 
---
Changes for v2:
--> New patch.

 Documentation/devicetree/bindings/net/macb.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/macb.txt 
b/Documentation/devicetree/bindings/net/macb.txt
index b5a42df..0d497a7 100644
--- a/Documentation/devicetree/bindings/net/macb.txt
+++ b/Documentation/devicetree/bindings/net/macb.txt
@@ -23,6 +23,10 @@ Required properties:
Optional elements: 'tx_clk'
 - clocks: Phandles to input clocks.
 
+Optional properties:
+- gmii2rgmii-phy-handle: phy-handle for gmiitorgmii converter.
+See xilinx_gmii2rgmii.txt file in the same directory.
+
 Optional properties for PHY child node:
 - reset-gpios : Should specify the gpio for phy reset
 - magic-packet : If present, indicates that the hardware supports waking
-- 
2.1.2

[PATCH 1/1] gpu: drm: msm_drv: add missing of_node_put after calling of_parse_phandle

[Peter Chen]

of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Signed-off-by: Peter Chen 
---
 drivers/gpu/drm/msm/msm_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 9c65409..d9ba6c4 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -284,6 +284,7 @@ static int msm_init_vram(struct drm_device *dev)
if (node) {
struct resource r;
ret = of_address_to_resource(node, 0, &r);
+   of_node_put(node);
if (ret)
return ret;
size = r.end - r.start;
-- 
1.9.1

Re: [PATCH] regulator: pwm: Fix regulator ramp delay for continuous mode

[Boris Brezillon]

Hi Mark,

On Mon, 4 Jul 2016 10:53:36 +0200
Mark Brown  wrote:

> On Sat, Jul 02, 2016 at 05:47:52PM +0200, Boris Brezillon wrote:
> 
> > I'm waiting for reviews or acks. AFAIR, I addressed all the comments
> > Thierry made on my v2, so I guess we're good on the PWM side, but that
> > would be good to have a review from Mark now that we agreed on the PWM
> > APIs.  
> 
> I've already have one round of review invalidated by changes in the PWM
> bits so I've been deprioritising it until it's clear that the churn
> there has stopped.  I understand things are supposed to be quieting down
> but I also have a bunch of other things to look at...

I understand, but can we still expect to have it in 4.8 (I mean,
assuming Thierry is okay taking the first 2 patching for 4.8 too)?

Thanks,

Boris

Re: [PATCH] regulator: core: Assign bool value to variable has_full_constraints

[Mark Brown]

On Mon, Jul 04, 2016 at 04:38:26PM +0800, Baoquan He wrote:

> By the way, I still think it makes code more read-able to assign a bool
> value to a bool variable. In your words, C truly has full support for
> using integers in a boolean context, then commit 21cf891a is not
> necessary to be made to change.

The feedback here is largely about the commit message - it's written
like it's fixing a bug but it's really just a stylistic change.


signature.asc
Description: PGP signature

Re: [PATCH 03/14] PCI: designware-plat: make it explicitly non-modular

[Joao Pinto]

Hi Paul,

On 7/3/2016 12:13 AM, Paul Gortmaker wrote:
> The Kconfig currently controlling compilation of this code is:
> 
> drivers/pci/host/Kconfig:config PCIE_DW_PLAT
> drivers/pci/host/Kconfig:   bool "Platform bus based DesignWare PCIe 
> Controller"
> 

(snip...)

> Cc: Jingoo Han 
> Cc: Pratyush Anand 
> Cc: Joao Pinto 
> Cc: Bjorn Helgaas 
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Paul Gortmaker 
> ---
>  drivers/pci/host/pcie-designware-plat.c | 10 ++
>  1 file changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/pci/host/pcie-designware-plat.c 
> b/drivers/pci/host/pcie-designware-plat.c
> index b3500994d08a..c8079dc81c10 100644
> --- a/drivers/pci/host/pcie-designware-plat.c
> +++ b/drivers/pci/host/pcie-designware-plat.c
> @@ -14,7 +14,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -121,7 +121,6 @@ static const struct of_device_id dw_plat_pcie_of_match[] 
> = {
>   { .compatible = "snps,dw-pcie", },
>   {},
>  };
> -MODULE_DEVICE_TABLE(of, dw_plat_pcie_of_match);
>  
>  static struct platform_driver dw_plat_pcie_driver = {
>   .driver = {
> @@ -130,9 +129,4 @@ static struct platform_driver dw_plat_pcie_driver = {
>   },
>   .probe = dw_plat_pcie_probe,
>  };
> -
> -module_platform_driver(dw_plat_pcie_driver);
> -
> -MODULE_AUTHOR("Joao Pinto ");
> -MODULE_DESCRIPTION("Synopsys PCIe host controller glue platform driver");
> -MODULE_LICENSE("GPL v2");
> +builtin_platform_driver(dw_plat_pcie_driver);
> 

Makes totally sense! Thanks!

Acked-by: Joao Pinto 

Re: [PATCH] regulator: pwm: Fix regulator ramp delay for continuous mode

[Mark Brown]

On Mon, Jul 04, 2016 at 11:05:04AM +0200, Boris Brezillon wrote:

> I understand, but can we still expect to have it in 4.8 (I mean,
> assuming Thierry is okay taking the first 2 patching for 4.8 too)?

Possibly - we are getting very close to the merge window now, I don't
know what Thierry's policies are on applying things as the merge window
gets near.


signature.asc
Description: PGP signature

Re: Build regressions/improvements in v4.7-rc6

[Arnd Bergmann]

On Monday, July 4, 2016 10:21:45 AM CEST Geert Uytterhoeven wrote:
> On Mon, Jul 4, 2016 at 10:12 AM, Geert Uytterhoeven
>  wrote:
> > JFYI, when comparing v4.7-rc6[1] to v4.7-rc5[3], the summaries are:
> >   - build errors: +3/-2
> 
>   + /home/kisskb/slave/src/drivers/vhost/vhost.c: error: call to
> '__compiletime_assert_844' declared with attribute error: BUILD_BUG_ON
> failed: __alignof__ *vq->avail > VRING_AVAIL_ALIGN_SIZE:  => 844:3
> 
> arm-randconfig
> 
> > [1] http://kisskb.ellerman.id.au/kisskb/head/10562/ (260 out of 263 configs)
> > [3] http://kisskb.ellerman.id.au/kisskb/head/10532/ (260 out of 263 configs)

I don't see any changes in the code in this time frame, but this is the
code causing it:


struct vring_avail {
__virtio16 flags;
__virtio16 idx;
__virtio16 ring[];
};  

/* The virtqueue structure describes a queue attached to a device. */
struct vhost_virtqueue {
struct vhost_dev *dev;

/* The actual ring of buffers. */
struct mutex mutex; 
unsigned int num; 
struct vring_desc __user *desc;
struct vring_avail __user *avail;
struct vring_used __user *used;
...
};

struct vhost_virtqueue *vq;
   BUILD_BUG_ON(__alignof__ *vq->avail > VRING_AVAIL_ALIGN_SIZE);


The alignment of the *vq->avail should be '2' on all architectures,
however an ARM OABI compiler will have a padded structure with alignment '4'.

Looking at the build logs, I find it only in a single randconfig build
at http://kisskb.ellerman.id.au/kisskb/buildresult/12735927/ which apparently
enabled the vhost driver in combination with ARM_AEABI=n.

In my own randconfig builds I am forcing ARM_AEABI=y because there are a
couple of other problems with OABI.

If we want to avoid this one, we could make the inclusion of
drivers/vhost/Kconfig from arch/arm/kvm/Kconfig depend on CONFIG_AEABI,
or perhaps go further force-enable CONFIG_AEABI for ARMv6k and higher
(cmpxchg64() is broken on OABI too), and only include vhost if KVM
is enabled (KVM in turn requires ARMv7).

Arnd

Re: [PATCH RFC v2 0/2] pxa_camera transition to v4l2 standalone device

[Hans Verkuil]

Hi Robert,

On 04/02/2016 04:26 PM, Robert Jarzmik wrote:
> Hi Hans and Guennadi,
> 
> This is the second opus of this RFC. The goal is still to see how close our
> ports are to see if there are things we could either reuse of change.
> 
> From RFCv1, the main change is cleaning up in function names and functions
> grouping, and fixes to make v4l2-compliance happy while live tests still show 
> no
> regression.
> 
> For the next steps, I'll have to :
>  - split the second patch, which will be a headache task, into :
>- first functions grouping and renaming
>  => this to ensure the "internal functions" are almost untouched
>- the the port itself
> 
> I'm leaving soc_mediabus for now, that's another task.
> 
> I'm not seeing a big review traction, especially on the vb2 conversion, so 
> I'll
> leave this patchset in RFC form until vb2 patch is reviewed and merged, and 
> then
> will come back to this work.

I'm going to review this today.

I have been trying on-and-off to convert the sh_mobile_ceu_camera to a regular
driver with basically no success. One major problem is that the sh driver 
doesn't
use the device tree, so I can't copy code from the new rcar-vin driver. The 
scaling
and cropping code is also tightly coupled to soc-camera.

It is of course possible to do given enough time, but I don't think it is worth 
it.

So instead I am going for plan B: convert all other soc-camera drivers to 
'regular'
drivers so in the end soc-camera is only used by the sh driver. Then I can turn
soc-camera into an sh driver, making it impossible for other drivers to use the
framework.

In other words, it would be great if you can continue this work, because after
this driver is converted only the atmel-isi driver remains (besides the sh 
driver,
of course).

Regards,

Hans

Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed

[Neo Jia]

On Mon, Jul 04, 2016 at 04:45:05PM +0800, Xiao Guangrong wrote:
> 
> 
> On 07/04/2016 04:41 PM, Neo Jia wrote:
> >On Mon, Jul 04, 2016 at 04:19:20PM +0800, Xiao Guangrong wrote:
> >>
> >>
> >>On 07/04/2016 03:53 PM, Neo Jia wrote:
> >>>On Mon, Jul 04, 2016 at 03:37:35PM +0800, Xiao Guangrong wrote:
> 
> 
> On 07/04/2016 03:03 PM, Neo Jia wrote:
> >On Mon, Jul 04, 2016 at 02:39:22PM +0800, Xiao Guangrong wrote:
> >>
> >>
> >>On 06/30/2016 09:01 PM, Paolo Bonzini wrote:
> >>>The vGPU folks would like to trap the first access to a BAR by setting
> >>>vm_ops on the VMAs produced by mmap-ing a VFIO device.  The fault 
> >>>handler
> >>>then can use remap_pfn_range to place some non-reserved pages in the 
> >>>VMA.
> >>
> >>Why does it require fetching the pfn when the fault is triggered rather
> >>than when mmap() is called?
> >
> >Hi Guangrong,
> >
> >as such mapping information between virtual mmio to physical mmio is 
> >only available
> >at runtime.
> 
> Sorry, i do not know what the different between mmap() and the time VM 
> actually
> accesses the memory for your case. Could you please more detail?
> >>>
> >>>Hi Guangrong,
> >>>
> >>>Sure. The mmap() gets called by qemu or any VFIO API userspace consumer 
> >>>when
> >>>setting up the virtual mmio, at that moment nobody has any knowledge about 
> >>>how
> >>>the physical mmio gets virtualized.
> >>>
> >>>When the vm (or application if we don't want to limit ourselves to vmm 
> >>>term)
> >>>starts, the virtual and physical mmio gets mapped by mpci kernel module 
> >>>with the
> >>>help from vendor supplied mediated host driver according to the hw resource
> >>>assigned to this vm / application.
> >>
> >>Thanks for your expiation.
> >>
> >>It sounds like a strategy of resource allocation, you delay the allocation 
> >>until VM really
> >>accesses it, right?
> >
> >Yes, that is where the fault handler inside mpci code comes to the picture.
> 
> 
> I am not sure this strategy is good. The instance is successfully created, 
> and it is started
> successful, but the VM is crashed due to the resource of that instance is not 
> enough. That sounds
> unreasonable.


Sorry, I think I misread the "allocation" as "mapping". We only delay the
cpu mapping, not the allocation.

Thanks,
Neo

> 
> 
> 

Re: [PATCH 3/4] bus: tegra-aconnect: make it explicitly non-modular

[Jon Hunter]

Hi Paul,

On 03/07/16 18:30, Paul Gortmaker wrote:
> The Kconfig currently controlling compilation of this code is:
> 
> drivers/bus/Kconfig:config TEGRA_ACONNECT
> drivers/bus/Kconfig:bool "Tegra ACONNECT Bus Driver"
> 
> ...meaning that it currently is not being built as a module by anyone.
> 
> Lets remove the modular code that is essentially orphaned, so that
> when reading the driver there is no doubt it is builtin-only.
> 
> We explicitly disallow a driver unbind, since that doesn't have a
> sensible use case anyway, and it allows us to drop the ".remove"
> code for non-modular drivers.
> 
> Since module_platform_driver() uses the same init level priority as
> builtin_platform_driver() the init ordering remains unchanged with
> this commit.
> 
> Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
> 
> We also delete the MODULE_LICENSE tag etc. since all that information
> was (or is now) contained at the top of the file in the comments.

In version 3 of the aconnect series [0] I had made this a tristate
because we allowed it to be removed and you had submitted a patch to
export the PM_CLK APIs. However, when discussing with Thierry he said
that we were unable to merge with tristate because of the dependency on
your patch. So he suggested we merge with bool for now and then change
it back to tristate for v4.9.

I understand that we should not do this, but we do plan to make this
modular in the future.

Cheers
Jon

[0] http://marc.info/?l=linux-tegra&m=146616753627760&w=2

-- 
nvpublic