RE: [tpmdd-devel] [PATCH v3 1/3] tpm_crb: map locality registers

> > In order to provide access to locality registers, this commits adds mapping of > the head of the CRB registers, which are located right before the control > area. > > Signed-off-by: Jarkko Sakkinen > --- > drivers/char/tpm/tpm_crb.c | 89

RE: [tpmdd-devel] [PATCH v3 1/3] tpm_crb: map locality registers

> > In order to provide access to locality registers, this commits adds mapping of > the head of the CRB registers, which are located right before the control > area. > > Signed-off-by: Jarkko Sakkinen > --- > drivers/char/tpm/tpm_crb.c | 89 + > - >

Re: [RFC, PATCHv1 22/28] x86/espfix: support 5-level paging

On Thu, Dec 08, 2016 at 10:40:41AM -0800, Andy Lutomirski wrote: > On Thu, Dec 8, 2016 at 8:21 AM, Kirill A. Shutemov > wrote: > > XXX: how to test this? > > tools/testing/selftests/x86/sigreturn_{32,64} Hm. They fail on non-patched kernel with QEMU, but not

Re: [RFC, PATCHv1 22/28] x86/espfix: support 5-level paging

On Thu, Dec 08, 2016 at 10:40:41AM -0800, Andy Lutomirski wrote: > On Thu, Dec 8, 2016 at 8:21 AM, Kirill A. Shutemov > wrote: > > XXX: how to test this? > > tools/testing/selftests/x86/sigreturn_{32,64} Hm. They fail on non-patched kernel with QEMU, but not KVM. :-/ I guess I'd need to fix

Re: [PATCH v2 1/4] net: hix5hd2_gmac: add generic compatible string

On Mon, Dec 12, 2016 at 5:16 AM, Dongpo Li wrote: > Hi Rob, > > On 2016/12/10 6:35, Rob Herring wrote: >> On Mon, Dec 05, 2016 at 09:27:58PM +0800, Dongpo Li wrote: >>> The "hix5hd2" is SoC name, add the generic ethernet driver name. >>> The "hisi-gemac-v1" is the basic

Re: [PATCH v2 1/4] net: hix5hd2_gmac: add generic compatible string

On Mon, Dec 12, 2016 at 5:16 AM, Dongpo Li wrote: > Hi Rob, > > On 2016/12/10 6:35, Rob Herring wrote: >> On Mon, Dec 05, 2016 at 09:27:58PM +0800, Dongpo Li wrote: >>> The "hix5hd2" is SoC name, add the generic ethernet driver name. >>> The "hisi-gemac-v1" is the basic version and

Re: Could we have request_firmware_nowait with FW_OPT_NO_WARN?

On 12 December 2016 at 15:07, Luis R. Rodriguez wrote: > On Mon, Dec 12, 2016 at 10:53:38AM +0100, Rafał Miłecki wrote: >> On 12 December 2016 at 10:26, Arend Van Spriel >> wrote: >> > On 12-12-2016 9:32, Rafał Miłecki wrote: >> >> On 12 December

Re: Could we have request_firmware_nowait with FW_OPT_NO_WARN?

On 12 December 2016 at 15:07, Luis R. Rodriguez wrote: > On Mon, Dec 12, 2016 at 10:53:38AM +0100, Rafał Miłecki wrote: >> On 12 December 2016 at 10:26, Arend Van Spriel >> wrote: >> > On 12-12-2016 9:32, Rafał Miłecki wrote: >> >> On 12 December 2016 at 09:12, Johannes Berg >> >> wrote: >>

Re: Could we have request_firmware_nowait with FW_OPT_NO_WARN?

On Sat, Dec 10, 2016 at 04:54:41PM +0100, Rafał Miłecki wrote: > So it would be nice to have version of request_firmware_nowait with > FW_OPT_NO_WARN. If requesting firmware NVRAM fails *and* getting > platform NVRAM fails, then I could to print error on my own. > Does it make sense? Can you see a

Re: Could we have request_firmware_nowait with FW_OPT_NO_WARN?

On Sat, Dec 10, 2016 at 04:54:41PM +0100, Rafał Miłecki wrote: > So it would be nice to have version of request_firmware_nowait with > FW_OPT_NO_WARN. If requesting firmware NVRAM fails *and* getting > platform NVRAM fails, then I could to print error on my own. > Does it make sense? Can you see a

Re: [RFC][PATCHv5 3/7] printk: introduce per-cpu safe_print seq buffer

On (12/12/16 14:54), Petr Mladek wrote: > On Sat 2016-12-10 12:10:22, Sergey Senozhatsky wrote: > > On (12/09/16 17:46), Petr Mladek wrote: > > > > -/* > > > > - * Safe printk() for NMI context. It uses a per-CPU buffer to > > > > - * store the message. NMIs are not nested, so there is always only

Re: [RFC][PATCHv5 3/7] printk: introduce per-cpu safe_print seq buffer

On (12/12/16 14:54), Petr Mladek wrote: > On Sat 2016-12-10 12:10:22, Sergey Senozhatsky wrote: > > On (12/09/16 17:46), Petr Mladek wrote: > > > > -/* > > > > - * Safe printk() for NMI context. It uses a per-CPU buffer to > > > > - * store the message. NMIs are not nested, so there is always only

Re: Could we have request_firmware_nowait with FW_OPT_NO_WARN?

On Mon, Dec 12, 2016 at 10:53:38AM +0100, Rafał Miłecki wrote: > On 12 December 2016 at 10:26, Arend Van Spriel > wrote: > > On 12-12-2016 9:32, Rafał Miłecki wrote: > >> On 12 December 2016 at 09:12, Johannes Berg > >> wrote: > >>> On

Re: Could we have request_firmware_nowait with FW_OPT_NO_WARN?

On Mon, Dec 12, 2016 at 10:53:38AM +0100, Rafał Miłecki wrote: > On 12 December 2016 at 10:26, Arend Van Spriel > wrote: > > On 12-12-2016 9:32, Rafał Miłecki wrote: > >> On 12 December 2016 at 09:12, Johannes Berg > >> wrote: > >>> On Sat, 2016-12-10 at 16:54 +0100, Rafał Miłecki wrote: >

Re: [PATCH v3 00/15] livepatch: hybrid consistency model

On Sun, Dec 11, 2016 at 01:08:33PM +1100, Balbir Singh wrote: > > > On 11/12/16 04:17, Josh Poimboeuf wrote: > > On Sat, Dec 10, 2016 at 04:46:17PM +1100, Balbir Singh wrote: > >> On Thu, 2016-12-08 at 12:08 -0600, Josh Poimboeuf wrote: > >>> Dusting the cobwebs off the consistency model again.

Re: [PATCH v3 00/15] livepatch: hybrid consistency model

On Sun, Dec 11, 2016 at 01:08:33PM +1100, Balbir Singh wrote: > > > On 11/12/16 04:17, Josh Poimboeuf wrote: > > On Sat, Dec 10, 2016 at 04:46:17PM +1100, Balbir Singh wrote: > >> On Thu, 2016-12-08 at 12:08 -0600, Josh Poimboeuf wrote: > >>> Dusting the cobwebs off the consistency model again.

[PATCH 1/2] Staging: ks7010: ks7010_sdio.h: Complex macro not in parentheses

Fixed coding style error. Complex macro not inside parentheses. Signed-off-by: Manoj Sawai --- drivers/staging/ks7010/ks7010_sdio.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/ks7010/ks7010_sdio.h b/drivers/staging/ks7010/ks7010_sdio.h

[PATCH 1/2] Staging: ks7010: ks7010_sdio.h: Complex macro not in parentheses

Fixed coding style error. Complex macro not inside parentheses. Signed-off-by: Manoj Sawai --- drivers/staging/ks7010/ks7010_sdio.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/ks7010/ks7010_sdio.h b/drivers/staging/ks7010/ks7010_sdio.h index

[PATCH] media: i2c: soc_camera: constify v4l2_subdev_* structures

v4l2_subdev_{core/video}_ops structures are stored in the fields of the v4l2_subdev_ops structure which are of type const. Also, v4l2_subdev_ops structure is passed to a function having its argument of type const. As these structures are never modified, so declare them as const. Done using

[PATCH 2/2] Staging: ks7010: ks7010_sdio.h: Trailing whitespace

Removed trailing whitespace. Signed-off-by: Manoj Sawai --- drivers/staging/ks7010/ks7010_sdio.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/ks7010/ks7010_sdio.h b/drivers/staging/ks7010/ks7010_sdio.h index 5820b5c9b684..0165994605ac

[PATCH] media: i2c: soc_camera: constify v4l2_subdev_* structures

v4l2_subdev_{core/video}_ops structures are stored in the fields of the v4l2_subdev_ops structure which are of type const. Also, v4l2_subdev_ops structure is passed to a function having its argument of type const. As these structures are never modified, so declare them as const. Done using

[PATCH 2/2] Staging: ks7010: ks7010_sdio.h: Trailing whitespace

Removed trailing whitespace. Signed-off-by: Manoj Sawai --- drivers/staging/ks7010/ks7010_sdio.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/ks7010/ks7010_sdio.h b/drivers/staging/ks7010/ks7010_sdio.h index 5820b5c9b684..0165994605ac 100644 ---

[PATCH] x86/mm: drop unused argument sync_global_pgds()

There's no users that wants sync_global_pgd(.remove=1) sinc af2cf278ef4f ("x86/mm/hotplug: Don't remove PGD entries in remove_pagetable()"). Let's drop 'remove'. Signed-off-by: Kirill A. Shutemov --- arch/x86/include/asm/pgtable_64.h | 3 +--

[PATCH] x86/mm: drop unused argument sync_global_pgds()

There's no users that wants sync_global_pgd(.remove=1) sinc af2cf278ef4f ("x86/mm/hotplug: Don't remove PGD entries in remove_pagetable()"). Let's drop 'remove'. Signed-off-by: Kirill A. Shutemov --- arch/x86/include/asm/pgtable_64.h | 3 +-- arch/x86/mm/fault.c | 2 +-

Re: [RESEND PATCH] arm: assabet_defconfig: disable IDE subsystem

Hi Bartlomiej, On Monday 12 December 2016 06:15 PM, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Monday, July 18, 2016 08:15:08 PM Sekhar Nori wrote: >> On Friday 15 July 2016 08:45 PM, Kevin Hilman wrote: >>> Arnd Bergmann writes: >>> On Wednesday, July 13, 2016

Re: [RESEND PATCH] arm: assabet_defconfig: disable IDE subsystem

Hi Bartlomiej, On Monday 12 December 2016 06:15 PM, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Monday, July 18, 2016 08:15:08 PM Sekhar Nori wrote: >> On Friday 15 July 2016 08:45 PM, Kevin Hilman wrote: >>> Arnd Bergmann writes: >>> On Wednesday, July 13, 2016 12:59:23 PM CEST

[GIT PULL] (swiotlb) stable/for-linus-4.9 for 4.10 merge window

Hey Linus! Please git pull the following branch: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb.git stable/for-linus-4.9 which has: - Minor fixes (rate limiting), remove certain functions. - Support for DMA_ATTR_SKIP_CPU_SYNC which is an optimization in the DMA API That is

[GIT PULL] (swiotlb) stable/for-linus-4.9 for 4.10 merge window

Hey Linus! Please git pull the following branch: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb.git stable/for-linus-4.9 which has: - Minor fixes (rate limiting), remove certain functions. - Support for DMA_ATTR_SKIP_CPU_SYNC which is an optimization in the DMA API That is

Re: [RFC][PATCHv5 3/7] printk: introduce per-cpu safe_print seq buffer

On Sat 2016-12-10 12:10:22, Sergey Senozhatsky wrote: > On (12/09/16 17:46), Petr Mladek wrote: > > > -/* > > > - * Safe printk() for NMI context. It uses a per-CPU buffer to > > > - * store the message. NMIs are not nested, so there is always only > > > - * one writer running. But the buffer

Re: [RFC][PATCHv5 3/7] printk: introduce per-cpu safe_print seq buffer

On Sat 2016-12-10 12:10:22, Sergey Senozhatsky wrote: > On (12/09/16 17:46), Petr Mladek wrote: > > > -/* > > > - * Safe printk() for NMI context. It uses a per-CPU buffer to > > > - * store the message. NMIs are not nested, so there is always only > > > - * one writer running. But the buffer

Re: [PATCH 1/1] Fixed to codestyle

On 12/12/16 4:53 AM, Ozgur Karatas wrote: > > Hello, > > I have error to use uuid and I think the functions should be used when -i'm > eye-catching- "(* uuid)". > I tested it. > > Regards, > > Signed-off-by: Ozgur Karatas NAK This doesn't fix code style at all;

Re: [PATCH 1/1] Fixed to codestyle

On 12/12/16 4:53 AM, Ozgur Karatas wrote: > > Hello, > > I have error to use uuid and I think the functions should be used when -i'm > eye-catching- "(* uuid)". > I tested it. > > Regards, > > Signed-off-by: Ozgur Karatas NAK This doesn't fix code style at all; there is no need and no

Re: [PATCH] sched/pid fix use-after free in task_tgid_vnr

On 12/10, Eric W. Biederman wrote: > > Oleg Nesterov writes: > > > On 12/09, EunTaik Lee wrote: > >> > >> There is a use-after-free case with below call stack. > >> > >> pid_nr_ns+0x10/0x38 > >> cgroup_pidlist_start+0x144/0x400 > >> cgroup_seqfile_start+0x1c/0x24 > >>

Re: [PATCH] sched/pid fix use-after free in task_tgid_vnr

On 12/10, Eric W. Biederman wrote: > > Oleg Nesterov writes: > > > On 12/09, EunTaik Lee wrote: > >> > >> There is a use-after-free case with below call stack. > >> > >> pid_nr_ns+0x10/0x38 > >> cgroup_pidlist_start+0x144/0x400 > >> cgroup_seqfile_start+0x1c/0x24 > >> kernfs_seq_start+0x54/0x90 >

Re: Re: [PATCH 1/1] kasan: Support for r/w instrumentation control

On Mon, Dec 12, 2016 at 2:43 PM, Dmitry Vyukov wrote: > > On Mon, Dec 12, 2016 at 12:12 PM, Vaneet Narang wrote: >> >> Hi, >> >> >>> Do you actually hit an issue with image size? In what context? >> >>> Do you use inline/outline instrumentation? Does

Re: Re: [PATCH 1/1] kasan: Support for r/w instrumentation control

On Mon, Dec 12, 2016 at 2:43 PM, Dmitry Vyukov wrote: > > On Mon, Dec 12, 2016 at 12:12 PM, Vaneet Narang wrote: >> >> Hi, >> >> >>> Do you actually hit an issue with image size? In what context? >> >>> Do you use inline/outline instrumentation? Does switching to the other >> >>> option help? >>

Re: [PATCH 1/5] perf mem: Fix --all-user/--all-kernel options

On Mon, Dec 12, 2016 at 10:43:11AM -0300, Arnaldo Carvalho de Melo wrote: > Em Mon, Dec 12, 2016 at 11:35:39AM +0100, Jiri Olsa escreveu: > > Removing extra '--' prefix. > > Please add a Fixes: tag in such cases, as this helps backporters to > figure out what affects packages they published, in

Re: [PATCH] vfio/pci: Support error recovery

Hi, I have 2 solutions(high level design) came to me, please see if they are acceptable, or which one is acceptable. Also have some questions. 1. block guest access during host recovery add new field error_recovering in struct vfio_pci_device to indicate host recovery status. aer driver in

Re: [PATCH 1/5] perf mem: Fix --all-user/--all-kernel options

On Mon, Dec 12, 2016 at 10:43:11AM -0300, Arnaldo Carvalho de Melo wrote: > Em Mon, Dec 12, 2016 at 11:35:39AM +0100, Jiri Olsa escreveu: > > Removing extra '--' prefix. > > Please add a Fixes: tag in such cases, as this helps backporters to > figure out what affects packages they published, in

Re: [PATCH] vfio/pci: Support error recovery

Hi, I have 2 solutions(high level design) came to me, please see if they are acceptable, or which one is acceptable. Also have some questions. 1. block guest access during host recovery add new field error_recovering in struct vfio_pci_device to indicate host recovery status. aer driver in

Re: [PATCH 1/5] perf mem: Fix --all-user/--all-kernel options

Em Mon, Dec 12, 2016 at 11:35:39AM +0100, Jiri Olsa escreveu: > Removing extra '--' prefix. Please add a Fixes: tag in such cases, as this helps backporters to figure out what affects packages they published, in this case I'm adding: Fixes: ad16511b0e40 ("perf mem: Add -U/-K

Re: [PATCH 1/5] perf mem: Fix --all-user/--all-kernel options

Em Mon, Dec 12, 2016 at 11:35:39AM +0100, Jiri Olsa escreveu: > Removing extra '--' prefix. Please add a Fixes: tag in such cases, as this helps backporters to figure out what affects packages they published, in this case I'm adding: Fixes: ad16511b0e40 ("perf mem: Add -U/-K

Re: [PATCH 1/7] ARM: EXYNOS: Constify list of retention registers

Hi, On Saturday, December 10, 2016 03:47:32 PM Krzysztof Kozlowski wrote: > The list of retention registers (release_ret_regs field of struct > exynos_pm_data and arrays with values) are not modified and can be made > const to improve the const safeness. > > Signed-off-by: Krzysztof Kozlowski

Re: [PATCH 1/7] ARM: EXYNOS: Constify list of retention registers

Hi, On Saturday, December 10, 2016 03:47:32 PM Krzysztof Kozlowski wrote: > The list of retention registers (release_ret_regs field of struct > exynos_pm_data and arrays with values) are not modified and can be made > const to improve the const safeness. > > Signed-off-by: Krzysztof Kozlowski

Re: [PATCH 1/1] btrfs: fix improper return value

On Sun, Dec 04, 2016 at 11:57:07AM -0800, Omar Sandoval wrote: > On Sun, Dec 04, 2016 at 12:51:53PM +0800, Pan Bian wrote: > > In function btrfs_uuid_tree_iterate(), errno is assigned to variable ret > > on errors. However, it directly returns 0. It may be better to return > > ret. This patch also

Re: [PATCH 1/1] btrfs: fix improper return value

On Sun, Dec 04, 2016 at 11:57:07AM -0800, Omar Sandoval wrote: > On Sun, Dec 04, 2016 at 12:51:53PM +0800, Pan Bian wrote: > > In function btrfs_uuid_tree_iterate(), errno is assigned to variable ret > > on errors. However, it directly returns 0. It may be better to return > > ret. This patch also

Re: [PATCH] ASoC: samsung: Remove tests of member address

Hi, On Saturday, December 10, 2016 11:51:11 AM Krzysztof Kozlowski wrote: > The driver was checking for non-NULL address of struct's members: > - s3c_audio_pdata->type (union), > - s3c_audio_pdata->type.i2s (embedded struct). > > This is pointless as these will be always non-NULL. The

Re: [PATCH] ASoC: samsung: Remove tests of member address

Hi, On Saturday, December 10, 2016 11:51:11 AM Krzysztof Kozlowski wrote: > The driver was checking for non-NULL address of struct's members: > - s3c_audio_pdata->type (union), > - s3c_audio_pdata->type.i2s (embedded struct). > > This is pointless as these will be always non-NULL. The

Re: [PATCH v7 1/8] Documentation: arm: define DT cpu capacity-dmips-mhz bindings

On 12/12/16 12:40, Lorenzo Pieralisi wrote: > On Mon, Sep 05, 2016 at 03:22:45PM +0100, Juri Lelli wrote: > > [...] > > > +=== > > +5 - References > > +=== > > + > > +[1] ARM Linux Kernel documentation - CPUs

Re: [PATCH v7 1/8] Documentation: arm: define DT cpu capacity-dmips-mhz bindings

On 12/12/16 12:40, Lorenzo Pieralisi wrote: > On Mon, Sep 05, 2016 at 03:22:45PM +0100, Juri Lelli wrote: > > [...] > > > +=== > > +5 - References > > +=== > > + > > +[1] ARM Linux Kernel documentation - CPUs

Re: [PATCH] rtc: max77683: avoid regmap bulk write for max77620

Hi, On Monday, December 12, 2016 05:14:45 PM Venkat Reddy Talla wrote: > Adding support to avoid regmap bulk write for the > devices which are not supported register bulk write. What about register bulk reads done by the driver? Do they also need a fixup? > Max77620 RTC device does not

Re: [lkp-developer] [sched/fair] 4e5160766f: +149% ftq.noise.50% regression

Hi Ying, On 12 December 2016 at 06:43, kernel test robot wrote: > Greeting, > > FYI, we noticed a 149% regression of ftq.noise.50% due to commit: > > > commit: 4e5160766fcc9f41bbd38bac11f92dce993644aa ("sched/fair: Propagate > asynchrous detach") >

Re: [PATCH] rtc: max77683: avoid regmap bulk write for max77620

Hi, On Monday, December 12, 2016 05:14:45 PM Venkat Reddy Talla wrote: > Adding support to avoid regmap bulk write for the > devices which are not supported register bulk write. What about register bulk reads done by the driver? Do they also need a fixup? > Max77620 RTC device does not

Re: [lkp-developer] [sched/fair] 4e5160766f: +149% ftq.noise.50% regression

Hi Ying, On 12 December 2016 at 06:43, kernel test robot wrote: > Greeting, > > FYI, we noticed a 149% regression of ftq.noise.50% due to commit: > > > commit: 4e5160766fcc9f41bbd38bac11f92dce993644aa ("sched/fair: Propagate > asynchrous detach") >

[GIT PULL] KVM changes for 4.10 merge window

Linus, The following changes since commit a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6: Linux 4.9-rc5 (2016-11-13 10:32:32 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus for you to fetch changes up to

[GIT PULL] KVM changes for 4.10 merge window

Linus, The following changes since commit a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6: Linux 4.9-rc5 (2016-11-13 10:32:32 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus for you to fetch changes up to

Re: [PATCH 3/3] power: supply: bq24735-charger: allow chargers to share the ac-detect gpio

On 2016-12-12 12:00, Peter Rosin wrote: > If several parallel bq24735 chargers have their ac-detect gpios wired > together (or if only one of the parallel bq24735 chargers have its > ac-detect pin wired to a gpio, and the others are assumed to react the > same), then all driver instances need to

Re: [PATCH 3/3] power: supply: bq24735-charger: allow chargers to share the ac-detect gpio

On 2016-12-12 12:00, Peter Rosin wrote: > If several parallel bq24735 chargers have their ac-detect gpios wired > together (or if only one of the parallel bq24735 chargers have its > ac-detect pin wired to a gpio, and the others are assumed to react the > same), then all driver instances need to

Re: [PATCH v5 1/2] Add OV5647 device tree documentation

Hi Sakari On 12/12/2016 12:19 PM, Sakari Ailus wrote: > Hi Ramiro, > > On Mon, Dec 12, 2016 at 12:15:04PM +, Ramiro Oliveira wrote: >> Hi Sakari >> >> On 12/12/2016 11:49 AM, Sakari Ailus wrote: >>> Hi Ramiro, >>> >>> On Mon, Dec 12, 2016 at 11:39:31AM +, Ramiro Oliveira wrote: Hi

Re: [PATCH v5 1/2] Add OV5647 device tree documentation

Hi Sakari On 12/12/2016 12:19 PM, Sakari Ailus wrote: > Hi Ramiro, > > On Mon, Dec 12, 2016 at 12:15:04PM +, Ramiro Oliveira wrote: >> Hi Sakari >> >> On 12/12/2016 11:49 AM, Sakari Ailus wrote: >>> Hi Ramiro, >>> >>> On Mon, Dec 12, 2016 at 11:39:31AM +, Ramiro Oliveira wrote: Hi

[PATCH v6 0/5] ARM: dts: da850: tilcdc related DT changes

This series contains the last DT changes required for LCDC support on da850-lcdk. The first one adds the dumb-vga-dac nodes, the second limits the maximum pixel clock rate. v1 -> v2: - drop patch 3/3 (already merged) - use max-pixelclock instead of max-bandwidth for display mode limiting v2 ->

[PATCH v6 3/5] drm: bridge: add support for TI ths8135

THS8135 is a configurable video DAC, but no configuration is actually necessary to make it work. For now use the dumb-vga-dac driver to support it. Signed-off-by: Bartosz Golaszewski Reviewed-by: Laurent Pinchart ---

[PATCH v6 0/5] ARM: dts: da850: tilcdc related DT changes

This series contains the last DT changes required for LCDC support on da850-lcdk. The first one adds the dumb-vga-dac nodes, the second limits the maximum pixel clock rate. v1 -> v2: - drop patch 3/3 (already merged) - use max-pixelclock instead of max-bandwidth for display mode limiting v2 ->

[PATCH v6 3/5] drm: bridge: add support for TI ths8135

THS8135 is a configurable video DAC, but no configuration is actually necessary to make it work. For now use the dumb-vga-dac driver to support it. Signed-off-by: Bartosz Golaszewski Reviewed-by: Laurent Pinchart --- drivers/gpu/drm/bridge/dumb-vga-dac.c | 1 + 1 file changed, 1 insertion(+)

[PATCH v6 1/5] ARM: dts: da850: rename the display node label

The tilcdc node name is 'display' as per the ePAPR 1.1 recommendation. The label is also 'display', but change it to 'lcdc' to make it clear what the underlying hardware is. Signed-off-by: Bartosz Golaszewski --- arch/arm/boot/dts/da850.dtsi | 2 +- 1 file changed, 1

[PATCH v6 4/5] ARM: dts: da850-lcdk: add the vga-bridge node

Add the vga-bridge node to the board DT together with corresponding ports and vga connector. This allows to retrieve the edid info from the display automatically. Signed-off-by: Bartosz Golaszewski Reviewed-by: Laurent Pinchart ---

[PATCH v6 2/5] drm: bridge: add DT bindings for TI ths8135

THS8135 is a configurable video DAC. Add DT bindings for this chip. Signed-off-by: Bartosz Golaszewski Reviewed-by: Laurent Pinchart --- .../bindings/display/bridge/ti,ths8135.txt | 52 ++ 1 file changed,

[PATCH v6 1/5] ARM: dts: da850: rename the display node label

The tilcdc node name is 'display' as per the ePAPR 1.1 recommendation. The label is also 'display', but change it to 'lcdc' to make it clear what the underlying hardware is. Signed-off-by: Bartosz Golaszewski --- arch/arm/boot/dts/da850.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH v6 4/5] ARM: dts: da850-lcdk: add the vga-bridge node

Add the vga-bridge node to the board DT together with corresponding ports and vga connector. This allows to retrieve the edid info from the display automatically. Signed-off-by: Bartosz Golaszewski Reviewed-by: Laurent Pinchart --- arch/arm/boot/dts/da850-lcdk.dts | 67

[PATCH v6 2/5] drm: bridge: add DT bindings for TI ths8135

THS8135 is a configurable video DAC. Add DT bindings for this chip. Signed-off-by: Bartosz Golaszewski Reviewed-by: Laurent Pinchart --- .../bindings/display/bridge/ti,ths8135.txt | 52 ++ 1 file changed, 52 insertions(+) create mode 100644

[PATCH v6 5/5] ARM: dts: da850: specify the maximum pixel clock rate for tilcdc

At maximum CPU frequency of 300 MHz the maximum pixel clock frequency is 37.5 MHz[1]. We must filter out any mode for which the calculated pixel clock rate would exceed this value. Specify the max-pixelclock property for the display node for da850-lcdk. [1]

[PATCH v6 5/5] ARM: dts: da850: specify the maximum pixel clock rate for tilcdc

At maximum CPU frequency of 300 MHz the maximum pixel clock frequency is 37.5 MHz[1]. We must filter out any mode for which the calculated pixel clock rate would exceed this value. Specify the max-pixelclock property for the display node for da850-lcdk. [1]

Re: [PATCH 1/1] Fixed to BUG_ON to WARN_ON def

Dear Romanovsky; I'm trying to learn english and I apologize for my mistake words and phrases. So, I think the code when call to "sg_set_buf" and next time set memory and buffer. For example, isn't to call "WARN_ON" function, get a error to implicit declaration, right? Because, you will use

Re: [PATCH 1/1] Fixed to BUG_ON to WARN_ON def

Dear Romanovsky; I'm trying to learn english and I apologize for my mistake words and phrases. So, I think the code when call to "sg_set_buf" and next time set memory and buffer. For example, isn't to call "WARN_ON" function, get a error to implicit declaration, right? Because, you will use

Re: [PATCH] Input: drv260x - fix initializing overdrive voltage

Dmitry On 12/11/2016 12:59 AM, Dmitry Torokhov wrote: > We were accidentally initializing haptics->rated_voltage twice, and did not > initialize overdrive voltage. > > Signed-off-by: Dmitry Torokhov > --- > drivers/input/misc/drv260x.c | 2 +- > 1 file changed, 1

Re: [PATCH] Input: drv260x - fix initializing overdrive voltage

Dmitry On 12/11/2016 12:59 AM, Dmitry Torokhov wrote: > We were accidentally initializing haptics->rated_voltage twice, and did not > initialize overdrive voltage. > > Signed-off-by: Dmitry Torokhov > --- > drivers/input/misc/drv260x.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >

Re: usb:xhci: support disable usb2 LPM Remote Wakeup

On 12.12.2016 06:00, Thang Q. Nguyen wrote: On Sat, Dec 10, 2016 at 4:36 AM, Rob Herring wrote: On Sun, Dec 04, 2016 at 07:42:01PM +0700, Thang Q. Nguyen wrote: From: Thang Nguyen As per USB 2.0 link power management addendum ECN, table 1-2, page 4, device

Re: usb:xhci: support disable usb2 LPM Remote Wakeup

On 12.12.2016 06:00, Thang Q. Nguyen wrote: On Sat, Dec 10, 2016 at 4:36 AM, Rob Herring wrote: On Sun, Dec 04, 2016 at 07:42:01PM +0700, Thang Q. Nguyen wrote: From: Thang Nguyen As per USB 2.0 link power management addendum ECN, table 1-2, page 4, device or host initiated via resume

Re: Re: [PATCH 1/1] arm/module: maximum utilization of module area.

On Mon, Dec 12, 2016 at 11:22:30AM +, Vaneet Narang wrote: > Hi, > > >A PC24 relocation has a range of +/-32MB. This means that where-ever > >the module is placed, it must be capable of reaching any function > >within the kernel text, which may itself be quite large (eg, 8MB, or > >possibly

Re: Re: [PATCH 1/1] arm/module: maximum utilization of module area.

On Mon, Dec 12, 2016 at 11:22:30AM +, Vaneet Narang wrote: > Hi, > > >A PC24 relocation has a range of +/-32MB. This means that where-ever > >the module is placed, it must be capable of reaching any function > >within the kernel text, which may itself be quite large (eg, 8MB, or > >possibly

Re: [RESEND PATCH] arm: assabet_defconfig: disable IDE subsystem

Hi, On Monday, July 18, 2016 08:15:08 PM Sekhar Nori wrote: > On Friday 15 July 2016 08:45 PM, Kevin Hilman wrote: > > Arnd Bergmann writes: > > > >> On Wednesday, July 13, 2016 12:59:23 PM CEST Bartlomiej Zolnierkiewicz > >> wrote: > >>> > >>> On Friday, July 08, 2016 10:23:48

Re: [RESEND PATCH] arm: assabet_defconfig: disable IDE subsystem

Hi, On Monday, July 18, 2016 08:15:08 PM Sekhar Nori wrote: > On Friday 15 July 2016 08:45 PM, Kevin Hilman wrote: > > Arnd Bergmann writes: > > > >> On Wednesday, July 13, 2016 12:59:23 PM CEST Bartlomiej Zolnierkiewicz > >> wrote: > >>> > >>> On Friday, July 08, 2016 10:23:48 PM Arnd

Re: [PATCH v2 1/1] lockd: Change nsm_use_hostnames from bool to u32

-to-u32/20161212-001614 base: git://linux-nfs.org/~bfields/linux.git nfsd-next config: x86_64-kexec (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed

Re: [PATCH v2 1/1] lockd: Change nsm_use_hostnames from bool to u32

-to-u32/20161212-001614 base: git://linux-nfs.org/~bfields/linux.git nfsd-next config: x86_64-kexec (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed

[PATCH] HID: add Asus macrokey support for Asus "Republic of Gamers" laptop

ROG means ASUS "Republic of Gamers" laptops. The input device info also represents itself as "ASASTeK COMPUTER INC. ROG MacroKey". It uses special HID_USAGE code for function keys. This commit remap the special code to standard keycode for function keys handling. It's verified on GL553VD/VE,

[PATCH] HID: add Asus macrokey support for Asus "Republic of Gamers" laptop

ROG means ASUS "Republic of Gamers" laptops. The input device info also represents itself as "ASASTeK COMPUTER INC. ROG MacroKey". It uses special HID_USAGE code for function keys. This commit remap the special code to standard keycode for function keys handling. It's verified on GL553VD/VE,

Re: Perf hotplug lockup in v4.9-rc8

On Mon, Dec 12, 2016 at 11:46:40AM +, Will Deacon wrote: > > @@ -2331,13 +2330,36 @@ perf_install_in_context(struct perf_event_context > > *ctx, > > /* > > * Installing events is tricky because we cannot rely on ctx->is_active > > * to be set in case this is the nr_events 0 -> 1

Re: Perf hotplug lockup in v4.9-rc8

On Mon, Dec 12, 2016 at 11:46:40AM +, Will Deacon wrote: > > @@ -2331,13 +2330,36 @@ perf_install_in_context(struct perf_event_context > > *ctx, > > /* > > * Installing events is tricky because we cannot rely on ctx->is_active > > * to be set in case this is the nr_events 0 -> 1

Re: [PATCH 1/1] Fixed to BUG_ON to WARN_ON def

On Mon, Dec 12, 2016 at 12:58:59PM +0200, Ozgur Karatas wrote: > Hello all, > I think should be use to "WARN_ON" and checkpatch script give to error, I > fixed and I think should don't use "BUG_ON". > Regards, > > Signed-off-by: Ozgur Karatas NAK, Leon Romanovsky

Re: [PATCH 1/1] Fixed to BUG_ON to WARN_ON def

On Mon, Dec 12, 2016 at 12:58:59PM +0200, Ozgur Karatas wrote: > Hello all, > I think should be use to "WARN_ON" and checkpatch script give to error, I > fixed and I think should don't use "BUG_ON". > Regards, > > Signed-off-by: Ozgur Karatas NAK, Leon Romanovsky If we put aside commit

Re: [PATCH v7 1/8] Documentation: arm: define DT cpu capacity-dmips-mhz bindings

On Mon, Sep 05, 2016 at 03:22:45PM +0100, Juri Lelli wrote: [...] > +=== > +5 - References > +=== > + > +[1] ARM Linux Kernel documentation - CPUs bindings > +Documentation/devicetree/bindings/arm/cpus.txt > diff

Re: [PATCH v7 1/8] Documentation: arm: define DT cpu capacity-dmips-mhz bindings

On Mon, Sep 05, 2016 at 03:22:45PM +0100, Juri Lelli wrote: [...] > +=== > +5 - References > +=== > + > +[1] ARM Linux Kernel documentation - CPUs bindings > +Documentation/devicetree/bindings/arm/cpus.txt > diff

Re: [PATCH v6 4/9] dt-bindings: iio: iio-mux: document iio-mux bindings

On 2016-12-10 19:21, Jonathan Cameron wrote: > On 06/12/16 09:18, Peter Rosin wrote: >> On 2016-12-06 00:26, Rob Herring wrote: >>> On Wed, Nov 30, 2016 at 09:16:58AM +0100, Peter Rosin wrote: Signed-off-by: Peter Rosin --- .../bindings/iio/multiplexer/iio-mux.txt

Re: [PATCH v6 4/9] dt-bindings: iio: iio-mux: document iio-mux bindings

On 2016-12-10 19:21, Jonathan Cameron wrote: > On 06/12/16 09:18, Peter Rosin wrote: >> On 2016-12-06 00:26, Rob Herring wrote: >>> On Wed, Nov 30, 2016 at 09:16:58AM +0100, Peter Rosin wrote: Signed-off-by: Peter Rosin --- .../bindings/iio/multiplexer/iio-mux.txt | 40

[RESEND PATCH v12] drm/i915/debugfs: Move out pipe CRC code

In preparation to using a generic API in the DRM core for continuous CRC generation, move the related code out of i915_debugfs.c into a new file. Eventually, only the Intel-specific code will remain in this new file. v2: Rebased. v6: Rebased. v7: Fix whitespace issue. v9: Have

[RESEND PATCH v12] drm/i915/debugfs: Move out pipe CRC code

In preparation to using a generic API in the DRM core for continuous CRC generation, move the related code out of i915_debugfs.c into a new file. Eventually, only the Intel-specific code will remain in this new file. v2: Rebased. v6: Rebased. v7: Fix whitespace issue. v9: Have

Re: [PATCH v2] KVM: hyperv: fix locking of struct kvm_hv fields

On Mon, Dec 12, 2016 at 10:12:53AM +0100, Paolo Bonzini wrote: > Introduce a new mutex to avoid an AB-BA deadlock between kvm->lock and > vcpu->mutex. Protect accesses in kvm_hv_setup_tsc_page too, as suggested > by Roman. > > Reported-by: Dmitry Vyukov > Cc: Roman Kagan

Re: [PATCH v2] KVM: hyperv: fix locking of struct kvm_hv fields

On Mon, Dec 12, 2016 at 10:12:53AM +0100, Paolo Bonzini wrote: > Introduce a new mutex to avoid an AB-BA deadlock between kvm->lock and > vcpu->mutex. Protect accesses in kvm_hv_setup_tsc_page too, as suggested > by Roman. > > Reported-by: Dmitry Vyukov > Cc: Roman Kagan > Signed-off-by: Paolo

Re: [PATCH v5 1/2] Add OV5647 device tree documentation

Hi Ramiro, On Mon, Dec 12, 2016 at 12:15:04PM +, Ramiro Oliveira wrote: > Hi Sakari > > On 12/12/2016 11:49 AM, Sakari Ailus wrote: > > Hi Ramiro, > > > > On Mon, Dec 12, 2016 at 11:39:31AM +, Ramiro Oliveira wrote: > >> Hi Sakari, > >> > >> Thank you for the feedback. > >> > >> On

Re: [PATCH v5 1/2] Add OV5647 device tree documentation

Hi Ramiro, On Mon, Dec 12, 2016 at 12:15:04PM +, Ramiro Oliveira wrote: > Hi Sakari > > On 12/12/2016 11:49 AM, Sakari Ailus wrote: > > Hi Ramiro, > > > > On Mon, Dec 12, 2016 at 11:39:31AM +, Ramiro Oliveira wrote: > >> Hi Sakari, > >> > >> Thank you for the feedback. > >> > >> On

<    7   8   9   10   11   12   13   14   15   16   >