Re: [PATCH] pinctrl: cherryview: Do not mask all interrupts on probe

On Wed, Sep 14, 2016 at 02:46:01PM +0200, Linus Walleij wrote: > > I'm going to re-read the hardware spec and see if there is anything we > > can do about this. The newer hardware (Skylake, Broxton) has a bit that > > tells the IRQ is routed directly to I/O-APIC but unfortunately Braswell > >

Re: [RESEND][PATCH V7 0/5] perf: Driver specific configuration for PMU

Em Wed, Sep 14, 2016 at 08:38:04AM -0600, Mathieu Poirier escreveu: > On 13 September 2016 at 14:06, Arnaldo Carvalho de Melo > wrote: > > Em Tue, Sep 06, 2016 at 10:37:12AM -0600, Mathieu Poirier escreveu: > >> Original blurb: > >> --- > > > > So, I managed to apply "perf tools: add

Re: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06

On 2016/9/14 20:33, Arnd Bergmann wrote: > On Wednesday, September 14, 2016 8:15:52 PM CEST Zhichang Yuan wrote: > >> +Required properties: >> +- compatible: should be "hisilicon,low-pin-count" >> +- #address-cells: must be 2 which stick to the ISA/EISA binding doc. >> +- #size-cells: must be 1

Re: [PATCH] net/mlx4_en: fix off by one in error handling

On 14/09/2016 4:53 PM, Sebastian Ott wrote: Hello Tariq, On Wed, 14 Sep 2016, Tariq Toukan wrote: On 14/09/2016 2:09 PM, Sebastian Ott wrote: If an error occurs in mlx4_init_eq_table the index used in the err_out_unmap label is one too big which results in a panic in mlx4_free_eq. This

Re: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06

On 2016/9/14 20:33, Arnd Bergmann wrote: > On Wednesday, September 14, 2016 8:15:52 PM CEST Zhichang Yuan wrote: > >> +Required properties: >> +- compatible: should be "hisilicon,low-pin-count" >> +- #address-cells: must be 2 which stick to the ISA/EISA binding doc. >> +- #size-cells: must be 1

Re: [PATCH] net/mlx4_en: fix off by one in error handling

On 14/09/2016 4:53 PM, Sebastian Ott wrote: Hello Tariq, On Wed, 14 Sep 2016, Tariq Toukan wrote: On 14/09/2016 2:09 PM, Sebastian Ott wrote: If an error occurs in mlx4_init_eq_table the index used in the err_out_unmap label is one too big which results in a panic in mlx4_free_eq. This

Re: [PATCH V3 3/4] ARM64 LPC: support serial based on low-pin-count

On 2016/9/14 20:25, Arnd Bergmann wrote: > On Wednesday, September 14, 2016 8:15:53 PM CEST Zhichang Yuan wrote: >> From: "zhichang.yuan" >> >> On Hip06 platform, a 16550 compatible UART is connected to low-pin-count and >> controlled through the LPC I/O cycles.

Re: [PATCH V3 3/4] ARM64 LPC: support serial based on low-pin-count

On 2016/9/14 20:25, Arnd Bergmann wrote: > On Wednesday, September 14, 2016 8:15:53 PM CEST Zhichang Yuan wrote: >> From: "zhichang.yuan" >> >> On Hip06 platform, a 16550 compatible UART is connected to low-pin-count and >> controlled through the LPC I/O cycles. After registering the LPC uart

[PATCH] of/platform: Initialise dev->fwnode appropriately

Whilst we're some of the way towards a universal firmware property interface, drivers which deal with both OF and ACPI probing end up having to do things like this: dev->of_node ? >of_node->fwnode : dev->fwnode This seems unnecessary, when the OF code could instead simply fill in the

[PATCH] of/platform: Initialise dev->fwnode appropriately

Whilst we're some of the way towards a universal firmware property interface, drivers which deal with both OF and ACPI probing end up having to do things like this: dev->of_node ? >of_node->fwnode : dev->fwnode This seems unnecessary, when the OF code could instead simply fill in the

Re: [RESEND PATCH] arm64: kgdb: fix single stepping

Hi Akashi, On Tue, Apr 21, 2015 at 02:13:13AM +0100, AKASHI Takahiro wrote: > Could you please review my patch below? > See also arm64 maintainer's comment: > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/313712.html -ETIMEDOUT waiting for the kdgb folk to comment. Ppeople

Re: [RESEND PATCH] arm64: kgdb: fix single stepping

Hi Akashi, On Tue, Apr 21, 2015 at 02:13:13AM +0100, AKASHI Takahiro wrote: > Could you please review my patch below? > See also arm64 maintainer's comment: > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/313712.html -ETIMEDOUT waiting for the kdgb folk to comment. Ppeople

Re: [PATCH 1/4] ACPI / watchdog: Add support for WDAT hardware watchdog

On 09/14/2016 01:06 AM, Mika Westerberg wrote: On Tue, Sep 13, 2016 at 02:00:25PM -0700, Guenter Roeck wrote: On 09/13/2016 08:23 AM, Mika Westerberg wrote: Starting from Intel Skylake the iTCO watchdog timer registers were moved to reside in the same register space with SMBus host controller.

Re: [PATCH 1/4] ACPI / watchdog: Add support for WDAT hardware watchdog

On 09/14/2016 01:06 AM, Mika Westerberg wrote: On Tue, Sep 13, 2016 at 02:00:25PM -0700, Guenter Roeck wrote: On 09/13/2016 08:23 AM, Mika Westerberg wrote: Starting from Intel Skylake the iTCO watchdog timer registers were moved to reside in the same register space with SMBus host controller.

Re: [PATCH 1/1] cpufreq: pcc-cpufreq: Re-introduce deadband effect to reduce number of frequency changes

On Wed, Sep 07, 2016 at 10:32:01AM +0530, Viresh Kumar wrote: > On 01-09-16, 15:21, Andreas Herrmann wrote: ---8<--- > > I started with the value return as "nominal latency" for PCC. This > > was 30 ns on the test system and made things worse. I've tested > > other values as well unitl

Re: [PATCH v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

On Wed, Sep 14, 2016 at 04:11:58PM +0200, NeilBrown wrote: > On Wed, Sep 14 2016, Mark Brown wrote: > > Yes, the idea is that the charger will back off charging and stop > > entirely if the rest of the system is consuming too much power to allow > > it to continue effectively. The same thing

Re: [PATCH 1/1] cpufreq: pcc-cpufreq: Re-introduce deadband effect to reduce number of frequency changes

On Wed, Sep 07, 2016 at 10:32:01AM +0530, Viresh Kumar wrote: > On 01-09-16, 15:21, Andreas Herrmann wrote: ---8<--- > > I started with the value return as "nominal latency" for PCC. This > > was 30 ns on the test system and made things worse. I've tested > > other values as well unitl

Re: [PATCH v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

On Wed, Sep 14, 2016 at 04:11:58PM +0200, NeilBrown wrote: > On Wed, Sep 14 2016, Mark Brown wrote: > > Yes, the idea is that the charger will back off charging and stop > > entirely if the rest of the system is consuming too much power to allow > > it to continue effectively. The same thing

Re: [PATCH 08/12] x86/dumpstack: Pin the target stack in save_stack_trace_tsk()

On Tue, Sep 13, 2016 at 02:29:28PM -0700, Andy Lutomirski wrote: > This will prevent a crash if the target task dies before or while > dumping its stack once we start freeing task stacks early. > > Signed-off-by: Andy Lutomirski Do we need a similar patch for show_stack()? --

Re: [PATCH 08/12] x86/dumpstack: Pin the target stack in save_stack_trace_tsk()

On Tue, Sep 13, 2016 at 02:29:28PM -0700, Andy Lutomirski wrote: > This will prevent a crash if the target task dies before or while > dumping its stack once we start freeing task stacks early. > > Signed-off-by: Andy Lutomirski Do we need a similar patch for show_stack()? -- Josh

[GIT PULL] GIC updates for 4.9

Hi Thomas, Please find below the pull request for some GIC updates, mostly focussing on the ITS ACPI support this time around. Rafael has acked the ACPI parts, and Bjorn has acked the PCI sides. None of that should conflict anyway, as the drivers/acpi/arm64 directory gets created for the

Re: [GIT PULL 3/4] arm64: dts: exynos: DeviceTree ARM64 for v4.9

On Tuesday, August 30, 2016 11:18:58 AM CEST Krzysztof Kozlowski wrote: > This is an old one. It was ready for v4.8 but then Marc Zynger posted > some conflicting change so I postponed it. Marc's patch didn't get in, > so there is no reason to wait. > > No conflict expected yet, but if you apply

[GIT PULL] GIC updates for 4.9

Hi Thomas, Please find below the pull request for some GIC updates, mostly focussing on the ITS ACPI support this time around. Rafael has acked the ACPI parts, and Bjorn has acked the PCI sides. None of that should conflict anyway, as the drivers/acpi/arm64 directory gets created for the

Re: [GIT PULL 3/4] arm64: dts: exynos: DeviceTree ARM64 for v4.9

On Tuesday, August 30, 2016 11:18:58 AM CEST Krzysztof Kozlowski wrote: > This is an old one. It was ready for v4.8 but then Marc Zynger posted > some conflicting change so I postponed it. Marc's patch didn't get in, > so there is no reason to wait. > > No conflict expected yet, but if you apply

[PATCH v5 1/5] vfs: Add current_time() api

current_fs_time() is used for inode timestamps. Change the signature of the function to take inode pointer instead of superblock as per Linus's suggestion. Also, move the api under vfs as per the discussion on the thread: https://lkml.org/lkml/2016/6/9/36 . As per Arnd's suggestion on the

[PATCH v5 1/5] vfs: Add current_time() api

current_fs_time() is used for inode timestamps. Change the signature of the function to take inode pointer instead of superblock as per Linus's suggestion. Also, move the api under vfs as per the discussion on the thread: https://lkml.org/lkml/2016/6/9/36 . As per Arnd's suggestion on the

[PATCH v5 2/5] fs: proc: Delete inode time initializations in proc_alloc_inode()

proc uses new_inode_pseudo() to allocate a new inode. This in turn calls the proc_inode_alloc() callback. But, at this point, inode is still not initialized with the super_block pointer which only happens just before alloc_inode() returns after the call to inode_init_always(). Also, the inode

[PATCH v5 2/5] fs: proc: Delete inode time initializations in proc_alloc_inode()

proc uses new_inode_pseudo() to allocate a new inode. This in turn calls the proc_inode_alloc() callback. But, at this point, inode is still not initialized with the super_block pointer which only happens just before alloc_inode() returns after the call to inode_init_always(). Also, the inode

[PATCH v5 5/5] fs: Replace current_fs_time() with current_time()

current_fs_time() uses struct super_block* as an argument. As per Linus's suggestion, this is changed to take struct inode* as a parameter instead. This is because the function is primarily meant for vfs inode timestamps. Also the function was renamed as per Arnd's suggestion. Change all calls to

Re: [RFC PATCH v2 19/20] x86: Access the setup data through debugfs un-encrypted

On Wed, Sep 14, 2016 at 09:29:41AM -0500, Tom Lendacky wrote: > This is still required because just using the __va() would still cause > the mapping created to have the encryption bit set. The ioremap call > will result in the mapping not having the encryption bit set. I meant this:

[PATCH v5 5/5] fs: Replace current_fs_time() with current_time()

current_fs_time() uses struct super_block* as an argument. As per Linus's suggestion, this is changed to take struct inode* as a parameter instead. This is because the function is primarily meant for vfs inode timestamps. Also the function was renamed as per Arnd's suggestion. Change all calls to

Re: [RFC PATCH v2 19/20] x86: Access the setup data through debugfs un-encrypted

On Wed, Sep 14, 2016 at 09:29:41AM -0500, Tom Lendacky wrote: > This is still required because just using the __va() would still cause > the mapping created to have the encryption bit set. The ioremap call > will result in the mapping not having the encryption bit set. I meant this:

[PATCH v5 4/5] fs: Replace CURRENT_TIME_SEC with current_time() for inode timestamps

CURRENT_TIME_SEC is not y2038 safe. current_time() will be transitioned to use 64 bit time along with vfs in a separate patch. There is no plan to transistion CURRENT_TIME_SEC to use y2038 safe time interfaces. current_time() will also be extended to use superblock range checking parameters when

[PATCH v5 4/5] fs: Replace CURRENT_TIME_SEC with current_time() for inode timestamps

CURRENT_TIME_SEC is not y2038 safe. current_time() will be transitioned to use 64 bit time along with vfs in a separate patch. There is no plan to transistion CURRENT_TIME_SEC to use y2038 safe time interfaces. current_time() will also be extended to use superblock range checking parameters when

Re: [RFC PATCH v2 15/20] iommu/amd: AMD IOMMU support for memory encryption

On Wed, Sep 14, 2016 at 08:45:44AM -0500, Tom Lendacky wrote: > Currently, mem_encrypt.h only lives in the arch/x86 directory so it > wouldn't be able to be included here without breaking other archs. I'm wondering if it would be simpler to move only sme_me_mask to an arch-agnostic header just so

[PATCH v2 0/5] drm: clean up several wrapper functions

Changes in v2: - Split per-driver - Remove i915_driver_open() - Fix dce_virtual_hw_init() as well Masahiro Yamada (5): drm/amdgpu: squash lines for simple wrapper functions drm/radeon: squash lines for simple wrapper functions drm/bridge: squash lines for simple wrapper functions

Re: [RFC PATCH v2 15/20] iommu/amd: AMD IOMMU support for memory encryption

On Wed, Sep 14, 2016 at 08:45:44AM -0500, Tom Lendacky wrote: > Currently, mem_encrypt.h only lives in the arch/x86 directory so it > wouldn't be able to be included here without breaking other archs. I'm wondering if it would be simpler to move only sme_me_mask to an arch-agnostic header just so

[PATCH v2 0/5] drm: clean up several wrapper functions

Changes in v2: - Split per-driver - Remove i915_driver_open() - Fix dce_virtual_hw_init() as well Masahiro Yamada (5): drm/amdgpu: squash lines for simple wrapper functions drm/radeon: squash lines for simple wrapper functions drm/bridge: squash lines for simple wrapper functions

[PATCH v5 3/5] fs: Replace CURRENT_TIME with current_time() for inode timestamps

CURRENT_TIME macro is not appropriate for filesystems as it doesn't use the right granularity for filesystem timestamps. Use current_time() instead. CURRENT_TIME is also not y2038 safe. This is also in preparation for the patch that transitions vfs timestamps to use 64 bit time and hence make

[PATCH v5 3/5] fs: Replace CURRENT_TIME with current_time() for inode timestamps

CURRENT_TIME macro is not appropriate for filesystems as it doesn't use the right granularity for filesystem timestamps. Use current_time() instead. CURRENT_TIME is also not y2038 safe. This is also in preparation for the patch that transitions vfs timestamps to use 64 bit time and hence make

Re: [kernel-hardening] [RFC PATCH v2 2/3] xpfo: Only put previous userspace pages into the hot cache

> On 09/02/2016 10:39 PM, Dave Hansen wrote: >> On 09/02/2016 04:39 AM, Juerg Haefliger wrote: >> Does this >> just mean that kernel allocations usually have to pay the penalty to >> convert a page? > > Only pages that are allocated for userspace (gfp & GFP_HIGHUSER == > GFP_HIGHUSER) which were

[PATCH v5 0/5] Introduce current_time() api

The series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC macros. The macros are not y2038 safe. There is no plan to transition them into being y2038 safe. ktime_get_* api's can be used in their place. And, these are y2038 safe. Thanks to Arnd Bergmann for all the guidance and

[PATCH v5 0/5] Introduce current_time() api

The series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC macros. The macros are not y2038 safe. There is no plan to transition them into being y2038 safe. ktime_get_* api's can be used in their place. And, these are y2038 safe. Thanks to Arnd Bergmann for all the guidance and

Re: [kernel-hardening] [RFC PATCH v2 2/3] xpfo: Only put previous userspace pages into the hot cache

> On 09/02/2016 10:39 PM, Dave Hansen wrote: >> On 09/02/2016 04:39 AM, Juerg Haefliger wrote: >> Does this >> just mean that kernel allocations usually have to pay the penalty to >> convert a page? > > Only pages that are allocated for userspace (gfp & GFP_HIGHUSER == > GFP_HIGHUSER) which were

Re: [PATCH 1/1] Drivers: hv: hv_util: Avoid dynamic allocation in time synch

On Fri, Sep 09, k...@exchange.microsoft.com wrote: > + * This check is safe since we are executing in the > + * interrupt context and time synch messages arre always Typo. Olaf signature.asc Description: PGP signature

Re: [PATCH 1/1] Drivers: hv: hv_util: Avoid dynamic allocation in time synch

On Fri, Sep 09, k...@exchange.microsoft.com wrote: > + * This check is safe since we are executing in the > + * interrupt context and time synch messages arre always Typo. Olaf signature.asc Description: PGP signature

[PATCH v2 3/5] drm/bridge: squash lines for simple wrapper functions

Remove unneeded variables and assignments. Signed-off-by: Masahiro Yamada --- drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 20 1 file changed, 4 insertions(+), 16 deletions(-) diff --git

[PATCH v2 3/5] drm/bridge: squash lines for simple wrapper functions

Remove unneeded variables and assignments. Signed-off-by: Masahiro Yamada --- drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 20 1 file changed, 4 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c

Re: [fuse-devel] Kernel panic under load

Hi Miklos, On Tue, Sep 13, 2016 at 10:42:17AM +0200, Miklos Szeredi wrote: > Fuse allows pages to be spliced into the page cache when reading the > file. It does this with replace_page_cache_page(), which is an atomic > version of delete_from_page_cache()+add_to_page_cache(). > > Fuse is the

Re: [fuse-devel] Kernel panic under load

Hi Miklos, On Tue, Sep 13, 2016 at 10:42:17AM +0200, Miklos Szeredi wrote: > Fuse allows pages to be spliced into the page cache when reading the > file. It does this with replace_page_cache_page(), which is an atomic > version of delete_from_page_cache()+add_to_page_cache(). > > Fuse is the

Re: [kernel-hardening] [RFC PATCH v2 2/3] xpfo: Only put previous userspace pages into the hot cache

Hi Dave, On 09/14/2016 04:33 PM, Dave Hansen wrote: > On 09/14/2016 12:19 AM, Juerg Haefliger wrote: >> Allocating a page to userspace that was previously allocated to the >> kernel requires an expensive TLB shootdown. To minimize this, we only >> put non-kernel pages into the hot cache to favor

[PATCH v2 1/5] drm/amdgpu: squash lines for simple wrapper functions

Remove unneeded variables and assignments. Signed-off-by: Masahiro Yamada --- drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 6 +- drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c | 6 +- drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 6 +- 3 files changed, 3

[PATCH v2 5/5] drm/i915: use i915_gem_open() directly instead of i915_driver_open()

i915_driver_open() is equivalent to i915_gem_open(). Replace the i915_driver_open with the direct use of i915_gem_open(). Signed-off-by: Masahiro Yamada --- drivers/gpu/drm/i915/i915_drv.c | 13 + 1 file changed, 1 insertion(+), 12 deletions(-) diff

[PATCH v2 2/5] drm/radeon: squash lines for simple wrapper functions

Remove unneeded variables and assignments. Signed-off-by: Masahiro Yamada --- drivers/gpu/drm/radeon/cik.c | 6 +- drivers/gpu/drm/radeon/r100.c | 6 +- drivers/gpu/drm/radeon/r600.c | 6 +- 3 files changed, 3 insertions(+), 15 deletions(-) diff

Re: [kernel-hardening] [RFC PATCH v2 2/3] xpfo: Only put previous userspace pages into the hot cache

Hi Dave, On 09/14/2016 04:33 PM, Dave Hansen wrote: > On 09/14/2016 12:19 AM, Juerg Haefliger wrote: >> Allocating a page to userspace that was previously allocated to the >> kernel requires an expensive TLB shootdown. To minimize this, we only >> put non-kernel pages into the hot cache to favor

[PATCH v2 1/5] drm/amdgpu: squash lines for simple wrapper functions

Remove unneeded variables and assignments. Signed-off-by: Masahiro Yamada --- drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 6 +- drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c | 6 +- drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 6 +- 3 files changed, 3 insertions(+), 15 deletions(-) diff

[PATCH v2 5/5] drm/i915: use i915_gem_open() directly instead of i915_driver_open()

i915_driver_open() is equivalent to i915_gem_open(). Replace the i915_driver_open with the direct use of i915_gem_open(). Signed-off-by: Masahiro Yamada --- drivers/gpu/drm/i915/i915_drv.c | 13 + 1 file changed, 1 insertion(+), 12 deletions(-) diff --git

[PATCH v2 2/5] drm/radeon: squash lines for simple wrapper functions

Remove unneeded variables and assignments. Signed-off-by: Masahiro Yamada --- drivers/gpu/drm/radeon/cik.c | 6 +- drivers/gpu/drm/radeon/r100.c | 6 +- drivers/gpu/drm/radeon/r600.c | 6 +- 3 files changed, 3 insertions(+), 15 deletions(-) diff --git

[PATCH v2 4/5] drm/qxl: squash lines for simple wrapper functions

Remove unneeded variables and assignments. Signed-off-by: Masahiro Yamada --- drivers/gpu/drm/qxl/qxl_draw.c| 7 ++- drivers/gpu/drm/qxl/qxl_release.c | 7 ++- 2 files changed, 4 insertions(+), 10 deletions(-) diff --git

[PATCH v2 4/5] drm/qxl: squash lines for simple wrapper functions

Remove unneeded variables and assignments. Signed-off-by: Masahiro Yamada --- drivers/gpu/drm/qxl/qxl_draw.c| 7 ++- drivers/gpu/drm/qxl/qxl_release.c | 7 ++- 2 files changed, 4 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/qxl/qxl_draw.c

RE: [RFC v3 00/22] Landlock LSM: Unprivileged sandboxing

From: Mickaël Salaün > Sent: 14 September 2016 08:24 ... > ## Why does seccomp-filter is not enough? > > A seccomp filter can access to raw syscall arguments which means that it is > not > possible to filter according to pointed data as a file path. As demonstrated > the first version of this

RE: [RFC v3 00/22] Landlock LSM: Unprivileged sandboxing

From: Mickaël Salaün > Sent: 14 September 2016 08:24 ... > ## Why does seccomp-filter is not enough? > > A seccomp filter can access to raw syscall arguments which means that it is > not > possible to filter according to pointed data as a file path. As demonstrated > the first version of this

Re: [PATCH 3/4] ARM: orion5x: avoid NO_IRQ in orion_ge00_switch_init

Hi Arnd, On jeu., sept. 08 2016, Arnd Bergmann wrote: > On Wednesday, September 7, 2016 4:03:16 AM CEST Andrew Lunn wrote: >> On Tue, Sep 06, 2016 at 04:06:22PM +0200, Arnd Bergmann wrote: >> > As of commit 5be9fc23cdb4 ("ARM: orion5x: fix legacy orion5x IRQ numbers"), >> > IRQ

Re: [PATCH 3/4] ARM: orion5x: avoid NO_IRQ in orion_ge00_switch_init

Hi Arnd, On jeu., sept. 08 2016, Arnd Bergmann wrote: > On Wednesday, September 7, 2016 4:03:16 AM CEST Andrew Lunn wrote: >> On Tue, Sep 06, 2016 at 04:06:22PM +0200, Arnd Bergmann wrote: >> > As of commit 5be9fc23cdb4 ("ARM: orion5x: fix legacy orion5x IRQ numbers"), >> > IRQ zero is no

Re: [PATCH 4/4] ARM: orion5x: remove extraneous NO_IRQ

Hi Arnd, On mar., sept. 06 2016, Arnd Bergmann wrote: > rd88f6183ap-ge passes NO_IRQ as the interrupt line for its m25p80 > NOR flash. However, this device never uses an interrupt and the > driver doesn't care, so we can simply remove the deprecated constant > here. > >

Re: [RESEND][PATCH V7 0/5] perf: Driver specific configuration for PMU

On 13 September 2016 at 14:06, Arnaldo Carvalho de Melo wrote: > Em Tue, Sep 06, 2016 at 10:37:12AM -0600, Mathieu Poirier escreveu: >> Original blurb: >> --- > > So, I managed to apply "perf tools: add infrastructure for PMU specific > configuration", the first, as

Re: [PATCH 4/4] ARM: orion5x: remove extraneous NO_IRQ

Hi Arnd, On mar., sept. 06 2016, Arnd Bergmann wrote: > rd88f6183ap-ge passes NO_IRQ as the interrupt line for its m25p80 > NOR flash. However, this device never uses an interrupt and the > driver doesn't care, so we can simply remove the deprecated constant > here. > > Signed-off-by: Arnd

Re: [RESEND][PATCH V7 0/5] perf: Driver specific configuration for PMU

On 13 September 2016 at 14:06, Arnaldo Carvalho de Melo wrote: > Em Tue, Sep 06, 2016 at 10:37:12AM -0600, Mathieu Poirier escreveu: >> Original blurb: >> --- > > So, I managed to apply "perf tools: add infrastructure for PMU specific > configuration", the first, as we discussed,

Re: [PATCH 2/4] ARM: mvebu/orion: remove NO_IRQ check from device init

Hi Arnd, On mar., sept. 06 2016, Arnd Bergmann wrote: > For most devices, we know in advance whether they have an > interrupt line or not, so we can avoid passing NO_IRQ and > instead split fill_resources() into two interfaces, with > only the new fill_resources_irq() function

Re: [PATCH 2/4] ARM: mvebu/orion: remove NO_IRQ check from device init

Hi Arnd, On mar., sept. 06 2016, Arnd Bergmann wrote: > For most devices, we know in advance whether they have an > interrupt line or not, so we can avoid passing NO_IRQ and > instead split fill_resources() into two interfaces, with > only the new fill_resources_irq() function taking an irq >

Re: [PATCH 1/4] ARM: mv78xx0: simplify ethernet device creation

Hi Arnd, On mar., sept. 06 2016, Arnd Bergmann wrote: > Out of the four ethernet devices on mv78xx0, only the first one > has an error interrupt line, for the other ones we pass NO_IRQ > and then ignore the argument. > > In order to get closer to complete remove of NO_IRQ, this

Re: [PATCH 1/4] ARM: mv78xx0: simplify ethernet device creation

Hi Arnd, On mar., sept. 06 2016, Arnd Bergmann wrote: > Out of the four ethernet devices on mv78xx0, only the first one > has an error interrupt line, for the other ones we pass NO_IRQ > and then ignore the argument. > > In order to get closer to complete remove of NO_IRQ, this simply > drops

Re: drivers/usb/musb/tusb6010.c:142:21: error: 'USB_INDEX' undeclared

* Bin Liu [160914 06:14]: > On Tue, Sep 13, 2016 at 03:35:05PM -0700, Tony Lindgren wrote: > > * Bin Liu [160908 11:26]: > > > On Thu, Sep 08, 2016 at 10:45:21AM -0700, Tony Lindgren wrote: > > > > --- a/drivers/usb/musb/Kconfig > > > > +++ b/drivers/usb/musb/Kconfig

Re: drivers/usb/musb/tusb6010.c:142:21: error: 'USB_INDEX' undeclared

* Bin Liu [160914 06:14]: > On Tue, Sep 13, 2016 at 03:35:05PM -0700, Tony Lindgren wrote: > > * Bin Liu [160908 11:26]: > > > On Thu, Sep 08, 2016 at 10:45:21AM -0700, Tony Lindgren wrote: > > > > --- a/drivers/usb/musb/Kconfig > > > > +++ b/drivers/usb/musb/Kconfig > > > > @@ -87,7 +87,7 @@

Re: get_maintainer.pl and git send-email: 5.1.2 The recipient address <linux-...@lists.infradead.org)> is not a valid

On Wed, 2016-09-14 at 07:13 -0700, Joe Perches wrote: > The scripts use --to-cmd to address the direct maintainers > and cc-cmd to address indirect maintainers and mailing lists. I neglected to mention I use a separate directory for each patch series so there are no other files in the directory

Re: get_maintainer.pl and git send-email: 5.1.2 The recipient address is not a valid

On Wed, 2016-09-14 at 07:13 -0700, Joe Perches wrote: > The scripts use --to-cmd to address the direct maintainers > and cc-cmd to address indirect maintainers and mailing lists. I neglected to mention I use a separate directory for each patch series so there are no other files in the directory

Re: [kernel-hardening] [RFC PATCH v2 2/3] xpfo: Only put previous userspace pages into the hot cache

On 09/14/2016 12:19 AM, Juerg Haefliger wrote: > Allocating a page to userspace that was previously allocated to the > kernel requires an expensive TLB shootdown. To minimize this, we only > put non-kernel pages into the hot cache to favor their allocation. Hi, I had some questions about this the

Re: [kernel-hardening] [RFC PATCH v2 2/3] xpfo: Only put previous userspace pages into the hot cache

On 09/14/2016 12:19 AM, Juerg Haefliger wrote: > Allocating a page to userspace that was previously allocated to the > kernel requires an expensive TLB shootdown. To minimize this, we only > put non-kernel pages into the hot cache to favor their allocation. Hi, I had some questions about this the

Re: Crashing 'kzm' target in next-20160913 due to 'gpio: mxc: shift gpio_mxc_init() to subsys_initcall level'

On 09/14/2016 12:19 AM, Linus Walleij wrote: On Wed, Sep 14, 2016 at 5:20 AM, Guenter Roeck wrote: So, in other words, lots of bugs here. Nevertheless, I would suggest to keep using postcore_initcall(), at least until it is sure that all gpio clients handle -EPROBE_DEFER

Re: Crashing 'kzm' target in next-20160913 due to 'gpio: mxc: shift gpio_mxc_init() to subsys_initcall level'

On 09/14/2016 12:19 AM, Linus Walleij wrote: On Wed, Sep 14, 2016 at 5:20 AM, Guenter Roeck wrote: So, in other words, lots of bugs here. Nevertheless, I would suggest to keep using postcore_initcall(), at least until it is sure that all gpio clients handle -EPROBE_DEFER correctly. So can

Re: [RFC PATCH v2 20/20] x86: Add support to make use of Secure Memory Encryption

On 09/12/2016 12:08 PM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:39:08PM -0500, Tom Lendacky wrote: >> This patch adds the support to check if SME has been enabled and if the >> mem_encrypt=on command line option is set. If both of these conditions >> are true, then the encryption mask

Re: [PATCH] driver-core: platform: Catch errors from calls to irq_get_irq_data

On 09/14/2016 02:44 AM, Greg Kroah-Hartman wrote: On Wed, Sep 14, 2016 at 11:06:08AM +0200, Linus Walleij wrote: On Wed, Sep 14, 2016 at 5:32 AM, Guenter Roeck wrote: irq_get_irq_data() can return NULL, which results in a nasty crash. Check its return value before passing

Re: [PATCH 2/2] HID: i2c-hid: support the regulator

On Sep 14 2016 or thereabouts, Brian Norris wrote: > On Wed, Sep 14, 2016 at 03:55:05PM +0800, Brian Norris wrote: > > The default behavior of regulator_get() is to provide a dummy regulator > > if none is found. So the pointer is never NULL, and it won't break > > devices without a regulator. If

Re: [RFC PATCH v2 20/20] x86: Add support to make use of Secure Memory Encryption

On 09/12/2016 12:08 PM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:39:08PM -0500, Tom Lendacky wrote: >> This patch adds the support to check if SME has been enabled and if the >> mem_encrypt=on command line option is set. If both of these conditions >> are true, then the encryption mask

Re: [PATCH] driver-core: platform: Catch errors from calls to irq_get_irq_data

On 09/14/2016 02:44 AM, Greg Kroah-Hartman wrote: On Wed, Sep 14, 2016 at 11:06:08AM +0200, Linus Walleij wrote: On Wed, Sep 14, 2016 at 5:32 AM, Guenter Roeck wrote: irq_get_irq_data() can return NULL, which results in a nasty crash. Check its return value before passing it on to

Re: [PATCH 2/2] HID: i2c-hid: support the regulator

On Sep 14 2016 or thereabouts, Brian Norris wrote: > On Wed, Sep 14, 2016 at 03:55:05PM +0800, Brian Norris wrote: > > The default behavior of regulator_get() is to provide a dummy regulator > > if none is found. So the pointer is never NULL, and it won't break > > devices without a regulator. If

Re: [RFC PATCH v2 19/20] x86: Access the setup data through debugfs un-encrypted

On 09/12/2016 11:59 AM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:38:59PM -0500, Tom Lendacky wrote: >> Since the setup data is in memory in the clear, it must be accessed as >> un-encrypted. Always use ioremap (similar to sysfs setup data support) >> to map the data. >> >>

Re: [RFC PATCH v2 19/20] x86: Access the setup data through debugfs un-encrypted

On 09/12/2016 11:59 AM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:38:59PM -0500, Tom Lendacky wrote: >> Since the setup data is in memory in the clear, it must be accessed as >> un-encrypted. Always use ioremap (similar to sysfs setup data support) >> to map the data. >> >>

Re: [PATCH v2 26/33] Task fork and exit for rdtgroup

On 09/13/2016 04:35 PM, Luck, Tony wrote: > On Tue, Sep 13, 2016 at 04:13:04PM -0700, Dave Hansen wrote: >> Yikes, is this a new global lock and possible atomic_inc() on a shared >> variable in the fork() path? Has there been any performance or >> scalability testing done on this code? >> >> That

Re: [PATCH v2 26/33] Task fork and exit for rdtgroup

On 09/13/2016 04:35 PM, Luck, Tony wrote: > On Tue, Sep 13, 2016 at 04:13:04PM -0700, Dave Hansen wrote: >> Yikes, is this a new global lock and possible atomic_inc() on a shared >> variable in the fork() path? Has there been any performance or >> scalability testing done on this code? >> >> That

[PATCH v2] ASoC: da7219: software reset codec at probe

From: Hsin-Yu Chao Da7219 does not trigger interrupt to report jack status when system boots from warm reset because its power remains on during warm reset. Doing software reset at probe to handle this. Signed-off-by: Hsin-Yu Chao Signed-off-by: Xing

[PATCH v2] ASoC: da7219: software reset codec at probe

From: Hsin-Yu Chao Da7219 does not trigger interrupt to report jack status when system boots from warm reset because its power remains on during warm reset. Doing software reset at probe to handle this. Signed-off-by: Hsin-Yu Chao Signed-off-by: Xing Zheng --- Changes in v2: - change the

[RFC PATCH v2 08/11] irqchip: mbigen: drop module owner

From: Kefeng Wang Module owner will be set by driver core, so drop it. Cc: Marc Zyngier Cc: Thomas Gleixner Cc: Ma Jun Signed-off-by: Kefeng Wang Signed-off-by: Hanjun Guo

[RFC PATCH v2 05/11] ACPI: platform: setup MSI domain for ACPI based platform device

From: Hanjun Guo With the platform msi domain created, we can set up the msi domain for a platform device when it's probed. This patch introduces acpi_configure_msi_domain(), which retrieves the domain from iort and set it to platform device. As some platform devices

[RFC PATCH v2 08/11] irqchip: mbigen: drop module owner

From: Kefeng Wang Module owner will be set by driver core, so drop it. Cc: Marc Zyngier Cc: Thomas Gleixner Cc: Ma Jun Signed-off-by: Kefeng Wang Signed-off-by: Hanjun Guo --- drivers/irqchip/irq-mbigen.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/irqchip/irq-mbigen.c

[RFC PATCH v2 05/11] ACPI: platform: setup MSI domain for ACPI based platform device

From: Hanjun Guo With the platform msi domain created, we can set up the msi domain for a platform device when it's probed. This patch introduces acpi_configure_msi_domain(), which retrieves the domain from iort and set it to platform device. As some platform devices such as an irqchip needs

[RFC PATCH v2 09/11] irqchip: mbigen: introduce mbigen_of_create_domain()

From: Kefeng Wang Introduce mbigen_of_create_domain() to consolidate OF related code and prepare for ACPI later. Cc: Marc Zyngier Cc: Thomas Gleixner Cc: Ma Jun Signed-off-by: Kefeng Wang

[RFC PATCH v2 09/11] irqchip: mbigen: introduce mbigen_of_create_domain()

From: Kefeng Wang Introduce mbigen_of_create_domain() to consolidate OF related code and prepare for ACPI later. Cc: Marc Zyngier Cc: Thomas Gleixner Cc: Ma Jun Signed-off-by: Kefeng Wang Signed-off-by: Hanjun Guo --- drivers/irqchip/irq-mbigen.c | 42

Re: [PATCH V3 1/4] ARM64 LPC: Indirect ISA port IO introduced

On Wednesday, September 14, 2016 10:16:28 PM CEST zhichang.yuan wrote: > > > > No need to guard includes with an #ifdef. > If remove #ifdef here, extio.h should not contain any function external > declarations whose definitions are in > extio.c compiled only when CONFIG_ARM64_INDIRECT_PIO is

[RFC PATCH v2 04/11] irqchip: gicv3-its: platform-msi: scan MADT to create platform msi domain

From: Hanjun Guo With the introduction of its_pmsi_init_one(), we can add some code on top for ACPI support of platform MSI. We are scanning the MADT table to get the ITS entry(ies), then use the information to create the platform msi domain for devices connect to it,

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