Re: Help with trace-cmd/ftrace recording process ID information

On Mon, Jul 17, 2017 at 4:17 PM, Steven Rostedt wrote: > On Mon, 17 Jul 2017 16:06:37 -0400 > Will Hawkins wrote: > > >> This seems to be the problem: >> >> On the "good" system, that file is up-to-date with cached PIDs and >> comms. On the bad host,

Re: Help with trace-cmd/ftrace recording process ID information

On Mon, Jul 17, 2017 at 4:17 PM, Steven Rostedt wrote: > On Mon, 17 Jul 2017 16:06:37 -0400 > Will Hawkins wrote: > > >> This seems to be the problem: >> >> On the "good" system, that file is up-to-date with cached PIDs and >> comms. On the bad host, there are no cached entries from any of the

Re: [PATCH 3/7] phy: qcom-qmp: Fix phy pipe clock name

On Mon 17 Jul 05:03 PDT 2017, Varadarajan Narayanan wrote: > Presently, the phy pipe clock's name is assumed to be either > usb3_phy_pipe_clk_src or pcie_XX_pipe_clk_src (where XX is the > phy lane's number). However, this will not work if an SoC has > more than one instance of the phy. Hence,

Re: [PATCH 3/7] phy: qcom-qmp: Fix phy pipe clock name

On Mon 17 Jul 05:03 PDT 2017, Varadarajan Narayanan wrote: > Presently, the phy pipe clock's name is assumed to be either > usb3_phy_pipe_clk_src or pcie_XX_pipe_clk_src (where XX is the > phy lane's number). However, this will not work if an SoC has > more than one instance of the phy. Hence,

[RFC PATCH 3/3] mm: shm: Use new hugetlb size encoding definitions

Use the common definitions from hugetlb_encode.h header file for encoding hugetlb size definitions in shmget system call flags. In addition, move these definitions to the from the internal to user (uapi) header file. Suggested-by: Matthew Wilcox Signed-off-by: Mike Kravetz

[RFC PATCH 2/3] mm: arch: Use new hugetlb size encoding definitions

Use the common definitions from hugetlb_encode.h header file for encoding hugetlb size definitions in mmap system call flags. Signed-off-by: Mike Kravetz --- arch/alpha/include/uapi/asm/mman.h | 14 ++ arch/mips/include/uapi/asm/mman.h | 14

[RFC PATCH 2/3] mm: arch: Use new hugetlb size encoding definitions

Use the common definitions from hugetlb_encode.h header file for encoding hugetlb size definitions in mmap system call flags. Signed-off-by: Mike Kravetz --- arch/alpha/include/uapi/asm/mman.h | 14 ++ arch/mips/include/uapi/asm/mman.h | 14 ++

[RFC PATCH 3/3] mm: shm: Use new hugetlb size encoding definitions

Use the common definitions from hugetlb_encode.h header file for encoding hugetlb size definitions in shmget system call flags. In addition, move these definitions to the from the internal to user (uapi) header file. Suggested-by: Matthew Wilcox Signed-off-by: Mike Kravetz ---

Re: [PATCH] mm,hugetlb: compute page_size_log properly

I hate to resurrect this thread, but I would like to add hugetlb support to memfd_create. This is for JVM garbage collection as discussed in this thread [1]. Adding hugetlb support to memfd_create, means that memfd_create will take a flag something like MFD_HUGETLB. And, if a user wants hugetlb

Re: [PATCH] mm,hugetlb: compute page_size_log properly

I hate to resurrect this thread, but I would like to add hugetlb support to memfd_create. This is for JVM garbage collection as discussed in this thread [1]. Adding hugetlb support to memfd_create, means that memfd_create will take a flag something like MFD_HUGETLB. And, if a user wants hugetlb

[RFC PATCH 1/3] mm:hugetlb: Define system call hugetlb size encodings in single file

If hugetlb pages are requested in mmap or shmget system calls, a huge page size other than default can be requested. This is accomplished by encoding the log2 of the huge page size in the upper bits of the flag argument. asm-generic and arch specific headers all define the same values for these

[RFC PATCH 1/3] mm:hugetlb: Define system call hugetlb size encodings in single file

If hugetlb pages are requested in mmap or shmget system calls, a huge page size other than default can be requested. This is accomplished by encoding the log2 of the huge page size in the upper bits of the flag argument. asm-generic and arch specific headers all define the same values for these

[PATCH] exec: Check stack space more strictly

We can currently blow past the stack rlimit and cause odd behavior if there are accounting bugs, rounding issues, or races. It's not clear that the odd behavior is actually a problem, but it's nicer to fail the exec instead of getting out of sync with stack limits. Improve the code to more

[PATCH] exec: Check stack space more strictly

We can currently blow past the stack rlimit and cause odd behavior if there are accounting bugs, rounding issues, or races. It's not clear that the odd behavior is actually a problem, but it's nicer to fail the exec instead of getting out of sync with stack limits. Improve the code to more

Re: [RFC 11/13] gpio-switch is for some reason neccessary for camera to work.

Hi Pavel, On Tue, Feb 14, 2017 at 02:40:19PM +0100, Pavel Machek wrote: > Probably something fun happening in userspace. What's the status of this one? I don't think it has a chance to be merged in the foreseeable future. Why is it needed? > --- > arch/arm/mach-omap2/Makefile

Re: [RFC 11/13] gpio-switch is for some reason neccessary for camera to work.

Hi Pavel, On Tue, Feb 14, 2017 at 02:40:19PM +0100, Pavel Machek wrote: > Probably something fun happening in userspace. What's the status of this one? I don't think it has a chance to be merged in the foreseeable future. Why is it needed? > --- > arch/arm/mach-omap2/Makefile

[RFC 2/4] perf script python: Refactor creation of perf sample dict

Move the creation of the dict containing perf_sample entries into a helper function to enable its reuse in other sample processing routines. Signed-off-by: Arun Kalyanasundaram --- .../util/scripting-engines/trace-event-python.c| 94 -- 1 file

[RFC 2/4] perf script python: Refactor creation of perf sample dict

Move the creation of the dict containing perf_sample entries into a helper function to enable its reuse in other sample processing routines. Signed-off-by: Arun Kalyanasundaram --- .../util/scripting-engines/trace-event-python.c| 94 -- 1 file changed, 53 insertions(+),

[RFC 3/4] perf script python: Add perf_sample dict to tracepoint handlers

The process_event python hook receives a dict with all perf_sample entries, but the tracepoint specific and trace_unhandled hooks predate the introduction of this dict, and do not receive it. Add the aforementioned dict as an additional argument to the affected handlers. To keep backwards

[RFC 3/4] perf script python: Add perf_sample dict to tracepoint handlers

The process_event python hook receives a dict with all perf_sample entries, but the tracepoint specific and trace_unhandled hooks predate the introduction of this dict, and do not receive it. Add the aforementioned dict as an additional argument to the affected handlers. To keep backwards

[RFC 1/4] perf script python: Allocate memory only if handler exists

Avoid allocating memory if hook handler is not available. This saves unused memory allocation and simplifies error path. Let handler in python_process_tracepoint point to either tracepoint specific or trace_unhandled hook. Use dict to check if handler points to trace_unhandled. Remove the exit

[RFC 1/4] perf script python: Allocate memory only if handler exists

Avoid allocating memory if hook handler is not available. This saves unused memory allocation and simplifies error path. Let handler in python_process_tracepoint point to either tracepoint specific or trace_unhandled hook. Use dict to check if handler points to trace_unhandled. Remove the exit

[PATCH v3] PM / suspend: Export pm_suspend_target_state

Have the core suspend/resume framework store the system-wide suspend state (suspend_state_t) we are about to enter, and expose it to drivers via pm_suspend_target_state in order to retrieve that. The state is assigned in suspend_devices_and_enter(). This is useful for platform specific drivers

[PATCH v3] PM / suspend: Export pm_suspend_target_state

Have the core suspend/resume framework store the system-wide suspend state (suspend_state_t) we are about to enter, and expose it to drivers via pm_suspend_target_state in order to retrieve that. The state is assigned in suspend_devices_and_enter(). This is useful for platform specific drivers

[RFC 4/4] perf script python: Generate hooks with additional argument

Modify the signature of tracepoint specific and trace_unhandled hooks to add the perf_sample dict as a new argument. Create a python helper function to print a dictionary. Signed-off-by: Arun Kalyanasundaram --- .../perf/util/scripting-engines/trace-event-python.c | 20

[RFC 0/4] perf script python: Provide perf_sample dict to all handlers

The process_event python hook receives a dict with all perf_sample entries. Other handlers (e.g. trace_unhandled, python_process_tracepoint) predate the introduction of this dict and do not receive it. This patch series adds the dict to all handlers, aiming to unify the information passed to

[RFC 4/4] perf script python: Generate hooks with additional argument

Modify the signature of tracepoint specific and trace_unhandled hooks to add the perf_sample dict as a new argument. Create a python helper function to print a dictionary. Signed-off-by: Arun Kalyanasundaram --- .../perf/util/scripting-engines/trace-event-python.c | 20 +--- 1

[RFC 0/4] perf script python: Provide perf_sample dict to all handlers

The process_event python hook receives a dict with all perf_sample entries. Other handlers (e.g. trace_unhandled, python_process_tracepoint) predate the introduction of this dict and do not receive it. This patch series adds the dict to all handlers, aiming to unify the information passed to

[PATCH 0/3] enable ghes_edac on selected platforms

The ghes_edac driver was introduced in 2013 [1], but it has not been enabled by any distro yet. This is because the driver obtains error info from firmware interfaces, which are not properly implemented on many platforms. To get out from this situation, add a platform check to selectively enable

[PATCH 0/3] enable ghes_edac on selected platforms

The ghes_edac driver was introduced in 2013 [1], but it has not been enabled by any distro yet. This is because the driver obtains error info from firmware interfaces, which are not properly implemented on many platforms. To get out from this situation, add a platform check to selectively enable

[PATCH 2/3] intel_pstate: convert to use acpi_match_oemlist()

Convert to use acpi_match_oemlist() for the platform type check. There is no change in functionality. Signed-off-by: Toshi Kani Cc: "Rafael J. Wysocki" Cc: Srinivas Pandruvada Cc: Len Brown Cc:

[PATCH 2/3] intel_pstate: convert to use acpi_match_oemlist()

Convert to use acpi_match_oemlist() for the platform type check. There is no change in functionality. Signed-off-by: Toshi Kani Cc: "Rafael J. Wysocki" Cc: Srinivas Pandruvada Cc: Len Brown Cc: Borislav Petkov Cc: Thomas Gleixner --- drivers/cpufreq/intel_pstate.c | 64

[PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

The ghes_edac driver was introduced in 2013 [1], but it has not been enabled by any distro yet. This driver obtains error info from firmware interfaces, which are not properly implemented on many platforms, as the driver always emits the messages below: This EDAC driver relies on BIOS to

[PATCH 1/3] ACPI / blacklist: add acpi_match_oemlist() interface

ACPI OEM ID / OEM Table ID / Revision can be used to identify platform type based on ACPI firmware. acpi_blacklisted(), intel_pstate_platform_pwr_mgmt_exists() and some other funcs have been using this type of check to detect a list of platforms that require special handlings. Move the platform

[PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

The ghes_edac driver was introduced in 2013 [1], but it has not been enabled by any distro yet. This driver obtains error info from firmware interfaces, which are not properly implemented on many platforms, as the driver always emits the messages below: This EDAC driver relies on BIOS to

[PATCH 1/3] ACPI / blacklist: add acpi_match_oemlist() interface

ACPI OEM ID / OEM Table ID / Revision can be used to identify platform type based on ACPI firmware. acpi_blacklisted(), intel_pstate_platform_pwr_mgmt_exists() and some other funcs have been using this type of check to detect a list of platforms that require special handlings. Move the platform

Re: [PATCH 7/7] PCI: dwc: qcom: Add support for IPQ8074 PCIe controller

On Mon 17 Jul 05:04 PDT 2017, Varadarajan Narayanan wrote: > Add support for the IPQ8074 PCIe controller. IPQ8074 supports > Gen 1/2, one lane, two PCIe root complex with support for MSI and > legacy interrupts, and it conforms to PCI Express Base 2.1 > specification. > > The core init is the

Re: [PATCH 7/7] PCI: dwc: qcom: Add support for IPQ8074 PCIe controller

On Mon 17 Jul 05:04 PDT 2017, Varadarajan Narayanan wrote: > Add support for the IPQ8074 PCIe controller. IPQ8074 supports > Gen 1/2, one lane, two PCIe root complex with support for MSI and > legacy interrupts, and it conforms to PCI Express Base 2.1 > specification. > > The core init is the

Re: [patch 0/3] Re: tty contention resulting from tty_open_by_device export

> Sure. I can fix the tty->count mismatch based on Alan's suggestion. However I > don't understand why the exclusivity flag should belong to tty_port and not > tty_struct. It will be good to know why. We are trying to move all the flags that we can and structs into the tty_port, except any

[PATCH v2 RESEND] dt-bindings: chosen: document kaslr-seed property

Document the /chosen/kaslr-seed property (and its interaction with the EFI_RNG_PROTOCOL API). Thanks to Ard for clarifications. Signed-off-by: Kees Cook Acked-by: Ard Biesheuvel Acked-by: Mark Rutland Acked-by: Will Deacon

Re: [patch 0/3] Re: tty contention resulting from tty_open_by_device export

> Sure. I can fix the tty->count mismatch based on Alan's suggestion. However I > don't understand why the exclusivity flag should belong to tty_port and not > tty_struct. It will be good to know why. We are trying to move all the flags that we can and structs into the tty_port, except any

[PATCH v2 RESEND] dt-bindings: chosen: document kaslr-seed property

Document the /chosen/kaslr-seed property (and its interaction with the EFI_RNG_PROTOCOL API). Thanks to Ard for clarifications. Signed-off-by: Kees Cook Acked-by: Ard Biesheuvel Acked-by: Mark Rutland Acked-by: Will Deacon --- v2: - improved the language a bit based on Ard's notes - added

[PATCH v2] timers: Don't wake ktimersoftd on every tick

We recently upgraded from 4.1 to 4.6 and noticed a minor latency regression caused by an additional thread wakeup (ktimersoftd) in interrupt context on every tick. The wakeups are from run_local_timers() raising TIMER_SOFTIRQ. Both TIMER and SCHED softirq coalesced into one ksoftirqd wakeup prior

[PATCH v2] timers: Don't wake ktimersoftd on every tick

We recently upgraded from 4.1 to 4.6 and noticed a minor latency regression caused by an additional thread wakeup (ktimersoftd) in interrupt context on every tick. The wakeups are from run_local_timers() raising TIMER_SOFTIRQ. Both TIMER and SCHED softirq coalesced into one ksoftirqd wakeup prior

Re: [PATCH] Revert "timers: Don't wake ktimersoftd on every tick"

On 06/04/2017 09:17 AM, Thomas Gleixner wrote: On Fri, 2 Jun 2017, Haris Okanovic wrote: On 05/26/2017 03:50 PM, Thomas Gleixner wrote: static void expire_timers(struct timer_base *base) { struct hlist_head *head; + int expCount = base->expired_count; No camel case for

Re: [PATCH] Revert "timers: Don't wake ktimersoftd on every tick"

On 06/04/2017 09:17 AM, Thomas Gleixner wrote: On Fri, 2 Jun 2017, Haris Okanovic wrote: On 05/26/2017 03:50 PM, Thomas Gleixner wrote: static void expire_timers(struct timer_base *base) { struct hlist_head *head; + int expCount = base->expired_count; No camel case for

Re: [PATCH v2 0/6] Better document Sphinx install instructions

Em Mon, 17 Jul 2017 15:26:33 -0600 Jonathan Corbet escreveu: > On Mon, 17 Jul 2017 18:23:05 -0300 > Mauro Carvalho Chehab wrote: > > > Btw, I'm submitting in a few a second version of the patches with > > add a script to check Sphinx dependencies. >

Re: [PATCH v2 0/6] Better document Sphinx install instructions

Em Mon, 17 Jul 2017 15:26:33 -0600 Jonathan Corbet escreveu: > On Mon, 17 Jul 2017 18:23:05 -0300 > Mauro Carvalho Chehab wrote: > > > Btw, I'm submitting in a few a second version of the patches with > > add a script to check Sphinx dependencies. > > I figured I wasn't going to look at

Re: [rfc] superblock shrinker accumulating excessive deferred counts

On Mon, Jul 17, 2017 at 01:37:35PM -0700, David Rientjes wrote: > On Mon, 17 Jul 2017, Dave Chinner wrote: > > > > This is a side effect of super_cache_count() returning the appropriate > > > count but super_cache_scan() refusing to do anything about it and > > > immediately terminating with

Re: [rfc] superblock shrinker accumulating excessive deferred counts

On Mon, Jul 17, 2017 at 01:37:35PM -0700, David Rientjes wrote: > On Mon, 17 Jul 2017, Dave Chinner wrote: > > > > This is a side effect of super_cache_count() returning the appropriate > > > count but super_cache_scan() refusing to do anything about it and > > > immediately terminating with

[PATCH v2 3/8] sphinx-pre-install: detect an existing virtualenv

Detect if the script runs after creating the virtualenv, printing the command line commands to enable the virtualenv. Signed-off-by: Mauro Carvalho Chehab --- scripts/sphinx-pre-install | 26 +- 1 file changed, 17 insertions(+), 9 deletions(-)

[PATCH v2 0/8] Add a script to check for Sphinx install requirements

Sphinx installation is not trivial, as not all versions are supported, and it requires a lot of stuff for math, images and PDF/LaTeX output to work. So, add a script that checks if everything is fine, providing distro-specific hints about what's needed for it to work. I posted already RFC

[PATCH v2 3/8] sphinx-pre-install: detect an existing virtualenv

Detect if the script runs after creating the virtualenv, printing the command line commands to enable the virtualenv. Signed-off-by: Mauro Carvalho Chehab --- scripts/sphinx-pre-install | 26 +- 1 file changed, 17 insertions(+), 9 deletions(-) diff --git

[PATCH v2 0/8] Add a script to check for Sphinx install requirements

Sphinx installation is not trivial, as not all versions are supported, and it requires a lot of stuff for math, images and PDF/LaTeX output to work. So, add a script that checks if everything is fine, providing distro-specific hints about what's needed for it to work. I posted already RFC

[PATCH v2 2/8] scripts/sphinx-pre-install: add a script to check Sphinx install

Solving Sphinx dependencies can be painful. Add a script to check if everything is ok. Tested on: - Fedora 25 and 26; - Ubuntu 17.04; - OpenSuse Tumbleweed; - Arch Linux; - Gentoo. Signed-off-by: Mauro Carvalho Chehab ---

[PATCH v2 2/8] scripts/sphinx-pre-install: add a script to check Sphinx install

Solving Sphinx dependencies can be painful. Add a script to check if everything is ok. Tested on: - Fedora 25 and 26; - Ubuntu 17.04; - OpenSuse Tumbleweed; - Arch Linux; - Gentoo. Signed-off-by: Mauro Carvalho Chehab --- scripts/sphinx-pre-install | 517

[PATCH v2 7/8] sphinx-pre-install: fix USE needs for GraphViz and ImageMagick

Gentoo need some USE for GraphViz and ImageMagick to have the features required by kfigure.py. Output that when providing instructions for Gentoo. Signed-off-by: Mauro Carvalho Chehab --- scripts/sphinx-pre-install | 7 ++- 1 file changed, 6 insertions(+), 1

[PATCH v2 7/8] sphinx-pre-install: fix USE needs for GraphViz and ImageMagick

Gentoo need some USE for GraphViz and ImageMagick to have the features required by kfigure.py. Output that when providing instructions for Gentoo. Signed-off-by: Mauro Carvalho Chehab --- scripts/sphinx-pre-install | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git

[PATCH v2 4/8] sphinx-pre-install: use a requirements file

Instead of using 3 commands to install a virtualenv, use a single one, reading the requirements from this file: Documentation/sphinx/requirements.txt Signed-off-by: Mauro Carvalho Chehab --- Documentation/sphinx/requirements.txt | 3 +++

[PATCH v2 4/8] sphinx-pre-install: use a requirements file

Instead of using 3 commands to install a virtualenv, use a single one, reading the requirements from this file: Documentation/sphinx/requirements.txt Signed-off-by: Mauro Carvalho Chehab --- Documentation/sphinx/requirements.txt | 3 +++ scripts/sphinx-pre-install| 5 ++---

[PATCH v2 5/8] sphinx-pre-install: check for the need of graphviz-gd

On newer versions of graphviz packaging on Fedora, it is needed to install a separate package for PDF support. Signed-off-by: Mauro Carvalho Chehab --- scripts/sphinx-pre-install | 9 + 1 file changed, 9 insertions(+) diff --git a/scripts/sphinx-pre-install

[PATCH v2 5/8] sphinx-pre-install: check for the need of graphviz-gd

On newer versions of graphviz packaging on Fedora, it is needed to install a separate package for PDF support. Signed-off-by: Mauro Carvalho Chehab --- scripts/sphinx-pre-install | 9 + 1 file changed, 9 insertions(+) diff --git a/scripts/sphinx-pre-install b/scripts/sphinx-pre-install

[PATCH v2 6/8] sphinx-pre-install: add dependencies for ImageMagick to work with svg

ImageMagick actually uses librsvg for conversions when converiting from SVG (actually, it uses rsvg-convert). That causes the build to fail with: WARNING: Error #1 when calling: /usr/bin/convert /home/mchehab/docs/Documentation/media/uapi/v4l/selection.svg

[PATCH v2 6/8] sphinx-pre-install: add dependencies for ImageMagick to work with svg

ImageMagick actually uses librsvg for conversions when converiting from SVG (actually, it uses rsvg-convert). That causes the build to fail with: WARNING: Error #1 when calling: /usr/bin/convert /home/mchehab/docs/Documentation/media/uapi/v4l/selection.svg

[PATCH v2 8/8] sphinx.rst: document scripts/sphinx-pre-install script

Now that we have a script to check for Sphinx dependencies, document it. Signed-off-by: Mauro Carvalho Chehab --- Documentation/doc-guide/sphinx.rst | 48 ++ 1 file changed, 44 insertions(+), 4 deletions(-) diff --git

[PATCH v2 8/8] sphinx.rst: document scripts/sphinx-pre-install script

Now that we have a script to check for Sphinx dependencies, document it. Signed-off-by: Mauro Carvalho Chehab --- Documentation/doc-guide/sphinx.rst | 48 ++ 1 file changed, 44 insertions(+), 4 deletions(-) diff --git a/Documentation/doc-guide/sphinx.rst

[PATCH v2 1/8] docs: Makefile: remove no-ops targets

After removal of DocBook, those targets are bogus. Reported-by: Jim Davis Signed-off-by: Mauro Carvalho Chehab --- Documentation/Makefile | 10 -- Documentation/translations/zh_CN/HOWTO | 2 -- Makefile

[PATCH v2 1/8] docs: Makefile: remove no-ops targets

After removal of DocBook, those targets are bogus. Reported-by: Jim Davis Signed-off-by: Mauro Carvalho Chehab --- Documentation/Makefile | 10 -- Documentation/translations/zh_CN/HOWTO | 2 -- Makefile | 2 +- 3 files changed, 1

[PATCH v3 2/3] ARM: i.MX25: add RNGC node to dtsi

From: Steffen Trumtrar Add a devicetree entry for the Random Number Generator Version C (RNGC). Signed-off-by: Steffen Trumtrar Signed-off-by: Martin Kaiser --- Changes in v3: - remove clock-names from dtsi Changes in

[PATCH v3 1/3] Documentation: devicetree: add Freescale RNGC binding

From: Steffen Trumtrar Add binding documentation for the Freescale RNGC found on some i.MX2/3 SoCs. Signed-off-by: Steffen Trumtrar Signed-off-by: Martin Kaiser --- Changes in v3: - add compatible string for imx35 -

[PATCH v3 2/3] ARM: i.MX25: add RNGC node to dtsi

From: Steffen Trumtrar Add a devicetree entry for the Random Number Generator Version C (RNGC). Signed-off-by: Steffen Trumtrar Signed-off-by: Martin Kaiser --- Changes in v3: - remove clock-names from dtsi Changes in v2: - remove interrupt-names from dtsi arch/arm/boot/dts/imx25.dtsi

[PATCH v3 1/3] Documentation: devicetree: add Freescale RNGC binding

From: Steffen Trumtrar Add binding documentation for the Freescale RNGC found on some i.MX2/3 SoCs. Signed-off-by: Steffen Trumtrar Signed-off-by: Martin Kaiser --- Changes in v3: - add compatible string for imx35 - remove imx5 from the commit message, I couldn't find an i.MX5 soc

[PATCH 3/3] hwrng: mxc-fsl - add support for Freescale RNGC

From: Steffen Trumtrar The driver is ported from Freescales Linux git and can be found in the vendor/freescale/imx_2.6.35_maintain branch. According to that code, the RNGC is found on Freescales i.MX3/5 SoCs. The i.MX2x actually has an RNGB, which has no

[PATCH 3/3] hwrng: mxc-fsl - add support for Freescale RNGC

From: Steffen Trumtrar The driver is ported from Freescales Linux git and can be found in the vendor/freescale/imx_2.6.35_maintain branch. According to that code, the RNGC is found on Freescales i.MX3/5 SoCs. The i.MX2x actually has an RNGB, which has no driver implementation in

Re: [PATCH 2/2] iio: Documentation: Add ina2xx shunt_resistor attribute documentation

On Montag, 17. Juli 2017 22:53:57 CEST Jonathan Cameron wrote: > On Mon, 17 Jul 2017 01:34:10 +0200 > > Stefan Brüns wrote: > > The ina2xx driver appeared in the Linux kernel version 4.5, but provided > > no documentation. Contrary to other uses of resistance in

Re: [PATCH 2/2] iio: Documentation: Add ina2xx shunt_resistor attribute documentation

On Montag, 17. Juli 2017 22:53:57 CEST Jonathan Cameron wrote: > On Mon, 17 Jul 2017 01:34:10 +0200 > > Stefan Brüns wrote: > > The ina2xx driver appeared in the Linux kernel version 4.5, but provided > > no documentation. Contrary to other uses of resistance in IIO, ina2xx uses > > microohms

Re: [PATCH v2] mm/page_alloc: Wait for oom_lock before retrying.

Michal Hocko wrote: > On Sun 16-07-17 19:59:51, Tetsuo Handa wrote: > > Since the whole memory reclaim path has never been designed to handle the > > scheduling priority inversions, those locations which are assuming that > > execution of some code path shall eventually complete without using > >

Re: [PATCH v2] mm/page_alloc: Wait for oom_lock before retrying.

Michal Hocko wrote: > On Sun 16-07-17 19:59:51, Tetsuo Handa wrote: > > Since the whole memory reclaim path has never been designed to handle the > > scheduling priority inversions, those locations which are assuming that > > execution of some code path shall eventually complete without using > >

RE: [PATCH] staging: unisys: visorbus: constify attribute_group structures.

> -Original Message- > From: Greg KH [mailto:g...@kroah.com] > Sent: Monday, July 17, 2017 8:38 AM > To: Arvind Yadav > Cc: Kershner, David A ; Sell, Timothy C > ; Thompson, Bryan E. >

RE: [PATCH] staging: unisys: visorbus: constify attribute_group structures.

> -Original Message- > From: Greg KH [mailto:g...@kroah.com] > Sent: Monday, July 17, 2017 8:38 AM > To: Arvind Yadav > Cc: Kershner, David A ; Sell, Timothy C > ; Thompson, Bryan E. > ; jon.fri...@unisys.com; Binder, David > Anthony ; *S-Par-Maintainer > ; de...@driverdev.osuosl.org;

Re: [GIT pull] irq updates for 4.13

On Mon 2017-07-17 13:01:58, Linus Torvalds wrote: > On Sat, Jul 15, 2017 at 1:24 PM, Pavel Machek wrote: > > > > But I don't see the commit in 4.13-rc0. Could we get it in now, so > > that problem is fixed in -rc1? > > It didn't hit rc1, but it's in my tree now. Thanks for

Re: [GIT pull] irq updates for 4.13

On Mon 2017-07-17 13:01:58, Linus Torvalds wrote: > On Sat, Jul 15, 2017 at 1:24 PM, Pavel Machek wrote: > > > > But I don't see the commit in 4.13-rc0. Could we get it in now, so > > that problem is fixed in -rc1? > > It didn't hit rc1, but it's in my tree now. Thanks for head-up. Yes, current

Re: [PATCH v2] KVM: x86: Avoid guest page table walk when gpa_available is set

Hi Paolo and Radim Any comments on this patch, I could not find it in 4.13-2 branch. Please let me know if you want to fix something, or want me to refresh and resend the patch. - Brijesh On 05/19/2017 10:12 AM, Brijesh Singh wrote: From: Brijesh Singh On AMD

Re: [PATCH v2] KVM: x86: Avoid guest page table walk when gpa_available is set

Hi Paolo and Radim Any comments on this patch, I could not find it in 4.13-2 branch. Please let me know if you want to fix something, or want me to refresh and resend the patch. - Brijesh On 05/19/2017 10:12 AM, Brijesh Singh wrote: From: Brijesh Singh On AMD hardware when a guest causes a

Re: [PATCH v2 2/2] staging: atomisp2: hmm: Alignment code (rebased)

On Thu, Jul 13, 2017 at 09:26:50PM +0200, Philipp wrote: > > > On 13. Jul 2017, at 17:45, Sakari Ailus wrote: > > > > On Thu, Jul 13, 2017 at 08:55:43AM +0200, Philipp Guendisch wrote: > >> This patch fixed code alignment to open paranthesis. > >> Semantic should not be

Re: [PATCH v2 2/2] staging: atomisp2: hmm: Alignment code (rebased)

On Thu, Jul 13, 2017 at 09:26:50PM +0200, Philipp wrote: > > > On 13. Jul 2017, at 17:45, Sakari Ailus wrote: > > > > On Thu, Jul 13, 2017 at 08:55:43AM +0200, Philipp Guendisch wrote: > >> This patch fixed code alignment to open paranthesis. > >> Semantic should not be affected by this patch.

[PATCH v3 2/5] dt-bindings: pwm-backlight: add PWM delay proprieties.

Hardware needs a delay between setting an initial (non-zero) PWM and enabling the backlight using GPIO. The post-pwm-on-delay-us specifies this delay in micro seconds. Hardware also needs a delay between disabing the backlight using GPIO and setting PWM value to 0. The pwm-off-delay-us is this

[PATCH v3 5/5] ARM: dts: rockchip: set PWM delay backlight settings for Minnie

The minnie devices comes with an AUO B101EAN01 panel which is different from default veyron devices, thus the power on/off timing sequence is slightly different. The datasheet specifies a pwm delay of 200 ms, so update the PMW delay proprieties accordingly. Signed-off-by: Enric Balletbo i Serra

[PATCH v3 2/5] dt-bindings: pwm-backlight: add PWM delay proprieties.

Hardware needs a delay between setting an initial (non-zero) PWM and enabling the backlight using GPIO. The post-pwm-on-delay-us specifies this delay in micro seconds. Hardware also needs a delay between disabing the backlight using GPIO and setting PWM value to 0. The pwm-off-delay-us is this

[PATCH v3 5/5] ARM: dts: rockchip: set PWM delay backlight settings for Minnie

The minnie devices comes with an AUO B101EAN01 panel which is different from default veyron devices, thus the power on/off timing sequence is slightly different. The datasheet specifies a pwm delay of 200 ms, so update the PMW delay proprieties accordingly. Signed-off-by: Enric Balletbo i Serra

[PATCH v3 1/5] pwm-backlight: enable/disable the PWM before/after LCD enable toggle.

Before this patch the enable signal was set before the PWM signal and vice-versa on power off. I guess that this sequence is wrong, at least, it is on the different panels datasheets that I checked, so I inverted the sequence to follow the specs. Signed-off-by: Enric Balletbo i Serra

[PATCH v3 1/5] pwm-backlight: enable/disable the PWM before/after LCD enable toggle.

Before this patch the enable signal was set before the PWM signal and vice-versa on power off. I guess that this sequence is wrong, at least, it is on the different panels datasheets that I checked, so I inverted the sequence to follow the specs. Signed-off-by: Enric Balletbo i Serra --- Changes

[PATCH v10 03/38] x86, mpparse, x86/acpi, x86/PCI, x86/dmi, SFI: Use memremap for RAM mappings

The ioremap() function is intended for mapping MMIO. For RAM, the memremap() function should be used. Convert calls from ioremap() to memremap() when re-mapping RAM. This will be used later by SME to control how the encryption mask is applied to memory mappings, with certain memory locations

[PATCH v10 03/38] x86, mpparse, x86/acpi, x86/PCI, x86/dmi, SFI: Use memremap for RAM mappings

The ioremap() function is intended for mapping MMIO. For RAM, the memremap() function should be used. Convert calls from ioremap() to memremap() when re-mapping RAM. This will be used later by SME to control how the encryption mask is applied to memory mappings, with certain memory locations

[PATCH v3 4/5] ARM: dts: rockchip: set PWM delay backlight settings for Veyron.

For veyron the binding should provide both PWM timings, the delay between you enable the PWM and set the enable signal, and the delay between you disable the PWM signal and clear the enable signal. Update the binding accordingly, in this case the panels connected to the veyron boards have a

[PATCH v10 07/38] x86/mm: Remove phys_to_virt() usage in ioremap()

Currently there is a check if the address being mapped is in the ISA range (is_ISA_range()), and if it is, then phys_to_virt() is used to perform the mapping. When SME is active, the default is to add pagetable mappings with the encryption bit set unless specifically overridden. The resulting

[PATCH v3 4/5] ARM: dts: rockchip: set PWM delay backlight settings for Veyron.

For veyron the binding should provide both PWM timings, the delay between you enable the PWM and set the enable signal, and the delay between you disable the PWM signal and clear the enable signal. Update the binding accordingly, in this case the panels connected to the veyron boards have a

[PATCH v10 07/38] x86/mm: Remove phys_to_virt() usage in ioremap()

Currently there is a check if the address being mapped is in the ISA range (is_ISA_range()), and if it is, then phys_to_virt() is used to perform the mapping. When SME is active, the default is to add pagetable mappings with the encryption bit set unless specifically overridden. The resulting

[PATCH v3 3/5] pwm-backlight: add support for PWM delays proprieties.

Some panels (i.e. N116BGE-L41), in their power sequence specifications, request a delay between set the PWM signal and enable the backlight and between clear the PWM signal and disable the backlight. Add support for the new post-pwm-on-delay-us and pwm-off-delay-us proprieties to meet the timings.

[PATCH v3 3/5] pwm-backlight: add support for PWM delays proprieties.

Some panels (i.e. N116BGE-L41), in their power sequence specifications, request a delay between set the PWM signal and enable the backlight and between clear the PWM signal and disable the backlight. Add support for the new post-pwm-on-delay-us and pwm-off-delay-us proprieties to meet the timings.

<    1   2   3   4   5   6   7   8   9   10   >