Re: [PATCH v3] KVM: remove buggy vcpu id check on vcpu creation

2016-04-22 09:40+0800, Wanpeng Li: > 2016-04-21 23:29 GMT+08:00 Radim Krčmář : >> x86 vcpu_id encodes APIC ID and APIC ID encodes CPU topology by >> reserving blocks of bits for socket/core/thread, so if core or thread >> count isn't a power of two, then the set of valid APIC

Re: [PATCH v3] KVM: remove buggy vcpu id check on vcpu creation

2016-04-22 09:40+0800, Wanpeng Li: > 2016-04-21 23:29 GMT+08:00 Radim Krčmář : >> x86 vcpu_id encodes APIC ID and APIC ID encodes CPU topology by >> reserving blocks of bits for socket/core/thread, so if core or thread >> count isn't a power of two, then the set of valid APIC IDs is sparse, > >

Re: [PATCH v7 05/10] iommu/dma-reserved-iommu: reserved binding rb-tree and helpers

On 20/04/16 17:18, Eric Auger wrote: Robin, On 04/20/2016 03:12 PM, Robin Murphy wrote: On 19/04/16 17:56, Eric Auger wrote: we will need to track which host physical addresses are mapped to reserved IOVA. In that prospect we introduce a new RB tree indexed by physical address. This RB tree

Re: [PATCH v7 05/10] iommu/dma-reserved-iommu: reserved binding rb-tree and helpers

On 20/04/16 17:18, Eric Auger wrote: Robin, On 04/20/2016 03:12 PM, Robin Murphy wrote: On 19/04/16 17:56, Eric Auger wrote: we will need to track which host physical addresses are mapped to reserved IOVA. In that prospect we introduce a new RB tree indexed by physical address. This RB tree

Re: [RFC][PATCH 00/31] implement atomic_fetch_$op

On Fri, Apr 22, 2016 at 08:56:56PM +0800, Fengguang Wu wrote: > On Fri, Apr 22, 2016 at 11:44:55AM +0200, Peter Zijlstra wrote: > > On Fri, Apr 22, 2016 at 11:04:13AM +0200, Peter Zijlstra wrote: > > > The one that I did not do was ARMv8.1-LSE and I was hoping Will would > > > help out > > > with

Re: [PATCH 02/11] clk: tegra: dfll: Move SoC specific data into of_device_id

On Fri, Apr 22, 2016 at 06:31:02PM +0800, Penny Chiu wrote: > Move all SoC specific fcpu data into of_device_id structure, and > move SoC fcpu data assignments from init function to probe > function. > > Signed-off-by: Penny Chiu > --- >

Re: [PATCH net v2 2/3] drivers: net: cpsw: fix error messages when using phy-handle DT property

On 04/21/2016 09:26 PM, David Rivshin (Allworx) wrote: > From: David Rivshin > > The phy-handle, phy_id, and fixed-link properties are mutually exclusive, > and only one need be specified. However if phy-handle was specified, an > error message would complain about the lack

Re: [RFC][PATCH 00/31] implement atomic_fetch_$op

On Fri, Apr 22, 2016 at 08:56:56PM +0800, Fengguang Wu wrote: > On Fri, Apr 22, 2016 at 11:44:55AM +0200, Peter Zijlstra wrote: > > On Fri, Apr 22, 2016 at 11:04:13AM +0200, Peter Zijlstra wrote: > > > The one that I did not do was ARMv8.1-LSE and I was hoping Will would > > > help out > > > with

Re: [PATCH 02/11] clk: tegra: dfll: Move SoC specific data into of_device_id

On Fri, Apr 22, 2016 at 06:31:02PM +0800, Penny Chiu wrote: > Move all SoC specific fcpu data into of_device_id structure, and > move SoC fcpu data assignments from init function to probe > function. > > Signed-off-by: Penny Chiu > --- > drivers/clk/tegra/clk-tegra124-dfll-fcpu.c | 51 >

Re: [PATCH net v2 2/3] drivers: net: cpsw: fix error messages when using phy-handle DT property

On 04/21/2016 09:26 PM, David Rivshin (Allworx) wrote: > From: David Rivshin > > The phy-handle, phy_id, and fixed-link properties are mutually exclusive, > and only one need be specified. However if phy-handle was specified, an > error message would complain about the lack of phy_id or

Re: [PATCH net v2 1/3] drivers: net: cpsw: fix parsing of phy-handle DT property in dual_emac config

On 04/21/2016 09:19 PM, David Rivshin (Allworx) wrote: From: David Rivshin Commit 9e42f715264ff158478fa30eaed847f6e131366b ("drivers: net: cpsw: add phy-handle parsing") saved the "phy-handle" phandle into a new cpsw_priv field. However, phy connections are per-slave, so

Re: [PATCH net v2 1/3] drivers: net: cpsw: fix parsing of phy-handle DT property in dual_emac config

On 04/21/2016 09:19 PM, David Rivshin (Allworx) wrote: From: David Rivshin Commit 9e42f715264ff158478fa30eaed847f6e131366b ("drivers: net: cpsw: add phy-handle parsing") saved the "phy-handle" phandle into a new cpsw_priv field. However, phy connections are per-slave, so the phy_node field

Re: [RFC][PATCH 27/31] locking: Remove linux/atomic.h:atomic_fetch_or

On Fri, Apr 22, 2016 at 11:04:40AM +0200, Peter Zijlstra wrote: > Since all architectures have this implemented natively, remove this > now dead code. > > > > > > Signed-off-by: Peter Zijlstra (Intel) > --- > arch/alpha/include/asm/atomic.h|2 -- >

Re: [PATCH v7 03/10] iommu: introduce a reserved iova cookie

Hi Robin, On 04/22/2016 02:36 PM, Robin Murphy wrote: > On 20/04/16 17:14, Eric Auger wrote: >> Hi Robin, >> On 04/20/2016 02:55 PM, Robin Murphy wrote: >>> On 19/04/16 17:56, Eric Auger wrote: This patch introduces some new fields in the iommu_domain struct, dedicated to reserved iova

Re: [RFC][PATCH 27/31] locking: Remove linux/atomic.h:atomic_fetch_or

On Fri, Apr 22, 2016 at 11:04:40AM +0200, Peter Zijlstra wrote: > Since all architectures have this implemented natively, remove this > now dead code. > > > > > > Signed-off-by: Peter Zijlstra (Intel) > --- > arch/alpha/include/asm/atomic.h|2 -- > arch/arc/include/asm/atomic.h

Re: [PATCH v7 03/10] iommu: introduce a reserved iova cookie

Hi Robin, On 04/22/2016 02:36 PM, Robin Murphy wrote: > On 20/04/16 17:14, Eric Auger wrote: >> Hi Robin, >> On 04/20/2016 02:55 PM, Robin Murphy wrote: >>> On 19/04/16 17:56, Eric Auger wrote: This patch introduces some new fields in the iommu_domain struct, dedicated to reserved iova

[PATCH v12 0/3] printk: Make printk() completely async

and thus we don't lockup any particular CPU or even interrupts. against next-20160422 v12: -- rename printk_kthread_can_run bool flag -- update printk_kthread_can_run comment (Petr) -- drop mutex from printk_sync_set(), sysfs writes are synchronised (Petr) v11: -- switch default to sync printk

Re: [RFC][PATCH 00/31] implement atomic_fetch_$op

On Fri, Apr 22, 2016 at 11:44:55AM +0200, Peter Zijlstra wrote: > On Fri, Apr 22, 2016 at 11:04:13AM +0200, Peter Zijlstra wrote: > > The one that I did not do was ARMv8.1-LSE and I was hoping Will would help > > out > > with that. Also, it looks like the 0-day built bot does not do arm64 builds,

[PATCH v12 0/3] printk: Make printk() completely async

and thus we don't lockup any particular CPU or even interrupts. against next-20160422 v12: -- rename printk_kthread_can_run bool flag -- update printk_kthread_can_run comment (Petr) -- drop mutex from printk_sync_set(), sysfs writes are synchronised (Petr) v11: -- switch default to sync printk

Re: [RFC][PATCH 00/31] implement atomic_fetch_$op

On Fri, Apr 22, 2016 at 11:44:55AM +0200, Peter Zijlstra wrote: > On Fri, Apr 22, 2016 at 11:04:13AM +0200, Peter Zijlstra wrote: > > The one that I did not do was ARMv8.1-LSE and I was hoping Will would help > > out > > with that. Also, it looks like the 0-day built bot does not do arm64 builds,

[PATCH v12 2/3] printk: Make wake_up_klogd_work_func() async

From: Jan Kara Offload printing of scheduler deferred messages from IRQ context to a schedulable printing kthread, when possible (the same way we do it in vprintk_emit()). Otherwise, the CPU can spend unbounded amount of time doing printing in console_unlock() from IRQ.

[PATCH v12 2/3] printk: Make wake_up_klogd_work_func() async

From: Jan Kara Offload printing of scheduler deferred messages from IRQ context to a schedulable printing kthread, when possible (the same way we do it in vprintk_emit()). Otherwise, the CPU can spend unbounded amount of time doing printing in console_unlock() from IRQ. Signed-off-by: Jan Kara

Re: [PATCH 05/11] pwm: tegra-dfll: Add driver for Tegra DFLL PWM controller

On Fri, Apr 22, 2016 at 06:31:05PM +0800, Penny Chiu wrote: > Tegra DFLL IP block controls off-chip PMIC via I2C bus or PWM > signals. This driver exposes DFLL as a PWM controller to generate > PWM signals to PWM regulator. > > Tegra DFLL HW changes regulator voltage by adjusting PWM signals >

[PATCH v12 3/3] printk: make printk.synchronous param rw

Change `synchronous' printk param to be RW, so user space can change printk mode back and forth to/from sync mode (which is considered to be more reliable). Signed-off-by: Sergey Senozhatsky --- kernel/printk/printk.c | 51

Re: [PATCH 05/11] pwm: tegra-dfll: Add driver for Tegra DFLL PWM controller

On Fri, Apr 22, 2016 at 06:31:05PM +0800, Penny Chiu wrote: > Tegra DFLL IP block controls off-chip PMIC via I2C bus or PWM > signals. This driver exposes DFLL as a PWM controller to generate > PWM signals to PWM regulator. > > Tegra DFLL HW changes regulator voltage by adjusting PWM signals >

[PATCH v12 3/3] printk: make printk.synchronous param rw

Change `synchronous' printk param to be RW, so user space can change printk mode back and forth to/from sync mode (which is considered to be more reliable). Signed-off-by: Sergey Senozhatsky --- kernel/printk/printk.c | 51 +++--- 1 file changed, 40

[PATCH v12 1/3] printk: Make printk() completely async

From: Jan Kara Currently, printk() sometimes waits for message to be printed to console and sometimes it does not (when console_sem is held by some other process). In case printk() grabs console_sem and starts printing to console, it prints messages from kernel printk buffer until

Re: [PATCH v2 1/2] mmc: sdhci: use IS_REACHABLE(CONFIG_LEDS_CLASS) to enable LED code

On 14 April 2016 at 06:19, Masahiro Yamada wrote: > defined(CONFIG_LEDS_CLASS) || (defined(CONFIG_LEDS_CLASS_MODULE) && \ > defined(CONFIG_MMC_SDHCI_MODULE)) > > is equivalent to: > > defined(CONFIG_LEDS_CLASS) || (defined(CONFIG_LEDS_CLASS_MODULE) && \ >

[PATCH v12 1/3] printk: Make printk() completely async

From: Jan Kara Currently, printk() sometimes waits for message to be printed to console and sometimes it does not (when console_sem is held by some other process). In case printk() grabs console_sem and starts printing to console, it prints messages from kernel printk buffer until the buffer is

Re: [PATCH v2 1/2] mmc: sdhci: use IS_REACHABLE(CONFIG_LEDS_CLASS) to enable LED code

On 14 April 2016 at 06:19, Masahiro Yamada wrote: > defined(CONFIG_LEDS_CLASS) || (defined(CONFIG_LEDS_CLASS_MODULE) && \ > defined(CONFIG_MMC_SDHCI_MODULE)) > > is equivalent to: > > defined(CONFIG_LEDS_CLASS) || (defined(CONFIG_LEDS_CLASS_MODULE) && \ > defined(MODULE)) > > and it can

Re: [PATCH v2 2/2] mmc: sdhci: use IS_ENABLE(CONFIG_LEDS_CLASS) to enable LED struct members

On 14 April 2016 at 06:19, Masahiro Yamada wrote: > defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE) > > is equivalent to: > > IS_ENABLED(CONFIG_LEDS_CLASS) > > Signed-off-by: Masahiro Yamada Thanks, applied for next!

Re: [PATCH v2 2/2] mmc: sdhci: use IS_ENABLE(CONFIG_LEDS_CLASS) to enable LED struct members

On 14 April 2016 at 06:19, Masahiro Yamada wrote: > defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE) > > is equivalent to: > > IS_ENABLED(CONFIG_LEDS_CLASS) > > Signed-off-by: Masahiro Yamada Thanks, applied for next! Kind regards Uffe > --- > > Changes in v2: > - Newly added

Re: [PATCH v2 0/7] mmc: sdhci-pltfm: fix and tidy up sdhci_pltfm_init()

On 20 April 2016 at 04:16, Masahiro Yamada wrote: > > > Changes in v2: > - Remove resource size checking rather than fix it. > - Add \n to the tail of the error message > > Masahiro Yamada (7): > mmc: sdhci-pltfm: drop error message for too small MMIO resource

Re: [PATCH v2 0/7] mmc: sdhci-pltfm: fix and tidy up sdhci_pltfm_init()

On 20 April 2016 at 04:16, Masahiro Yamada wrote: > > > Changes in v2: > - Remove resource size checking rather than fix it. > - Add \n to the tail of the error message > > Masahiro Yamada (7): > mmc: sdhci-pltfm: drop error message for too small MMIO resource size > mmc: sdhci-pltfm:

[PATCH 2/2] regulator: max77620: Add support for device specific ramp rate setting

Maxim advertised the ramp rate of the rail with some recommended design specification like output capacitance of rail should be 2.2uF. This make sure that current change in the rail is within maximum current limit and hence meet the advertised ramp rate. If there is variation in design which

[PATCH 1/2] regulator: max77620: Add details of device specific ramp rate setting

It is observed that the ramp rate measured on platform is not same as advertised ramp rate due to platform design variation. On this case, measured ramp rate is provided with property regulator-ramp-rate. For such cases, add DT property for device specific configurations. Signed-off-by: Laxman

[PATCH 2/2] regulator: max77620: Add support for device specific ramp rate setting

Maxim advertised the ramp rate of the rail with some recommended design specification like output capacitance of rail should be 2.2uF. This make sure that current change in the rail is within maximum current limit and hence meet the advertised ramp rate. If there is variation in design which

[PATCH 1/2] regulator: max77620: Add details of device specific ramp rate setting

It is observed that the ramp rate measured on platform is not same as advertised ramp rate due to platform design variation. On this case, measured ramp rate is provided with property regulator-ramp-rate. For such cases, add DT property for device specific configurations. Signed-off-by: Laxman

Re: [PATCH V6 09/13] pci, acpi: Support for ACPI based generic PCI host controller

On Thu, Apr 21, 2016 at 2:36 PM, Tomasz Nowicki wrote: > On 20.04.2016 21:12, Jayachandran C wrote: >> >> On Fri, Apr 15, 2016 at 10:36 PM, Tomasz Nowicki wrote: >>> >>> This patch is going to implement generic PCI host controller for >>> ACPI world, similar

Re: [PATCH V6 09/13] pci, acpi: Support for ACPI based generic PCI host controller

On Thu, Apr 21, 2016 at 2:36 PM, Tomasz Nowicki wrote: > On 20.04.2016 21:12, Jayachandran C wrote: >> >> On Fri, Apr 15, 2016 at 10:36 PM, Tomasz Nowicki wrote: >>> >>> This patch is going to implement generic PCI host controller for >>> ACPI world, similar to what pci-host-generic.c driver

Re: [PATCH v2] Force cppc_cpufreq to report values in KHz to fix user space reporting

On Tuesday, April 19, 2016 04:12:41 PM Ashwin Chaugule wrote: > + Ryan > > Hi Al, > > On 18 April 2016 at 20:11, Al Stone wrote: > > When CPPC is being used by ACPI on arm64, user space tools such as > > cpupower report CPU frequency values from sysfs that are incorrect. > > >

Re: [PATCH v2] Force cppc_cpufreq to report values in KHz to fix user space reporting

On Tuesday, April 19, 2016 04:12:41 PM Ashwin Chaugule wrote: > + Ryan > > Hi Al, > > On 18 April 2016 at 20:11, Al Stone wrote: > > When CPPC is being used by ACPI on arm64, user space tools such as > > cpupower report CPU frequency values from sysfs that are incorrect. > > > > What the driver

Re: [PATCH v7] Bluetooth: hci_uart: Support firmware download for Marvell

Hi Amitkumar, + +static int mrvl_setup(struct hci_uart *hu) { + struct mrvl_data *mrvl = hu->priv; + + mrvl_init_fw_data(hu); + set_bit(HCI_UART_DNLD_FW, >flags); + + return hci_uart_dnld_fw(hu); +} >>> >>> So this is clearly the wrong spot. When

Re: [PATCH v7] Bluetooth: hci_uart: Support firmware download for Marvell

Hi Amitkumar, + +static int mrvl_setup(struct hci_uart *hu) { + struct mrvl_data *mrvl = hu->priv; + + mrvl_init_fw_data(hu); + set_bit(HCI_UART_DNLD_FW, >flags); + + return hci_uart_dnld_fw(hu); +} >>> >>> So this is clearly the wrong spot. When

Re: [PATCH 17/19] dm: get rid of superfluous gfp flags

On Sat 16-04-16 16:31:35, Michal Hocko wrote: > On Fri 15-04-16 14:41:29, Mikulas Patocka wrote: > > > > > > On Fri, 15 Apr 2016, Michal Hocko wrote: > > > > > On Fri 15-04-16 08:29:28, Mikulas Patocka wrote: > > > > > > > > > > > > On Mon, 11 Apr 2016, Michal Hocko wrote: > > > > > > > > >

Re: [PATCH 17/19] dm: get rid of superfluous gfp flags

On Sat 16-04-16 16:31:35, Michal Hocko wrote: > On Fri 15-04-16 14:41:29, Mikulas Patocka wrote: > > > > > > On Fri, 15 Apr 2016, Michal Hocko wrote: > > > > > On Fri 15-04-16 08:29:28, Mikulas Patocka wrote: > > > > > > > > > > > > On Mon, 11 Apr 2016, Michal Hocko wrote: > > > > > > > > >

[PATCH v2] dmaengine: tegra-apb: proper default init of channel slave_id

Initialize default channel slave_id(req_sel) to invalid id (i.e max supported slave id + 1) to avoid overwriting of slave_id during tegra_dma_slave_config() with client data if slave_id is not initialized through DT Signed-off-by: Shardar Shariff Md --- - Instead of

[PATCH v2] dmaengine: tegra-apb: proper default init of channel slave_id

Initialize default channel slave_id(req_sel) to invalid id (i.e max supported slave id + 1) to avoid overwriting of slave_id during tegra_dma_slave_config() with client data if slave_id is not initialized through DT Signed-off-by: Shardar Shariff Md --- - Instead of initializing the slave id to

Re: [PATCH v2] Force cppc_cpufreq to report values in KHz to fix user space reporting

On Friday, April 22, 2016 11:00:20 AM Viresh Kumar wrote: > On 19-04-16, 16:12, Ashwin Chaugule wrote: > > + Ryan > > > > Hi Al, > > > > On 18 April 2016 at 20:11, Al Stone wrote: > > > When CPPC is being used by ACPI on arm64, user space tools such as > > > cpupower report CPU

Re: [PATCH v2] Force cppc_cpufreq to report values in KHz to fix user space reporting

On Friday, April 22, 2016 11:00:20 AM Viresh Kumar wrote: > On 19-04-16, 16:12, Ashwin Chaugule wrote: > > + Ryan > > > > Hi Al, > > > > On 18 April 2016 at 20:11, Al Stone wrote: > > > When CPPC is being used by ACPI on arm64, user space tools such as > > > cpupower report CPU frequency values

Re: [PATCH] PM / OPP: -ENOSYS is applicable only to syscalls

On Friday, April 22, 2016 08:46:51 AM Viresh Kumar wrote: > Some of the routines have use -ENOSYS, which is supposed to be used only > for syscalls. Replace that with -EINVAL. -EINVAL specifically means "invalid argument". What about using -ENXIO instead?

Re: [PATCH] PM / OPP: -ENOSYS is applicable only to syscalls

On Friday, April 22, 2016 08:46:51 AM Viresh Kumar wrote: > Some of the routines have use -ENOSYS, which is supposed to be used only > for syscalls. Replace that with -EINVAL. -EINVAL specifically means "invalid argument". What about using -ENXIO instead?

Re: [PATCH 5/6] leds: pca963x: Inform the output that it is inverted

Hey Rob, On 21-04-16 17:07, Rob Herring wrote: On Tue, Apr 19, 2016 at 09:40:49AM +0200, Olliver Schinagl wrote: When leds are connected in a totem-pole configuration, they can be connected either in a active-high, or active-low manor. The driver currently always assumes active-high. This

Re: [PATCH 5/6] leds: pca963x: Inform the output that it is inverted

Hey Rob, On 21-04-16 17:07, Rob Herring wrote: On Tue, Apr 19, 2016 at 09:40:49AM +0200, Olliver Schinagl wrote: When leds are connected in a totem-pole configuration, they can be connected either in a active-high, or active-low manor. The driver currently always assumes active-high. This

Re: [PATCH] media: vb2: Fix regression on poll() for RW mode

On 04/22/2016 02:31 PM, Mauro Carvalho Chehab wrote: > Em Fri, 22 Apr 2016 11:19:09 +0200 > Hans Verkuil escreveu: > >> Hi Ricardo, >> >> On 04/21/2016 11:15 AM, Ricardo Ribalda Delgado wrote: >>> When using a device is read/write mode, vb2 does not handle properly the >>>

Re: [PATCH] media: vb2: Fix regression on poll() for RW mode

On 04/22/2016 02:31 PM, Mauro Carvalho Chehab wrote: > Em Fri, 22 Apr 2016 11:19:09 +0200 > Hans Verkuil escreveu: > >> Hi Ricardo, >> >> On 04/21/2016 11:15 AM, Ricardo Ribalda Delgado wrote: >>> When using a device is read/write mode, vb2 does not handle properly the >>> first select/poll

Re: [PATCH v7 03/10] iommu: introduce a reserved iova cookie

On 20/04/16 17:14, Eric Auger wrote: Hi Robin, On 04/20/2016 02:55 PM, Robin Murphy wrote: On 19/04/16 17:56, Eric Auger wrote: This patch introduces some new fields in the iommu_domain struct, dedicated to reserved iova management. In a similar way as DMA mapping IOVA window, we need to

Re: [PATCH v7 03/10] iommu: introduce a reserved iova cookie

On 20/04/16 17:14, Eric Auger wrote: Hi Robin, On 04/20/2016 02:55 PM, Robin Murphy wrote: On 19/04/16 17:56, Eric Auger wrote: This patch introduces some new fields in the iommu_domain struct, dedicated to reserved iova management. In a similar way as DMA mapping IOVA window, we need to

Re: [PATCH] media: vb2: Fix regression on poll() for RW mode

Em Fri, 22 Apr 2016 11:19:09 +0200 Hans Verkuil escreveu: > Hi Ricardo, > > On 04/21/2016 11:15 AM, Ricardo Ribalda Delgado wrote: > > When using a device is read/write mode, vb2 does not handle properly the > > first select/poll operation. It allways return POLLERR. > > >

Re: [PATCH] media: vb2: Fix regression on poll() for RW mode

Em Fri, 22 Apr 2016 11:19:09 +0200 Hans Verkuil escreveu: > Hi Ricardo, > > On 04/21/2016 11:15 AM, Ricardo Ribalda Delgado wrote: > > When using a device is read/write mode, vb2 does not handle properly the > > first select/poll operation. It allways return POLLERR. > > > > The reason for

Re: [PATCH v7 00/10] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 1/3: iommu changes

Hi Alex, On 04/21/2016 09:32 PM, Alex Williamson wrote: > On Thu, 21 Apr 2016 14:18:09 +0200 > Eric Auger wrote: > >> Hi Alex, Robin, >> On 04/19/2016 06:56 PM, Eric Auger wrote: >>> This series introduces the dma-reserved-iommu api used to: >>> >>> - create/destroy an

Re: [PATCH v7 00/10] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 1/3: iommu changes

Hi Alex, On 04/21/2016 09:32 PM, Alex Williamson wrote: > On Thu, 21 Apr 2016 14:18:09 +0200 > Eric Auger wrote: > >> Hi Alex, Robin, >> On 04/19/2016 06:56 PM, Eric Auger wrote: >>> This series introduces the dma-reserved-iommu api used to: >>> >>> - create/destroy an iova domain dedicated to

Re: [PATCH v7 1/8] genirq/msi: Add a new MSI_FLAG_IRQ_REMAPPING flag

Robin, On 04/22/2016 01:02 PM, Robin Murphy wrote: > Hi Eric, > > On 19/04/16 18:13, Eric Auger wrote: >> Let's introduce a new msi_domain_info flag value, MSI_FLAG_IRQ_REMAPPING >> meant to tell the domain supports IRQ REMAPPING, also known as Interrupt >> Translation Service. On Intel HW this

Re: [PATCH v7 1/8] genirq/msi: Add a new MSI_FLAG_IRQ_REMAPPING flag

Robin, On 04/22/2016 01:02 PM, Robin Murphy wrote: > Hi Eric, > > On 19/04/16 18:13, Eric Auger wrote: >> Let's introduce a new msi_domain_info flag value, MSI_FLAG_IRQ_REMAPPING >> meant to tell the domain supports IRQ REMAPPING, also known as Interrupt >> Translation Service. On Intel HW this

Re: [PATCH] mmc: mediatek: fix request blocked by cancel_delayed_work

On 18 April 2016 at 09:13, Chaotian Jing wrote: > there are 2 points will cause could not call mmc_request_done() > and eventually cause the caller thread blocked. > > A. if card was busy, cancel_delayed_work() will return false because > the delay work has not been

Re: [PATCH] mmc: mediatek: fix request blocked by cancel_delayed_work

On 18 April 2016 at 09:13, Chaotian Jing wrote: > there are 2 points will cause could not call mmc_request_done() > and eventually cause the caller thread blocked. > > A. if card was busy, cancel_delayed_work() will return false because > the delay work has not been scheduled, in this case, need

Re: [PATCHv7 2/3] x86/vdso: add mremap hook to vm_special_mapping

On 04/21/2016 10:52 PM, Andy Lutomirski wrote: On Mon, Apr 18, 2016 at 7:23 AM, Dmitry Safonov wrote: Add possibility for userspace 32-bit applications to move vdso mapping. Previously, when userspace app called mremap for vdso, in return path it would land on previous

Re: [PATCHv7 2/3] x86/vdso: add mremap hook to vm_special_mapping

On 04/21/2016 10:52 PM, Andy Lutomirski wrote: On Mon, Apr 18, 2016 at 7:23 AM, Dmitry Safonov wrote: Add possibility for userspace 32-bit applications to move vdso mapping. Previously, when userspace app called mremap for vdso, in return path it would land on previous address of vdso page,

Re: [PATCH] qla1280: Reduce can_queue to 32

The change looks fine, I see its hard-coded to 32 in qla1280_set_defaults() Would it be better to create a #define like other drivers and use that in both. Also did the below patch resolve this for the bug reporter. I ask because if I check 4.3 it was also set to the same value of 0xf and

Re: [PATCH] qla1280: Reduce can_queue to 32

The change looks fine, I see its hard-coded to 32 in qla1280_set_defaults() Would it be better to create a #define like other drivers and use that in both. Also did the below patch resolve this for the bug reporter. I ask because if I check 4.3 it was also set to the same value of 0xf and

Re: [PATCH] media: vb2: Fix regression on poll() for RW mode

Em Thu, 21 Apr 2016 11:15:16 +0200 Ricardo Ribalda Delgado escreveu: > When using a device is read/write mode, vb2 does not handle properly the > first select/poll operation. It allways return POLLERR. > > The reason for this is that when this code has been

Re: [PATCH] media: vb2: Fix regression on poll() for RW mode

Em Thu, 21 Apr 2016 11:15:16 +0200 Ricardo Ribalda Delgado escreveu: > When using a device is read/write mode, vb2 does not handle properly the > first select/poll operation. It allways return POLLERR. > > The reason for this is that when this code has been refactored, some of > the operations

[PATCH 1/2] crypto: s5p-sss - Use common BIT macro

The BIT() macro is obvious and well known, so prefer to use it instead of crafted own macro. Signed-off-by: Krzysztof Kozlowski --- drivers/crypto/s5p-sss.c | 95 1 file changed, 47 insertions(+), 48 deletions(-) diff

[PATCH 2/2] crypto: s5p-sss - Fix missed interrupts when working with 8 kB blocks

The tcrypt testing module on Exynos5422-based Odroid XU3/4 board failed on testing 8 kB size blocks: $ sudo modprobe tcrypt sec=1 mode=500 testing speed of async ecb(aes) (ecb-aes-s5p) encryption test 0 (128 bit key, 16 byte blocks): 21971 operations in 1 seconds (351536

[PATCH 1/2] crypto: s5p-sss - Use common BIT macro

The BIT() macro is obvious and well known, so prefer to use it instead of crafted own macro. Signed-off-by: Krzysztof Kozlowski --- drivers/crypto/s5p-sss.c | 95 1 file changed, 47 insertions(+), 48 deletions(-) diff --git

[PATCH 2/2] crypto: s5p-sss - Fix missed interrupts when working with 8 kB blocks

The tcrypt testing module on Exynos5422-based Odroid XU3/4 board failed on testing 8 kB size blocks: $ sudo modprobe tcrypt sec=1 mode=500 testing speed of async ecb(aes) (ecb-aes-s5p) encryption test 0 (128 bit key, 16 byte blocks): 21971 operations in 1 seconds (351536

Re: [PATCH v11 3/3] printk: make printk.synchronous param rw

Hello, On (04/22/16 10:41), Petr Mladek wrote: > Ah, I see and feel shame. It is actually explained in the comment > above printk_initcall_done declaration. Well, the explanation confused > me a bit ;-) I suggest to change it sligtly: > > /* > * printk_sync_set() can be called from two places:

Re: [PATCH v11 3/3] printk: make printk.synchronous param rw

Hello, On (04/22/16 10:41), Petr Mladek wrote: > Ah, I see and feel shame. It is actually explained in the comment > above printk_initcall_done declaration. Well, the explanation confused > me a bit ;-) I suggest to change it sligtly: > > /* > * printk_sync_set() can be called from two places:

Re: [alsa-devel] [PATCH 4/4] ASoC: simple-card: Support for selecting system clocks by ID

On 22/04/16 14:52, Peter Ujfalusi wrote: On 04/22/16 01:29, Stephen Boyd wrote: The first issue with converting the McASP to use CCF internally for clock selection, muxing and rate configuration is that the daVinci platform does not use CCF at all. Given that the davinci-mcasp driver is used by

Re: [alsa-devel] [PATCH 4/4] ASoC: simple-card: Support for selecting system clocks by ID

On 22/04/16 14:52, Peter Ujfalusi wrote: On 04/22/16 01:29, Stephen Boyd wrote: The first issue with converting the McASP to use CCF internally for clock selection, muxing and rate configuration is that the daVinci platform does not use CCF at all. Given that the davinci-mcasp driver is used by

Re: [PATCH v3] sched/cpufreq: optimize cpufreq update kicker to avoid update multiple times

[Added linux-pm to the CC - can you please do so for PM-related patches in the future?] On 4/22/2016 11:07 AM, Wanpeng Li wrote: From: Wanpeng Li Sometimes delta_exec is 0 due to update_curr() is called multiple times, this is captured by: u64 delta_exec =

Re: [PATCH v3] sched/cpufreq: optimize cpufreq update kicker to avoid update multiple times

[Added linux-pm to the CC - can you please do so for PM-related patches in the future?] On 4/22/2016 11:07 AM, Wanpeng Li wrote: From: Wanpeng Li Sometimes delta_exec is 0 due to update_curr() is called multiple times, this is captured by: u64 delta_exec = rq_clock_task(rq) -

[PATCH 2/2] printk, allow different timestamps for printk.time

Over the past years I've seen many reports of bugs that include time-stamped kernel logs (enabled when CONFIG_PRINTK_TIME=y or print.time=1 is specified as a kernel parameter) that do not align with either external time stamped logs or /var/log/messages. This also makes determining the time of a

[PATCH 1/2] lib, switch CONFIG_PRINTK_TIME to int

CONFIG_PRINTK_TIME is a bool and in order to add timestamp options for the monotonic and real time clock it must be expanded to an int. Cc: Petr Mladek Cc: John Stultz Cc: Xunlei Pang Cc: Thomas Gleixner Cc:

[PATCH 0/2 v7]: printk, Add monotonic and real printk timestamps

This patchset adds monotonic and real printk timestamps. The first patch changes CONFIG_PRINT_TIME from a bool to an int to allow for the additional timestamps that are added in patch 2. Changes from v6: Petr Mladek pointed out that the current patch causes problems for dmesg (and potentially

[PATCH 2/2] printk, allow different timestamps for printk.time

Over the past years I've seen many reports of bugs that include time-stamped kernel logs (enabled when CONFIG_PRINTK_TIME=y or print.time=1 is specified as a kernel parameter) that do not align with either external time stamped logs or /var/log/messages. This also makes determining the time of a

[PATCH 1/2] lib, switch CONFIG_PRINTK_TIME to int

CONFIG_PRINTK_TIME is a bool and in order to add timestamp options for the monotonic and real time clock it must be expanded to an int. Cc: Petr Mladek Cc: John Stultz Cc: Xunlei Pang Cc: Thomas Gleixner Cc: Baolin Wang Cc: Andrew Morton Cc: Greg Kroah-Hartman Cc: Petr Mladek Cc: Tejun

[PATCH 0/2 v7]: printk, Add monotonic and real printk timestamps

This patchset adds monotonic and real printk timestamps. The first patch changes CONFIG_PRINT_TIME from a bool to an int to allow for the additional timestamps that are added in patch 2. Changes from v6: Petr Mladek pointed out that the current patch causes problems for dmesg (and potentially

Re: [PATCH v7 01/10] iommu: Add DOMAIN_ATTR_MSI_MAPPING attribute

Hi Robin, On 04/22/2016 01:31 PM, Robin Murphy wrote: > On 20/04/16 16:58, Eric Auger wrote: >> Hi Robin, >> On 04/20/2016 02:47 PM, Robin Murphy wrote: >>> Hi Eric, >>> >>> On 19/04/16 17:56, Eric Auger wrote: Introduce a new DOMAIN_ATTR_MSI_MAPPING domain attribute. If supported, this

Re: [PATCH v7 01/10] iommu: Add DOMAIN_ATTR_MSI_MAPPING attribute

Hi Robin, On 04/22/2016 01:31 PM, Robin Murphy wrote: > On 20/04/16 16:58, Eric Auger wrote: >> Hi Robin, >> On 04/20/2016 02:47 PM, Robin Murphy wrote: >>> Hi Eric, >>> >>> On 19/04/16 17:56, Eric Auger wrote: Introduce a new DOMAIN_ATTR_MSI_MAPPING domain attribute. If supported, this

Re: [RFC][PATCH 06/31] locking,avr32: Implement atomic_fetch_{add,sub,and,or,xor}()

Around Fri 22 Apr 2016 11:04:19 +0200 or thereabout, Peter Zijlstra wrote: > Implement FETCH-OP atomic primitives, these are very similar to the > existing OP-RETURN primitives we already have, except they return the > value of the atomic variable _before_ modification. > > This is especially

Re: [PATCH v2 2/4] dt-bindings: Add jdi lt070me05000 panel bindings

On Fri, Apr 22, 2016 at 12:25:52PM +0530, Vinay Simha wrote: > On Thu, Apr 21, 2016 at 9:15 PM, Rob Herring wrote: > > On Wed, Apr 20, 2016 at 03:02:31PM +0530, Vinay Simha BN wrote: > >> Add documentation for lt070me05000 panel > >> > >> Signed-off-by: Vinay Simha BN

Re: [RFC][PATCH 06/31] locking,avr32: Implement atomic_fetch_{add,sub,and,or,xor}()

Around Fri 22 Apr 2016 11:04:19 +0200 or thereabout, Peter Zijlstra wrote: > Implement FETCH-OP atomic primitives, these are very similar to the > existing OP-RETURN primitives we already have, except they return the > value of the atomic variable _before_ modification. > > This is especially

Re: [PATCH v2 2/4] dt-bindings: Add jdi lt070me05000 panel bindings

On Fri, Apr 22, 2016 at 12:25:52PM +0530, Vinay Simha wrote: > On Thu, Apr 21, 2016 at 9:15 PM, Rob Herring wrote: > > On Wed, Apr 20, 2016 at 03:02:31PM +0530, Vinay Simha BN wrote: > >> Add documentation for lt070me05000 panel > >> > >> Signed-off-by: Vinay Simha BN > >> --- > >>

Re: [PATCH v11 15/17] ARM64: XEN: Add a function to initialize Xen specific UEFI runtime services

On Fri, 22 Apr 2016, Catalin Marinas wrote: > On Thu, Apr 07, 2016 at 08:03:32PM +0800, Shannon Zhao wrote: > > From: Shannon Zhao > > > > When running on Xen hypervisor, runtime services are supported through > > hypercall. Add a Xen specific function to initialize

Re: [PATCH v11 15/17] ARM64: XEN: Add a function to initialize Xen specific UEFI runtime services

On Fri, 22 Apr 2016, Catalin Marinas wrote: > On Thu, Apr 07, 2016 at 08:03:32PM +0800, Shannon Zhao wrote: > > From: Shannon Zhao > > > > When running on Xen hypervisor, runtime services are supported through > > hypercall. Add a Xen specific function to initialize runtime services. > > > >

Re: [PATCH] usb: gadget: f_fs: Fix kernel panic for SuperSpeed

Hi Jim, Jim Lin writes: > Android N adds os_desc_compat in v2_descriptor by init_functionfs() > (system/core/adb/usb_linux_client.cpp) to support automatic install > of MTP driver on Windows for USB device mode. > > Current __ffs_data_do_os_desc() of f_fs.c will check

Re: [PATCH] usb: gadget: f_fs: Fix kernel panic for SuperSpeed

Hi Jim, Jim Lin writes: > Android N adds os_desc_compat in v2_descriptor by init_functionfs() > (system/core/adb/usb_linux_client.cpp) to support automatic install > of MTP driver on Windows for USB device mode. > > Current __ffs_data_do_os_desc() of f_fs.c will check reserved1 field > and

Re: [PATCH v7 00/24] i2c mux cleanup and locking update

Wolfram Sang wrote: > > The problem with waiting until 4.8 with the rest of the series is that it > > will likely go stale, e.g. patch 22 ([media] rtl2832: change the i2c gate > > to be mux-locked) touches a ton of register accesses in that driver since > > it removes a regmap wrapper that is

Re: [PATCH v7 00/24] i2c mux cleanup and locking update

Wolfram Sang wrote: > > The problem with waiting until 4.8 with the rest of the series is that it > > will likely go stale, e.g. patch 22 ([media] rtl2832: change the i2c gate > > to be mux-locked) touches a ton of register accesses in that driver since > > it removes a regmap wrapper that is

<    5   6   7   8   9   10   11   12   13   14   >