[PATCH 1/2] arm64: kernel: Add SMC Session ID to results

This patch adds the SMC Session ID to the results passed back from SMC calls. The Qualcomm SMC implementation provides for interrupted SMC functions. When this occurs, the SMC call will return a session ID that is required to be used when resuming the interrupted SMC call. Signed-off-by: Andy

[PATCH 2/2] firmware: qcom: scm: Fix interrupted SCM calls

This patch fixes an issue with the SCM64 calls. Sometimes SCM calls can be interrupted and return early. When this happens, the contents of register 6 will contain a session ID that is required when resuming the SCM call. Signed-off-by: Andy Gross ---

[PATCH 0/2] Qualcomm SMCCC Session ID Support

This set of patches fixes a problem with the recent adoption of the ARM SMCCC in the Qualcomm SCM firmware. Qualcomm actually uses the optional Trusted OS Session ID parameter. When SCM calls are interrupted, the session ID field is populated with a value that must be used when the SCM call is

[PATCH 1/2] arm64: kernel: Add SMC Session ID to results

This patch adds the SMC Session ID to the results passed back from SMC calls. The Qualcomm SMC implementation provides for interrupted SMC functions. When this occurs, the SMC call will return a session ID that is required to be used when resuming the interrupted SMC call. Signed-off-by: Andy

[PATCH 2/2] firmware: qcom: scm: Fix interrupted SCM calls

This patch fixes an issue with the SCM64 calls. Sometimes SCM calls can be interrupted and return early. When this happens, the contents of register 6 will contain a session ID that is required when resuming the SCM call. Signed-off-by: Andy Gross --- drivers/firmware/qcom_scm-64.c | 6 --

[PATCH 0/2] Qualcomm SMCCC Session ID Support

This set of patches fixes a problem with the recent adoption of the ARM SMCCC in the Qualcomm SCM firmware. Qualcomm actually uses the optional Trusted OS Session ID parameter. When SCM calls are interrupted, the session ID field is populated with a value that must be used when the SCM call is

Re: [PATCH net] vmxnet3: fix tx data ring copy for variable size

From: Shrikrishna Khare Date: Fri, 19 Aug 2016 10:33:42 -0700 > 'Commit 3c8b3efc061a ("vmxnet3: allow variable length transmit data ring > buffer")' changed the size of the buffers in the tx data ring from a > fixed size of 128 bytes to a variable size. > > However, while

Re: [PATCH net] vmxnet3: fix tx data ring copy for variable size

From: Shrikrishna Khare Date: Fri, 19 Aug 2016 10:33:42 -0700 > 'Commit 3c8b3efc061a ("vmxnet3: allow variable length transmit data ring > buffer")' changed the size of the buffers in the tx data ring from a > fixed size of 128 bytes to a variable size. > > However, while copying data to the

Re: [PATCH net-next] hv_netvsc: Implement batching of receive completions

From: Haiyang Zhang Date: Fri, 19 Aug 2016 14:47:09 -0700 > From: Haiyang Zhang > > The existing code uses busy retry when unable to send out receive > completions due to full ring buffer. It also gives up retrying after limit > is reached,

Re: [PATCH 2/2] hwrng: thunderx: Add Cavium HWRNG driver for ThunderX SoC.

Hello I have some minor comments below On 20/08/2016 00:32, Omer Khaliq wrote: > The Cavium ThunderX SoC has a hardware random number generator. > This driver provides support using the HWRNG framework. > > Signed-off-by: Omer Khaliq > Signed-off-by: Ananth Jasty

Re: [PATCH net-next] hv_netvsc: Implement batching of receive completions

From: Haiyang Zhang Date: Fri, 19 Aug 2016 14:47:09 -0700 > From: Haiyang Zhang > > The existing code uses busy retry when unable to send out receive > completions due to full ring buffer. It also gives up retrying after limit > is reached, and causes receive buffer slots not being recycled. >

Re: [PATCH 2/2] hwrng: thunderx: Add Cavium HWRNG driver for ThunderX SoC.

Hello I have some minor comments below On 20/08/2016 00:32, Omer Khaliq wrote: > The Cavium ThunderX SoC has a hardware random number generator. > This driver provides support using the HWRNG framework. > > Signed-off-by: Omer Khaliq > Signed-off-by: Ananth Jasty > Acked-by: David Daney >

Re: [PATCH v10 1/2] printk: Make printk() completely async

On (08/19/16 21:00), Jan Kara wrote: > > > depending on .config BUG() may never return back -- passing control > > > to do_exit(), so printk_deferred_exit() won't be executed. thus we > > > probably need to have a per-cpu variable that would indicate that > > > we are in deferred_bug. hm... but do

Re: [PATCH v10 1/2] printk: Make printk() completely async

On (08/19/16 21:00), Jan Kara wrote: > > > depending on .config BUG() may never return back -- passing control > > > to do_exit(), so printk_deferred_exit() won't be executed. thus we > > > probably need to have a per-cpu variable that would indicate that > > > we are in deferred_bug. hm... but do

Re: perf: fuzzer crashes immediately on AMD system

On Fri, 19 Aug 2016, Peter Zijlstra wrote: > On Thu, Aug 18, 2016 at 10:46:31AM -0400, Vince Weaver wrote: > > On Thu, 18 Aug 2016, Vince Weaver wrote: > > > > > Tried the perf_fuzzer on my A10 fam15h/model13h system with 4.8-rc2 and it > > > falls over more or less immediately. > > > > > >

Re: perf: fuzzer crashes immediately on AMD system

On Fri, 19 Aug 2016, Peter Zijlstra wrote: > On Thu, Aug 18, 2016 at 10:46:31AM -0400, Vince Weaver wrote: > > On Thu, 18 Aug 2016, Vince Weaver wrote: > > > > > Tried the perf_fuzzer on my A10 fam15h/model13h system with 4.8-rc2 and it > > > falls over more or less immediately. > > > > > >

[PATCH 0/2] hwrng/PCI/IOV: Add driver for Cavium Thunder RNG

There is a hardware error rendering the FDL field incorrect for the some Thunder RNG devices. The first patch adds infrastructure to fix the problem. The second patch adds the driver. David Daney (1): PCI/IOV: Add function to allow Function Dependency Link override. Omer Khaliq (1):

[PATCH 0/2] hwrng/PCI/IOV: Add driver for Cavium Thunder RNG

There is a hardware error rendering the FDL field incorrect for the some Thunder RNG devices. The first patch adds infrastructure to fix the problem. The second patch adds the driver. David Daney (1): PCI/IOV: Add function to allow Function Dependency Link override. Omer Khaliq (1):

[PATCH] mmc: dw_mmc: return -EILSEQ for EBE and SBE error

The following log we found indicate the fact that dw_mmc didn't treat EBE or SBE as a similar problem as CRC error. -EIO is quite not informative as it may indicate that the device is broken rather than that of tuning stuff. ... [ 89.057226] bcmsdh_sdmmc: Failed to Read byte F1:@0x1001f=ff, Err:

[PATCH] mmc: dw_mmc: return -EILSEQ for EBE and SBE error

The following log we found indicate the fact that dw_mmc didn't treat EBE or SBE as a similar problem as CRC error. -EIO is quite not informative as it may indicate that the device is broken rather than that of tuning stuff. ... [ 89.057226] bcmsdh_sdmmc: Failed to Read byte F1:@0x1001f=ff, Err:

Re: [PATCH 0/6] perf/ftrace: Introduce hexadecimal type casting

On Thu, 18 Aug 2016 13:13:21 -0300 Arnaldo Carvalho de Melo wrote: > Em Fri, Aug 19, 2016 at 01:01:43AM +0900, Masami Hiramatsu escreveu: > > On Thu, 18 Aug 2016 11:14:42 -0300 > > Arnaldo Carvalho de Melo wrote: > > > > > Em Thu, Aug 18, 2016 at 05:57:32PM

Re: [PATCH 0/6] perf/ftrace: Introduce hexadecimal type casting

On Thu, 18 Aug 2016 13:13:21 -0300 Arnaldo Carvalho de Melo wrote: > Em Fri, Aug 19, 2016 at 01:01:43AM +0900, Masami Hiramatsu escreveu: > > On Thu, 18 Aug 2016 11:14:42 -0300 > > Arnaldo Carvalho de Melo wrote: > > > > > Em Thu, Aug 18, 2016 at 05:57:32PM +0900, Masami Hiramatsu escreveu: >

Re: [PATCH] sh: Fix building j2_defconfig

On 08/16/2016 04:23 PM, Jason Cooper wrote: > Hi Rob, > > On Tue, Aug 16, 2016 at 04:15:22PM -0500, Rob Landley wrote: >> On 08/16/2016 10:41 AM, Jason Cooper wrote: >>> When targeting the j2, we need to retain '-m2'. Previously, the >>> Makefile blew out -m2 on the next line via :=. >>> >>> Fix

Re: [PATCH] sh: Fix building j2_defconfig

On 08/16/2016 04:23 PM, Jason Cooper wrote: > Hi Rob, > > On Tue, Aug 16, 2016 at 04:15:22PM -0500, Rob Landley wrote: >> On 08/16/2016 10:41 AM, Jason Cooper wrote: >>> When targeting the j2, we need to retain '-m2'. Previously, the >>> Makefile blew out -m2 on the next line via :=. >>> >>> Fix

Re: [PATCH v2 2/2] mmc: core: fall back host->f_init if failing to init mmc card after resume

Hi Ulf, Any idea to share with this patch? :) On 2016/7/20 9:57, Shawn Lin wrote: We observed the failure of initializing card after resume accidentally. It's hard to reproduce but we did get report from the suspend/resume test of our RK3399 mp test farm . Unfortunately, we still fail to

Re: [PATCH v2 2/2] mmc: core: fall back host->f_init if failing to init mmc card after resume

Hi Ulf, Any idea to share with this patch? :) On 2016/7/20 9:57, Shawn Lin wrote: We observed the failure of initializing card after resume accidentally. It's hard to reproduce but we did get report from the suspend/resume test of our RK3399 mp test farm . Unfortunately, we still fail to

[PATCH v5 2/2] phy: add a driver for the Rockchip SoC internal PCIe PHY

This patch to add a generic PHY driver for rockchip PCIe PHY. Access the PHY via registers provided by GRF (general register files) module. Signed-off-by: Shawn Lin --- Changes in v5: - add COMPILE_TEST and select MFD_SYSCON on Kconfig Changes in v4: - remove laneoff

[PATCH v5 2/2] phy: add a driver for the Rockchip SoC internal PCIe PHY

This patch to add a generic PHY driver for rockchip PCIe PHY. Access the PHY via registers provided by GRF (general register files) module. Signed-off-by: Shawn Lin --- Changes in v5: - add COMPILE_TEST and select MFD_SYSCON on Kconfig Changes in v4: - remove laneoff symbol as we still fail

[PATCH v5 1/2] Documentation: bindings: add dt documentation for Rockchip PCIe PHY

This patch adds a binding that describes the Rockchip PCIe PHY found on Rockchip SoCs PCIe interface. Signed-off-by: Shawn Lin Acked-by: Rob Herring --- Changes in v5: - add Rob's ack tag Changes in v4: None Changes in v3: - rename the node to

[PATCH v5 1/2] Documentation: bindings: add dt documentation for Rockchip PCIe PHY

This patch adds a binding that describes the Rockchip PCIe PHY found on Rockchip SoCs PCIe interface. Signed-off-by: Shawn Lin Acked-by: Rob Herring --- Changes in v5: - add Rob's ack tag Changes in v4: None Changes in v3: - rename the node to pcie_phy: pcie-phy suggested by Doug Changes in

[PATCH] drm/vc4: Don't force new binner overflow allocation per draw.

This came from the initial bringup code, which always idled the GPU and always reset the overflow. That massively increases the size of the working set when you're doing lots of small draws, though, as is common on X desktops or piglit. Signed-off-by: Eric Anholt ---

[PATCH] drm/vc4: Don't force new binner overflow allocation per draw.

This came from the initial bringup code, which always idled the GPU and always reset the overflow. That massively increases the size of the working set when you're doing lots of small draws, though, as is common on X desktops or piglit. Signed-off-by: Eric Anholt ---

Re: [PATCH v10 1/2] Documentation: bindings: add dt doc for Rockchip PCIe controller

在 2016/8/20 3:33, Bjorn Helgaas 写道: On Fri, Aug 19, 2016 at 09:34:31AM +0800, Shawn Lin wrote: This patch adds a binding that describes the Rockchip PCIe controller found on Rockchip SoCs PCIe interface. Signed-off-by: Shawn Lin Acked-by: Rob Herring

Re: [PATCH v10 1/2] Documentation: bindings: add dt doc for Rockchip PCIe controller

在 2016/8/20 3:33, Bjorn Helgaas 写道: On Fri, Aug 19, 2016 at 09:34:31AM +0800, Shawn Lin wrote: This patch adds a binding that describes the Rockchip PCIe controller found on Rockchip SoCs PCIe interface. Signed-off-by: Shawn Lin Acked-by: Rob Herring Reviewed-by: Brian Norris I applied

Re: [PATCH 4/5] driver core: set up ownership of class devices in sysfs

On Tue, 16 Aug 2016 15:33:14 -0700 Dmitry Torokhov wrote: > static struct kobj_type device_ktype = { > .release= device_release, > .sysfs_ops = _sysfs_ops, > .namespace = device_namespace, > + .get_ownership =

Re: [PATCH 4/5] driver core: set up ownership of class devices in sysfs

On Tue, 16 Aug 2016 15:33:14 -0700 Dmitry Torokhov wrote: > static struct kobj_type device_ktype = { > .release= device_release, > .sysfs_ops = _sysfs_ops, > .namespace = device_namespace, > + .get_ownership = device_get_ownership, > }; > OT - I

RE: Observing Softlockup's while running heavy IOs

> -Original Message- > From: Sreekanth Reddy [mailto:sreekanth.re...@broadcom.com] > Sent: Friday, August 19, 2016 6:45 AM > To: Elliott, Robert (Persistent Memory) > Subject: Re: Observing Softlockup's while running heavy IOs > ... > Yes I am also observing that all

RE: Observing Softlockup's while running heavy IOs

> -Original Message- > From: Sreekanth Reddy [mailto:sreekanth.re...@broadcom.com] > Sent: Friday, August 19, 2016 6:45 AM > To: Elliott, Robert (Persistent Memory) > Subject: Re: Observing Softlockup's while running heavy IOs > ... > Yes I am also observing that all the interrupts are

[PATCH] x86/e820: set end to (start + size - 1) in __append_e820_map()

The (start, size) tuple represents a range [start, start + size - 1], which means "start" and "start + size - 1" should be compared to see whether the range overflows. For example, a range with (start, size) (0x fff0, 0x 0010) represents [0x

[PATCH] x86/e820: set end to (start + size - 1) in __append_e820_map()

The (start, size) tuple represents a range [start, start + size - 1], which means "start" and "start + size - 1" should be compared to see whether the range overflows. For example, a range with (start, size) (0x fff0, 0x 0010) represents [0x

Re: [LKP] [lkp] [xfs] 68a9f5e700: aim7.jobs-per-min -13.6% regression

On Fri, Aug 19, 2016 at 4:48 PM, Dave Chinner wrote: > > Well, it depends on the speed of the storage. The higher the speed > of the storage, the less we care about stalling on dirty pages > during reclaim Actually, that's largely true independently of the speed of the

Re: [LKP] [lkp] [xfs] 68a9f5e700: aim7.jobs-per-min -13.6% regression

On Fri, Aug 19, 2016 at 4:48 PM, Dave Chinner wrote: > > Well, it depends on the speed of the storage. The higher the speed > of the storage, the less we care about stalling on dirty pages > during reclaim Actually, that's largely true independently of the speed of the storage, I feel. On

[PATCH 2/2] hwrng: thunderx: Add Cavium HWRNG driver for ThunderX SoC.

The Cavium ThunderX SoC has a hardware random number generator. This driver provides support using the HWRNG framework. Signed-off-by: Omer Khaliq Signed-off-by: Ananth Jasty Acked-by: David Daney ---

[PATCH 2/2] hwrng: thunderx: Add Cavium HWRNG driver for ThunderX SoC.

The Cavium ThunderX SoC has a hardware random number generator. This driver provides support using the HWRNG framework. Signed-off-by: Omer Khaliq Signed-off-by: Ananth Jasty Acked-by: David Daney --- drivers/char/hw_random/Kconfig | 13 + drivers/char/hw_random/Makefile|

[PATCH 1/2] PCI/IOV: Add function to allow Function Dependency Link override.

From: David Daney Some hardware presents an incorrect SR-IOV Function Dependency Link, add a function to allow this to be overridden in the PF driver for such devices. Signed-off-by: David Daney Signed-off-by: Omer Khaliq

[PATCH 1/2] PCI/IOV: Add function to allow Function Dependency Link override.

From: David Daney Some hardware presents an incorrect SR-IOV Function Dependency Link, add a function to allow this to be overridden in the PF driver for such devices. Signed-off-by: David Daney Signed-off-by: Omer Khaliq --- drivers/pci/iov.c | 14 ++ include/linux/pci.h | 1

Re: [PATCH v2 1/2] cpufreq / sched: Pass flags to cpufreq_update_util()

On Friday, August 19, 2016 03:26:21 PM Krzysztof Kozlowski wrote: > On Fri, Aug 12, 2016 at 2:04 AM, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > > > It is useful to know the reason why cpufreq_update_util() has just > > been called and

Re: [PATCH v2 1/2] cpufreq / sched: Pass flags to cpufreq_update_util()

On Friday, August 19, 2016 03:26:21 PM Krzysztof Kozlowski wrote: > On Fri, Aug 12, 2016 at 2:04 AM, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > > > It is useful to know the reason why cpufreq_update_util() has just > > been called and that can be passed as flags to

Re: [RFC][PATCH 7/7] cpufreq: intel_pstate: Change P-state selection algorithm for Core

On Friday, August 19, 2016 04:47:29 PM Peter Zijlstra wrote: > On Sat, Aug 13, 2016 at 08:59:01AM -0700, Doug Smythies wrote: > > My previous replies (and see below) have suggested that some filtering > > is needed on the target pstate, otherwise, and dependant on the type of > > workload, it

Re: [RFC][PATCH 7/7] cpufreq: intel_pstate: Change P-state selection algorithm for Core

On Friday, August 19, 2016 04:47:29 PM Peter Zijlstra wrote: > On Sat, Aug 13, 2016 at 08:59:01AM -0700, Doug Smythies wrote: > > My previous replies (and see below) have suggested that some filtering > > is needed on the target pstate, otherwise, and dependant on the type of > > workload, it

[PATCH v2 1/3] ACPI: fix incorrect counts returned by acpi_parse_entries_array()

The static function acpi_parse_entries_array() is provided an array of type struct acpi_subtable_proc that has a callback function and a count. The count should reflect how many times the callback has been called. However, the current code only increments the 0th element of the array, regardless

[PATCH v2 1/3] ACPI: fix incorrect counts returned by acpi_parse_entries_array()

The static function acpi_parse_entries_array() is provided an array of type struct acpi_subtable_proc that has a callback function and a count. The count should reflect how many times the callback has been called. However, the current code only increments the 0th element of the array, regardless

[PATCH v2 3/3] ACPI: do not report the number of entries ignored by acpi_parse_entries()

The function acpi_parse_entries_array() has a limiting parameter, max_entries, which tells the function to stop looking at subtables once that limit has been reached. If the limit is reached, it is reported. However, the logic is incorrect in that the loop to examine all subtables will always

[PATCH v2 3/3] ACPI: do not report the number of entries ignored by acpi_parse_entries()

The function acpi_parse_entries_array() has a limiting parameter, max_entries, which tells the function to stop looking at subtables once that limit has been reached. If the limit is reached, it is reported. However, the logic is incorrect in that the loop to examine all subtables will always

[PATCH v2 2/3] ACPI: fix acpi_parse_entries_array() so it traverses all subtables

The acpi_parse_entries_array() function currently returns the very first time there is any error found by one of the callback functions, or if one of the callbacks returns a non-zero value. However, the ACPI subtables being traversed could still have valid entries that could be used by one of the

[PATCH v2 0/3] Correct errors in acpi_parse_entries_array()

Several strange things were found while prototyping a way to correctly report whether or not an IORT is needed by an arm64 platform. What the prototype needed to do was iterate over the MADT subtables and look for certain types of subtable, count how many there were by type, and capture some info

[PATCH v2 2/3] ACPI: fix acpi_parse_entries_array() so it traverses all subtables

The acpi_parse_entries_array() function currently returns the very first time there is any error found by one of the callback functions, or if one of the callbacks returns a non-zero value. However, the ACPI subtables being traversed could still have valid entries that could be used by one of the

[PATCH v2 0/3] Correct errors in acpi_parse_entries_array()

Several strange things were found while prototyping a way to correctly report whether or not an IORT is needed by an arm64 platform. What the prototype needed to do was iterate over the MADT subtables and look for certain types of subtable, count how many there were by type, and capture some info

Re: [PATCH 10/11] acpi: bus: Set _OSC for diverse core support

On Thursday, August 18, 2016 03:36:51 PM Srinivas Pandruvada wrote: > Set the OSC_SB_CPC_DIVERSE_HIGH_SUPPORT (bit 12) to enable diverse > core support. > > Signed-off-by: Srinivas Pandruvada > --- > drivers/acpi/bus.c | 4 +++- > include/linux/acpi.h | 1

Re: [PATCH 10/11] acpi: bus: Set _OSC for diverse core support

On Thursday, August 18, 2016 03:36:51 PM Srinivas Pandruvada wrote: > Set the OSC_SB_CPC_DIVERSE_HIGH_SUPPORT (bit 12) to enable diverse > core support. > > Signed-off-by: Srinivas Pandruvada > --- > drivers/acpi/bus.c | 4 +++- > include/linux/acpi.h | 1 + > 2 files changed, 4

Re: [PATCH 09/11] acpi: bus: Enable HWP CPPC objects

On Thursday, August 18, 2016 03:36:50 PM Srinivas Pandruvada wrote: > Need to set platform wide _OSC bits to enable CPPC and CPPC version 2. > If platform supports CPPC, then BIOS exposess CPPC tables. > > Signed-off-by: Srinivas Pandruvada > --- >

Re: [PATCH 09/11] acpi: bus: Enable HWP CPPC objects

On Thursday, August 18, 2016 03:36:50 PM Srinivas Pandruvada wrote: > Need to set platform wide _OSC bits to enable CPPC and CPPC version 2. > If platform supports CPPC, then BIOS exposess CPPC tables. > > Signed-off-by: Srinivas Pandruvada > --- > drivers/acpi/bus.c | 7 +++ > 1 file

Re: [PATCH v2] thermal: imx: depend on imx SoC arch

On Wed, May 25, 2016 at 9:45 PM, Peter Robinson wrote: > Not much use unless the SoC is selected so depend on the ARCH_MXC > and COMPILE_TEST like all the other thermal drivers. > > v2: drop extraneous OF > > Signed-off-by: Peter Robinson Acked-by:

Re: [PATCH v2] thermal: imx: depend on imx SoC arch

On Wed, May 25, 2016 at 9:45 PM, Peter Robinson wrote: > Not much use unless the SoC is selected so depend on the ARCH_MXC > and COMPILE_TEST like all the other thermal drivers. > > v2: drop extraneous OF > > Signed-off-by: Peter Robinson Acked-by: Shawn Guo

Re: [PATCH 07/11] acpi: cppc: Add support for function fixed hardware address

On Thursday, August 18, 2016 03:36:48 PM Srinivas Pandruvada wrote: > The CPPC registers can also be accessed via function fixed hardware > addresses in X86. Add support by modifying cpc_read and cpc_write > to be able to read/write MSRs on x86 platform. Also with this change, >

Re: [PATCH 07/11] acpi: cppc: Add support for function fixed hardware address

On Thursday, August 18, 2016 03:36:48 PM Srinivas Pandruvada wrote: > The CPPC registers can also be accessed via function fixed hardware > addresses in X86. Add support by modifying cpc_read and cpc_write > to be able to read/write MSRs on x86 platform. Also with this change, >

Re: [PATCH 05/11] acpi: cppc: Allow build with ACPI_CPU_FREQ_PSS config

On Thursday, August 18, 2016 03:36:46 PM Srinivas Pandruvada wrote: > Some newer x86 platforms have support for both _CPC and _PSS object. So > kernel config can have both ACPI_CPU_FREQ_PSS and ACPI_CPPC_LIB. So remove > restriction for ACPI_CPPC_LIB to build only when ACPI_CPU_FREQ_PSS is not >

Re: [PATCH 05/11] acpi: cppc: Allow build with ACPI_CPU_FREQ_PSS config

On Thursday, August 18, 2016 03:36:46 PM Srinivas Pandruvada wrote: > Some newer x86 platforms have support for both _CPC and _PSS object. So > kernel config can have both ACPI_CPU_FREQ_PSS and ACPI_CPPC_LIB. So remove > restriction for ACPI_CPPC_LIB to build only when ACPI_CPU_FREQ_PSS is not >

[PATCH 0/3] ARM: K2G: Add support for TI-SCI Clocks

Texas Instruments' Keystone generation System on Chips (SoC) starting with 66AK2G02[1], now include a dedicated SoC System Control entity called PMMC(Power Management Micro Controller) in line with ARM architecture recommendations. The function of this module is to integrate all system operations

[PATCH 1/3] Documentation: dt: Add TI SCI clock driver

From: Tero Kristo Add a clock implementation, TI SCI clock, that will hook to the common clock framework, and allow each clock to be controlled via TI SCI protocol. Signed-off-by: Tero Kristo Tested-by: Dave Gerlach Signed-off-by: Nishanth

[PATCH 0/3] ARM: K2G: Add support for TI-SCI Clocks

Texas Instruments' Keystone generation System on Chips (SoC) starting with 66AK2G02[1], now include a dedicated SoC System Control entity called PMMC(Power Management Micro Controller) in line with ARM architecture recommendations. The function of this module is to integrate all system operations

[PATCH 1/3] Documentation: dt: Add TI SCI clock driver

From: Tero Kristo Add a clock implementation, TI SCI clock, that will hook to the common clock framework, and allow each clock to be controlled via TI SCI protocol. Signed-off-by: Tero Kristo Tested-by: Dave Gerlach Signed-off-by: Nishanth Menon ---

[PATCH 2/3] dt-binding: clock: Add k2g clock definitions

From: Tero Kristo Add identifiers for the K2G clocks managed by the PMMC. Signed-off-by: Tero Kristo Tested-by: Dave Gerlach Signed-off-by: Nishanth Menon --- MAINTAINERS | 1 +

[PATCH 3/3] clk: keystone: Add sci-clk driver support

From: Tero Kristo In K2G, the clock handling is done through firmware executing on a separate core. Linux kernel needs to communicate to the firmware through TI system control interface to access any power management related resources, including clocks. The keystone sci-clk

[PATCH 2/3] dt-binding: clock: Add k2g clock definitions

From: Tero Kristo Add identifiers for the K2G clocks managed by the PMMC. Signed-off-by: Tero Kristo Tested-by: Dave Gerlach Signed-off-by: Nishanth Menon --- MAINTAINERS | 1 + include/dt-bindings/clock/k2g.h | 234 2 files

[PATCH 3/3] clk: keystone: Add sci-clk driver support

From: Tero Kristo In K2G, the clock handling is done through firmware executing on a separate core. Linux kernel needs to communicate to the firmware through TI system control interface to access any power management related resources, including clocks. The keystone sci-clk driver does this, by

[PATCH v4] i2c: imx: make bus recovery through pinctrl optional

Since commit 1c4b6c3bcf30 ("i2c: imx: implement bus recovery") the driver starts to use gpio/pinctrl to do i2c bus recovery. But pinctrl is not always available for platforms using this driver such as ls1021a and ls1043a, and the device tree binding also mentioned this gpio based recovery

[PATCH v4] i2c: imx: make bus recovery through pinctrl optional

Since commit 1c4b6c3bcf30 ("i2c: imx: implement bus recovery") the driver starts to use gpio/pinctrl to do i2c bus recovery. But pinctrl is not always available for platforms using this driver such as ls1021a and ls1043a, and the device tree binding also mentioned this gpio based recovery

[PATCH v6 02/12] kexec_file: Change kexec_add_buffer to take kexec_buf as argument.

This is done to simplify the kexec_add_buffer argument list. Adapt all callers to set up a kexec_buf to pass to kexec_add_buffer. In addition, change the type of kexec_buf.buffer from char * to void *. There is no particular reason for it to be a char *, and the change allows us to get rid of 3

[PATCH v6 02/12] kexec_file: Change kexec_add_buffer to take kexec_buf as argument.

This is done to simplify the kexec_add_buffer argument list. Adapt all callers to set up a kexec_buf to pass to kexec_add_buffer. In addition, change the type of kexec_buf.buffer from char * to void *. There is no particular reason for it to be a char *, and the change allows us to get rid of 3

[PATCH v6 00/12] kexec_file_load implementation for PowerPC

[ Andrew, since this series touches generic code, x86 and powerpc, Michael Ellerman and Dave Young think it should go via your tree. ] I'm sending a new version because of a few problems with version 5 of the patch series (more detailed changelog at the end of this email): - Since maintainers

[PATCH v6 01/12] kexec_file: Allow arch-specific memory walking for kexec_add_buffer

Allow architectures to specify a different memory walking function for kexec_add_buffer. x86 uses iomem to track reserved memory ranges, but PowerPC uses the memblock subsystem. Signed-off-by: Thiago Jung Bauermann Acked-by: Dave Young Acked-by:

[PATCH v6 00/12] kexec_file_load implementation for PowerPC

[ Andrew, since this series touches generic code, x86 and powerpc, Michael Ellerman and Dave Young think it should go via your tree. ] I'm sending a new version because of a few problems with version 5 of the patch series (more detailed changelog at the end of this email): - Since maintainers

[PATCH v6 01/12] kexec_file: Allow arch-specific memory walking for kexec_add_buffer

Allow architectures to specify a different memory walking function for kexec_add_buffer. x86 uses iomem to track reserved memory ranges, but PowerPC uses the memblock subsystem. Signed-off-by: Thiago Jung Bauermann Acked-by: Dave Young Acked-by: Balbir Singh --- include/linux/kexec.h | 29

[PATCH v6 06/12] powerpc: Adapt elf64_apply_relocate_add for kexec_file_load.

Extend elf64_apply_relocate_add to support relative symbols. This is necessary because there is a difference between how the module loading mechanism and the kexec purgatory loading code use Elf64_Sym.st_value at relocation time: the former changes st_value to point to the absolute memory address

[PATCH v6 06/12] powerpc: Adapt elf64_apply_relocate_add for kexec_file_load.

Extend elf64_apply_relocate_add to support relative symbols. This is necessary because there is a difference between how the module loading mechanism and the kexec purgatory loading code use Elf64_Sym.st_value at relocation time: the former changes st_value to point to the absolute memory address

[PATCH v6 04/12] powerpc: Factor out relocation code from module_64.c to elf_util_64.c.

The kexec_file_load system call needs to relocate the purgatory, so factor out the module relocation code so that it can be shared. This patch's purpose is to move the ELF relocation logic from apply_relocate_add to elf_util_64.c with as few changes as possible. The following changes were needed:

[PATCH v6 07/12] powerpc: Add functions to read ELF files of any endianness.

A little endian kernel might need to kexec a big endian kernel (the opposite is less likely but could happen as well), so we can't just cast the buffer with the binary to ELF structs and use them as is done elsewhere. This patch adds functions which do byte-swapping as necessary when populating

[PATCH v6 04/12] powerpc: Factor out relocation code from module_64.c to elf_util_64.c.

The kexec_file_load system call needs to relocate the purgatory, so factor out the module relocation code so that it can be shared. This patch's purpose is to move the ELF relocation logic from apply_relocate_add to elf_util_64.c with as few changes as possible. The following changes were needed:

[PATCH v6 07/12] powerpc: Add functions to read ELF files of any endianness.

A little endian kernel might need to kexec a big endian kernel (the opposite is less likely but could happen as well), so we can't just cast the buffer with the binary to ELF structs and use them as is done elsewhere. This patch adds functions which do byte-swapping as necessary when populating

[PATCH v6 11/12] powerpc: Add purgatory for kexec_file_load implementation.

This purgatory implementation comes from kexec-tools, almost unchanged. The only changes were that the sha256_regions global variable was renamed to sha_regions to match what kexec_file_load expects, and to use the sha256.c file from x86's purgatory to avoid adding yet another SHA-256

[PATCH v6 12/12] powerpc: Enable CONFIG_KEXEC_FILE in powerpc server defconfigs.

Enable CONFIG_KEXEC_FILE in powernv_defconfig, ppc64_defconfig and pseries_defconfig. It depends on CONFIG_CRYPTO_SHA256=y, so add that as well. Signed-off-by: Thiago Jung Bauermann --- arch/powerpc/configs/powernv_defconfig | 2 ++

[PATCH v6 11/12] powerpc: Add purgatory for kexec_file_load implementation.

This purgatory implementation comes from kexec-tools, almost unchanged. The only changes were that the sha256_regions global variable was renamed to sha_regions to match what kexec_file_load expects, and to use the sha256.c file from x86's purgatory to avoid adding yet another SHA-256

[PATCH v6 12/12] powerpc: Enable CONFIG_KEXEC_FILE in powerpc server defconfigs.

Enable CONFIG_KEXEC_FILE in powernv_defconfig, ppc64_defconfig and pseries_defconfig. It depends on CONFIG_CRYPTO_SHA256=y, so add that as well. Signed-off-by: Thiago Jung Bauermann --- arch/powerpc/configs/powernv_defconfig | 2 ++ arch/powerpc/configs/ppc64_defconfig | 2 ++

[PATCH v6 09/12] powerpc: Add code to work with device trees in kexec_file_load.

kexec_file_load needs to set up the device tree that will be used by the next kernel and check whether it provides a console that can be used by the purgatory. Signed-off-by: Thiago Jung Bauermann --- arch/powerpc/include/asm/kexec.h | 3 +

[PATCH v6 10/12] powerpc: Add support for loading ELF kernels with kexec_file_load.

This uses all the infrastructure built up by the previous patches in the series to load an ELF vmlinux file and an initrd. It uses the flattened device tree at initial_boot_params as a base and adjusts memory reservations and its /chosen node for the next kernel. Signed-off-by: Thiago Jung

[PATCH v6 09/12] powerpc: Add code to work with device trees in kexec_file_load.

kexec_file_load needs to set up the device tree that will be used by the next kernel and check whether it provides a console that can be used by the purgatory. Signed-off-by: Thiago Jung Bauermann --- arch/powerpc/include/asm/kexec.h | 3 + arch/powerpc/kernel/machine_kexec_64.c | 220

[PATCH v6 10/12] powerpc: Add support for loading ELF kernels with kexec_file_load.

This uses all the infrastructure built up by the previous patches in the series to load an ELF vmlinux file and an initrd. It uses the flattened device tree at initial_boot_params as a base and adjusts memory reservations and its /chosen node for the next kernel. Signed-off-by: Thiago Jung

[PATCH v6 08/12] powerpc: Implement kexec_file_load.

arch_kexec_walk_mem and arch_kexec_apply_relocations_add are used by generic kexec code, while setup_purgatory is powerpc-specific and sets runtime variables needed by the powerpc purgatory implementation. Signed-off-by: Josh Sklar Signed-off-by: Thiago Jung Bauermann

[PATCH v6 05/12] powerpc: Generalize elf64_apply_relocate_add.

When apply_relocate_add is called, modules are already loaded at their final location in memory so Elf64_Shdr.sh_addr can be used for accessing the section contents as well as the base address for relocations. This is not the case for kexec's purgatory, because it will only be copied to its final

  1   2   3   4   5   6   7   8   9   10   >