Re: [PATCH v8 06/10] tpm: Replace device number bitmap with IDR

On Sun, Mar 13, 2016 at 06:54:36PM -0400, Stefan Berger wrote: > Replace the device number bitmap with IDR. Extend the number of devices we > can create to 64k. > Since an IDR allows us to associate a pointer with an ID, we use this now > to rewrite tpm_chip_find_get() to simply look up the chip

Re: [PATCH v8 06/10] tpm: Replace device number bitmap with IDR

On Sun, Mar 13, 2016 at 06:54:36PM -0400, Stefan Berger wrote: > Replace the device number bitmap with IDR. Extend the number of devices we > can create to 64k. > Since an IDR allows us to associate a pointer with an ID, we use this now > to rewrite tpm_chip_find_get() to simply look up the chip

Re: coccinelle: generalized removal of unnecessary pointer casts?

On Mon, 14 Mar 2016, Joe Perches wrote: > On Mon, 2016-03-14 at 21:43 +0100, Julia Lawall wrote: > > On Mon, 14 Mar 2016, Joe Perches wrote: > > > I wrote a little cocci script to remove unnecessary > > > casts for memset and memcpy (below) and tested it on > > > linux kernel's drivers/staging/

Re: coccinelle: generalized removal of unnecessary pointer casts?

On Mon, 14 Mar 2016, Joe Perches wrote: > On Mon, 2016-03-14 at 21:43 +0100, Julia Lawall wrote: > > On Mon, 14 Mar 2016, Joe Perches wrote: > > > I wrote a little cocci script to remove unnecessary > > > casts for memset and memcpy (below) and tested it on > > > linux kernel's drivers/staging/

[GIT PULL] remoteproc updates for v4.6

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d: Linux 4.5-rc1 (2016-01-24 13:06:47 -0800) are available in the git repository at: git://github.com/andersson/remoteproc.git tags/rproc-v4.6 for you to fetch changes up to 69ae9895d3fed49ee830c491b3d51c72966a8a4c:

[GIT PULL] remoteproc updates for v4.6

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d: Linux 4.5-rc1 (2016-01-24 13:06:47 -0800) are available in the git repository at: git://github.com/andersson/remoteproc.git tags/rproc-v4.6 for you to fetch changes up to 69ae9895d3fed49ee830c491b3d51c72966a8a4c:

Re: [PATCH V7 00/12] Add T210 support in Tegra soctherm

On 2016年03月15日 05:01, Eduardo Valentin wrote: > * PGP Signed by an unknown key > > On Fri, Mar 11, 2016 at 11:09:11AM +0800, Wei Ni wrote: >> This patchset adds following functions for tegra_soctherm driver: >> 1. add T210 support. > > It would be good to update the compatible string in the

Re: [PATCH V7 00/12] Add T210 support in Tegra soctherm

On 2016年03月15日 05:01, Eduardo Valentin wrote: > * PGP Signed by an unknown key > > On Fri, Mar 11, 2016 at 11:09:11AM +0800, Wei Ni wrote: >> This patchset adds following functions for tegra_soctherm driver: >> 1. add T210 support. > > It would be good to update the compatible string in the

Re: [lkp] [drm/i915] 0bbca274a3: 3.6% piglit.time.elapsed_time

On Mon, Mar 14, 2016 at 03:37:51PM +0200, Ville Syrjälä wrote: >On Mon, Mar 14, 2016 at 10:14:37AM +0800, kernel test robot wrote: >> FYI, we noticed that piglit.time.elapsed_time 3.6% regression on >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master >> commit

Re: [lkp] [drm/i915] 0bbca274a3: 3.6% piglit.time.elapsed_time

On Mon, Mar 14, 2016 at 03:37:51PM +0200, Ville Syrjälä wrote: >On Mon, Mar 14, 2016 at 10:14:37AM +0800, kernel test robot wrote: >> FYI, we noticed that piglit.time.elapsed_time 3.6% regression on >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master >> commit

Re: [PATCH 12/13] thermal: convert tegra_thermal to use devm_thermal_zone_of_sensor_register

On 2016年03月15日 05:16, Eduardo Valentin wrote: > * PGP Signed by an unknown key > > On Thu, Mar 10, 2016 at 04:46:55PM +0800, Wei Ni wrote: >> >> >> On 2016年03月10日 05:35, Eduardo Valentin wrote: >>> This changes the driver to use the devm_ version >>> of thermal_zone_of_sensor_register and

Re: [PATCH 12/13] thermal: convert tegra_thermal to use devm_thermal_zone_of_sensor_register

On 2016年03月15日 05:16, Eduardo Valentin wrote: > * PGP Signed by an unknown key > > On Thu, Mar 10, 2016 at 04:46:55PM +0800, Wei Ni wrote: >> >> >> On 2016年03月10日 05:35, Eduardo Valentin wrote: >>> This changes the driver to use the devm_ version >>> of thermal_zone_of_sensor_register and

Re: linux-next: manual merge of the aio tree with the vfs tree

On Mon, Mar 14, 2016 at 11:24:38AM -0400, Benjamin LaHaise wrote: > On Mon, Mar 14, 2016 at 08:35:23AM +0100, Christoph Hellwig wrote: > > The aio changes have either been reviewed negatively or not at all. That > > tree should be dropped. > > That isn't solely your decision. If you have

Re: linux-next: manual merge of the aio tree with the vfs tree

On Mon, Mar 14, 2016 at 11:24:38AM -0400, Benjamin LaHaise wrote: > On Mon, Mar 14, 2016 at 08:35:23AM +0100, Christoph Hellwig wrote: > > The aio changes have either been reviewed negatively or not at all. That > > tree should be dropped. > > That isn't solely your decision. If you have

Re: [PATCH V2 2/2] mailbox: Introduce TI message manager driver

On Tue, Mar 8, 2016 at 8:07 PM, Nishanth Menon wrote: > Jassi, > > On Tue, Mar 8, 2016 at 1:10 AM, Jassi Brar wrote: >> On Tue, Mar 8, 2016 at 2:18 AM, Nishanth Menon wrote: >>> On 03/07/2016 12:31 PM, Jassi Brar wrote: On Fri, Mar 4,

Re: [PATCH V2 2/2] mailbox: Introduce TI message manager driver

On Tue, Mar 8, 2016 at 8:07 PM, Nishanth Menon wrote: > Jassi, > > On Tue, Mar 8, 2016 at 1:10 AM, Jassi Brar wrote: >> On Tue, Mar 8, 2016 at 2:18 AM, Nishanth Menon wrote: >>> On 03/07/2016 12:31 PM, Jassi Brar wrote: On Fri, Mar 4, 2016 at 8:05 PM, Nishanth Menon wrote: >> >>>

Re: linux-next: Tree for Mar 14 (mips qemu failure bisected)

bb11cff327e54 ("MIPS: Make smp CMP, CPS and MT use the new generic IPI functions". Bisect log is attached. > mips64:smp:mips_malta64_defconfig > mips:mipsel_malta_smp_defconfig > mips:mipsel_malta64_smp_defconfig If necessary I can repeat the bisect for those. Please let me

Re: linux-next: Tree for Mar 14 (mips qemu failure bisected)

bb11cff327e54 ("MIPS: Make smp CMP, CPS and MT use the new generic IPI functions". Bisect log is attached. > mips64:smp:mips_malta64_defconfig > mips:mipsel_malta_smp_defconfig > mips:mipsel_malta64_smp_defconfig If necessary I can repeat the bisect for those. Please let me

Re: linux-next: manual merge of the aio tree with the vfs tree

On Tue, Mar 15, 2016 at 05:07:12AM +, Al Viro wrote: > There *is* a reason for code review. Or, at least, asking somebody familiar > with the code you are working with whether some assumption you are making > is true or false. Me, for example, in our conversation regarding earlier > parts

Re: linux-next: manual merge of the aio tree with the vfs tree

On Tue, Mar 15, 2016 at 05:07:12AM +, Al Viro wrote: > There *is* a reason for code review. Or, at least, asking somebody familiar > with the code you are working with whether some assumption you are making > is true or false. Me, for example, in our conversation regarding earlier > parts

Re: linux-next: manual merge of the aio tree with the vfs tree

On Tue, Mar 15, 2016 at 04:34:48AM +, Al Viro wrote: > Incidentally, why the hell has that thing never landed in my mailbox? Not > directly, not Cc'd, not via fsdevel either. > > Ben, what the fuck going on? OK, you don't feel necessary to mention > that to me (or have me take a look

Re: linux-next: manual merge of the aio tree with the vfs tree

On Tue, Mar 15, 2016 at 04:34:48AM +, Al Viro wrote: > Incidentally, why the hell has that thing never landed in my mailbox? Not > directly, not Cc'd, not via fsdevel either. > > Ben, what the fuck going on? OK, you don't feel necessary to mention > that to me (or have me take a look

Re: linux-next: manual merge of the aio tree with the vfs tree

Hi Al, On Tue, 15 Mar 2016 04:34:48 + Al Viro wrote: > > > between commit: > > > > 5955102c9984 ("wrappers for ->i_mutex access") > > > > from the vfs tree and commit: > > What. > > The. > > Hell? > > The first commit is in the mainline, not in vfs tree. And

Re: linux-next: manual merge of the aio tree with the vfs tree

Hi Al, On Tue, 15 Mar 2016 04:34:48 + Al Viro wrote: > > > between commit: > > > > 5955102c9984 ("wrappers for ->i_mutex access") > > > > from the vfs tree and commit: > > What. > > The. > > Hell? > > The first commit is in the mainline, not in vfs tree. And it had been > there

Re: [PATCH v6 0/3] thermal: mediatek: Add cpu dynamic power cooling model.

On Thu, 2015-12-17 at 09:52 +0800, Viresh Kumar wrote: > On 16-12-15, 21:29, Dawei Chien wrote: > > Use Intelligent Power Allocation (IPA) technical to add dynamic power model > > for binding CPU thermal zone. The power allocator governor allocates power > > budget to control CPU temperature. > >

Re: [PATCH v6 0/3] thermal: mediatek: Add cpu dynamic power cooling model.

On Thu, 2015-12-17 at 09:52 +0800, Viresh Kumar wrote: > On 16-12-15, 21:29, Dawei Chien wrote: > > Use Intelligent Power Allocation (IPA) technical to add dynamic power model > > for binding CPU thermal zone. The power allocator governor allocates power > > budget to control CPU temperature. > >

Re: linux-next: manual merge of the aio tree with the vfs tree

On Tue, Mar 15, 2016 at 03:06:40PM +1100, Stephen Rothwell wrote: > Hi Ben, > > Today's linux-next merge of the aio tree got a conflict in: > > fs/namei.c > > between commit: > > 5955102c9984 ("wrappers for ->i_mutex access") > > from the vfs tree and commit: > > 5d3d80fcf992 ("aio:

Re: linux-next: manual merge of the aio tree with the vfs tree

On Tue, Mar 15, 2016 at 03:06:40PM +1100, Stephen Rothwell wrote: > Hi Ben, > > Today's linux-next merge of the aio tree got a conflict in: > > fs/namei.c > > between commit: > > 5955102c9984 ("wrappers for ->i_mutex access") > > from the vfs tree and commit: > > 5d3d80fcf992 ("aio:

Re: [PATCH v2 7/7] ARM: dts: Add initial gpio setting of MMC2 device for exynos3250-monk

Hi, On 2016년 03월 15일 13:18, kbuild test robot wrote: > Hi Chanwoo, > > [auto build test ERROR on v4.5-rc7] > [also build test ERROR on next-20160314] > [if your patch is applied to the wrong git tree, please drop us a note to > help improving the system] > > url: &

Re: [PATCH v2 7/7] ARM: dts: Add initial gpio setting of MMC2 device for exynos3250-monk

Hi, On 2016년 03월 15일 13:18, kbuild test robot wrote: > Hi Chanwoo, > > [auto build test ERROR on v4.5-rc7] > [also build test ERROR on next-20160314] > [if your patch is applied to the wrong git tree, please drop us a note to > help improving the system] > > url: &

[PATCH v2 04/04] iommu/ipmmu-vmsa: Drop LPAE Kconfig dependency

From: Magnus Damm Neither the ARM page table code enabled by IOMMU_IO_PGTABLE_LPAE nor the IPMMU_VMSA driver actually depends on ARM_LPAE, so get rid of the dependency. Tested with ipmmu-vmsa on r8a7794 ALT and a kernel config using: # CONFIG_ARM_LPAE is not set

[PATCH v2 04/04] iommu/ipmmu-vmsa: Drop LPAE Kconfig dependency

From: Magnus Damm Neither the ARM page table code enabled by IOMMU_IO_PGTABLE_LPAE nor the IPMMU_VMSA driver actually depends on ARM_LPAE, so get rid of the dependency. Tested with ipmmu-vmsa on r8a7794 ALT and a kernel config using: # CONFIG_ARM_LPAE is not set Signed-off-by: Magnus Damm

[PATCH v2 03/04] iommu/ipmmu-vmsa: Break out 32-bit ARM mapping code

From: Magnus Damm Make the driver compile on more than just 32-bit ARM by breaking out and wrapping ARM specific functions in #ifdefs. Not pretty, but needed to be able to use the driver on other architectures like ARM64. Signed-off-by: Magnus Damm

[PATCH v2] watchdog: don't run proc_watchdog_update if new value is same as old

While working on a script to restore all sysctl params before a series of tests I found that writing any value into the /proc/sys/kernel/{nmi_watchdog,soft_watchdog,watchdog,watchdog_thresh} causes them to call proc_watchdog_update(). [ 955.756196] NMI watchdog: enabled on all CPUs,

Re: [PATCH v2 7/7] ARM: dts: Add initial gpio setting of MMC2 device for exynos3250-monk

Hi Chanwoo, [auto build test ERROR on v4.5-rc7] [also build test ERROR on next-20160314] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Chanwoo-Choi/ARM-dts-Add-new-Exynos3250-based-ARTIK5

[PATCH v2 03/04] iommu/ipmmu-vmsa: Break out 32-bit ARM mapping code

From: Magnus Damm Make the driver compile on more than just 32-bit ARM by breaking out and wrapping ARM specific functions in #ifdefs. Not pretty, but needed to be able to use the driver on other architectures like ARM64. Signed-off-by: Magnus Damm --- Changes since V1: - Rebased to work

[PATCH v2] watchdog: don't run proc_watchdog_update if new value is same as old

While working on a script to restore all sysctl params before a series of tests I found that writing any value into the /proc/sys/kernel/{nmi_watchdog,soft_watchdog,watchdog,watchdog_thresh} causes them to call proc_watchdog_update(). [ 955.756196] NMI watchdog: enabled on all CPUs,

Re: [PATCH v2 7/7] ARM: dts: Add initial gpio setting of MMC2 device for exynos3250-monk

Hi Chanwoo, [auto build test ERROR on v4.5-rc7] [also build test ERROR on next-20160314] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Chanwoo-Choi/ARM-dts-Add-new-Exynos3250-based-ARTIK5

[PATCH v2 01/04] iommu/ipmmu-vmsa: Remove platform data handling

From: Magnus Damm The IPMMU driver is using DT these days, and platform data is no longer used by the driver. Remove unused code. Signed-off-by: Magnus Damm Reviewed-by: Laurent Pinchart --- Changes

[PATCH v2 01/04] iommu/ipmmu-vmsa: Remove platform data handling

From: Magnus Damm The IPMMU driver is using DT these days, and platform data is no longer used by the driver. Remove unused code. Signed-off-by: Magnus Damm Reviewed-by: Laurent Pinchart --- Changes since V1: - Added Reviewed-by from Laurent drivers/iommu/ipmmu-vmsa.c |5 - 1

[PATCH v2 02/04] iommu/ipmmu-vmsa: Rework interrupt code and use bitmap for context

From: Magnus Damm Introduce a bitmap for context handing and convert the interrupt routine to go handle all registered contexts. At this point the number of contexts are still limited. Also remove the use of the ARM specific mapping variable from ipmmu_irq() to

[PATCH v2 00/04] iommu/ipmmu-vmsa: IPMMU multi-arch update V2

from initial series - Updated bitmap code locking and also used lighter bitop functions - Updated the Kconfig bits to apply on top of ARCH_RENESAS Signed-off-by: Magnus Damm <damm+rene...@opensource.se> --- Built on top of next-20160314 drivers/iommu/Kconfig |1 drivers/iommu

[PATCH v2 02/04] iommu/ipmmu-vmsa: Rework interrupt code and use bitmap for context

From: Magnus Damm Introduce a bitmap for context handing and convert the interrupt routine to go handle all registered contexts. At this point the number of contexts are still limited. Also remove the use of the ARM specific mapping variable from ipmmu_irq() to allow compile on ARM64.

[PATCH v2 00/04] iommu/ipmmu-vmsa: IPMMU multi-arch update V2

from initial series - Updated bitmap code locking and also used lighter bitop functions - Updated the Kconfig bits to apply on top of ARCH_RENESAS Signed-off-by: Magnus Damm --- Built on top of next-20160314 drivers/iommu/Kconfig |1 drivers/iommu/ipmmu-vmsa.c | 146

linux-next: manual merge of the aio tree with the vfs tree

Hi Ben, Today's linux-next merge of the aio tree got a conflict in: fs/namei.c between commit: 5955102c9984 ("wrappers for ->i_mutex access") from the vfs tree and commit: 5d3d80fcf992 ("aio: add support for in-submit openat") from the aio tree. I fixed it up (see below) and can

linux-next: manual merge of the aio tree with the vfs tree

Hi Ben, Today's linux-next merge of the aio tree got a conflict in: fs/namei.c between commit: 5955102c9984 ("wrappers for ->i_mutex access") from the vfs tree and commit: 5d3d80fcf992 ("aio: add support for in-submit openat") from the aio tree. I fixed it up (see below) and can

Re: [PATCH] gpio: 74x164: Implement gpiochip.set_multiple()

On 14/03/2016 11:19 PM, Geert Uytterhoeven wrote: This allows to set multiple outputs using a single SPI transfer. Signed-off-by: Geert Uytterhoeven Reviewed-by: Phil Reid I do have a general question about GPIO drivers. pca953x does not

Re: [PATCH] gpio: 74x164: Implement gpiochip.set_multiple()

On 14/03/2016 11:19 PM, Geert Uytterhoeven wrote: This allows to set multiple outputs using a single SPI transfer. Signed-off-by: Geert Uytterhoeven Reviewed-by: Phil Reid I do have a general question about GPIO drivers. pca953x does not update the cached data unless the write operation

Re: [PATCH] watchdog: don't run proc_watchdog_update if new value is same as old

On 03/14/2016 11:29 AM, Don Zickus wrote: Hi Josh, I believe Uli thought the below patch might fix it. Cheers, Don Don It looks like I was incorrect when I said 4.5 was getting the soft lockup. I originally found this problem on 4.1.19 and saw both the problem my patch solves and the

Re: [PATCH] watchdog: don't run proc_watchdog_update if new value is same as old

On 03/14/2016 11:29 AM, Don Zickus wrote: Hi Josh, I believe Uli thought the below patch might fix it. Cheers, Don Don It looks like I was incorrect when I said 4.5 was getting the soft lockup. I originally found this problem on 4.1.19 and saw both the problem my patch solves and the

RE: [RFC qemu 0/4] A PV solution for live migration optimization

> > > Hi, > > > I'm just catching back up on this thread; so without reference to > > > any particular previous mail in the thread. > > > > > > 1) How many of the free pages do we tell the host about? > > > Your main change is telling the host about all the > > > free pages. > > > >

RE: [RFC qemu 0/4] A PV solution for live migration optimization

> > > Hi, > > > I'm just catching back up on this thread; so without reference to > > > any particular previous mail in the thread. > > > > > > 1) How many of the free pages do we tell the host about? > > > Your main change is telling the host about all the > > > free pages. > > > >

Re: [PATCH 20/22] atari_scsi: Set a reasonable default for cmd_per_lun

On Mon, 14 Mar 2016, Hannes Reinecke wrote: > On 03/14/2016 05:27 AM, Finn Thain wrote: > > This setting does not need to be conditional on Atari ST or TT. > > > > Without TCQ support, cmd_per_lun == 2 is probably reasonable... > > > > Signed-off-by: Finn Thain > >

Re: [PATCH 20/22] atari_scsi: Set a reasonable default for cmd_per_lun

On Mon, 14 Mar 2016, Hannes Reinecke wrote: > On 03/14/2016 05:27 AM, Finn Thain wrote: > > This setting does not need to be conditional on Atari ST or TT. > > > > Without TCQ support, cmd_per_lun == 2 is probably reasonable... > > > > Signed-off-by: Finn Thain > > > > --- > >

Re: [PATCH 16/22] ncr5380: Fix register decoding for debugging

On Mon, 14 Mar 2016, Hannes Reinecke wrote: > Well ... using individual printk() like here might end up in each > call to be broken up into individual lines. > You might want to consider using a line buffer here or, better > still, move to seq_file or debugfs output. This routine is meant to be

Re: [PATCH 16/22] ncr5380: Fix register decoding for debugging

On Mon, 14 Mar 2016, Hannes Reinecke wrote: > Well ... using individual printk() like here might end up in each > call to be broken up into individual lines. > You might want to consider using a line buffer here or, better > still, move to seq_file or debugfs output. This routine is meant to be

Re: [PATCH 14/22] ncr5380: Add MAX_LUN limit

On Mon, 14 Mar 2016, Christoph Hellwig wrote: > On Mon, Mar 14, 2016 at 03:27:14PM +1100, Finn Thain wrote: > > The driver has a limit of eight LUs because of the byte-sized bitfield > > that is used for busy flags. Reject commands with LUN > 7. > > Please just set the max_lun parameter in the

Re: [PATCH 14/22] ncr5380: Add MAX_LUN limit

On Mon, 14 Mar 2016, Christoph Hellwig wrote: > On Mon, Mar 14, 2016 at 03:27:14PM +1100, Finn Thain wrote: > > The driver has a limit of eight LUs because of the byte-sized bitfield > > that is used for busy flags. Reject commands with LUN > 7. > > Please just set the max_lun parameter in the

Re: [PATCH 09/22] ncr5380: Adopt uniform DMA setup convention

On Mon, 14 Mar 2016, Hannes Reinecke wrote: > > @@ -1555,8 +1555,7 @@ static int NCR5380_transfer_dma(struct S > > NCR5380_read(RESET_PARITY_INTERRUPT_REG); > > *data = d + c; > > *count = 0; > > - *phase = NCR5380_read(STATUS_REG) & PHASE_MASK; > > - return foo; > > + return

Re: [PATCH 09/22] ncr5380: Adopt uniform DMA setup convention

On Mon, 14 Mar 2016, Hannes Reinecke wrote: > > @@ -1555,8 +1555,7 @@ static int NCR5380_transfer_dma(struct S > > NCR5380_read(RESET_PARITY_INTERRUPT_REG); > > *data = d + c; > > *count = 0; > > - *phase = NCR5380_read(STATUS_REG) & PHASE_MASK; > > - return foo; > > + return

Re: [PATCH 04/22] atari_NCR5380: Remove DMA_MIN_SIZE macro

On Mon, 14 Mar 2016, Hannes Reinecke wrote: > I still would keep the 'DMA_MIN_LEN' definition around for sun3_scsi.c; > makes it a bit more obvious what the magic number '129' is supposed to > mean. OK. --

Re: [PATCH 04/22] atari_NCR5380: Remove DMA_MIN_SIZE macro

On Mon, 14 Mar 2016, Hannes Reinecke wrote: > I still would keep the 'DMA_MIN_LEN' definition around for sun3_scsi.c; > makes it a bit more obvious what the magic number '129' is supposed to > mean. OK. --

Re: [PATCH V4 0/3] basic busy polling support for vhost_net

On 03/10/2016 02:48 PM, Michael Rapoport wrote: > Hi Greg, > >> > Greg Kurz wrote on 03/09/2016 09:26:45 PM: >>> > > On Fri, 4 Mar 2016 06:24:50 -0500 >>> > > Jason Wang wrote: >> > >>> > > This series tries to add basic busy polling for vhost

Re: [PATCH V4 0/3] basic busy polling support for vhost_net

On 03/10/2016 02:48 PM, Michael Rapoport wrote: > Hi Greg, > >> > Greg Kurz wrote on 03/09/2016 09:26:45 PM: >>> > > On Fri, 4 Mar 2016 06:24:50 -0500 >>> > > Jason Wang wrote: >> > >>> > > This series tries to add basic busy polling for vhost net. The idea is >>> > > simple: at the end of

[PATCH v2 3/5] dt-bindings: Add documentation for GM20B GPU

GM20B's definition is mostly similar to GK20A's, but requires an additional clock. Signed-off-by: Alexandre Courbot --- .../devicetree/bindings/gpu/nvidia,gk20a.txt | 27 -- 1 file changed, 25 insertions(+), 2 deletions(-) diff --git

[PATCH v2 1/5] dt-bindings: gk20a: Fix typo in compatible name

The correct compatible name is "nvidia,gk20a". Signed-off-by: Alexandre Courbot --- Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt

[PATCH v2 3/5] dt-bindings: Add documentation for GM20B GPU

GM20B's definition is mostly similar to GK20A's, but requires an additional clock. Signed-off-by: Alexandre Courbot --- .../devicetree/bindings/gpu/nvidia,gk20a.txt | 27 -- 1 file changed, 25 insertions(+), 2 deletions(-) diff --git

[PATCH v2 1/5] dt-bindings: gk20a: Fix typo in compatible name

The correct compatible name is "nvidia,gk20a". Signed-off-by: Alexandre Courbot --- Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt

[PATCH v2 0/5] arm64: tegra: fix DT definitions for GM20B GPU

Small series that fixes/completes DT bindings for Tegra GPUs and add two missing entries required for the Tegra210 GPU to operate properly. Changes since v1: - Renamed "pllg_ref" clock to "ref" in DT bindings Alexandre Courbot (5): dt-bindings: gk20a: Fix typo in compatible name dt-bindings:

[PATCH v2 0/5] arm64: tegra: fix DT definitions for GM20B GPU

Small series that fixes/completes DT bindings for Tegra GPUs and add two missing entries required for the Tegra210 GPU to operate properly. Changes since v1: - Renamed "pllg_ref" clock to "ref" in DT bindings Alexandre Courbot (5): dt-bindings: gk20a: Fix typo in compatible name dt-bindings:

[PATCH v2 4/5] arm64: tegra210: Add reference clock to GM20B

This clock is required for the GPU to operate. Signed-off-by: Alexandre Courbot --- arch/arm64/boot/dts/nvidia/tegra210.dtsi | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi

Re: [PATCH v3] rtc: s3c: Don't print an error on probe deferral

Hello Krzysztof, On 03/14/2016 11:26 PM, Krzysztof Kozlowski wrote: > On 15.03.2016 10:59, Javier Martinez Canillas wrote: if (info->data->needs_src_clk) { info->rtc_src_clk = devm_clk_get(>dev, "rtc_src"); if (IS_ERR(info->rtc_src_clk)) { -

[PATCH v2 4/5] arm64: tegra210: Add reference clock to GM20B

This clock is required for the GPU to operate. Signed-off-by: Alexandre Courbot --- arch/arm64/boot/dts/nvidia/tegra210.dtsi | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi b/arch/arm64/boot/dts/nvidia/tegra210.dtsi index

Re: [PATCH v3] rtc: s3c: Don't print an error on probe deferral

Hello Krzysztof, On 03/14/2016 11:26 PM, Krzysztof Kozlowski wrote: > On 15.03.2016 10:59, Javier Martinez Canillas wrote: if (info->data->needs_src_clk) { info->rtc_src_clk = devm_clk_get(>dev, "rtc_src"); if (IS_ERR(info->rtc_src_clk)) { -

[PATCH v2 2/5] dt-bindings: gk20a: Document iommus property

GK20A can optionally make use of an IOMMU. Signed-off-by: Alexandre Courbot --- Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt

[PATCH v2 5/5] arm64: tegra210: Add IOMMU node to GM20B

Nouveau can take advantage of this declaration to remove the need for contiguous memory. Signed-off-by: Alexandre Courbot --- arch/arm64/boot/dts/nvidia/tegra210.dtsi | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi

[PATCH v2 2/5] dt-bindings: gk20a: Document iommus property

GK20A can optionally make use of an IOMMU. Signed-off-by: Alexandre Courbot --- Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt

[PATCH v2 5/5] arm64: tegra210: Add IOMMU node to GM20B

Nouveau can take advantage of this declaration to remove the need for contiguous memory. Signed-off-by: Alexandre Courbot --- arch/arm64/boot/dts/nvidia/tegra210.dtsi | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi

Re: [PATCH V2 net 0/6] net: hns: hns driver updates

From: Daode Huang Date: Tue, 15 Mar 2016 09:56:02 +0800 > Could you please help me to review this patch set? I am not reviewing anything until you guys sort out your submission scheme, and resend these fresh using that central maintainer. I am also not the only person

Re: [PATCH] epoll: add exclusive wakeups flag

Hi Michael, On 03/14/2016 07:26 PM, Michael Kerrisk (man-pages) wrote: > Hi Jason, > > On 03/15/2016 11:35 AM, Jason Baron wrote: >> Hi Michael, >> >> On 03/14/2016 05:03 PM, Michael Kerrisk (man-pages) wrote: >>> Hi Jason, >>> >>> On 03/15/2016 09:01 AM, Michael Kerrisk (man-pages) wrote:

Re: [PATCH V2 net 0/6] net: hns: hns driver updates

From: Daode Huang Date: Tue, 15 Mar 2016 09:56:02 +0800 > Could you please help me to review this patch set? I am not reviewing anything until you guys sort out your submission scheme, and resend these fresh using that central maintainer. I am also not the only person in the world who is

Re: [PATCH] epoll: add exclusive wakeups flag

Hi Michael, On 03/14/2016 07:26 PM, Michael Kerrisk (man-pages) wrote: > Hi Jason, > > On 03/15/2016 11:35 AM, Jason Baron wrote: >> Hi Michael, >> >> On 03/14/2016 05:03 PM, Michael Kerrisk (man-pages) wrote: >>> Hi Jason, >>> >>> On 03/15/2016 09:01 AM, Michael Kerrisk (man-pages) wrote:

Re: [PATCH v2 0/7] ARM: dts: Add new Exynos3250-based ARTIK5 module dtsi file

On 15.03.2016 11:39, Chanwoo Choi wrote: > On 2016년 03월 15일 11:35, Krzysztof Kozlowski wrote: >> On 15.03.2016 11:08, Chanwoo Choi wrote: >>> This patchset add the support for Device Tree source for Samsung ARTIK5 >>> module[1] >>> based on Exynos3250 SoC and development board[2]. The ARTIK5

Re: [PATCH v2 0/7] ARM: dts: Add new Exynos3250-based ARTIK5 module dtsi file

On 15.03.2016 11:39, Chanwoo Choi wrote: > On 2016년 03월 15일 11:35, Krzysztof Kozlowski wrote: >> On 15.03.2016 11:08, Chanwoo Choi wrote: >>> This patchset add the support for Device Tree source for Samsung ARTIK5 >>> module[1] >>> based on Exynos3250 SoC and development board[2]. The ARTIK5

Re: [GIT PULL] NOHZ updates for v4.6

On Mon, Mar 14, 2016 at 5:32 AM, Ingo Molnar wrote: > +/** > + * fetch_or - perform *ptr |= mask and return old value of *ptr > + * @ptr: pointer to value > + * @mask: mask to OR on the value > + * > + * cmpxchg based fetch_or, macro so it works for different integer types > +

Re: [GIT PULL] NOHZ updates for v4.6

On Mon, Mar 14, 2016 at 5:32 AM, Ingo Molnar wrote: > +/** > + * fetch_or - perform *ptr |= mask and return old value of *ptr > + * @ptr: pointer to value > + * @mask: mask to OR on the value > + * > + * cmpxchg based fetch_or, macro so it works for different integer types > + */ > +#ifndef

Re: [PATCH v2 5/7] ARM: dts: Add exynos3250-artik5 dtsi file for ARTIK5 module

On 2016년 03월 15일 11:33, Krzysztof Kozlowski wrote: > On 15.03.2016 11:08, Chanwoo Choi wrote: >> This patch adds the support for Device Tree source for Samsung ARTIK5 >> module[1] >> based on Exynos3250 SoC. The ARTIK5 module includes the follwoing devices: >> - Application Processor (Samsung

Re: [PATCH v2 5/7] ARM: dts: Add exynos3250-artik5 dtsi file for ARTIK5 module

On 2016년 03월 15일 11:33, Krzysztof Kozlowski wrote: > On 15.03.2016 11:08, Chanwoo Choi wrote: >> This patch adds the support for Device Tree source for Samsung ARTIK5 >> module[1] >> based on Exynos3250 SoC. The ARTIK5 module includes the follwoing devices: >> - Application Processor (Samsung

Re: [PATCH v2 0/7] ARM: dts: Add new Exynos3250-based ARTIK5 module dtsi file

On 2016년 03월 15일 11:35, Krzysztof Kozlowski wrote: > On 15.03.2016 11:08, Chanwoo Choi wrote: >> This patchset add the support for Device Tree source for Samsung ARTIK5 >> module[1] >> based on Exynos3250 SoC and development board[2]. The ARTIK5 module includes >> the follwoing devices: >> -

Re: [PATCH v2 0/7] ARM: dts: Add new Exynos3250-based ARTIK5 module dtsi file

On 2016년 03월 15일 11:35, Krzysztof Kozlowski wrote: > On 15.03.2016 11:08, Chanwoo Choi wrote: >> This patchset add the support for Device Tree source for Samsung ARTIK5 >> module[1] >> based on Exynos3250 SoC and development board[2]. The ARTIK5 module includes >> the follwoing devices: >> -

Re: [PATCH v2 7/7] ARM: dts: Add initial gpio setting of MMC2 device for exynos3250-monk

On 15.03.2016 11:08, Chanwoo Choi wrote: > This patch adds initial pin configuration of MMC2 device on exynos3250-monk > board because the MMC2 gpio pin (gpk2[0-6]) are NC (not connected) state. > > Suggested-by: Krzysztof Kozlowski > Signed-off-by: Chanwoo Choi

Re: [PATCH v2 7/7] ARM: dts: Add initial gpio setting of MMC2 device for exynos3250-monk

On 15.03.2016 11:08, Chanwoo Choi wrote: > This patch adds initial pin configuration of MMC2 device on exynos3250-monk > board because the MMC2 gpio pin (gpk2[0-6]) are NC (not connected) state. > > Suggested-by: Krzysztof Kozlowski > Signed-off-by: Chanwoo Choi > --- >

Re: [PATCH 1/4] acpi,pci,irq: reduce resource requirements

On Mon, Mar 14, 2016 at 10:28:11PM -0400, Sinan Kaya wrote: > On 3/14/2016 9:48 PM, Bjorn Helgaas wrote: > > Yes. I was talking about PCIe on ARM64. > > > If you go to Fry's and buy a conventional PCI card, it is going to > > pull INTA# low to assert an interrupt. It doesn't matter whether you

Re: [PATCH 1/4] acpi,pci,irq: reduce resource requirements

On Mon, Mar 14, 2016 at 10:28:11PM -0400, Sinan Kaya wrote: > On 3/14/2016 9:48 PM, Bjorn Helgaas wrote: > > Yes. I was talking about PCIe on ARM64. > > > If you go to Fry's and buy a conventional PCI card, it is going to > > pull INTA# low to assert an interrupt. It doesn't matter whether you

Re: [PATCH 04/06] iommu/ipmmu-vmsa: Rework interrupt code and use bitmap for context

Hi Laurent, On Tue, Dec 29, 2015 at 9:14 AM, Laurent Pinchart wrote: > Hi Magnus, > > Thank you for the patch. Thanks for your feedback! > On Tuesday 15 December 2015 21:02:49 Magnus Damm wrote: >> From: Magnus Damm >> >>

Re: [PATCH 3.10 00/18] 3.10.101-stable review

On 03/14/2016 10:52 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.10.101 release. There are 18 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH v2 6/7] ARM: dts: Add MSHC2 dt node for SD card for exynos3250-artik5-eval board

On 15.03.2016 11:08, Chanwoo Choi wrote: > From: Jaehoon Chung > > This patch adds MSHC (Mobile Storage Host Controller) dt node for > Exynos3250 SoC. MSHC is an interface between the system and the SD card > > Signed-off-by: Jaehoon Chung >

Re: [PATCH 04/06] iommu/ipmmu-vmsa: Rework interrupt code and use bitmap for context

Hi Laurent, On Tue, Dec 29, 2015 at 9:14 AM, Laurent Pinchart wrote: > Hi Magnus, > > Thank you for the patch. Thanks for your feedback! > On Tuesday 15 December 2015 21:02:49 Magnus Damm wrote: >> From: Magnus Damm >> >> Introduce a bitmap for context handing and convert the >> interrupt

Re: [PATCH 3.10 00/18] 3.10.101-stable review

On 03/14/2016 10:52 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.10.101 release. There are 18 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH v2 6/7] ARM: dts: Add MSHC2 dt node for SD card for exynos3250-artik5-eval board

On 15.03.2016 11:08, Chanwoo Choi wrote: > From: Jaehoon Chung > > This patch adds MSHC (Mobile Storage Host Controller) dt node for > Exynos3250 SoC. MSHC is an interface between the system and the SD card > > Signed-off-by: Jaehoon Chung > Signed-off-by: Chanwoo Choi > --- >

  1   2   3   4   5   6   7   8   9   10   >