SIGNAL_UNKILLABLE and init again

Hi Oleg, I'm back looking at SIGNAL_UNKILLABLE and debugging child reapers again, and the current issue is when running code in the target process, SIGTRAP firing and that causing SIGNAL_UNKILLABLE protection to be removed in force_sig_info(): if (action->sa.sa_handler == SIG_DFL)

SIGNAL_UNKILLABLE and init again

Hi Oleg, I'm back looking at SIGNAL_UNKILLABLE and debugging child reapers again, and the current issue is when running code in the target process, SIGTRAP firing and that causing SIGNAL_UNKILLABLE protection to be removed in force_sig_info(): if (action->sa.sa_handler == SIG_DFL)

[PATCH] of: Provide dummy of_device_compatible_match() for compile-testing

Most of_device_*() functions have dummy versions for CONFIG_OF=n, but of_device_compatible_match() hasn't. Fix that to improve the ability to do compile-testing. Fixes: b9c13fe32faaa71c ("dt: Add of_device_compatible_match()") Signed-off-by: Geert Uytterhoeven ---

[PATCH] of: Provide dummy of_device_compatible_match() for compile-testing

Most of_device_*() functions have dummy versions for CONFIG_OF=n, but of_device_compatible_match() hasn't. Fix that to improve the ability to do compile-testing. Fixes: b9c13fe32faaa71c ("dt: Add of_device_compatible_match()") Signed-off-by: Geert Uytterhoeven --- include/linux/of.h | 6 ++

Re: [PATCH v7 1/6] platform/x86: intel_pmc_ipc: fix gcr offset

On 04/25/2017 06:29 AM, Andy Shevchenko wrote: On Mon, Apr 10, 2017 at 1:00 AM, Kuppuswamy Sathyanarayanan wrote: According to Broxton APL spec, PMC MIMO resources for Global Control Registers(GCR) are located at 4K(0x1000) offset from IPC base

Re: [PATCH v7 1/6] platform/x86: intel_pmc_ipc: fix gcr offset

On 04/25/2017 06:29 AM, Andy Shevchenko wrote: On Mon, Apr 10, 2017 at 1:00 AM, Kuppuswamy Sathyanarayanan wrote: According to Broxton APL spec, PMC MIMO resources for Global Control Registers(GCR) are located at 4K(0x1000) offset from IPC base address. In this driver,

Re: typec: tcpm/tcpci drivers acceptable for drivers/staging in v4.12 ?

On Tue, Apr 25, 2017 at 09:50:31AM -0700, Guenter Roeck wrote: > Hi Greg, > > would you be open to accepting the tcpm [1] and tcpci [2] drivers into > drivers/staging for v4.12 ? What's the rush? > The drivers are not ready for prime time, yet there is interest by others > to have them

Re: typec: tcpm/tcpci drivers acceptable for drivers/staging in v4.12 ?

On Tue, Apr 25, 2017 at 09:50:31AM -0700, Guenter Roeck wrote: > Hi Greg, > > would you be open to accepting the tcpm [1] and tcpci [2] drivers into > drivers/staging for v4.12 ? What's the rush? > The drivers are not ready for prime time, yet there is interest by others > to have them

[PATCH] scsi: stex: make S6flag static

From: Colin Ian King This module specific flag can be made static as it does not need to be in global scope. Signed-off-by: Colin Ian King --- drivers/scsi/stex.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] scsi: stex: make S6flag static

From: Colin Ian King This module specific flag can be made static as it does not need to be in global scope. Signed-off-by: Colin Ian King --- drivers/scsi/stex.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c index

Re: [PATCH] ARM/shmem: Drop page coloring align for non-VIPT CPUs

On Tue, Apr 25, 2017 at 08:19:21PM +0300, Dmitry Safonov wrote: > On 04/14/2017 01:09 PM, Dmitry Safonov wrote: > >On ARMv6 CPUs with VIPT caches there are aliasing issues: if two > >different cache line indexes correspond to the same physical > >address, then changes made to one of the alias

Re: [PATCH] ARM/shmem: Drop page coloring align for non-VIPT CPUs

On Tue, Apr 25, 2017 at 08:19:21PM +0300, Dmitry Safonov wrote: > On 04/14/2017 01:09 PM, Dmitry Safonov wrote: > >On ARMv6 CPUs with VIPT caches there are aliasing issues: if two > >different cache line indexes correspond to the same physical > >address, then changes made to one of the alias

Re: [PATCH] ARM: dts: imx6sx-sdb: Remove cpufreq OPP override

On 04/25/2017 07:23 PM, Leonard Crestez wrote: > On Tue, 2017-04-25 at 14:02 -0300, Fabio Estevam wrote: >> On Tue, Apr 25, 2017 at 2:02 PM, Fabio Estevam wrote: >>> >>> Hi Leonard, >>> >>> On Tue, Apr 25, 2017 at 1:57 PM, Leonard Crestez >>> wrote:

Re: [patch V2 00/24] cpu/hotplug: Convert get_online_cpus() to a percpu_rwsem

On 2017-04-25 17:10:37 [+0100], Mark Rutland wrote: > Hi, Hi, > When we bring the secondary CPU online, we detect an erratum that wasn't > present on the boot CPU, and try to enable a static branch we use to > track the erratum. The call to static_branch_enable() blows up as above. this

Re: [patch V2 00/24] cpu/hotplug: Convert get_online_cpus() to a percpu_rwsem

On 2017-04-25 17:10:37 [+0100], Mark Rutland wrote: > Hi, Hi, > When we bring the secondary CPU online, we detect an erratum that wasn't > present on the boot CPU, and try to enable a static branch we use to > track the erratum. The call to static_branch_enable() blows up as above. this

Re: [PATCH] ARM: dts: imx6sx-sdb: Remove cpufreq OPP override

On 04/25/2017 07:23 PM, Leonard Crestez wrote: > On Tue, 2017-04-25 at 14:02 -0300, Fabio Estevam wrote: >> On Tue, Apr 25, 2017 at 2:02 PM, Fabio Estevam wrote: >>> >>> Hi Leonard, >>> >>> On Tue, Apr 25, 2017 at 1:57 PM, Leonard Crestez >>> wrote: The board file for imx6sx-dbg

RE: [RFC 0/6] optimize ctx switch with rb-tree

Hi David, Is there any update about the patch series? We recently encountered another performance issue on KNL. I think the RB-tree solution also has benefits for it. Thanks, Kan > Subject: [RFC 0/6] optimize ctx switch with rb-tree > > Following the discussion in: >

RE: [RFC 0/6] optimize ctx switch with rb-tree

Hi David, Is there any update about the patch series? We recently encountered another performance issue on KNL. I think the RB-tree solution also has benefits for it. Thanks, Kan > Subject: [RFC 0/6] optimize ctx switch with rb-tree > > Following the discussion in: >

Re: [PATCH] ARM: dts: imx6sx-sdb: Remove cpufreq OPP override

On Tue, Apr 25, 2017 at 2:23 PM, Leonard Crestez wrote: > Wow, that was literally 15 minutes before my patch. In my defense I did > search the archives before starting to format the patch but it had not > arrived yet. > > Anyway, that version also sets the supply for

Re: [PATCH] ARM: dts: imx6sx-sdb: Remove cpufreq OPP override

On Tue, Apr 25, 2017 at 2:23 PM, Leonard Crestez wrote: > Wow, that was literally 15 minutes before my patch. In my defense I did > search the archives before starting to format the patch but it had not > arrived yet. > > Anyway, that version also sets the supply for reg_arm and reg_soc. It > is

Re: [PATCH] ARM/shmem: Drop page coloring align for non-VIPT CPUs

On 04/14/2017 01:09 PM, Dmitry Safonov wrote: On ARMv6 CPUs with VIPT caches there are aliasing issues: if two different cache line indexes correspond to the same physical address, then changes made to one of the alias might be lost or they can overwrite each other. To overcome aliasing issues,

Re: [PATCH] ARM/shmem: Drop page coloring align for non-VIPT CPUs

On 04/14/2017 01:09 PM, Dmitry Safonov wrote: On ARMv6 CPUs with VIPT caches there are aliasing issues: if two different cache line indexes correspond to the same physical address, then changes made to one of the alias might be lost or they can overwrite each other. To overcome aliasing issues,

Re: [PATCHv2] ARM32: Support mremap() for sigpage/vDSO

On 04/14/2017 04:25 PM, Dmitry Safonov wrote: CRIU restores application mappings on the same place where they were before Checkpoint. That means, that we need to move vDSO and sigpage during restore on exactly the same place where they were before C/R. Make mremap() code update

Re: [PATCHv2] ARM32: Support mremap() for sigpage/vDSO

On 04/14/2017 04:25 PM, Dmitry Safonov wrote: CRIU restores application mappings on the same place where they were before Checkpoint. That means, that we need to move vDSO and sigpage during restore on exactly the same place where they were before C/R. Make mremap() code update

Re: [PATCH] ARM: dts: imx6sx-sdb: Remove cpufreq OPP override

On Tue, 2017-04-25 at 14:02 -0300, Fabio Estevam wrote: > On Tue, Apr 25, 2017 at 2:02 PM, Fabio Estevam wrote: > > > > Hi Leonard, > > > > On Tue, Apr 25, 2017 at 1:57 PM, Leonard Crestez > > wrote: > > > > > > The board file for imx6sx-dbg

Re: [PATCH] ARM: dts: imx6sx-sdb: Remove cpufreq OPP override

On Tue, 2017-04-25 at 14:02 -0300, Fabio Estevam wrote: > On Tue, Apr 25, 2017 at 2:02 PM, Fabio Estevam wrote: > > > > Hi Leonard, > > > > On Tue, Apr 25, 2017 at 1:57 PM, Leonard Crestez > > wrote: > > > > > > The board file for imx6sx-dbg overrides cpufreq operating points to use > > >

Re: [PATCH 1/2] xen/arm, arm64: fix xen_dma_ops after 815dd18 "Consolidate get_dma_ops..."

On Tue, 25 Apr 2017, Julien Grall wrote: > Hi Stefano, > > On 24/04/17 20:16, Stefano Stabellini wrote: > > Given the outstanding regression we need to fix as soon as possible, > > I'll queue these patches on the xentip tree for 4.12. > > It looks like there is another rc for 4.11. I am

Re: [PATCH 1/2] xen/arm, arm64: fix xen_dma_ops after 815dd18 "Consolidate get_dma_ops..."

On Tue, 25 Apr 2017, Julien Grall wrote: > Hi Stefano, > > On 24/04/17 20:16, Stefano Stabellini wrote: > > Given the outstanding regression we need to fix as soon as possible, > > I'll queue these patches on the xentip tree for 4.12. > > It looks like there is another rc for 4.11. I am

Re: [PATCH V15 06/11] acpi: apei: handle SEA notification type for ARMv8

On Tue, Apr 18, 2017 at 05:05:18PM -0600, Tyler Baicar wrote: > ARM APEI extension proposal added SEA (Synchronous External Abort) > notification type for ARMv8. > Add a new GHES error source handling function for SEA. If an error > source's notification type is SEA, then this function can be

Re: [PATCH V15 06/11] acpi: apei: handle SEA notification type for ARMv8

On Tue, Apr 18, 2017 at 05:05:18PM -0600, Tyler Baicar wrote: > ARM APEI extension proposal added SEA (Synchronous External Abort) > notification type for ARMv8. > Add a new GHES error source handling function for SEA. If an error > source's notification type is SEA, then this function can be

RE: [PATCH] kallsyms: optimize kallsyms_lookup_name() for a few cases

Excerpts from David Laight's message of April 25, 2017 22:06: From: Naveen N. Rao Sent: 25 April 2017 17:18 1. Fail early for invalid/zero length symbols. 2. Detect names of the form and skip checking for kernel symbols in that case. Signed-off-by: Naveen N. Rao

RE: [PATCH] kallsyms: optimize kallsyms_lookup_name() for a few cases

Excerpts from David Laight's message of April 25, 2017 22:06: From: Naveen N. Rao Sent: 25 April 2017 17:18 1. Fail early for invalid/zero length symbols. 2. Detect names of the form and skip checking for kernel symbols in that case. Signed-off-by: Naveen N. Rao --- Masami, Michael, I have

Re: Re: [Intel-wired-lan] [PATCH] ixgbe: initialize u64_stats_sync structures early at ixgbe_probe

On Tue, Apr 25, 2017 at 8:39 AM, Lino Sanfilippo wrote: > Hi, > >> This patch doesn't look right to me. I would suggest rejecting it. >> >> The call to initialize the stats should be done when the ring is >> allocated, not in ixgbe_probe(). This should probably be done in

Re: Re: [Intel-wired-lan] [PATCH] ixgbe: initialize u64_stats_sync structures early at ixgbe_probe

On Tue, Apr 25, 2017 at 8:39 AM, Lino Sanfilippo wrote: > Hi, > >> This patch doesn't look right to me. I would suggest rejecting it. >> >> The call to initialize the stats should be done when the ring is >> allocated, not in ixgbe_probe(). This should probably be done in >>

[PATCH] clk: sunxi-ng: Fix dependency on sunxi_gate

When CONFIG_SUNXI_CCU is set but no other SUNXI_CCU is selected i got the following build error: drivers/built-in.o: In function `ccu_pll_notifier_cb': drivers/clk/sunxi-ng/ccu_common.c:71: undefined reference to `ccu_gate_helper_disable' drivers/clk/sunxi-ng/ccu_common.c:73: undefined reference

[PATCH] clk: sunxi-ng: Fix dependency on sunxi_gate

When CONFIG_SUNXI_CCU is set but no other SUNXI_CCU is selected i got the following build error: drivers/built-in.o: In function `ccu_pll_notifier_cb': drivers/clk/sunxi-ng/ccu_common.c:71: undefined reference to `ccu_gate_helper_disable' drivers/clk/sunxi-ng/ccu_common.c:73: undefined reference

Re: [PATCH 2/2] arm64: pmu: Wire-up L2 cache events for ARMv8 PMUv3

On 04/25/2017 05:44 AM, Will Deacon wrote: > Hi Florian, > > On Thu, Apr 20, 2017 at 12:05:46PM -0700, Florian Fainelli wrote: >> The ARMv8 PMUv3 cache map did not include the L2 cache events, add >> them. >> >> Signed-off-by: Florian Fainelli >> --- >>

Re: [PATCH 2/2] arm64: pmu: Wire-up L2 cache events for ARMv8 PMUv3

On 04/25/2017 05:44 AM, Will Deacon wrote: > Hi Florian, > > On Thu, Apr 20, 2017 at 12:05:46PM -0700, Florian Fainelli wrote: >> The ARMv8 PMUv3 cache map did not include the L2 cache events, add >> them. >> >> Signed-off-by: Florian Fainelli >> --- >> arch/arm64/kernel/perf_event.c | 5 +

Re: [v10, 2/2] Documentation/ABI: Add ABI information for QCOM socinfo driver

On Mon, Apr 24, 2017 at 6:05 PM, Bjorn Andersson wrote: > On Mon 24 Apr 09:27 PDT 2017, Rob Herring wrote: > >> On Mon, Apr 24, 2017 at 11:00 AM, Imran Khan wrote: >> > On 4/18/2017 7:53 PM, Imran Khan wrote: >> > Hi Rob, >> > Could you please

Re: [v10, 2/2] Documentation/ABI: Add ABI information for QCOM socinfo driver

On Mon, Apr 24, 2017 at 6:05 PM, Bjorn Andersson wrote: > On Mon 24 Apr 09:27 PDT 2017, Rob Herring wrote: > >> On Mon, Apr 24, 2017 at 11:00 AM, Imran Khan wrote: >> > On 4/18/2017 7:53 PM, Imran Khan wrote: >> > Hi Rob, >> > Could you please provide some feedback so that this discussion can

Re: [PATCH] iio: inkern: fix a static checker error

On 2017-04-25 18:01, Lars-Peter Clausen wrote: > On 04/24/2017 11:32 AM, Peter Rosin wrote: >> On 2017-04-20 23:13, Peter Rosin wrote: >>> On 2017-04-20 23:12, Lars-Peter Clausen wrote: On 04/20/2017 11:01 PM, Peter Rosin wrote: > Avoid this smatch error: > drivers/iio/inkern.c:751

Re: [PATCH] iio: inkern: fix a static checker error

On 2017-04-25 18:01, Lars-Peter Clausen wrote: > On 04/24/2017 11:32 AM, Peter Rosin wrote: >> On 2017-04-20 23:13, Peter Rosin wrote: >>> On 2017-04-20 23:12, Lars-Peter Clausen wrote: On 04/20/2017 11:01 PM, Peter Rosin wrote: > Avoid this smatch error: > drivers/iio/inkern.c:751

Re: [PATCH v6] Documentation: Input: Add uinput documentation

On Sun, Apr 23, 2017 at 03:40:50PM -0300, Marcos Paulo de Souza wrote: > Signed-off-by: Marcos Paulo de Souza > --- I adjusted wording a bit here and there and applied, thank you. > > v5 -> v6: > Resend v5, but now include a change into input_uapi.rst (added by

Re: [PATCH v6] Documentation: Input: Add uinput documentation

On Sun, Apr 23, 2017 at 03:40:50PM -0300, Marcos Paulo de Souza wrote: > Signed-off-by: Marcos Paulo de Souza > --- I adjusted wording a bit here and there and applied, thank you. > > v5 -> v6: > Resend v5, but now include a change into input_uapi.rst (added by Dmitry and > Mauro) to

[PATCH v2] macsec: dynamically allocate space for sglist

We call skb_cow_data, which is good anyway to ensure we can actually modify the skb as such (another error from prior). Now that we have the number of fragments required, we can safely allocate exactly that amount of memory. Signed-off-by: Jason A. Donenfeld Cc: Sabrina Dubroca

[PATCH v2] macsec: dynamically allocate space for sglist

We call skb_cow_data, which is good anyway to ensure we can actually modify the skb as such (another error from prior). Now that we have the number of fragments required, we can safely allocate exactly that amount of memory. Signed-off-by: Jason A. Donenfeld Cc: Sabrina Dubroca Cc:

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 25/04/17 12:30 AM, Knut Omang wrote: > Yes, that's why I used 'significant'. One good thing is that given resources > it can easily be done in parallel with other development, and will give > additional > insight of some form. Yup, well if someone wants to start working on an emulated RDMA

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 25/04/17 12:30 AM, Knut Omang wrote: > Yes, that's why I used 'significant'. One good thing is that given resources > it can easily be done in parallel with other development, and will give > additional > insight of some form. Yup, well if someone wants to start working on an emulated RDMA

Re: [PATCH 11/28] drm/qxl: fix include notation and remove -Iinclude/drm flag

Masahiro Yamada writes: > Include instead of relative path from include/drm, then > remove the -Iinclude/drm compiler flag. > > Signed-off-by: Masahiro Yamada Please add Reviewed-by: Gabriel Krisman Bertazi

Re: [PATCH 11/28] drm/qxl: fix include notation and remove -Iinclude/drm flag

Masahiro Yamada writes: > Include instead of relative path from include/drm, then > remove the -Iinclude/drm compiler flag. > > Signed-off-by: Masahiro Yamada Please add Reviewed-by: Gabriel Krisman Bertazi for this and patch 1. Thanks, -- Gabriel Krisman Bertazi

Re: [PATCH] ARM: dts: imx6sx-sdb: Remove cpufreq OPP override

On Tue, Apr 25, 2017 at 2:02 PM, Fabio Estevam wrote: > Hi Leonard, > > On Tue, Apr 25, 2017 at 1:57 PM, Leonard Crestez > wrote: >> The board file for imx6sx-dbg overrides cpufreq operating points to use >> higher voltages. This is done because the

Re: [PATCH] ARM: dts: imx6sx-sdb: Remove cpufreq OPP override

On Tue, Apr 25, 2017 at 2:02 PM, Fabio Estevam wrote: > Hi Leonard, > > On Tue, Apr 25, 2017 at 1:57 PM, Leonard Crestez > wrote: >> The board file for imx6sx-dbg overrides cpufreq operating points to use >> higher voltages. This is done because the board has a shared rail for >> VDD_ARM_IN and

Re: [PATCH v2 01/12] IB/ocrdma: Use kcalloc() in ocrdma_mbx_alloc_pd_range()

On Mon, 2017-04-24 at 21:57 +0530, Devesh Sharma wrote: > Acked-By: Devesh Sharma Devesh, after you have reviewed any of Markus' patches that you care to review, if you wish any of them to go into my tree, please submit them to me yourself.  Thanks. -- Doug Ledford

Re: [PATCH v2 01/12] IB/ocrdma: Use kcalloc() in ocrdma_mbx_alloc_pd_range()

On Mon, 2017-04-24 at 21:57 +0530, Devesh Sharma wrote: > Acked-By: Devesh Sharma Devesh, after you have reviewed any of Markus' patches that you care to review, if you wish any of them to go into my tree, please submit them to me yourself.  Thanks. -- Doug Ledford     GPG KeyID:

Re: [PATCH] ARM: dts: imx6sx-sdb: Remove cpufreq OPP override

Hi Leonard, On Tue, Apr 25, 2017 at 1:57 PM, Leonard Crestez wrote: > The board file for imx6sx-dbg overrides cpufreq operating points to use > higher voltages. This is done because the board has a shared rail for > VDD_ARM_IN and VDD_SOC_IN and when using LDO bypass the

Re: [PATCH] ARM: dts: imx6sx-sdb: Remove cpufreq OPP override

Hi Leonard, On Tue, Apr 25, 2017 at 1:57 PM, Leonard Crestez wrote: > The board file for imx6sx-dbg overrides cpufreq operating points to use > higher voltages. This is done because the board has a shared rail for > VDD_ARM_IN and VDD_SOC_IN and when using LDO bypass the shared voltage > needs

Re: [musl] Re: [PATCH resent] uapi libc compat: allow non-glibc to opt out of uapi definitions

On Tue, Apr 25, 2017 at 08:29:00AM -0400, Carlos O'Donell wrote: > On 04/25/2017 02:45 AM, Hauke Mehrtens wrote: > > On 03/08/2017 05:39 PM, Carlos O'Donell wrote: > >> Any header needing compat with a libc includes libc-compat.h (per the > >> documented way the model works). With this patch any

Re: [musl] Re: [PATCH resent] uapi libc compat: allow non-glibc to opt out of uapi definitions

On Tue, Apr 25, 2017 at 08:29:00AM -0400, Carlos O'Donell wrote: > On 04/25/2017 02:45 AM, Hauke Mehrtens wrote: > > On 03/08/2017 05:39 PM, Carlos O'Donell wrote: > >> Any header needing compat with a libc includes libc-compat.h (per the > >> documented way the model works). With this patch any

Re: [PATCH 5/7] IB/hfi1: use pcie_flr instead of duplicating it

On Mon, 2017-04-24 at 16:35 +0200, Christoph Hellwig wrote: > On Mon, Apr 24, 2017 at 02:16:31PM +, Byczkowski, Jakub wrote: > > > > Tested-by: Jakub Byczkowski > > Are you (and Doug) ok with queueing this up in the PCI tree? I'm fine with that.  Feel free to

Re: [PATCH 5/7] IB/hfi1: use pcie_flr instead of duplicating it

On Mon, 2017-04-24 at 16:35 +0200, Christoph Hellwig wrote: > On Mon, Apr 24, 2017 at 02:16:31PM +, Byczkowski, Jakub wrote: > > > > Tested-by: Jakub Byczkowski > > Are you (and Doug) ok with queueing this up in the PCI tree? I'm fine with that.  Feel free to add my Acked-by to the hfi1

Re: [RFC 1/8] Introduce Peer-to-Peer memory (p2pmem) device

On 25/04/17 05:58 AM, Marta Rybczynska wrote: > I would add one issue that doesn't seem to be addressed: in my experience > P2P doesn't work when IOMMU activated. It works best with deactivation at > the BIOS level, even the kernel options are not enough in some cases. Well this would likely be

Re: [RFC 1/8] Introduce Peer-to-Peer memory (p2pmem) device

On 25/04/17 05:58 AM, Marta Rybczynska wrote: > I would add one issue that doesn't seem to be addressed: in my experience > P2P doesn't work when IOMMU activated. It works best with deactivation at > the BIOS level, even the kernel options are not enough in some cases. Well this would likely be

Re: [PATCH 0/2] DS1374 Watchdog fixes

On Tue, Apr 25, 2017 at 06:32:04PM +0200, Alexandre Belloni wrote: > On 25/04/2017 at 09:17:43 -0700, Guenter Roeck wrote: > > On Tue, Apr 25, 2017 at 07:55:28AM -0700, Moritz Fischer wrote: > > > Hi Guenter, > > > > > > On Mon, Apr 24, 2017 at 10:03 PM, Guenter Roeck > > >

Re: [PATCH 0/2] DS1374 Watchdog fixes

On Tue, Apr 25, 2017 at 06:32:04PM +0200, Alexandre Belloni wrote: > On 25/04/2017 at 09:17:43 -0700, Guenter Roeck wrote: > > On Tue, Apr 25, 2017 at 07:55:28AM -0700, Moritz Fischer wrote: > > > Hi Guenter, > > > > > > On Mon, Apr 24, 2017 at 10:03 PM, Guenter Roeck > > > wrote: > > > > On

[PATCH] ARM: dts: imx6sx-sdb: Remove cpufreq OPP override

The board file for imx6sx-dbg overrides cpufreq operating points to use higher voltages. This is done because the board has a shared rail for VDD_ARM_IN and VDD_SOC_IN and when using LDO bypass the shared voltage needs to be a value suitable for both ARM and SOC. This was introduced in: commit

[PATCH] ARM: dts: imx6sx-sdb: Remove cpufreq OPP override

The board file for imx6sx-dbg overrides cpufreq operating points to use higher voltages. This is done because the board has a shared rail for VDD_ARM_IN and VDD_SOC_IN and when using LDO bypass the shared voltage needs to be a value suitable for both ARM and SOC. This was introduced in: commit

Re: [PATCH 3/3] sound: ASoC: tegra: Select tegra30 i2s and ahub for tegra124 SoC

On 04/24/2017 12:41 PM, Paul Kocialkowski wrote: Le lundi 24 avril 2017 à 09:35 -0600, Stephen Warren a écrit : On 04/24/2017 09:07 AM, Paul Kocialkowski wrote: Le mercredi 19 avril 2017 à 16:00 -0600, Stephen Warren a écrit : On 04/18/2017 10:38 AM, Paul Kocialkowski wrote: Le mardi 18

Re: [PATCH 3/3] sound: ASoC: tegra: Select tegra30 i2s and ahub for tegra124 SoC

On 04/24/2017 12:41 PM, Paul Kocialkowski wrote: Le lundi 24 avril 2017 à 09:35 -0600, Stephen Warren a écrit : On 04/24/2017 09:07 AM, Paul Kocialkowski wrote: Le mercredi 19 avril 2017 à 16:00 -0600, Stephen Warren a écrit : On 04/18/2017 10:38 AM, Paul Kocialkowski wrote: Le mardi 18

Re: support autofocus / autogain in libv4l2

Le mardi 25 avril 2017 à 13:30 +0200, Pali Rohár a écrit : > Pinos (renamed from PulseVideo) > > https://blogs.gnome.org/uraeus/2015/06/30/introducing-pulse-video/ > https://cgit.freedesktop.org/~wtay/pinos/ > > But from git history it looks like it is probably dead now... This is also

Re: support autofocus / autogain in libv4l2

Le mardi 25 avril 2017 à 13:30 +0200, Pali Rohár a écrit : > Pinos (renamed from PulseVideo) > > https://blogs.gnome.org/uraeus/2015/06/30/introducing-pulse-video/ > https://cgit.freedesktop.org/~wtay/pinos/ > > But from git history it looks like it is probably dead now... This is also

Re: support autofocus / autogain in libv4l2

Le mardi 25 avril 2017 à 10:05 +0200, Pavel Machek a écrit : > Well, fd's are hard, because application can do fork() and now > interesting stuff happens. Threads are tricky, because now you have > locking etc. > > libv4l2 is designed to be LD_PRELOADED. That is not really feasible > with

Re: [PATCH v3] fpga manager: Add Altera CvP driver

hi Anatolij On 04/21/2017 04:14 PM, Li, Yi wrote: On 4/20/2017 12:29 PM, matthew.gerl...@linux.intel.com wrote: On Thu, 20 Apr 2017, Anatolij Gustschin wrote: Add FPGA manager driver for loading Arria/Cyclone/Stratix FPGAs via CvP. Signed-off-by: Anatolij Gustschin ---

Re: support autofocus / autogain in libv4l2

Le mardi 25 avril 2017 à 10:05 +0200, Pavel Machek a écrit : > Well, fd's are hard, because application can do fork() and now > interesting stuff happens. Threads are tricky, because now you have > locking etc. > > libv4l2 is designed to be LD_PRELOADED. That is not really feasible > with

Re: [PATCH v3] fpga manager: Add Altera CvP driver

hi Anatolij On 04/21/2017 04:14 PM, Li, Yi wrote: On 4/20/2017 12:29 PM, matthew.gerl...@linux.intel.com wrote: On Thu, 20 Apr 2017, Anatolij Gustschin wrote: Add FPGA manager driver for loading Arria/Cyclone/Stratix FPGAs via CvP. Signed-off-by: Anatolij Gustschin --- Hi Anatolij,

Re: [PATCH] arm64: Preventing READ_IMPLIES_EXEC propagation

On Tue, Apr 25, 2017 at 02:11:29PM +0800, dongbo (E) wrote: > From: Dong Bo > > Once the READ_IMPLIES_EXEC flag is set on arm64, the flag is > propagated to its child processes, even the ELF files are > marked as not requiring executable stack. > > Signed-off-by: Dong Bo

Re: [PATCH] arm64: Preventing READ_IMPLIES_EXEC propagation

On Tue, Apr 25, 2017 at 02:11:29PM +0800, dongbo (E) wrote: > From: Dong Bo > > Once the READ_IMPLIES_EXEC flag is set on arm64, the flag is > propagated to its child processes, even the ELF files are > marked as not requiring executable stack. > > Signed-off-by: Dong Bo > --- >

Re: [PATCH] scsi/mac_esp: Replace bogus memory barrier with spinlock

Michael, > looks good to me, so: > > Reviewed-By: Michael Schmitz Applied to 4.12/scsi-queue. Thank you! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] scsi/mac_esp: Replace bogus memory barrier with spinlock

Michael, > looks good to me, so: > > Reviewed-By: Michael Schmitz Applied to 4.12/scsi-queue. Thank you! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH v2] arm64: perf: Use only exclude_kernel attribute when kernel is running in HYP

On Tue, Apr 25, 2017 at 09:13:40AM +0530, Ganapatrao Kulkarni wrote: > On Mon, Apr 24, 2017 at 9:15 PM, Will Deacon wrote: > > On Thu, Apr 20, 2017 at 02:56:50PM +0530, Ganapatrao Kulkarni wrote: > >> On Thu, Apr 20, 2017 at 2:19 PM, Mark Rutland wrote:

Re: [PATCH v2] arm64: perf: Use only exclude_kernel attribute when kernel is running in HYP

On Tue, Apr 25, 2017 at 09:13:40AM +0530, Ganapatrao Kulkarni wrote: > On Mon, Apr 24, 2017 at 9:15 PM, Will Deacon wrote: > > On Thu, Apr 20, 2017 at 02:56:50PM +0530, Ganapatrao Kulkarni wrote: > >> On Thu, Apr 20, 2017 at 2:19 PM, Mark Rutland wrote: > >> > On Wed, Apr 19, 2017 at 11:14:06PM

[PATCH] net/packet: check length in getsockopt() called with PACKET_HDRLEN

In the case getsockopt() is called with PACKET_HDRLEN and optlen < 4 |val| remains uninitialized and the syscall may behave differently depending on its value, and even copy garbage to userspace on certain architectures. To fix this we now return -EINVAL if optlen is too small. This bug has been

[PATCH] net/packet: check length in getsockopt() called with PACKET_HDRLEN

In the case getsockopt() is called with PACKET_HDRLEN and optlen < 4 |val| remains uninitialized and the syscall may behave differently depending on its value, and even copy garbage to userspace on certain architectures. To fix this we now return -EINVAL if optlen is too small. This bug has been

Re: [PATCH] scsi: fcoe: make fcoe_e_d_tov and fcoe_r_a_tov static

Colin, > These module parameter variables don't need global scope, make them > static Applied to 4.12/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] scsi: fcoe: make fcoe_e_d_tov and fcoe_r_a_tov static

Colin, > These module parameter variables don't need global scope, make them > static Applied to 4.12/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering

Re: Applied "ASoC: Add support for Maxim Integrated MAX98927 Amplifier" to the asoc tree

' On Thu, Apr 6, 2017 at 11:55 AM, Mark Brown wrote: > The patch > >ASoC: Add support for Maxim Integrated MAX98927 Amplifier > > has been applied to the asoc tree at > >git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git > > All being well this means that

Re: Applied "ASoC: Add support for Maxim Integrated MAX98927 Amplifier" to the asoc tree

' On Thu, Apr 6, 2017 at 11:55 AM, Mark Brown wrote: > The patch > >ASoC: Add support for Maxim Integrated MAX98927 Amplifier > > has been applied to the asoc tree at > >git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git > > All being well this means that it will be

Re: support autofocus / autogain in libv4l2

Le mardi 25 avril 2017 à 10:08 +0200, Pali Rohár a écrit : > On Tuesday 25 April 2017 10:05:38 Pavel Machek wrote: > > > > It would be nice if more than one application could be > > > > accessing the > > > > camera at the same time... (I.e. something graphical running > > > > preview > > > > then

Re: support autofocus / autogain in libv4l2

Le mardi 25 avril 2017 à 10:08 +0200, Pali Rohár a écrit : > On Tuesday 25 April 2017 10:05:38 Pavel Machek wrote: > > > > It would be nice if more than one application could be > > > > accessing the > > > > camera at the same time... (I.e. something graphical running > > > > preview > > > > then

typec: tcpm/tcpci drivers acceptable for drivers/staging in v4.12 ?

Hi Greg, would you be open to accepting the tcpm [1] and tcpci [2] drivers into drivers/staging for v4.12 ? The drivers are not ready for prime time, yet there is interest by others to have them available and to help improving the code. I could create a repository/branch at github to enable

typec: tcpm/tcpci drivers acceptable for drivers/staging in v4.12 ?

Hi Greg, would you be open to accepting the tcpm [1] and tcpci [2] drivers into drivers/staging for v4.12 ? The drivers are not ready for prime time, yet there is interest by others to have them available and to help improving the code. I could create a repository/branch at github to enable

Re: [PATCH v2] x86, msr: Document AMD "tweak MSRs", use MSR_FnnH_NAME scheme for them

On 04/25/2017 06:23 PM, Borislav Petkov wrote: On Tue, Apr 25, 2017 at 06:15:23PM +0200, Denys Vlasenko wrote: On 04/25/2017 06:06 PM, Borislav Petkov wrote: Pls no. Not every MSR for every family. Only the 4 which are actually being used. We can't hold in here the full 32-bit MSR space. The

Re: [PATCH v2] x86, msr: Document AMD "tweak MSRs", use MSR_FnnH_NAME scheme for them

On 04/25/2017 06:23 PM, Borislav Petkov wrote: On Tue, Apr 25, 2017 at 06:15:23PM +0200, Denys Vlasenko wrote: On 04/25/2017 06:06 PM, Borislav Petkov wrote: Pls no. Not every MSR for every family. Only the 4 which are actually being used. We can't hold in here the full 32-bit MSR space. The

Re: [PATCH] ARM: dts: Add devicetree for the Raspberry Pi 3, for arm32 (v5)

Stefan Wahren writes: > Am 24.04.2017 um 22:00 schrieb Eric Anholt: >> Raspbian and Fedora have decided to support the Pi3 in 32-bit mode for >> now, so it's useful to be able to test that mode on an upstream >> kernel. It's also been useful for me to use the same board

Re: [PATCH] ARM: dts: Add devicetree for the Raspberry Pi 3, for arm32 (v5)

Stefan Wahren writes: > Am 24.04.2017 um 22:00 schrieb Eric Anholt: >> Raspbian and Fedora have decided to support the Pi3 in 32-bit mode for >> now, so it's useful to be able to test that mode on an upstream >> kernel. It's also been useful for me to use the same board for 32-bit >> and 64-bit

[PATCH] ARM: dts: Add devicetree for the Raspberry Pi 3, for arm32 (v6)

Raspbian and Fedora have decided to support the Pi3 in 32-bit mode for now, so it's useful to be able to test that mode on an upstream kernel. It's also been useful for me to use the same board for 32-bit and 64-bit development. Signed-off-by: Eric Anholt ---

[PATCH] ARM: dts: Add devicetree for the Raspberry Pi 3, for arm32 (v6)

Raspbian and Fedora have decided to support the Pi3 in 32-bit mode for now, so it's useful to be able to test that mode on an upstream kernel. It's also been useful for me to use the same board for 32-bit and 64-bit development. Signed-off-by: Eric Anholt --- arch/arm/boot/dts/Makefile

Re: [PATCH v2 2/2] of: Add unit tests for applying overlays

On Mon, Apr 24, 2017 at 6:05 PM, wrote: > From: Frank Rowand > > Existing overlay unit tests examine individual pieces of the overlay > code. The new tests target the entire process of applying an overlay. Just a few nits. > Signed-off-by: Frank

Re: [PATCH v2 2/2] of: Add unit tests for applying overlays

On Mon, Apr 24, 2017 at 6:05 PM, wrote: > From: Frank Rowand > > Existing overlay unit tests examine individual pieces of the overlay > code. The new tests target the entire process of applying an overlay. Just a few nits. > Signed-off-by: Frank Rowand [...] > diff --git

Re: get_zone_device_page() in get_page() and page_cache_get_speculative()

On Tue, Apr 25, 2017 at 6:19 AM, Kirill A. Shutemov wrote: > On Mon, Apr 24, 2017 at 11:41:51AM -0700, Dan Williams wrote: >> On Mon, Apr 24, 2017 at 11:25 AM, Kirill A. Shutemov >> wrote: >> > On Mon, Apr 24, 2017 at 09:01:58PM

Re: [PATCH] x86/mm/64: Fix crash in remove_pagetable()

On Tue, Apr 25, 2017 at 2:25 AM, Kirill A. Shutemov wrote: > remove_pagetable() does page walk using p*d_page_vaddr() plus cast. > It's not canonical approach -- we usually use p*d_offset() for that. > > It works fine as long as all page table levels are present.

<    3   4   5   6   7   8   9   10   11   12   >