[PATCH v4] acpi: Issue _OSC call for native thermal interrupt handling

[Srinivas Pandruvada]

There are several reports of freeze on enabling HWP (Hardware PStates)
feature on Skylake based systems by Intel P states driver. The root
cause is identified as the HWP interrupts causing BIOS code to freeze.
HWP interrupts uses thermal LVT.
Linux natively handles thermal interrupts, but in Skylake based systems
SMM will take control of thermal interrupts. This is a problem for several
reasons:
- It is freezing in BIOS when tries to handle thermal interrupt, which
will require BIOS upgrade
- With SMM handling thermal we loose all the reporting features of
Linux arch/x86/kernel/cpu/mcheck/therm_throt driver
- Some thermal drivers like x86-package-temp driver depends on the thermal
threshold interrupts
- The HWP interrupts are useful for debugging and tuning performance

So we need native handling of thermal interrupts. To inform SMM that
OS will handle thermal interrupts, we need to use _OSC under processor
scope very early in ACPI initialization flow. This needs to be done
before SMM code path looks for _OSC capabilities. The bit 12 of
_OSC in processor scope defines whether OS will handle thermal interrupts.
When bit 12 is set to 1, OS will handle thermal interrupts.
Refer to this document for details on _OSC
http://www.intel.com/content/www/us/en/standards/processor-vendor-
specific-acpi-specification.html

This change introduces a new function acpi_early_processor_set_osc(),
which walks acpi name space and finds acpi processor object and
set capability via _OSC method to take over thermal LVT.

Also this change writes HWP status bits to 0 to clear any HWP status
bits in intel_thermal_interrupt().

Signed-off-by: Srinivas Pandruvada 
---
v4:
Suggestion by Boris for removing use of intermediate variable for
clearing HWP status and using boot_cpu_has instead of static_cpu_has

v3:
- Added CONFIG_X86 around static_cpu_has() to fix compile error on
ARCH=ia64, reported by kbuild test robot
- return AE_CTRL_TERMINATE to terminate acpi name walk space, when _OSC
is set already once.
v2:
Unnecessary newline was introduced, removed that in acpi_processor.c

 arch/x86/kernel/cpu/mcheck/therm_throt.c |  3 ++
 drivers/acpi/acpi_processor.c| 47 
 drivers/acpi/bus.c   |  3 ++
 drivers/acpi/internal.h  |  2 ++
 4 files changed, 55 insertions(+)

diff --git a/arch/x86/kernel/cpu/mcheck/therm_throt.c 
b/arch/x86/kernel/cpu/mcheck/therm_throt.c
index 2c5aaf8..0553858 100644
--- a/arch/x86/kernel/cpu/mcheck/therm_throt.c
+++ b/arch/x86/kernel/cpu/mcheck/therm_throt.c
@@ -385,6 +385,9 @@ static void intel_thermal_interrupt(void)
 {
__u64 msr_val;
 
+   if (static_cpu_has(X86_FEATURE_HWP))
+   wrmsrl_safe(MSR_HWP_STATUS, 0);
+
rdmsrl(MSR_IA32_THERM_STATUS, msr_val);
 
/* Check for violation of core thermal thresholds*/
diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index 6979186..18da84f 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -491,6 +491,53 @@ static void acpi_processor_remove(struct acpi_device 
*device)
 }
 #endif /* CONFIG_ACPI_HOTPLUG_CPU */
 
+#ifdef CONFIG_X86
+static bool acpi_hwp_native_thermal_lvt_set;
+static acpi_status acpi_set_hwp_native_thermal_lvt_osc(acpi_handle handle,
+  u32 lvl, void *context,
+  void **rv)
+{
+   u8 sb_uuid_str[] = "4077A616-290C-47BE-9EBD-D87058713953";
+   u32 capbuf[2];
+   struct acpi_osc_context osc_context = {
+   .uuid_str = sb_uuid_str,
+   .rev = 1,
+   .cap.length = 8,
+   .cap.pointer = capbuf,
+   };
+
+   if (acpi_hwp_native_thermal_lvt_set)
+   return AE_CTRL_TERMINATE;
+
+   capbuf[0] = 0x;
+   capbuf[1] = 0x1000; /* set bit 12 */
+
+   if (ACPI_SUCCESS(acpi_run_osc(handle, _context))) {
+   acpi_hwp_native_thermal_lvt_set = true;
+   kfree(osc_context.ret.pointer);
+   }
+
+   return AE_OK;
+}
+
+void acpi_early_processor_set_osc(void)
+{
+   if (boot_cpu_has(X86_FEATURE_HWP)) {
+   acpi_walk_namespace(ACPI_TYPE_PROCESSOR, ACPI_ROOT_OBJECT,
+   ACPI_UINT32_MAX,
+   acpi_set_hwp_native_thermal_lvt_osc,
+   NULL, NULL, NULL);
+   acpi_get_devices(ACPI_PROCESSOR_DEVICE_HID,
+acpi_set_hwp_native_thermal_lvt_osc,
+NULL, NULL);
+   }
+}
+#else
+
+void acpi_early_processor_set_osc(void) {}
+
+#endif
+
 /*
  * The following ACPI IDs are known to be suitable for representing as
  * processor devices.
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 891c42d..7e73aea 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ 

[PATCH v4] acpi: Issue _OSC call for native thermal interrupt handling

[Srinivas Pandruvada]

There are several reports of freeze on enabling HWP (Hardware PStates)
feature on Skylake based systems by Intel P states driver. The root
cause is identified as the HWP interrupts causing BIOS code to freeze.
HWP interrupts uses thermal LVT.
Linux natively handles thermal interrupts, but in Skylake based systems
SMM will take control of thermal interrupts. This is a problem for several
reasons:
- It is freezing in BIOS when tries to handle thermal interrupt, which
will require BIOS upgrade
- With SMM handling thermal we loose all the reporting features of
Linux arch/x86/kernel/cpu/mcheck/therm_throt driver
- Some thermal drivers like x86-package-temp driver depends on the thermal
threshold interrupts
- The HWP interrupts are useful for debugging and tuning performance

So we need native handling of thermal interrupts. To inform SMM that
OS will handle thermal interrupts, we need to use _OSC under processor
scope very early in ACPI initialization flow. This needs to be done
before SMM code path looks for _OSC capabilities. The bit 12 of
_OSC in processor scope defines whether OS will handle thermal interrupts.
When bit 12 is set to 1, OS will handle thermal interrupts.
Refer to this document for details on _OSC
http://www.intel.com/content/www/us/en/standards/processor-vendor-
specific-acpi-specification.html

This change introduces a new function acpi_early_processor_set_osc(),
which walks acpi name space and finds acpi processor object and
set capability via _OSC method to take over thermal LVT.

Also this change writes HWP status bits to 0 to clear any HWP status
bits in intel_thermal_interrupt().

Signed-off-by: Srinivas Pandruvada 
---
v4:
Suggestion by Boris for removing use of intermediate variable for
clearing HWP status and using boot_cpu_has instead of static_cpu_has

v3:
- Added CONFIG_X86 around static_cpu_has() to fix compile error on
ARCH=ia64, reported by kbuild test robot
- return AE_CTRL_TERMINATE to terminate acpi name walk space, when _OSC
is set already once.
v2:
Unnecessary newline was introduced, removed that in acpi_processor.c

 arch/x86/kernel/cpu/mcheck/therm_throt.c |  3 ++
 drivers/acpi/acpi_processor.c| 47 
 drivers/acpi/bus.c   |  3 ++
 drivers/acpi/internal.h  |  2 ++
 4 files changed, 55 insertions(+)

diff --git a/arch/x86/kernel/cpu/mcheck/therm_throt.c 
b/arch/x86/kernel/cpu/mcheck/therm_throt.c
index 2c5aaf8..0553858 100644
--- a/arch/x86/kernel/cpu/mcheck/therm_throt.c
+++ b/arch/x86/kernel/cpu/mcheck/therm_throt.c
@@ -385,6 +385,9 @@ static void intel_thermal_interrupt(void)
 {
__u64 msr_val;
 
+   if (static_cpu_has(X86_FEATURE_HWP))
+   wrmsrl_safe(MSR_HWP_STATUS, 0);
+
rdmsrl(MSR_IA32_THERM_STATUS, msr_val);
 
/* Check for violation of core thermal thresholds*/
diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index 6979186..18da84f 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -491,6 +491,53 @@ static void acpi_processor_remove(struct acpi_device 
*device)
 }
 #endif /* CONFIG_ACPI_HOTPLUG_CPU */
 
+#ifdef CONFIG_X86
+static bool acpi_hwp_native_thermal_lvt_set;
+static acpi_status acpi_set_hwp_native_thermal_lvt_osc(acpi_handle handle,
+  u32 lvl, void *context,
+  void **rv)
+{
+   u8 sb_uuid_str[] = "4077A616-290C-47BE-9EBD-D87058713953";
+   u32 capbuf[2];
+   struct acpi_osc_context osc_context = {
+   .uuid_str = sb_uuid_str,
+   .rev = 1,
+   .cap.length = 8,
+   .cap.pointer = capbuf,
+   };
+
+   if (acpi_hwp_native_thermal_lvt_set)
+   return AE_CTRL_TERMINATE;
+
+   capbuf[0] = 0x;
+   capbuf[1] = 0x1000; /* set bit 12 */
+
+   if (ACPI_SUCCESS(acpi_run_osc(handle, _context))) {
+   acpi_hwp_native_thermal_lvt_set = true;
+   kfree(osc_context.ret.pointer);
+   }
+
+   return AE_OK;
+}
+
+void acpi_early_processor_set_osc(void)
+{
+   if (boot_cpu_has(X86_FEATURE_HWP)) {
+   acpi_walk_namespace(ACPI_TYPE_PROCESSOR, ACPI_ROOT_OBJECT,
+   ACPI_UINT32_MAX,
+   acpi_set_hwp_native_thermal_lvt_osc,
+   NULL, NULL, NULL);
+   acpi_get_devices(ACPI_PROCESSOR_DEVICE_HID,
+acpi_set_hwp_native_thermal_lvt_osc,
+NULL, NULL);
+   }
+}
+#else
+
+void acpi_early_processor_set_osc(void) {}
+
+#endif
+
 /*
  * The following ACPI IDs are known to be suitable for representing as
  * processor devices.
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 891c42d..7e73aea 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -1005,6 +1005,9 @@ static int __init 

Re: [PATCH v6 3/4] i2c: i801: add support of Host Notify

[Andrew Duggan]

On Wed, Mar 16, 2016 at 9:39 AM, Benjamin Tissoires
 wrote:
> The i801 chip can handle the Host Notify feature since ICH 3 as mentioned
> in 
> http://www.intel.com/content/dam/doc/datasheet/82801ca-io-controller-hub-3-datasheet.pdf
>
> Enable the functionality unconditionally and propagate the alert
> on each notification.
>
> With a T440s and a Synaptics touchpad that implements Host Notify, the
> payload data is always 0x, so I am not sure if the device actually
> sends the payload or if there is a problem regarding the implementation.
>
> Signed-off-by: Benjamin Tissoires 

Tested-by: Andrew Duggan 

> ---
>
> changes in v2:
> - removed the description of the Slave functionality support in the chip table
>   (the table shows what is supported, not what the hardware is capable of)
> - use i2c-smbus to forward the notification
> - remove the fifo, and directly retrieve the address and payload in the worker
> - do not check for Host Notification is the feature is not enabled
> - use inw_p() to read the payload instead of 2 inb_p() calls
> - add /* fall-through */ comment
> - unconditionally enable Host Notify if the hardware supports it (can be
>   disabled by the user)
>
> no changes in v3
>
> changes in v4:
> - make use of the new API -> no more worker spawning here
> - solved a race between the access of the Host Notify registers and the actual
>   I2C transfers.
>
> changes in v5:
> - added SKL Host Notify support
>
> changes in v6:
> - select I2C_SMBUS in Kconfig to prevent an undefined reference when I2C_I801
>   is set to 'Y' while I2C_SMBUS is set to 'M'
>
>  drivers/i2c/busses/Kconfig|  1 +
>  drivers/i2c/busses/i2c-i801.c | 85 
> +--
>  2 files changed, 83 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index faa8e68..8c8fa12 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -91,6 +91,7 @@ config I2C_I801
> tristate "Intel 82801 (ICH/PCH)"
> depends on PCI
> select CHECK_SIGNATURE if X86 && DMI
> +   select I2C_SMBUS
> help
>   If you say yes to this option, support will be included for the 
> Intel
>   801 family of mainboard I2C interfaces.  Specifically, the following
> diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
> index 585a3b7..b244aa40 100644
> --- a/drivers/i2c/busses/i2c-i801.c
> +++ b/drivers/i2c/busses/i2c-i801.c
> @@ -72,6 +72,7 @@
>   * Block process call transaction  no
>   * I2C block read transaction  yes (doesn't use the block buffer)
>   * Slave mode  no
> + * SMBus Host Notify   yes
>   * Interrupt processingyes
>   *
>   * See the file Documentation/i2c/busses/i2c-i801 for details.
> @@ -86,6 +87,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -112,6 +114,10 @@
>  #define SMBPEC(p)  (8 + (p)->smba) /* ICH3 and later */
>  #define SMBAUXSTS(p)   (12 + (p)->smba)/* ICH4 and later */
>  #define SMBAUXCTL(p)   (13 + (p)->smba)/* ICH4 and later */
> +#define SMBSLVSTS(p)   (16 + (p)->smba)/* ICH3 and later */
> +#define SMBSLVCMD(p)   (17 + (p)->smba)/* ICH3 and later */
> +#define SMBNTFDADD(p)  (20 + (p)->smba)/* ICH3 and later */
> +#define SMBNTFDDAT(p)  (22 + (p)->smba)/* ICH3 and later */
>
>  /* PCI Address Constants */
>  #define SMBBAR 4
> @@ -176,6 +182,12 @@
>  #define SMBHSTSTS_INTR 0x02
>  #define SMBHSTSTS_HOST_BUSY0x01
>
> +/* Host Notify Status registers bits */
> +#define SMBSLVSTS_HST_NTFY_STS 1
> +
> +/* Host Notify Command registers bits */
> +#define SMBSLVCMD_HST_NTFY_INTREN  0x01
> +
>  #define STATUS_ERROR_FLAGS (SMBHSTSTS_FAILED | SMBHSTSTS_BUS_ERR | \
>  SMBHSTSTS_DEV_ERR)
>
> @@ -244,13 +256,18 @@ struct i801_priv {
> struct platform_device *mux_pdev;
>  #endif
> struct platform_device *tco_pdev;
> +
> +   struct smbus_host_notify *host_notify;
>  };
>
> +#define SMBHSTNTFY_SIZE8
> +
>  #define FEATURE_SMBUS_PEC  (1 << 0)
>  #define FEATURE_BLOCK_BUFFER   (1 << 1)
>  #define FEATURE_BLOCK_PROC (1 << 2)
>  #define FEATURE_I2C_BLOCK_READ (1 << 3)
>  #define FEATURE_IRQ(1 << 4)
> +#define FEATURE_HOST_NOTIFY(1 << 5)
>  /* Not really a feature, but it's convenient to handle it as such */
>  #define FEATURE_IDF(1 << 15)
>  #define FEATURE_TCO(1 << 16)
> @@ -261,6 +278,7 @@ static const char *i801_feature_names[] = {
> "Block process call",
> "I2C block read",
> "Interrupt",
> +   "SMBus Host Notify",
>  };
>
>  static unsigned int disable_features;
> @@ -269,7 +287,8 @@ MODULE_PARM_DESC(disable_features, 

Re: [PATCH v6 3/4] i2c: i801: add support of Host Notify

[Andrew Duggan]

On Wed, Mar 16, 2016 at 9:39 AM, Benjamin Tissoires
 wrote:
> The i801 chip can handle the Host Notify feature since ICH 3 as mentioned
> in 
> http://www.intel.com/content/dam/doc/datasheet/82801ca-io-controller-hub-3-datasheet.pdf
>
> Enable the functionality unconditionally and propagate the alert
> on each notification.
>
> With a T440s and a Synaptics touchpad that implements Host Notify, the
> payload data is always 0x, so I am not sure if the device actually
> sends the payload or if there is a problem regarding the implementation.
>
> Signed-off-by: Benjamin Tissoires 

Tested-by: Andrew Duggan 

> ---
>
> changes in v2:
> - removed the description of the Slave functionality support in the chip table
>   (the table shows what is supported, not what the hardware is capable of)
> - use i2c-smbus to forward the notification
> - remove the fifo, and directly retrieve the address and payload in the worker
> - do not check for Host Notification is the feature is not enabled
> - use inw_p() to read the payload instead of 2 inb_p() calls
> - add /* fall-through */ comment
> - unconditionally enable Host Notify if the hardware supports it (can be
>   disabled by the user)
>
> no changes in v3
>
> changes in v4:
> - make use of the new API -> no more worker spawning here
> - solved a race between the access of the Host Notify registers and the actual
>   I2C transfers.
>
> changes in v5:
> - added SKL Host Notify support
>
> changes in v6:
> - select I2C_SMBUS in Kconfig to prevent an undefined reference when I2C_I801
>   is set to 'Y' while I2C_SMBUS is set to 'M'
>
>  drivers/i2c/busses/Kconfig|  1 +
>  drivers/i2c/busses/i2c-i801.c | 85 
> +--
>  2 files changed, 83 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index faa8e68..8c8fa12 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -91,6 +91,7 @@ config I2C_I801
> tristate "Intel 82801 (ICH/PCH)"
> depends on PCI
> select CHECK_SIGNATURE if X86 && DMI
> +   select I2C_SMBUS
> help
>   If you say yes to this option, support will be included for the 
> Intel
>   801 family of mainboard I2C interfaces.  Specifically, the following
> diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
> index 585a3b7..b244aa40 100644
> --- a/drivers/i2c/busses/i2c-i801.c
> +++ b/drivers/i2c/busses/i2c-i801.c
> @@ -72,6 +72,7 @@
>   * Block process call transaction  no
>   * I2C block read transaction  yes (doesn't use the block buffer)
>   * Slave mode  no
> + * SMBus Host Notify   yes
>   * Interrupt processingyes
>   *
>   * See the file Documentation/i2c/busses/i2c-i801 for details.
> @@ -86,6 +87,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -112,6 +114,10 @@
>  #define SMBPEC(p)  (8 + (p)->smba) /* ICH3 and later */
>  #define SMBAUXSTS(p)   (12 + (p)->smba)/* ICH4 and later */
>  #define SMBAUXCTL(p)   (13 + (p)->smba)/* ICH4 and later */
> +#define SMBSLVSTS(p)   (16 + (p)->smba)/* ICH3 and later */
> +#define SMBSLVCMD(p)   (17 + (p)->smba)/* ICH3 and later */
> +#define SMBNTFDADD(p)  (20 + (p)->smba)/* ICH3 and later */
> +#define SMBNTFDDAT(p)  (22 + (p)->smba)/* ICH3 and later */
>
>  /* PCI Address Constants */
>  #define SMBBAR 4
> @@ -176,6 +182,12 @@
>  #define SMBHSTSTS_INTR 0x02
>  #define SMBHSTSTS_HOST_BUSY0x01
>
> +/* Host Notify Status registers bits */
> +#define SMBSLVSTS_HST_NTFY_STS 1
> +
> +/* Host Notify Command registers bits */
> +#define SMBSLVCMD_HST_NTFY_INTREN  0x01
> +
>  #define STATUS_ERROR_FLAGS (SMBHSTSTS_FAILED | SMBHSTSTS_BUS_ERR | \
>  SMBHSTSTS_DEV_ERR)
>
> @@ -244,13 +256,18 @@ struct i801_priv {
> struct platform_device *mux_pdev;
>  #endif
> struct platform_device *tco_pdev;
> +
> +   struct smbus_host_notify *host_notify;
>  };
>
> +#define SMBHSTNTFY_SIZE8
> +
>  #define FEATURE_SMBUS_PEC  (1 << 0)
>  #define FEATURE_BLOCK_BUFFER   (1 << 1)
>  #define FEATURE_BLOCK_PROC (1 << 2)
>  #define FEATURE_I2C_BLOCK_READ (1 << 3)
>  #define FEATURE_IRQ(1 << 4)
> +#define FEATURE_HOST_NOTIFY(1 << 5)
>  /* Not really a feature, but it's convenient to handle it as such */
>  #define FEATURE_IDF(1 << 15)
>  #define FEATURE_TCO(1 << 16)
> @@ -261,6 +278,7 @@ static const char *i801_feature_names[] = {
> "Block process call",
> "I2C block read",
> "Interrupt",
> +   "SMBus Host Notify",
>  };
>
>  static unsigned int disable_features;
> @@ -269,7 +287,8 @@ MODULE_PARM_DESC(disable_features, "Disable selected 
> driver features:\n"
> "\t\t  0x01  disable SMBus PEC\n"
> 

[PATCH 3.19.y-ckt 44/70] drm/radeon/pm: update current crtc info after setting the powerstate

[Kamal Mostafa]

v3.19.8-ckt17 -stable review patch.  If anyone has any objections, please let 
me know.

---8<

From: Alex Deucher 

commit 5e031d9fe8b0741f11d49667dfc3ebf5454121fd upstream.

On CI, we need to see if the number of crtcs changes to determine
whether or not we need to upload the mclk table again.  In practice
we don't currently upload the mclk table again after the initial load.
The only reason you would would be to add new states, e.g., for
arbitrary mclk setting which is not currently supported.

Acked-by: Christian König 
Signed-off-by: Alex Deucher 
[ kamal: backport to 4.2-stable: context ]
Signed-off-by: Kamal Mostafa 
---
 drivers/gpu/drm/radeon/radeon_pm.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_pm.c 
b/drivers/gpu/drm/radeon/radeon_pm.c
index 5fc27e9..c28e400 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -939,10 +939,6 @@ force:
/* update displays */
radeon_dpm_display_configuration_changed(rdev);
 
-   rdev->pm.dpm.current_active_crtcs = rdev->pm.dpm.new_active_crtcs;
-   rdev->pm.dpm.current_active_crtc_count = 
rdev->pm.dpm.new_active_crtc_count;
-   rdev->pm.dpm.single_display = single_display;
-
/* wait for the rings to drain */
for (i = 0; i < RADEON_NUM_RINGS; i++) {
struct radeon_ring *ring = >ring[i];
@@ -958,6 +954,10 @@ force:
 
radeon_dpm_post_set_power_state(rdev);
 
+   rdev->pm.dpm.current_active_crtcs = rdev->pm.dpm.new_active_crtcs;
+   rdev->pm.dpm.current_active_crtc_count = 
rdev->pm.dpm.new_active_crtc_count;
+   rdev->pm.dpm.single_display = single_display;
+
if (rdev->asic->dpm.force_performance_level) {
if (rdev->pm.dpm.thermal_active) {
enum radeon_dpm_forced_level level = 
rdev->pm.dpm.forced_level;
-- 
2.7.0

[PATCH 3.19.y-ckt 44/70] drm/radeon/pm: update current crtc info after setting the powerstate

[Kamal Mostafa]

v3.19.8-ckt17 -stable review patch.  If anyone has any objections, please let 
me know.

---8<

From: Alex Deucher 

commit 5e031d9fe8b0741f11d49667dfc3ebf5454121fd upstream.

On CI, we need to see if the number of crtcs changes to determine
whether or not we need to upload the mclk table again.  In practice
we don't currently upload the mclk table again after the initial load.
The only reason you would would be to add new states, e.g., for
arbitrary mclk setting which is not currently supported.

Acked-by: Christian König 
Signed-off-by: Alex Deucher 
[ kamal: backport to 4.2-stable: context ]
Signed-off-by: Kamal Mostafa 
---
 drivers/gpu/drm/radeon/radeon_pm.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_pm.c 
b/drivers/gpu/drm/radeon/radeon_pm.c
index 5fc27e9..c28e400 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -939,10 +939,6 @@ force:
/* update displays */
radeon_dpm_display_configuration_changed(rdev);
 
-   rdev->pm.dpm.current_active_crtcs = rdev->pm.dpm.new_active_crtcs;
-   rdev->pm.dpm.current_active_crtc_count = 
rdev->pm.dpm.new_active_crtc_count;
-   rdev->pm.dpm.single_display = single_display;
-
/* wait for the rings to drain */
for (i = 0; i < RADEON_NUM_RINGS; i++) {
struct radeon_ring *ring = >ring[i];
@@ -958,6 +954,10 @@ force:
 
radeon_dpm_post_set_power_state(rdev);
 
+   rdev->pm.dpm.current_active_crtcs = rdev->pm.dpm.new_active_crtcs;
+   rdev->pm.dpm.current_active_crtc_count = 
rdev->pm.dpm.new_active_crtc_count;
+   rdev->pm.dpm.single_display = single_display;
+
if (rdev->asic->dpm.force_performance_level) {
if (rdev->pm.dpm.thermal_active) {
enum radeon_dpm_forced_level level = 
rdev->pm.dpm.forced_level;
-- 
2.7.0

[PATCH 2/2] bcma: use of_dma_configure() to set initial dma mask

[Arnd Bergmann]

While fixing another bug, I noticed that bcma manually sets up
a dma_mask pointer for its child devices. We have a generic
helper for that now, which should be able to cope better with
any variations that might be needed to deal with cache coherency,
unusual DMA address offsets, iommus, or limited DMA masks, none
of which are currently handled here.

This changes the core to use the of_dma_configure(), like
we do for platform devices that are probed directly from
DT.

Signed-off-by: Arnd Bergmann 
---

This patch needs to be tested to ensure we don't introduce
regressions, and should probably go into 4.7 as a cleanup.
---
 drivers/bcma/main.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
index 1f635471f318..57d223a7a720 100644
--- a/drivers/bcma/main.c
+++ b/drivers/bcma/main.c
@@ -209,6 +209,8 @@ static void bcma_of_fill_device(struct platform_device 
*parent,
core->dev.of_node = node;
 
core->irq = bcma_of_get_irq(parent, core, 0);
+
+   of_dma_configure(core->dev, node);
 }
 
 unsigned int bcma_core_irq(struct bcma_device *core, int num)
@@ -248,12 +250,12 @@ void bcma_prepare_core(struct bcma_bus *bus, struct 
bcma_device *core)
core->irq = bus->host_pci->irq;
break;
case BCMA_HOSTTYPE_SOC:
-   core->dev.dma_mask = >dev.coherent_dma_mask;
-   if (bus->host_pdev) {
+   if (IS_ENABLED(CONFIG_OF) && bus->host_pdev) {
core->dma_dev = >host_pdev->dev;
core->dev.parent = >host_pdev->dev;
bcma_of_fill_device(bus->host_pdev, core);
} else {
+   core->dev.dma_mask = >dev.coherent_dma_mask;
core->dma_dev = >dev;
}
break;
-- 
2.7.0

[PATCH 2/2] bcma: use of_dma_configure() to set initial dma mask

[Arnd Bergmann]

While fixing another bug, I noticed that bcma manually sets up
a dma_mask pointer for its child devices. We have a generic
helper for that now, which should be able to cope better with
any variations that might be needed to deal with cache coherency,
unusual DMA address offsets, iommus, or limited DMA masks, none
of which are currently handled here.

This changes the core to use the of_dma_configure(), like
we do for platform devices that are probed directly from
DT.

Signed-off-by: Arnd Bergmann 
---

This patch needs to be tested to ensure we don't introduce
regressions, and should probably go into 4.7 as a cleanup.
---
 drivers/bcma/main.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
index 1f635471f318..57d223a7a720 100644
--- a/drivers/bcma/main.c
+++ b/drivers/bcma/main.c
@@ -209,6 +209,8 @@ static void bcma_of_fill_device(struct platform_device 
*parent,
core->dev.of_node = node;
 
core->irq = bcma_of_get_irq(parent, core, 0);
+
+   of_dma_configure(core->dev, node);
 }
 
 unsigned int bcma_core_irq(struct bcma_device *core, int num)
@@ -248,12 +250,12 @@ void bcma_prepare_core(struct bcma_bus *bus, struct 
bcma_device *core)
core->irq = bus->host_pci->irq;
break;
case BCMA_HOSTTYPE_SOC:
-   core->dev.dma_mask = >dev.coherent_dma_mask;
-   if (bus->host_pdev) {
+   if (IS_ENABLED(CONFIG_OF) && bus->host_pdev) {
core->dma_dev = >host_pdev->dev;
core->dev.parent = >host_pdev->dev;
bcma_of_fill_device(bus->host_pdev, core);
} else {
+   core->dev.dma_mask = >dev.coherent_dma_mask;
core->dma_dev = >dev;
}
break;
-- 
2.7.0

Re: [PATCH] Drivers: hv: vmbus: handle various crash scenarios

[Vitaly Kuznetsov]

Radim Krcmar  writes:

> 2016-03-18 13:33+0100, Vitaly Kuznetsov:
>> Kdump keeps biting. Turns out CHANNELMSG_UNLOAD_RESPONSE is always
>> delivered to CPU0 regardless of what CPU we're sending CHANNELMSG_UNLOAD
>> from. vmbus_wait_for_unload() doesn't account for the fact that in case
>> we're crashing on some other CPU and CPU0 is still alive and operational
>> CHANNELMSG_UNLOAD_RESPONSE will be delivered there completing
>> vmbus_connection.unload_event, our wait on the current CPU will never
>> end.
>
> (Any chance of learning about this behavior from the spec?)
>
>> Do the following:
>> 1) Check for completion_done() in the loop. In case interrupt handler is
>>still alive we'll get the confirmation we need.
>> 
>> 2) Always read CPU0's message page as CHANNELMSG_UNLOAD_RESPONSE will be
>>delivered there. We can race with still-alive interrupt handler doing
>>the same but we don't care as we're checking completion_done() now.
>
> (Yeah, seems better than hv_setup_vmbus_irq(NULL) or other hacks.)
>
>> 3) Cleanup message pages on all CPUs. This is required (at least for the
>>current CPU as we're clearing CPU0 messages now but we may want to bring
>>up additional CPUs on crash) as new messages won't be delivered till we
>>consume what's pending. On boot we'll place message pages somewhere else
>>and we won't be able to read stale messages.
>
> What if HV already set the pending message bit on current message,
> do we get any guarantees that clearing once after UNLOAD_RESPONSE is
> enough?

I think so but I'd like to get a confirmation from K.Y./Alex/Haiyang.

>
>> Signed-off-by: Vitaly Kuznetsov 
>> ---
>
> I had a question about NULL below.  (Parenthesised rants aren't related
> to r-b tag. ;)
>
>>  drivers/hv/channel_mgmt.c | 30 +-
>>  1 file changed, 25 insertions(+), 5 deletions(-)
>> 
>> diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
>> index b10e8f74..5f37057 100644
>> --- a/drivers/hv/channel_mgmt.c
>> +++ b/drivers/hv/channel_mgmt.c
>> @@ -512,14 +512,26 @@ static void init_vp_index(struct vmbus_channel 
>> *channel, const uuid_le *type_gui
>>  
>>  static void vmbus_wait_for_unload(void)
>>  {
>> -int cpu = smp_processor_id();
>> -void *page_addr = hv_context.synic_message_page[cpu];
>> +int cpu;
>> +void *page_addr = hv_context.synic_message_page[0];
>>  struct hv_message *msg = (struct hv_message *)page_addr +
>>VMBUS_MESSAGE_SINT;
>>  struct vmbus_channel_message_header *hdr;
>>  bool unloaded = false;
>>  
>> -while (1) {
>> +/*
>> + * CHANNELMSG_UNLOAD_RESPONSE is always delivered to CPU0. When we're
>> + * crashing on a different CPU let's hope that IRQ handler on CPU0 is
>> + * still functional and vmbus_unload_response() will complete
>> + * vmbus_connection.unload_event. If not, the last thing we can do is
>> + * read message page for CPU0 regardless of what CPU we're on.
>> + */
>> +while (!unloaded) {
>
> (I'd feel a bit safer if this was bounded by some timeout, but all
>  scenarios where this would make a difference are unplausible ...
>  queue_work() not working while the rest is fine is the best one.)
>
>> +if (completion_done(_connection.unload_event)) {
>> +unloaded = true;
>
> (No need to set unloaded when you break.)
>
>> +break;
>> +}
>> +
>>  if (READ_ONCE(msg->header.message_type) == HVMSG_NONE) {
>>  mdelay(10);
>>  continue;
>> @@ -530,9 +542,17 @@ static void vmbus_wait_for_unload(void)
>
> (I'm not a huge fan of the unloaded variable; what about remembering the
>  header/msgtype here ...
>
>>  unloaded = true;
>>  
>>  vmbus_signal_eom(msg);
>
>  and checking its value here?)
>

Sure, but we'll have to use a variable for that ... why would it be
better than 'unloaded'?

>> +}
>>  
>> -if (unloaded)
>> -break;
>> +/*
>> + * We're crashing and already got the UNLOAD_RESPONSE, cleanup all
>> + * maybe-pending messages on all CPUs to be able to receive new
>> + * messages after we reconnect.
>> + */
>> +for_each_online_cpu(cpu) {
>> +page_addr = hv_context.synic_message_page[cpu];
>
> Can't this be NULL?

It can't, we allocate it from hv_synic_alloc() (and we don't support cpu
onlining/offlining on WS2012R2+).

>
>> +msg = (struct hv_message *)page_addr + VMBUS_MESSAGE_SINT;
>> +msg->header.message_type = HVMSG_NONE;
>>  }
>
> (And, this block belongs to a separate function. ;])

I thought about moving it to hv_crash_handler() but then I decided to
leave it here as the need for this fixup is rather an artifact of how we
recieve the message. But I'm flexible here)

-- 
  Vitaly

Re: [PATCH] Drivers: hv: vmbus: handle various crash scenarios

[Vitaly Kuznetsov]

Radim Krcmar  writes:

> 2016-03-18 13:33+0100, Vitaly Kuznetsov:
>> Kdump keeps biting. Turns out CHANNELMSG_UNLOAD_RESPONSE is always
>> delivered to CPU0 regardless of what CPU we're sending CHANNELMSG_UNLOAD
>> from. vmbus_wait_for_unload() doesn't account for the fact that in case
>> we're crashing on some other CPU and CPU0 is still alive and operational
>> CHANNELMSG_UNLOAD_RESPONSE will be delivered there completing
>> vmbus_connection.unload_event, our wait on the current CPU will never
>> end.
>
> (Any chance of learning about this behavior from the spec?)
>
>> Do the following:
>> 1) Check for completion_done() in the loop. In case interrupt handler is
>>still alive we'll get the confirmation we need.
>> 
>> 2) Always read CPU0's message page as CHANNELMSG_UNLOAD_RESPONSE will be
>>delivered there. We can race with still-alive interrupt handler doing
>>the same but we don't care as we're checking completion_done() now.
>
> (Yeah, seems better than hv_setup_vmbus_irq(NULL) or other hacks.)
>
>> 3) Cleanup message pages on all CPUs. This is required (at least for the
>>current CPU as we're clearing CPU0 messages now but we may want to bring
>>up additional CPUs on crash) as new messages won't be delivered till we
>>consume what's pending. On boot we'll place message pages somewhere else
>>and we won't be able to read stale messages.
>
> What if HV already set the pending message bit on current message,
> do we get any guarantees that clearing once after UNLOAD_RESPONSE is
> enough?

I think so but I'd like to get a confirmation from K.Y./Alex/Haiyang.

>
>> Signed-off-by: Vitaly Kuznetsov 
>> ---
>
> I had a question about NULL below.  (Parenthesised rants aren't related
> to r-b tag. ;)
>
>>  drivers/hv/channel_mgmt.c | 30 +-
>>  1 file changed, 25 insertions(+), 5 deletions(-)
>> 
>> diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
>> index b10e8f74..5f37057 100644
>> --- a/drivers/hv/channel_mgmt.c
>> +++ b/drivers/hv/channel_mgmt.c
>> @@ -512,14 +512,26 @@ static void init_vp_index(struct vmbus_channel 
>> *channel, const uuid_le *type_gui
>>  
>>  static void vmbus_wait_for_unload(void)
>>  {
>> -int cpu = smp_processor_id();
>> -void *page_addr = hv_context.synic_message_page[cpu];
>> +int cpu;
>> +void *page_addr = hv_context.synic_message_page[0];
>>  struct hv_message *msg = (struct hv_message *)page_addr +
>>VMBUS_MESSAGE_SINT;
>>  struct vmbus_channel_message_header *hdr;
>>  bool unloaded = false;
>>  
>> -while (1) {
>> +/*
>> + * CHANNELMSG_UNLOAD_RESPONSE is always delivered to CPU0. When we're
>> + * crashing on a different CPU let's hope that IRQ handler on CPU0 is
>> + * still functional and vmbus_unload_response() will complete
>> + * vmbus_connection.unload_event. If not, the last thing we can do is
>> + * read message page for CPU0 regardless of what CPU we're on.
>> + */
>> +while (!unloaded) {
>
> (I'd feel a bit safer if this was bounded by some timeout, but all
>  scenarios where this would make a difference are unplausible ...
>  queue_work() not working while the rest is fine is the best one.)
>
>> +if (completion_done(_connection.unload_event)) {
>> +unloaded = true;
>
> (No need to set unloaded when you break.)
>
>> +break;
>> +}
>> +
>>  if (READ_ONCE(msg->header.message_type) == HVMSG_NONE) {
>>  mdelay(10);
>>  continue;
>> @@ -530,9 +542,17 @@ static void vmbus_wait_for_unload(void)
>
> (I'm not a huge fan of the unloaded variable; what about remembering the
>  header/msgtype here ...
>
>>  unloaded = true;
>>  
>>  vmbus_signal_eom(msg);
>
>  and checking its value here?)
>

Sure, but we'll have to use a variable for that ... why would it be
better than 'unloaded'?

>> +}
>>  
>> -if (unloaded)
>> -break;
>> +/*
>> + * We're crashing and already got the UNLOAD_RESPONSE, cleanup all
>> + * maybe-pending messages on all CPUs to be able to receive new
>> + * messages after we reconnect.
>> + */
>> +for_each_online_cpu(cpu) {
>> +page_addr = hv_context.synic_message_page[cpu];
>
> Can't this be NULL?

It can't, we allocate it from hv_synic_alloc() (and we don't support cpu
onlining/offlining on WS2012R2+).

>
>> +msg = (struct hv_message *)page_addr + VMBUS_MESSAGE_SINT;
>> +msg->header.message_type = HVMSG_NONE;
>>  }
>
> (And, this block belongs to a separate function. ;])

I thought about moving it to hv_crash_handler() but then I decided to
leave it here as the need for this fixup is rather an artifact of how we
recieve the message. But I'm flexible here)

-- 
  Vitaly

Re: [PATCH] mac80211: fix order of flag descriptions

[Joe Perches]

On Fri, 2016-03-18 at 16:35 +, Luis de Bethencourt wrote:
> Fix order of mac80211_rx_flags description to match the enum.
> 
> Signed-off-by: Luis de Bethencourt 
> ---
> Hi,
> 
> I want ahead and fixed the order of the descriptions. checkpatch.pl was giving
> a warning to my previous patch and I had a hunch it was because the wrong 
> order
> breaks the parser. Indeed it does and with this patch below checkpatch.pl does
> not complain about this flag descriptions anymore.

checkpatch complains?  About what?

Re: [PATCH] mac80211: fix order of flag descriptions

[Joe Perches]

On Fri, 2016-03-18 at 16:35 +, Luis de Bethencourt wrote:
> Fix order of mac80211_rx_flags description to match the enum.
> 
> Signed-off-by: Luis de Bethencourt 
> ---
> Hi,
> 
> I want ahead and fixed the order of the descriptions. checkpatch.pl was giving
> a warning to my previous patch and I had a hunch it was because the wrong 
> order
> breaks the parser. Indeed it does and with this patch below checkpatch.pl does
> not complain about this flag descriptions anymore.

checkpatch complains?  About what?

Re: [RFC PATCH v4 3/7] PCI: Ignore resource_alignment if PCI_PROBE_ONLY was set

[Yongji Xie]

On 2016/3/17 0:31, Alex Williamson wrote:

On Mon,  7 Mar 2016 15:48:34 +0800
Yongji Xie  wrote:


The resource_alignment will releases memory resources
allocated by firmware so that kernel can reassign new
resources later on. But this will cause the problem
that no resources can be allocated by kernel if
PCI_PROBE_ONLY was set, e.g. on pSeries platform
because PCI_PROBE_ONLY force kernel to use firmware
setup and not to reassign any resources.

To solve this problem, this patch ignores
resource_alignment if PCI_PROBE_ONLY was set.

Signed-off-by: Yongji Xie 
---
  Documentation/kernel-parameters.txt |2 ++
  drivers/pci/probe.c |3 ++-
  2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index d8b29ab..8028631 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2922,6 +2922,8 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
windows need to be expanded.
noresize: Don't change the resources' sizes when
reassigning alignment.
+   Note that this option will not work if
+   PCI_PROBE_ONLY is set.

How would a user have any idea if this is set?


I found the PCI_PROBE_ONLY is set on pSeries, maple and
arm with "firmware" kernel parameter enabled.

So can we say: Note that this option will not work on pSeries,
maple and arm with "firmware" kernel parameter enabled?
Or do you have any suggestion?

Thanks,
Yongji Xie

Re: [RFC PATCH v4 3/7] PCI: Ignore resource_alignment if PCI_PROBE_ONLY was set

[Yongji Xie]

On 2016/3/17 0:31, Alex Williamson wrote:

On Mon,  7 Mar 2016 15:48:34 +0800
Yongji Xie  wrote:


The resource_alignment will releases memory resources
allocated by firmware so that kernel can reassign new
resources later on. But this will cause the problem
that no resources can be allocated by kernel if
PCI_PROBE_ONLY was set, e.g. on pSeries platform
because PCI_PROBE_ONLY force kernel to use firmware
setup and not to reassign any resources.

To solve this problem, this patch ignores
resource_alignment if PCI_PROBE_ONLY was set.

Signed-off-by: Yongji Xie 
---
  Documentation/kernel-parameters.txt |2 ++
  drivers/pci/probe.c |3 ++-
  2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index d8b29ab..8028631 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2922,6 +2922,8 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
windows need to be expanded.
noresize: Don't change the resources' sizes when
reassigning alignment.
+   Note that this option will not work if
+   PCI_PROBE_ONLY is set.

How would a user have any idea if this is set?


I found the PCI_PROBE_ONLY is set on pSeries, maple and
arm with "firmware" kernel parameter enabled.

So can we say: Note that this option will not work on pSeries,
maple and arm with "firmware" kernel parameter enabled?
Or do you have any suggestion?

Thanks,
Yongji Xie

Re: [PATCH] Revert "arm64: Increase the max granular size"

[Timur Tabi]

Catalin Marinas wrote:

>Yes, that's exactly it.  Ours is an ACPI system, and so we have to have our
>own defconfig for now.  We're holding off on pushing our own defconfig
>changes (enabling drivers, etc) until ACPI is enabled in
>arch/arm64/configs/defconfig.



Is there anything that prevents you from providing a dtb/dts for this
SoC?


We don't have a boot loader capable of passing a device tree to the 
kernel.  It's an ARM Server chip.  It doesn't do device tree.  It's 100% 
ACPI.  We boot with UEFI that configures the system and generates ACPI 
tables.


I just want to make this crystal clear, because it comes up every now 
and then.  The QDF2432 is an ACPI-only SOC with no device tree support 
whatsoever.  Zero.  Zip.  Nada.  It's not an option.


Keep in mind that on an ACPI system like ours, the boot loader (UEFI in 
our case) configures the system extensively.  It does a lot of things 
that the kernel would normally do on a device tree system.  For example, 
pin control is handled completely by UEFI.  The kernel does not set the 
pin muxes or GPIO directions.  That means we don't support dynamic pin 
muxing.  Before the kernel is booted, the GPIO pins are fixed.


We're not going to create an entire device tree from scratch for this 
chip, and then make the extensive modifications necessary to our boot 
loader for parsing and modifying that device tree.  That would take 
months of work, and it would be all throw-away code.


--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.

Re: [PATCH] ARC: build: Turn off -Wmaybe-uninitialized for ARC gcc 4.8

[Arnd Bergmann]

On Friday 18 March 2016 16:13:28 Vineet Gupta wrote:
> On Friday 18 March 2016 03:59 PM, Arnd Bergmann wrote:
> > On Friday 18 March 2016 15:50:11 Vineet Gupta wrote:
> >> Sure, but I prefer this to be only for gcc 4.8 as this warning seems to be
> >> healthy in small doses  At least it keeps the door open for future 
> >> discussion
> >> with gcc guys !
> > 
> > FWIW, testing on ARM with gcc-6.0 -O3, I also get tons of 
> > maybe-uninitialized
> > warnings. It's unlikely that this is architecture specific or fixed in newer
> > compiler versions.
> 
> So we disable this for good just like -Os.
> What a shame - seemed like a reasonable safety net for programming errors.

Yes, it's an immensely useful warning, if you manage to avoid the
false positives.

> >> The following nested construct actually works - does that look OK to you ?
> >>
> >> ARCH_CFLAGS += -O3 $(call cc-ifversion, -lt, 0408, $(call 
> >> cc-disable-warning,maybe-uninitialized,))
> > 
> > Yes, that seems ok.
> 
> There was typo actually -lt needed to be -eq
> 
> > I don't really understand why -O3 is needed though, maybe it's better to
> > assume that it won't be needed in future gcc versions and do
> 
> Not sure what you mean, -O3 for triggering the warnings or -O3 in ARC 
> makefile at all.
> Assuming it's latter, this is how its been forever and was added consciously 
> as
> performance seemed better with -O3 than the default -O2.

I think it's dangerous to use -O3 in one architecture when nothing else
uses it. If you don't have a strong reason to use -O3, maybe just drop that
use the default -O2 -Wmaybe-uninitialized like everyone else does.

On a related note, I have submitted a patch that turns 
CONFIG_CC_OPTIMIZE_FOR_SIZE
into a choice statement, so we actually get the -Wmaybe-uninitialized warnings
in an allyesconfig or allmodconfig build. It would be trivial to extend that
to give the choice between -Os, -O2 and -O3, and then pick -O3 in a defconfig,
over the -O2 default.

Arnd

Re: [PATCH] Revert "arm64: Increase the max granular size"

[Timur Tabi]

Catalin Marinas wrote:

>Yes, that's exactly it.  Ours is an ACPI system, and so we have to have our
>own defconfig for now.  We're holding off on pushing our own defconfig
>changes (enabling drivers, etc) until ACPI is enabled in
>arch/arm64/configs/defconfig.



Is there anything that prevents you from providing a dtb/dts for this
SoC?


We don't have a boot loader capable of passing a device tree to the 
kernel.  It's an ARM Server chip.  It doesn't do device tree.  It's 100% 
ACPI.  We boot with UEFI that configures the system and generates ACPI 
tables.


I just want to make this crystal clear, because it comes up every now 
and then.  The QDF2432 is an ACPI-only SOC with no device tree support 
whatsoever.  Zero.  Zip.  Nada.  It's not an option.


Keep in mind that on an ACPI system like ours, the boot loader (UEFI in 
our case) configures the system extensively.  It does a lot of things 
that the kernel would normally do on a device tree system.  For example, 
pin control is handled completely by UEFI.  The kernel does not set the 
pin muxes or GPIO directions.  That means we don't support dynamic pin 
muxing.  Before the kernel is booted, the GPIO pins are fixed.


We're not going to create an entire device tree from scratch for this 
chip, and then make the extensive modifications necessary to our boot 
loader for parsing and modifying that device tree.  That would take 
months of work, and it would be all throw-away code.


--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.

Re: [PATCH] ARC: build: Turn off -Wmaybe-uninitialized for ARC gcc 4.8

[Arnd Bergmann]

On Friday 18 March 2016 16:13:28 Vineet Gupta wrote:
> On Friday 18 March 2016 03:59 PM, Arnd Bergmann wrote:
> > On Friday 18 March 2016 15:50:11 Vineet Gupta wrote:
> >> Sure, but I prefer this to be only for gcc 4.8 as this warning seems to be
> >> healthy in small doses  At least it keeps the door open for future 
> >> discussion
> >> with gcc guys !
> > 
> > FWIW, testing on ARM with gcc-6.0 -O3, I also get tons of 
> > maybe-uninitialized
> > warnings. It's unlikely that this is architecture specific or fixed in newer
> > compiler versions.
> 
> So we disable this for good just like -Os.
> What a shame - seemed like a reasonable safety net for programming errors.

Yes, it's an immensely useful warning, if you manage to avoid the
false positives.

> >> The following nested construct actually works - does that look OK to you ?
> >>
> >> ARCH_CFLAGS += -O3 $(call cc-ifversion, -lt, 0408, $(call 
> >> cc-disable-warning,maybe-uninitialized,))
> > 
> > Yes, that seems ok.
> 
> There was typo actually -lt needed to be -eq
> 
> > I don't really understand why -O3 is needed though, maybe it's better to
> > assume that it won't be needed in future gcc versions and do
> 
> Not sure what you mean, -O3 for triggering the warnings or -O3 in ARC 
> makefile at all.
> Assuming it's latter, this is how its been forever and was added consciously 
> as
> performance seemed better with -O3 than the default -O2.

I think it's dangerous to use -O3 in one architecture when nothing else
uses it. If you don't have a strong reason to use -O3, maybe just drop that
use the default -O2 -Wmaybe-uninitialized like everyone else does.

On a related note, I have submitted a patch that turns 
CONFIG_CC_OPTIMIZE_FOR_SIZE
into a choice statement, so we actually get the -Wmaybe-uninitialized warnings
in an allyesconfig or allmodconfig build. It would be trivial to extend that
to give the choice between -Os, -O2 and -O3, and then pick -O3 in a defconfig,
over the -O2 default.

Arnd

[PART1 RFC v3 00/12] KVM: x86: Introduce SVM AVIC support

[Suravee Suthikulpanit]

CHANGES FROM RFCv2:
==
(https://lkml.org/lkml/2016/3/4/746)
* Do not use bit-field in VMCB.
* Get rid of struct svm_vm_data, and consolidate the struct members
  into struct kvm_arch.
* Do not abbreviate AVIC vmexit function and structure names.
* Adding VM init/uninit function hooks and use it to initialize /
  uninitialize per-VM data structures.  
* Simplify AVIC backing page allocation to use the emulated lapic
  register page.
* Introduce kvm_vcpu_wake_up() (from Radim).
* Clean up AVIC vmexit handling functions.
* Replace pr_debug with new AVIC tracepoints.
* Use per-vcpu AVIC enable check (besides the global avic flag).
* Add smb_mb__after_atomic() in svm_deliver_avic_intr.
* Get rid of iommu related code for now.

CHANGES FROM RFCv1:
==
(https://lkml.org/lkml/2016/2/12/225)
* Rebased from tip.git
* Use the vAPIC backing page as the emulated LAPIC register page.
* Clarified with HW engineer that Avic sets the IRR of all the cores
  targeted whether they are running or not. It sends doorbells to the
  ones that are running to get them to evaluate their new state.
  If one or more weren't running it does the VMEXIT to indicate that
  the host needs to go run the not running guests. It gives it the
  ID of one of the guests that it observed not running which should
  be enough of a hint for the hypervisor to track them all down.
* Rewrite the logic for handling AVIC_INCOMPLETE_IPI #vmexit for
  IPI target not running case based on information above.
* Rewrite the logic in avic_vcpu_load() and avic_set_running().
* Rewrite the interrupt injection to remove the avic_pending_cnt
  variable.
* Adding vcpu blocking/unblocking function hooks

GITHUB
==
Latest git tree can be found at:
http://github.com/ssuthiku/linux.gitavic_part1_rfc_v3

OVERVIEW

This patch set is the first of the two-part patch series to introduce 
the new AMD Advance Virtual Interrupt Controller (AVIC) support.

Basically, SVM AVIC hardware virtualizes local APIC registers of each
vCPU via the virtual APIC (vAPIC) backing page. This allows guest access
to certain APIC registers without the need to emulate the hardware behavior
in the hypervisor. More information about AVIC can be found in the
AMD64 Architecture Programmer’s Manual Volume 2 - System Programming.

  http://support.amd.com/TechDocs/24593.pdf

For SVM AVIC, we extend the existing kvm_amd driver to:
  * Check CPUID to detect AVIC support in the processor
  * Program new fields in VMCB to enable AVIC
  * Introduce new AVIC data structures and add code to manage them
  * Handle two new AVIC #VMEXITs
  * Add new interrupt intjection code using vAPIC backing page
instead of the existing V_IRQ, V_INTR_PRIO, V_INTR_VECTOR,
and V_IGN_TPR fields

Currently, this patch series does not enable AVIC by default.
Users can enable SVM AVIC by specifying avic=1 during insmod kvm-amd.

Later, in part 2, we will introduce the IOMMU AVIC support, which
provides speed up for PCI device pass-through use case by allowing
the IOMMU hardware to inject interrupt directly into the guest via
the vAPIC backing page.

PERFORMANCE RESULTS
===
Currently, AVIC is supported in the AMD family 15h models 6Xh
(Carrizo) processors. Therefore, it is used to collect the 
perforamance data shown below.

Generaly, SVM AVIC alone (w/o IOMMU AVIC) should provide speedup for
IPI interrupt since hypervisor does not require VMEXIT to inject
these interrupts. Also, it should speed up the case when hypervisor
wants to inject an interrupt into a running guest by setting the
corresponded IRR bit in the vAPIC backing page and trigger
AVIC_DOORBELL MSR.

IPI PERFORMANCE
===

* BENCHMARK 1: HACKBENCH
For IPI, I have collected some performance number on 2 and 4 CPU running
hackbech with the following detail:

  hackbench -p -l 10
  Running in process mode with 10 groups using 40 file descriptors each (== 400 
tasks)
  Each sender will pass 10 messages of 100 bytes

|2 vcpus |4 vcpus 
 
 Vanila |  273.76|  190.21  
  AVIC disabled |  260.51 (~5%)  |  184.40 (~5%)
   AVIC |  248.53 (~10%) |  155.01 (~20%)

OVERALL PERFORMANCE
===
Enabling AVIC should helps speeding up workloads, which generate
large amount of interrupts. However, it requires additional logics to
maintain AVIC-specific data structures during vCPU load/unload
due to vcpu scheduling.

The goal is to minimize the overhead of AVIC in most cases, so that
we can achieve equivalent or improvement in overall performance when
enabling AVIC.

* BENCHMARK 1: TAR DECOMPRESSION
This test measures the average running time (of 10 runs) of the following
tar decompression command with 1, 2, and 4 vcpus.

   tar xf linux-4.3.3.tar.xz

| 

[PART1 RFC v3 00/12] KVM: x86: Introduce SVM AVIC support

[Suravee Suthikulpanit]

CHANGES FROM RFCv2:
==
(https://lkml.org/lkml/2016/3/4/746)
* Do not use bit-field in VMCB.
* Get rid of struct svm_vm_data, and consolidate the struct members
  into struct kvm_arch.
* Do not abbreviate AVIC vmexit function and structure names.
* Adding VM init/uninit function hooks and use it to initialize /
  uninitialize per-VM data structures.  
* Simplify AVIC backing page allocation to use the emulated lapic
  register page.
* Introduce kvm_vcpu_wake_up() (from Radim).
* Clean up AVIC vmexit handling functions.
* Replace pr_debug with new AVIC tracepoints.
* Use per-vcpu AVIC enable check (besides the global avic flag).
* Add smb_mb__after_atomic() in svm_deliver_avic_intr.
* Get rid of iommu related code for now.

CHANGES FROM RFCv1:
==
(https://lkml.org/lkml/2016/2/12/225)
* Rebased from tip.git
* Use the vAPIC backing page as the emulated LAPIC register page.
* Clarified with HW engineer that Avic sets the IRR of all the cores
  targeted whether they are running or not. It sends doorbells to the
  ones that are running to get them to evaluate their new state.
  If one or more weren't running it does the VMEXIT to indicate that
  the host needs to go run the not running guests. It gives it the
  ID of one of the guests that it observed not running which should
  be enough of a hint for the hypervisor to track them all down.
* Rewrite the logic for handling AVIC_INCOMPLETE_IPI #vmexit for
  IPI target not running case based on information above.
* Rewrite the logic in avic_vcpu_load() and avic_set_running().
* Rewrite the interrupt injection to remove the avic_pending_cnt
  variable.
* Adding vcpu blocking/unblocking function hooks

GITHUB
==
Latest git tree can be found at:
http://github.com/ssuthiku/linux.gitavic_part1_rfc_v3

OVERVIEW

This patch set is the first of the two-part patch series to introduce 
the new AMD Advance Virtual Interrupt Controller (AVIC) support.

Basically, SVM AVIC hardware virtualizes local APIC registers of each
vCPU via the virtual APIC (vAPIC) backing page. This allows guest access
to certain APIC registers without the need to emulate the hardware behavior
in the hypervisor. More information about AVIC can be found in the
AMD64 Architecture Programmer’s Manual Volume 2 - System Programming.

  http://support.amd.com/TechDocs/24593.pdf

For SVM AVIC, we extend the existing kvm_amd driver to:
  * Check CPUID to detect AVIC support in the processor
  * Program new fields in VMCB to enable AVIC
  * Introduce new AVIC data structures and add code to manage them
  * Handle two new AVIC #VMEXITs
  * Add new interrupt intjection code using vAPIC backing page
instead of the existing V_IRQ, V_INTR_PRIO, V_INTR_VECTOR,
and V_IGN_TPR fields

Currently, this patch series does not enable AVIC by default.
Users can enable SVM AVIC by specifying avic=1 during insmod kvm-amd.

Later, in part 2, we will introduce the IOMMU AVIC support, which
provides speed up for PCI device pass-through use case by allowing
the IOMMU hardware to inject interrupt directly into the guest via
the vAPIC backing page.

PERFORMANCE RESULTS
===
Currently, AVIC is supported in the AMD family 15h models 6Xh
(Carrizo) processors. Therefore, it is used to collect the 
perforamance data shown below.

Generaly, SVM AVIC alone (w/o IOMMU AVIC) should provide speedup for
IPI interrupt since hypervisor does not require VMEXIT to inject
these interrupts. Also, it should speed up the case when hypervisor
wants to inject an interrupt into a running guest by setting the
corresponded IRR bit in the vAPIC backing page and trigger
AVIC_DOORBELL MSR.

IPI PERFORMANCE
===

* BENCHMARK 1: HACKBENCH
For IPI, I have collected some performance number on 2 and 4 CPU running
hackbech with the following detail:

  hackbench -p -l 10
  Running in process mode with 10 groups using 40 file descriptors each (== 400 
tasks)
  Each sender will pass 10 messages of 100 bytes

|2 vcpus |4 vcpus 
 
 Vanila |  273.76|  190.21  
  AVIC disabled |  260.51 (~5%)  |  184.40 (~5%)
   AVIC |  248.53 (~10%) |  155.01 (~20%)

OVERALL PERFORMANCE
===
Enabling AVIC should helps speeding up workloads, which generate
large amount of interrupts. However, it requires additional logics to
maintain AVIC-specific data structures during vCPU load/unload
due to vcpu scheduling.

The goal is to minimize the overhead of AVIC in most cases, so that
we can achieve equivalent or improvement in overall performance when
enabling AVIC.

* BENCHMARK 1: TAR DECOMPRESSION
This test measures the average running time (of 10 runs) of the following
tar decompression command with 1, 2, and 4 vcpus.

   tar xf linux-4.3.3.tar.xz

| 

Re: [PATCH 2/2] pinctrl: sh-pfc: IPSRx and MOD_SELx should be set before GPSRx

[Kuninori Morimoto]

Hi Geert

> > From: Kuninori Morimoto 
> >
> > Gen2 / Gen3 datasheet will have below note in next version.
> > This patch follows this note.
> >
> > IPSRx and MOD_SELx registers shall be set before setting GPSRx
> > registers in case that they need to be configured.
> > MOD_SELx registers can be set either earlier or later than setting
> > IPSRx registers.
> 
> Does this note apply to R-Car Gen1 and SH7734, too?
> Both use the PINMUX_IPSR_MSEL() macro.

Yes, this note can be match for these.
But I'm not sure whether these datasheet will be updated.

Re: [PATCH 2/2] pinctrl: sh-pfc: IPSRx and MOD_SELx should be set before GPSRx

[Kuninori Morimoto]

Hi Geert

> > From: Kuninori Morimoto 
> >
> > Gen2 / Gen3 datasheet will have below note in next version.
> > This patch follows this note.
> >
> > IPSRx and MOD_SELx registers shall be set before setting GPSRx
> > registers in case that they need to be configured.
> > MOD_SELx registers can be set either earlier or later than setting
> > IPSRx registers.
> 
> Does this note apply to R-Car Gen1 and SH7734, too?
> Both use the PINMUX_IPSR_MSEL() macro.

Yes, this note can be match for these.
But I'm not sure whether these datasheet will be updated.

[PATCH] mmc: card: don't use PF_MEMALLOC

[Martin Kepplinger]

PF_MEMALLOC is assigned to processes by mm. If drivers prevent memory
reclaim and mm is not in control, strange hang-up or OOM Killer invocation
could happen.

Signed-off-by: Martin Kepplinger 
---
I use MMC cards with this change perfectly fine. As I understand it,
even *if* PF_MEMALLOC has a real reason to be here, I think it should
be very well documented.


 drivers/mmc/card/queue.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
index 6f4323c..be71249 100644
--- a/drivers/mmc/card/queue.c
+++ b/drivers/mmc/card/queue.c
@@ -51,8 +51,6 @@ static int mmc_queue_thread(void *d)
struct mmc_queue *mq = d;
struct request_queue *q = mq->queue;
 
-   current->flags |= PF_MEMALLOC;
-
down(>thread_sem);
do {
struct request *req = NULL;
-- 
2.1.4

[PATCH] mmc: card: don't use PF_MEMALLOC

[Martin Kepplinger]

PF_MEMALLOC is assigned to processes by mm. If drivers prevent memory
reclaim and mm is not in control, strange hang-up or OOM Killer invocation
could happen.

Signed-off-by: Martin Kepplinger 
---
I use MMC cards with this change perfectly fine. As I understand it,
even *if* PF_MEMALLOC has a real reason to be here, I think it should
be very well documented.


 drivers/mmc/card/queue.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
index 6f4323c..be71249 100644
--- a/drivers/mmc/card/queue.c
+++ b/drivers/mmc/card/queue.c
@@ -51,8 +51,6 @@ static int mmc_queue_thread(void *d)
struct mmc_queue *mq = d;
struct request_queue *q = mq->queue;
 
-   current->flags |= PF_MEMALLOC;
-
down(>thread_sem);
do {
struct request *req = NULL;
-- 
2.1.4

[PATCH] cpufreq: rockchip: add driver

[Feng Xiao]

This driver will directly use cpufreq-dt driver as backend.

As there is not a generic devicetree board file(rockchip.c)
on ARM64 architecture, so remove platform_device_register_simple
in rockchip.c and add a new cpufreq driver to support for all
Rockchip SoCs.

Signed-off-by: Feng Xiao 
---
 arch/arm/mach-rockchip/rockchip.c  |  1 -
 drivers/cpufreq/Kconfig.arm| 10 ++
 drivers/cpufreq/Makefile   |  1 +
 drivers/cpufreq/rockchip-cpufreq.c | 36 
 4 files changed, 47 insertions(+), 1 deletion(-)
 create mode 100644 drivers/cpufreq/rockchip-cpufreq.c

diff --git a/arch/arm/mach-rockchip/rockchip.c 
b/arch/arm/mach-rockchip/rockchip.c
index 3f07cc5..beb71da 100644
--- a/arch/arm/mach-rockchip/rockchip.c
+++ b/arch/arm/mach-rockchip/rockchip.c
@@ -74,7 +74,6 @@ static void __init rockchip_dt_init(void)
 {
rockchip_suspend_init();
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
-   platform_device_register_simple("cpufreq-dt", 0, NULL, 0);
 }
 
 static const char * const rockchip_board_dt_compat[] = {
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 14b1f93..1786315 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -97,6 +97,16 @@ config ARM_OMAP2PLUS_CPUFREQ
depends on ARCH_OMAP2PLUS
default ARCH_OMAP2PLUS
 
+config ARM_ROCKCHIP_CPUFREQ
+   tristate "Rockchip CPUfreq driver"
+   depends on ARCH_ROCKCHIP && CPUFREQ_DT
+   select PM_OPP
+   help
+ This adds the CPUFreq driver support for Rockchip SoCs.
+ The driver will directly use cpufreq-dt driver as backend.
+
+ If in doubt, say N.
+
 config ARM_S3C_CPUFREQ
bool
help
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 9e63fb1..91d8bb7 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_ARM_MT8173_CPUFREQ)  += mt8173-cpufreq.o
 obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)+= omap-cpufreq.o
 obj-$(CONFIG_ARM_PXA2xx_CPUFREQ)   += pxa2xx-cpufreq.o
 obj-$(CONFIG_PXA3xx)   += pxa3xx-cpufreq.o
+obj-$(CONFIG_ARM_ROCKCHIP_CPUFREQ) += rockchip-cpufreq.o
 obj-$(CONFIG_ARM_S3C24XX_CPUFREQ)  += s3c24xx-cpufreq.o
 obj-$(CONFIG_ARM_S3C24XX_CPUFREQ_DEBUGFS) += s3c24xx-cpufreq-debugfs.o
 obj-$(CONFIG_ARM_S3C2410_CPUFREQ)  += s3c2410-cpufreq.o
diff --git a/drivers/cpufreq/rockchip-cpufreq.c 
b/drivers/cpufreq/rockchip-cpufreq.c
new file mode 100644
index 000..ecbadcd
--- /dev/null
+++ b/drivers/cpufreq/rockchip-cpufreq.c
@@ -0,0 +1,36 @@
+/*
+ * Rockchip Platforms CPUFreq Support
+ *
+ * Copyright (C) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Feng Xiao 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int __init rockchip_cpufreq_driver_init(void)
+{
+   struct platform_device *pdev;
+
+   pdev = platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
+   return PTR_ERR_OR_ZERO(pdev);
+}
+module_init(rockchip_cpufreq_driver_init);
+
+MODULE_AUTHOR("Feng Xiao ");
+MODULE_DESCRIPTION("Rockchip cpufreq driver");
+MODULE_LICENSE("GPL v2");
-- 
1.9.1

[PATCH] cpufreq: rockchip: add driver

[Feng Xiao]

This driver will directly use cpufreq-dt driver as backend.

As there is not a generic devicetree board file(rockchip.c)
on ARM64 architecture, so remove platform_device_register_simple
in rockchip.c and add a new cpufreq driver to support for all
Rockchip SoCs.

Signed-off-by: Feng Xiao 
---
 arch/arm/mach-rockchip/rockchip.c  |  1 -
 drivers/cpufreq/Kconfig.arm| 10 ++
 drivers/cpufreq/Makefile   |  1 +
 drivers/cpufreq/rockchip-cpufreq.c | 36 
 4 files changed, 47 insertions(+), 1 deletion(-)
 create mode 100644 drivers/cpufreq/rockchip-cpufreq.c

diff --git a/arch/arm/mach-rockchip/rockchip.c 
b/arch/arm/mach-rockchip/rockchip.c
index 3f07cc5..beb71da 100644
--- a/arch/arm/mach-rockchip/rockchip.c
+++ b/arch/arm/mach-rockchip/rockchip.c
@@ -74,7 +74,6 @@ static void __init rockchip_dt_init(void)
 {
rockchip_suspend_init();
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
-   platform_device_register_simple("cpufreq-dt", 0, NULL, 0);
 }
 
 static const char * const rockchip_board_dt_compat[] = {
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 14b1f93..1786315 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -97,6 +97,16 @@ config ARM_OMAP2PLUS_CPUFREQ
depends on ARCH_OMAP2PLUS
default ARCH_OMAP2PLUS
 
+config ARM_ROCKCHIP_CPUFREQ
+   tristate "Rockchip CPUfreq driver"
+   depends on ARCH_ROCKCHIP && CPUFREQ_DT
+   select PM_OPP
+   help
+ This adds the CPUFreq driver support for Rockchip SoCs.
+ The driver will directly use cpufreq-dt driver as backend.
+
+ If in doubt, say N.
+
 config ARM_S3C_CPUFREQ
bool
help
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 9e63fb1..91d8bb7 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_ARM_MT8173_CPUFREQ)  += mt8173-cpufreq.o
 obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)+= omap-cpufreq.o
 obj-$(CONFIG_ARM_PXA2xx_CPUFREQ)   += pxa2xx-cpufreq.o
 obj-$(CONFIG_PXA3xx)   += pxa3xx-cpufreq.o
+obj-$(CONFIG_ARM_ROCKCHIP_CPUFREQ) += rockchip-cpufreq.o
 obj-$(CONFIG_ARM_S3C24XX_CPUFREQ)  += s3c24xx-cpufreq.o
 obj-$(CONFIG_ARM_S3C24XX_CPUFREQ_DEBUGFS) += s3c24xx-cpufreq-debugfs.o
 obj-$(CONFIG_ARM_S3C2410_CPUFREQ)  += s3c2410-cpufreq.o
diff --git a/drivers/cpufreq/rockchip-cpufreq.c 
b/drivers/cpufreq/rockchip-cpufreq.c
new file mode 100644
index 000..ecbadcd
--- /dev/null
+++ b/drivers/cpufreq/rockchip-cpufreq.c
@@ -0,0 +1,36 @@
+/*
+ * Rockchip Platforms CPUFreq Support
+ *
+ * Copyright (C) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Feng Xiao 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int __init rockchip_cpufreq_driver_init(void)
+{
+   struct platform_device *pdev;
+
+   pdev = platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
+   return PTR_ERR_OR_ZERO(pdev);
+}
+module_init(rockchip_cpufreq_driver_init);
+
+MODULE_AUTHOR("Feng Xiao ");
+MODULE_DESCRIPTION("Rockchip cpufreq driver");
+MODULE_LICENSE("GPL v2");
-- 
1.9.1

Re: linux-next: build failure after merge of the kbuild tree

[Michal Marek]

On 2016-03-16 12:29, Stephen Rothwell wrote:
> Hi Michal,
> 
> On Wed, 16 Mar 2016 08:56:50 +0100 Michal Marek  wrote:
>>
>> Right. Stephen, could you perhaps move the kbuild tree down in your list
>> a bit, so that the fixes are present?
> 
> Done.
> 
> Now you just need to make sure Linus gets them in the right order :-)

That's the plan :).

Michal

Re: linux-next: build failure after merge of the kbuild tree

[Michal Marek]

On 2016-03-16 12:29, Stephen Rothwell wrote:
> Hi Michal,
> 
> On Wed, 16 Mar 2016 08:56:50 +0100 Michal Marek  wrote:
>>
>> Right. Stephen, could you perhaps move the kbuild tree down in your list
>> a bit, so that the fixes are present?
> 
> Done.
> 
> Now you just need to make sure Linus gets them in the right order :-)

That's the plan :).

Michal

Re: [PATCH] sound/usb: Fix memory leak in media_snd_stream_delete() during unbind

[Shuah Khan]

Adding Takashi Iwai

On 03/16/2016 08:58 PM, Shuah Khan wrote:
> media_snd_stream_delete() fails to release resources during unbind. This
> leads to use-after-free in media_gobj_create() on a subsequent bind.
> 
> [ 1445.086410] BUG: KASAN: use-after-free in media_gobj_create+0x3a1/0x470 
> [media] at addr 8801ead49998
> 
> [ 1445.086771] Call Trace:
> [ 1445.086779]  [] dump_stack+0x67/0x94
> [ 1445.086785]  [] print_trailer+0xf9/0x150
> [ 1445.086790]  [] object_err+0x34/0x40
> [ 1445.086796]  [] kasan_report_error+0x221/0x530
> [ 1445.086803]  [] __asan_report_store8_noabort+0x43/0x50
> [ 1445.086813]  [] ? media_gobj_create+0x3a1/0x470 [media]
> [ 1445.086822]  [] media_gobj_create+0x3a1/0x470 [media]
> [ 1445.086831]  [] media_device_register_entity+0x259/0x6f0 
> [media]
> [ 1445.086841]  [] ? 
> media_device_unregister_entity_notify+0x100/0x100 [media]
> [ 1445.086846]  [] ? ___slab_alloc+0x172/0x500
> [ 1445.086854]  [] ? mark_held_locks+0xc8/0x120
> [ 1445.086859]  [] ? __slab_alloc+0x50/0x70
> [ 1445.086878]  [] ? media_snd_mixer_init+0x16c/0x500 
> [snd_usb_audio]
> [ 1445.086884]  [] ? kasan_unpoison_shadow+0x36/0x50
> [ 1445.086890]  [] ? kasan_unpoison_shadow+0x36/0x50
> [ 1445.086895]  [] ? kasan_kmalloc+0x5e/0x70
> 
> Signed-off-by: Shuah Khan 
> ---
>  sound/usb/media.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sound/usb/media.c b/sound/usb/media.c
> index 44a5de9..0d03773 100644
> --- a/sound/usb/media.c
> +++ b/sound/usb/media.c
> @@ -135,7 +135,7 @@ void media_snd_stream_delete(struct snd_usb_substream 
> *subs)
>   if (mctl && mctl->media_dev) {
>   struct media_device *mdev;
>  
> - mdev = subs->stream->chip->media_dev;
> + mdev = mctl->media_dev;
>   if (mdev && media_devnode_is_registered(>devnode)) {
>   media_devnode_remove(mctl->intf_devnode);
>   media_device_unregister_entity(>media_entity);
> 


-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978

Re: [PATCH] sound/usb: Fix memory leak in media_snd_stream_delete() during unbind

[Shuah Khan]

Adding Takashi Iwai

On 03/16/2016 08:58 PM, Shuah Khan wrote:
> media_snd_stream_delete() fails to release resources during unbind. This
> leads to use-after-free in media_gobj_create() on a subsequent bind.
> 
> [ 1445.086410] BUG: KASAN: use-after-free in media_gobj_create+0x3a1/0x470 
> [media] at addr 8801ead49998
> 
> [ 1445.086771] Call Trace:
> [ 1445.086779]  [] dump_stack+0x67/0x94
> [ 1445.086785]  [] print_trailer+0xf9/0x150
> [ 1445.086790]  [] object_err+0x34/0x40
> [ 1445.086796]  [] kasan_report_error+0x221/0x530
> [ 1445.086803]  [] __asan_report_store8_noabort+0x43/0x50
> [ 1445.086813]  [] ? media_gobj_create+0x3a1/0x470 [media]
> [ 1445.086822]  [] media_gobj_create+0x3a1/0x470 [media]
> [ 1445.086831]  [] media_device_register_entity+0x259/0x6f0 
> [media]
> [ 1445.086841]  [] ? 
> media_device_unregister_entity_notify+0x100/0x100 [media]
> [ 1445.086846]  [] ? ___slab_alloc+0x172/0x500
> [ 1445.086854]  [] ? mark_held_locks+0xc8/0x120
> [ 1445.086859]  [] ? __slab_alloc+0x50/0x70
> [ 1445.086878]  [] ? media_snd_mixer_init+0x16c/0x500 
> [snd_usb_audio]
> [ 1445.086884]  [] ? kasan_unpoison_shadow+0x36/0x50
> [ 1445.086890]  [] ? kasan_unpoison_shadow+0x36/0x50
> [ 1445.086895]  [] ? kasan_kmalloc+0x5e/0x70
> 
> Signed-off-by: Shuah Khan 
> ---
>  sound/usb/media.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sound/usb/media.c b/sound/usb/media.c
> index 44a5de9..0d03773 100644
> --- a/sound/usb/media.c
> +++ b/sound/usb/media.c
> @@ -135,7 +135,7 @@ void media_snd_stream_delete(struct snd_usb_substream 
> *subs)
>   if (mctl && mctl->media_dev) {
>   struct media_device *mdev;
>  
> - mdev = subs->stream->chip->media_dev;
> + mdev = mctl->media_dev;
>   if (mdev && media_devnode_is_registered(>devnode)) {
>   media_devnode_remove(mctl->intf_devnode);
>   media_device_unregister_entity(>media_entity);
> 


-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978

Re: [ANNOUNCE] 3.14.64-rt67

[Josh Cartwright]

On Tue, Mar 15, 2016 at 10:50:31PM -0400, Paul Gortmaker wrote:
> On Tue, Mar 15, 2016 at 7:25 PM, Paul Gortmaker
>  wrote:
> > On Tue, Mar 15, 2016 at 5:45 PM, Paul Gortmaker
> >  wrote:
> >> On Mon, Mar 14, 2016 at 11:49 AM, Steven Rostedt  
> >> wrote:
> >>>
> >>> Dear RT Folks,
> >>>
> >>> 3.14 release on PI(E) Day!
> >>>
> >>> I'm pleased to announce the 3.14.64-rt67 stable release.
> >>
> >> Testing this with what is largely a x86-64 defconfig but with RT_FULL,
> >> I now see:
> >>
> >> root@dell760-paul:~# dmesg|grep NOH
> >> [8.605854] NOHZ: local_softirq_pending 100
> >> [8.732677] NOHZ: local_softirq_pending 100
> >> [8.852729] NOHZ: local_softirq_pending 100
> >> [8.963964] NOHZ: local_softirq_pending 100
> >> [9.061892] NOHZ: local_softirq_pending 100
> >> [9.184921] NOHZ: local_softirq_pending 100
> >> [9.370958] NOHZ: local_softirq_pending 100
> >> [9.657811] NOHZ: local_softirq_pending 100
> >> [9.942631] NOHZ: local_softirq_pending 100
> >> [   10.783710] NOHZ: local_softirq_pending 100
> >> root@dell760-paul:~#
> >>
> >> ...early in boot (we cap them after ~10 msgs).
> >>
> >> I think 100 is RCU if I did my bit counting properly; remind
> >> me to submit a patch that uses the human readable names.

As mentioned on IRC, 100 is HRTIMER_SOFTIRQ, which I think makes more
sense...at least it meshes better with the commit you identified as
being problematic.

> >>
> >> I had a good hunch which commit was responsible but I did
> >> a check of it and the one directly underneath it to be sure,
> >> and the latter boots w/o any pending messages.
> >>
> >> git log --oneline  v3.14-rt ^v3.14.64
> >> [...]
> >> 0a80a6849f19 latencyhist: disable jump-labels
> >> a884ef48e1ca net: provide a way to delegate processing a softirq to 
> >> ksoftirqd
> >> 780d7ca2fdb0 softirq: split timer softirqs out of ksoftirqd<--
> >> *** fail ***

Looking at the places where HRTIMER_SOFTIRQ is raised, it did look like
there is at least one case where a hrtimer started from process context
would cause HRTIMER_SOFTIRQ to be set pending, but the associated
ktimersoftirq/N not woken, which seems problematic.

  Josh

diff --git a/kernel/softirq.c b/kernel/softirq.c
index 7abfdab..d91f378 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -749,7 +749,7 @@ void raise_softirq_irqoff(unsigned int nr)
 *
 */
if (!current->softirq_nestcnt)
-   wakeup_softirqd();
+   wakeup_proper_softirq(nr);
 }
 
 static inline int ksoftirqd_softirq_pending(void)

Re: [ANNOUNCE] 3.14.64-rt67

[Josh Cartwright]

On Tue, Mar 15, 2016 at 10:50:31PM -0400, Paul Gortmaker wrote:
> On Tue, Mar 15, 2016 at 7:25 PM, Paul Gortmaker
>  wrote:
> > On Tue, Mar 15, 2016 at 5:45 PM, Paul Gortmaker
> >  wrote:
> >> On Mon, Mar 14, 2016 at 11:49 AM, Steven Rostedt  
> >> wrote:
> >>>
> >>> Dear RT Folks,
> >>>
> >>> 3.14 release on PI(E) Day!
> >>>
> >>> I'm pleased to announce the 3.14.64-rt67 stable release.
> >>
> >> Testing this with what is largely a x86-64 defconfig but with RT_FULL,
> >> I now see:
> >>
> >> root@dell760-paul:~# dmesg|grep NOH
> >> [8.605854] NOHZ: local_softirq_pending 100
> >> [8.732677] NOHZ: local_softirq_pending 100
> >> [8.852729] NOHZ: local_softirq_pending 100
> >> [8.963964] NOHZ: local_softirq_pending 100
> >> [9.061892] NOHZ: local_softirq_pending 100
> >> [9.184921] NOHZ: local_softirq_pending 100
> >> [9.370958] NOHZ: local_softirq_pending 100
> >> [9.657811] NOHZ: local_softirq_pending 100
> >> [9.942631] NOHZ: local_softirq_pending 100
> >> [   10.783710] NOHZ: local_softirq_pending 100
> >> root@dell760-paul:~#
> >>
> >> ...early in boot (we cap them after ~10 msgs).
> >>
> >> I think 100 is RCU if I did my bit counting properly; remind
> >> me to submit a patch that uses the human readable names.

As mentioned on IRC, 100 is HRTIMER_SOFTIRQ, which I think makes more
sense...at least it meshes better with the commit you identified as
being problematic.

> >>
> >> I had a good hunch which commit was responsible but I did
> >> a check of it and the one directly underneath it to be sure,
> >> and the latter boots w/o any pending messages.
> >>
> >> git log --oneline  v3.14-rt ^v3.14.64
> >> [...]
> >> 0a80a6849f19 latencyhist: disable jump-labels
> >> a884ef48e1ca net: provide a way to delegate processing a softirq to 
> >> ksoftirqd
> >> 780d7ca2fdb0 softirq: split timer softirqs out of ksoftirqd<--
> >> *** fail ***

Looking at the places where HRTIMER_SOFTIRQ is raised, it did look like
there is at least one case where a hrtimer started from process context
would cause HRTIMER_SOFTIRQ to be set pending, but the associated
ktimersoftirq/N not woken, which seems problematic.

  Josh

diff --git a/kernel/softirq.c b/kernel/softirq.c
index 7abfdab..d91f378 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -749,7 +749,7 @@ void raise_softirq_irqoff(unsigned int nr)
 *
 */
if (!current->softirq_nestcnt)
-   wakeup_softirqd();
+   wakeup_proper_softirq(nr);
 }
 
 static inline int ksoftirqd_softirq_pending(void)

Re: arch/x86/um/user-offsets.c:8:24: fatal error: asm/ptrace.h: No such file or directory

[Krzysztof Kozlowski]

On 18.03.2016 12:19, Philip Li wrote:
> On Mon, Mar 14, 2016 at 09:53:06AM +0900, Krzysztof Kozlowski wrote:
>> On Sun, Mar 13, 2016 at 7:45 AM, kbuild test robot
>>  wrote:
>>> Hi Al,
>>>
>>> FYI, the error/warning still remains.
>>>
>>> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
>>> master
>>> head:   03c668a93187fe7fba9464f96fbe7c22eebd9897
>>> commit: 5c48b108ecbf6505d929e64d50dace13ac2bdf34 um: take arch/um/sys-x86 
>>> to arch/x86/um
>>> date:   4 years, 4 months ago
>>> config: um-i386_defconfig (attached as .config)
>>> reproduce:
>>> git checkout 5c48b108ecbf6505d929e64d50dace13ac2bdf34
>>> # save the attached .config to linux build tree
>>> make ARCH=um SUBARCH=i386
>>>
>>
>> Hi,
>>
>> The code is correct. The build machine lacks asm/ptrace.h for i386
>> (e.g. /usr/include/i386-linux-gnu/asm/ptrace.h). For example on Ubuntu
>> this is provided by linux-libc-dev:i386.
> 
> sorry for late response, we have installed linux-libc-dev:i386 on our build 
> environment to have this head file.

... and does it help? Is the issue fixed?

Best regards,
Krzysztof

Re: arch/x86/um/user-offsets.c:8:24: fatal error: asm/ptrace.h: No such file or directory

[Krzysztof Kozlowski]

On 18.03.2016 12:19, Philip Li wrote:
> On Mon, Mar 14, 2016 at 09:53:06AM +0900, Krzysztof Kozlowski wrote:
>> On Sun, Mar 13, 2016 at 7:45 AM, kbuild test robot
>>  wrote:
>>> Hi Al,
>>>
>>> FYI, the error/warning still remains.
>>>
>>> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
>>> master
>>> head:   03c668a93187fe7fba9464f96fbe7c22eebd9897
>>> commit: 5c48b108ecbf6505d929e64d50dace13ac2bdf34 um: take arch/um/sys-x86 
>>> to arch/x86/um
>>> date:   4 years, 4 months ago
>>> config: um-i386_defconfig (attached as .config)
>>> reproduce:
>>> git checkout 5c48b108ecbf6505d929e64d50dace13ac2bdf34
>>> # save the attached .config to linux build tree
>>> make ARCH=um SUBARCH=i386
>>>
>>
>> Hi,
>>
>> The code is correct. The build machine lacks asm/ptrace.h for i386
>> (e.g. /usr/include/i386-linux-gnu/asm/ptrace.h). For example on Ubuntu
>> this is provided by linux-libc-dev:i386.
> 
> sorry for late response, we have installed linux-libc-dev:i386 on our build 
> environment to have this head file.

... and does it help? Is the issue fixed?

Best regards,
Krzysztof

[PATCH v4 3/3] x86/iopl: Fix iopl capability check on Xen PV

[Andy Lutomirski]

iopl(3) is supposed to work if iopl is already 3, even if
unprivileged.  This didn't work right on Xen PV.  Fix it.

Cc: sta...@vger.kernel.org
Reviewewd-by: Jan Beulich 
Signed-off-by: Andy Lutomirski 
---
 arch/x86/kernel/ioport.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c
index 37dae792dbbe..589b3193f102 100644
--- a/arch/x86/kernel/ioport.c
+++ b/arch/x86/kernel/ioport.c
@@ -96,9 +96,14 @@ asmlinkage long sys_ioperm(unsigned long from, unsigned long 
num, int turn_on)
 SYSCALL_DEFINE1(iopl, unsigned int, level)
 {
struct pt_regs *regs = current_pt_regs();
-   unsigned int old = (regs->flags >> 12) & 3;
struct thread_struct *t = >thread;
 
+   /*
+* Careful: the IOPL bits in regs->flags are undefined under Xen PV
+* and changing them has no effect.
+*/
+   unsigned int old = t->iopl >> X86_EFLAGS_IOPL_BIT;
+
if (level > 3)
return -EINVAL;
/* Trying to gain more privileges? */
@@ -106,8 +111,9 @@ SYSCALL_DEFINE1(iopl, unsigned int, level)
if (!capable(CAP_SYS_RAWIO))
return -EPERM;
}
-   regs->flags = (regs->flags & ~X86_EFLAGS_IOPL) | (level << 12);
-   t->iopl = level << 12;
+   regs->flags = (regs->flags & ~X86_EFLAGS_IOPL) |
+   (level << X86_EFLAGS_IOPL_BIT);
+   t->iopl = level << X86_EFLAGS_IOPL_BIT;
set_iopl_mask(t->iopl);
 
return 0;
-- 
2.5.0

[PATCH 3/5] usb: host: xhci: add broken pe quirk flag to pdata

[Roger Quadros]

From: Felipe Balbi 

Let platform_data users pass broken pe flag to
xhci driver.

Signed-off-by: Felipe Balbi 
Signed-off-by: Sekhar Nori 
Signed-off-by: Roger Quadros 
---
 include/linux/usb/xhci_pdriver.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/usb/xhci_pdriver.h b/include/linux/usb/xhci_pdriver.h
index 376654b..81b15ea 100644
--- a/include/linux/usb/xhci_pdriver.h
+++ b/include/linux/usb/xhci_pdriver.h
@@ -18,10 +18,12 @@
  *
  * @usb3_lpm_capable:  determines if this xhci platform supports USB3
  * LPM capability
+ * @quirk_port_broken_pe: If true, XHCI will not use Port Disable.
  *
  */
 struct usb_xhci_pdata {
unsignedusb3_lpm_capable:1;
+   unsignedquirk_port_broken_pe:1;
 };
 
 #endif /* __USB_CORE_XHCI_PDRIVER_H */
-- 
2.5.0

[PATCH v4 3/3] x86/iopl: Fix iopl capability check on Xen PV

[Andy Lutomirski]

iopl(3) is supposed to work if iopl is already 3, even if
unprivileged.  This didn't work right on Xen PV.  Fix it.

Cc: sta...@vger.kernel.org
Reviewewd-by: Jan Beulich 
Signed-off-by: Andy Lutomirski 
---
 arch/x86/kernel/ioport.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c
index 37dae792dbbe..589b3193f102 100644
--- a/arch/x86/kernel/ioport.c
+++ b/arch/x86/kernel/ioport.c
@@ -96,9 +96,14 @@ asmlinkage long sys_ioperm(unsigned long from, unsigned long 
num, int turn_on)
 SYSCALL_DEFINE1(iopl, unsigned int, level)
 {
struct pt_regs *regs = current_pt_regs();
-   unsigned int old = (regs->flags >> 12) & 3;
struct thread_struct *t = >thread;
 
+   /*
+* Careful: the IOPL bits in regs->flags are undefined under Xen PV
+* and changing them has no effect.
+*/
+   unsigned int old = t->iopl >> X86_EFLAGS_IOPL_BIT;
+
if (level > 3)
return -EINVAL;
/* Trying to gain more privileges? */
@@ -106,8 +111,9 @@ SYSCALL_DEFINE1(iopl, unsigned int, level)
if (!capable(CAP_SYS_RAWIO))
return -EPERM;
}
-   regs->flags = (regs->flags & ~X86_EFLAGS_IOPL) | (level << 12);
-   t->iopl = level << 12;
+   regs->flags = (regs->flags & ~X86_EFLAGS_IOPL) |
+   (level << X86_EFLAGS_IOPL_BIT);
+   t->iopl = level << X86_EFLAGS_IOPL_BIT;
set_iopl_mask(t->iopl);
 
return 0;
-- 
2.5.0

[PATCH 3/5] usb: host: xhci: add broken pe quirk flag to pdata

[Roger Quadros]

From: Felipe Balbi 

Let platform_data users pass broken pe flag to
xhci driver.

Signed-off-by: Felipe Balbi 
Signed-off-by: Sekhar Nori 
Signed-off-by: Roger Quadros 
---
 include/linux/usb/xhci_pdriver.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/usb/xhci_pdriver.h b/include/linux/usb/xhci_pdriver.h
index 376654b..81b15ea 100644
--- a/include/linux/usb/xhci_pdriver.h
+++ b/include/linux/usb/xhci_pdriver.h
@@ -18,10 +18,12 @@
  *
  * @usb3_lpm_capable:  determines if this xhci platform supports USB3
  * LPM capability
+ * @quirk_port_broken_pe: If true, XHCI will not use Port Disable.
  *
  */
 struct usb_xhci_pdata {
unsignedusb3_lpm_capable:1;
+   unsignedquirk_port_broken_pe:1;
 };
 
 #endif /* __USB_CORE_XHCI_PDRIVER_H */
-- 
2.5.0

[PATCH 1/8] lib/mpi: mpi_write_sgl(): fix skipping of leading zero limbs

[Nicolai Stange]

Currently, if the number of leading zeros is greater than fits into a
complete limb, mpi_write_sgl() skips them by iterating over them limb-wise.

However, it fails to adjust its internal leading zeros tracking variable,
lzeros, accordingly: it does a

  p -= sizeof(alimb);
  continue;

which should really have been a

  lzeros -= sizeof(alimb);
  continue;

Since lzeros never decreases if its initial value >= sizeof(alimb), nothing
gets copied by mpi_write_sgl() in that case.

Instead of skipping the high order zero limbs within the loop as shown
above, fix the issue by adjusting the copying loop's bounds.

Fixes: 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers")
Signed-off-by: Nicolai Stange 
---
 lib/mpi/mpicoder.c | 21 +
 1 file changed, 9 insertions(+), 12 deletions(-)

diff --git a/lib/mpi/mpicoder.c b/lib/mpi/mpicoder.c
index eb15e7d..6bb52be 100644
--- a/lib/mpi/mpicoder.c
+++ b/lib/mpi/mpicoder.c
@@ -380,7 +380,9 @@ int mpi_write_to_sgl(MPI a, struct scatterlist *sgl, 
unsigned *nbytes,
buf_len = sgl->length;
p2 = sg_virt(sgl);
 
-   for (i = a->nlimbs - 1; i >= 0; i--) {
+   for (i = a->nlimbs - 1 - lzeros / BYTES_PER_MPI_LIMB,
+   lzeros %= BYTES_PER_MPI_LIMB;
+   i >= 0; i--) {
alimb = a->d[i];
p = (u8 *)
 #if BYTES_PER_MPI_LIMB == 4
@@ -401,17 +403,12 @@ int mpi_write_to_sgl(MPI a, struct scatterlist *sgl, 
unsigned *nbytes,
 #error please implement for this limb size.
 #endif
if (lzeros > 0) {
-   if (lzeros >= sizeof(alimb)) {
-   p -= sizeof(alimb);
-   continue;
-   } else {
-   mpi_limb_t *limb1 = (void *)p - sizeof(alimb);
-   mpi_limb_t *limb2 = (void *)p - sizeof(alimb)
-   + lzeros;
-   *limb1 = *limb2;
-   p -= lzeros;
-   y = lzeros;
-   }
+   mpi_limb_t *limb1 = (void *)p - sizeof(alimb);
+   mpi_limb_t *limb2 = (void *)p - sizeof(alimb)
+   + lzeros;
+   *limb1 = *limb2;
+   p -= lzeros;
+   y = lzeros;
lzeros -= sizeof(alimb);
}
 
-- 
2.7.2

[PATCH 1/8] lib/mpi: mpi_write_sgl(): fix skipping of leading zero limbs

[Nicolai Stange]

Currently, if the number of leading zeros is greater than fits into a
complete limb, mpi_write_sgl() skips them by iterating over them limb-wise.

However, it fails to adjust its internal leading zeros tracking variable,
lzeros, accordingly: it does a

  p -= sizeof(alimb);
  continue;

which should really have been a

  lzeros -= sizeof(alimb);
  continue;

Since lzeros never decreases if its initial value >= sizeof(alimb), nothing
gets copied by mpi_write_sgl() in that case.

Instead of skipping the high order zero limbs within the loop as shown
above, fix the issue by adjusting the copying loop's bounds.

Fixes: 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers")
Signed-off-by: Nicolai Stange 
---
 lib/mpi/mpicoder.c | 21 +
 1 file changed, 9 insertions(+), 12 deletions(-)

diff --git a/lib/mpi/mpicoder.c b/lib/mpi/mpicoder.c
index eb15e7d..6bb52be 100644
--- a/lib/mpi/mpicoder.c
+++ b/lib/mpi/mpicoder.c
@@ -380,7 +380,9 @@ int mpi_write_to_sgl(MPI a, struct scatterlist *sgl, 
unsigned *nbytes,
buf_len = sgl->length;
p2 = sg_virt(sgl);
 
-   for (i = a->nlimbs - 1; i >= 0; i--) {
+   for (i = a->nlimbs - 1 - lzeros / BYTES_PER_MPI_LIMB,
+   lzeros %= BYTES_PER_MPI_LIMB;
+   i >= 0; i--) {
alimb = a->d[i];
p = (u8 *)
 #if BYTES_PER_MPI_LIMB == 4
@@ -401,17 +403,12 @@ int mpi_write_to_sgl(MPI a, struct scatterlist *sgl, 
unsigned *nbytes,
 #error please implement for this limb size.
 #endif
if (lzeros > 0) {
-   if (lzeros >= sizeof(alimb)) {
-   p -= sizeof(alimb);
-   continue;
-   } else {
-   mpi_limb_t *limb1 = (void *)p - sizeof(alimb);
-   mpi_limb_t *limb2 = (void *)p - sizeof(alimb)
-   + lzeros;
-   *limb1 = *limb2;
-   p -= lzeros;
-   y = lzeros;
-   }
+   mpi_limb_t *limb1 = (void *)p - sizeof(alimb);
+   mpi_limb_t *limb2 = (void *)p - sizeof(alimb)
+   + lzeros;
+   *limb1 = *limb2;
+   p -= lzeros;
+   y = lzeros;
lzeros -= sizeof(alimb);
}
 
-- 
2.7.2

[RFC/RFT PATCH 2/2] mfd: max14577: Allow driver to be built as a module

[Javier Martinez Canillas]

The driver's Kconfig symbol is a boolean but nothing prevents the driver
to be built as a module instead of built-in. It is true that most system
integrators will choose the latter but the config should not restrict it.

Suggested-by: Krzysztof Kozlowski 
Signed-off-by: Javier Martinez Canillas 

---

 drivers/mfd/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index eea61e349e26..be0ff820621b 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -514,8 +514,8 @@ config MFD_88PM860X
  battery-charger under the corresponding menus.
 
 config MFD_MAX14577
-   bool "Maxim Semiconductor MAX14577/77836 MUIC + Charger Support"
-   depends on I2C=y
+   tristate "Maxim Semiconductor MAX14577/77836 MUIC + Charger Support"
+   depends on I2C
select MFD_CORE
select REGMAP_I2C
select REGMAP_IRQ
-- 
2.5.0

[RFC/RFT PATCH 2/2] mfd: max14577: Allow driver to be built as a module

[Javier Martinez Canillas]

The driver's Kconfig symbol is a boolean but nothing prevents the driver
to be built as a module instead of built-in. It is true that most system
integrators will choose the latter but the config should not restrict it.

Suggested-by: Krzysztof Kozlowski 
Signed-off-by: Javier Martinez Canillas 

---

 drivers/mfd/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index eea61e349e26..be0ff820621b 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -514,8 +514,8 @@ config MFD_88PM860X
  battery-charger under the corresponding menus.
 
 config MFD_MAX14577
-   bool "Maxim Semiconductor MAX14577/77836 MUIC + Charger Support"
-   depends on I2C=y
+   tristate "Maxim Semiconductor MAX14577/77836 MUIC + Charger Support"
+   depends on I2C
select MFD_CORE
select REGMAP_I2C
select REGMAP_IRQ
-- 
2.5.0

Re: [RFC PATCH 0/4] ACPI based PCI host driver with generic ECAM

[Jayachandran C]

On Fri, Mar 18, 2016 at 1:48 AM, Jayachandran C  wrote:
> Hi Bjorn,
>
> Here is a new patchset for the ACPI PCI controller driver based on the
> earlier discussion[1].
>
> The first two patches in the patchset implements pci/ecam.c for generic
> config space access and uses it in pci-host-generic.c and related files.
>
> The third patch implements the ACPI PCI host driver using the same ecam
> access functions. The fourth patch adds the implementation of raw
> operations.
>
> I have not used the pci_mmcfg_list or the region definitions from x86,
> but have used a much simpler approach here.
>
> This should apply cleanly on top of the current pci next tree, and
> can be reviewed as a patchset.  To use it on ARM64, we need to pull
> in about 7 patches more from Tomasz patchset that fixes various
> issues (like stub code in arm64 pci.c, ACPI companion setup,
> domain number assignment, IO resources fixup etc.).
>
> If you are okay with this approach, I will work with Tomasz and
> post the full patchset.
>
> This has been tested on qemu with OVMF for the ACPI part and with
> device tree for pci-host-generic code.

The full patchset is available at https://github.com/jchandra-brcm/linux.git on
branch arm64-acpi-pci, if anyone wants to try it.

Comments, suggestions and testing would be welcome.

Thanks,
JC.

Re: [RFC PATCH 0/4] ACPI based PCI host driver with generic ECAM

[Jayachandran C]

On Fri, Mar 18, 2016 at 1:48 AM, Jayachandran C  wrote:
> Hi Bjorn,
>
> Here is a new patchset for the ACPI PCI controller driver based on the
> earlier discussion[1].
>
> The first two patches in the patchset implements pci/ecam.c for generic
> config space access and uses it in pci-host-generic.c and related files.
>
> The third patch implements the ACPI PCI host driver using the same ecam
> access functions. The fourth patch adds the implementation of raw
> operations.
>
> I have not used the pci_mmcfg_list or the region definitions from x86,
> but have used a much simpler approach here.
>
> This should apply cleanly on top of the current pci next tree, and
> can be reviewed as a patchset.  To use it on ARM64, we need to pull
> in about 7 patches more from Tomasz patchset that fixes various
> issues (like stub code in arm64 pci.c, ACPI companion setup,
> domain number assignment, IO resources fixup etc.).
>
> If you are okay with this approach, I will work with Tomasz and
> post the full patchset.
>
> This has been tested on qemu with OVMF for the ACPI part and with
> device tree for pci-host-generic code.

The full patchset is available at https://github.com/jchandra-brcm/linux.git on
branch arm64-acpi-pci, if anyone wants to try it.

Comments, suggestions and testing would be welcome.

Thanks,
JC.

Re: dynamic ftrace/recordmcount.c problem on ARMv5

[Namhyung Kim]

Hi,

On Fri, Mar 11, 2016 at 10:21:59AM +0100, Uwe Kleine-König wrote:
> Hello,
> 
> On Wed, Jan 13, 2016 at 09:51:28AM +0100, Marc Kleine-Budde wrote:
> > Hello,
> > 
> > I'm on a ARMv5 (freescale mx25) and seeing this ftrace bug during bootup:
> > 
> > > [0.059235] [ cut here ]
> > > [0.059449] WARNING: CPU: 0 PID: 0 at kernel/trace/ftrace.c:1938 
> > > ftrace_bug+0x210/0x2c8()
> > > [0.059645] Modules linked in:
> > > [0.059780] CPU: 0 PID: 0 Comm: swapper Not tainted 
> > > 4.0.9-20151211-1-g45dbe7d2c077 #1
> > > [0.059966] Hardware name: Freescale i.MX25 (Device Tree Support)
> > > [0.060157] [<8000f494>] (unwind_backtrace) from [<8000ce3c>] 
> > > (show_stack+0x20/0x24)
> > > [0.060396] [<8000ce3c>] (show_stack) from [<8041ea68>] 
> > > (dump_stack+0x20/0x28)
> > > [0.060630] [<8041ea68>] (dump_stack) from [<8001a74c>] 
> > > (warn_slowpath_common+0x88/0xc0)
> > > [0.060853] [<8001a74c>] (warn_slowpath_common) from [<8001a840>] 
> > > (warn_slowpath_null+0x2c/0x34)
> > > [0.061091] [<8001a840>] (warn_slowpath_null) from [<80083748>] 
> > > (ftrace_bug+0x210/0x2c8)
> > > [0.061332] [<80083748>] (ftrace_bug) from [<80083bb8>] 
> > > (ftrace_process_locs+0x330/0x6f0)
> > > [0.061576] [<80083bb8>] (ftrace_process_locs) from [<805bdc84>] 
> > > (ftrace_init+0x8c/0x14c)
> > > [0.061815] [<805bdc84>] (ftrace_init) from [<805b0c80>] 
> > > (start_kernel+0x33c/0x3b4)
> > > [0.062039] [<805b0c80>] (start_kernel) from [<80008040>] (0x80008040)
> > > [0.062238] ---[ end trace cb88537fdc8fa200 ]---
> > > [0.062364] ftrace failed to modify [<8000c7d8>] 
> > > walk_stackframe+0x24/0x44
> > > [0.062544]  actual: 16:ff:2f:e1
> > > [0.062702] ftrace record flags: 0
> > > [0.062803]  (0)   expected tramp: 8000e864
> > 
> > The problem is that walk_stackframe ends up in the __mcount_loc section,
> > although it has a "notrace" attribute:
> 
> Not having much clue about elf and stuff, but being hit by this problem
> I added some debug output to recordmcount.c and found that
> sift_rel_mcount (aka sift32_rel_mcount) loops over .rel.text which looks
> as follows for me:
> 
>   $ readelf -R .rel.text arch/arm/kernel/stacktrace.o 
>   ...
>   Relocation section '.rel.text' at offset 0xb5c contains 15 entries:
>Offset InfoTypeSym.Value  Sym. Name
>   001c  0028 R_ARM_V4BX   
>   002c  1d1c R_ARM_CALL   unwind_frame
>   0044  1f1c R_ARM_CALL   __gnu_mcount_nc
>   0104  201c R_ARM_CALL   in_sched_functions
>   0118  2102 R_ARM_ABS32      __exception_text_start
>   011c  2202 R_ARM_ABS32      __exception_text_end
>   0130  1f1c R_ARM_CALL   __gnu_mcount_nc
>   0194  1c1c R_ARM_CALL   walk_stackframe
>   01e0  0902 R_ARM_ABS32   003c   save_trace
>   01e4  0c02 R_ARM_ABS32   0120   __save_stack_trace
>   01ec  1f1c R_ARM_CALL   __gnu_mcount_nc
>   0218  1f1c R_ARM_CALL   __gnu_mcount_nc
>   0260  1c1c R_ARM_CALL   walk_stackframe
>   028c  0902 R_ARM_ABS32   003c   save_trace
>   0294  1f1c R_ARM_CALL   __gnu_mcount_nc
>   ...
> 
> and the unwanted entry in __mcount_loc is generated from the first line
> which isn't a call, but just the information that there is a bx call
> that needs a fixup for ARMv4 machines (that don't support the bx
> instruction).
> 
> For this entry get_mcountsym returns 0.
> 
> recordmcount.pl only operates on R_ARM_(CALL|PC24|THM_CALL) types for
> ARM and so does it right.

Hmm.. that means we need to check the reloc types?  It seems the
binutils treats R_ARM_THM_PC22 as R_ARM_THM_CALL.

in /usr/include/elf.h:
#define R_ARM_SBREL32   9
#define R_ARM_THM_PC22  10  /* PC relative 24 bit (Thumb32 BL).  */
#define R_ARM_THM_PC8   11  /* PC relative & 0x3FC

in binutils-gdb/include/elf/arm.h:
  RELOC_NUMBER (R_ARM_SBREL32,9)
  RELOC_NUMBER (R_ARM_THM_CALL,   10)
  RELOC_NUMBER (R_ARM_THM_PC8,11)


So following patch (untested) works for you?

Thanks,
Namhyung



diff --git a/scripts/recordmcount.c b/scripts/recordmcount.c
index e167592793a7..dcc7896dce25 100644
--- a/scripts/recordmcount.c
+++ b/scripts/recordmcount.c
@@ -398,6 +398,20 @@ static void MIPS64_r_info(Elf64_Rel *const rp, unsigned 
sym, unsigned type)
}).r_info;
 }
 
+static int ARM_is_fake_mcount(Elf32_Rel const *rp)
+{
+   unsigned r_type = ELF32_R_TYPE(w(rp->r_info));
+
+   switch (r_type) {
+   case R_ARM_CALL:
+   case R_ARM_PC24:
+   case R_ARM_THM_PC22:
+   return 0;
+   default:
+   return 1;
+   }
+}
+
 static void
 do_file(char const 

Re: dynamic ftrace/recordmcount.c problem on ARMv5

[Namhyung Kim]

Hi,

On Fri, Mar 11, 2016 at 10:21:59AM +0100, Uwe Kleine-König wrote:
> Hello,
> 
> On Wed, Jan 13, 2016 at 09:51:28AM +0100, Marc Kleine-Budde wrote:
> > Hello,
> > 
> > I'm on a ARMv5 (freescale mx25) and seeing this ftrace bug during bootup:
> > 
> > > [0.059235] [ cut here ]
> > > [0.059449] WARNING: CPU: 0 PID: 0 at kernel/trace/ftrace.c:1938 
> > > ftrace_bug+0x210/0x2c8()
> > > [0.059645] Modules linked in:
> > > [0.059780] CPU: 0 PID: 0 Comm: swapper Not tainted 
> > > 4.0.9-20151211-1-g45dbe7d2c077 #1
> > > [0.059966] Hardware name: Freescale i.MX25 (Device Tree Support)
> > > [0.060157] [<8000f494>] (unwind_backtrace) from [<8000ce3c>] 
> > > (show_stack+0x20/0x24)
> > > [0.060396] [<8000ce3c>] (show_stack) from [<8041ea68>] 
> > > (dump_stack+0x20/0x28)
> > > [0.060630] [<8041ea68>] (dump_stack) from [<8001a74c>] 
> > > (warn_slowpath_common+0x88/0xc0)
> > > [0.060853] [<8001a74c>] (warn_slowpath_common) from [<8001a840>] 
> > > (warn_slowpath_null+0x2c/0x34)
> > > [0.061091] [<8001a840>] (warn_slowpath_null) from [<80083748>] 
> > > (ftrace_bug+0x210/0x2c8)
> > > [0.061332] [<80083748>] (ftrace_bug) from [<80083bb8>] 
> > > (ftrace_process_locs+0x330/0x6f0)
> > > [0.061576] [<80083bb8>] (ftrace_process_locs) from [<805bdc84>] 
> > > (ftrace_init+0x8c/0x14c)
> > > [0.061815] [<805bdc84>] (ftrace_init) from [<805b0c80>] 
> > > (start_kernel+0x33c/0x3b4)
> > > [0.062039] [<805b0c80>] (start_kernel) from [<80008040>] (0x80008040)
> > > [0.062238] ---[ end trace cb88537fdc8fa200 ]---
> > > [0.062364] ftrace failed to modify [<8000c7d8>] 
> > > walk_stackframe+0x24/0x44
> > > [0.062544]  actual: 16:ff:2f:e1
> > > [0.062702] ftrace record flags: 0
> > > [0.062803]  (0)   expected tramp: 8000e864
> > 
> > The problem is that walk_stackframe ends up in the __mcount_loc section,
> > although it has a "notrace" attribute:
> 
> Not having much clue about elf and stuff, but being hit by this problem
> I added some debug output to recordmcount.c and found that
> sift_rel_mcount (aka sift32_rel_mcount) loops over .rel.text which looks
> as follows for me:
> 
>   $ readelf -R .rel.text arch/arm/kernel/stacktrace.o 
>   ...
>   Relocation section '.rel.text' at offset 0xb5c contains 15 entries:
>Offset InfoTypeSym.Value  Sym. Name
>   001c  0028 R_ARM_V4BX   
>   002c  1d1c R_ARM_CALL   unwind_frame
>   0044  1f1c R_ARM_CALL   __gnu_mcount_nc
>   0104  201c R_ARM_CALL   in_sched_functions
>   0118  2102 R_ARM_ABS32      __exception_text_start
>   011c  2202 R_ARM_ABS32      __exception_text_end
>   0130  1f1c R_ARM_CALL   __gnu_mcount_nc
>   0194  1c1c R_ARM_CALL   walk_stackframe
>   01e0  0902 R_ARM_ABS32   003c   save_trace
>   01e4  0c02 R_ARM_ABS32   0120   __save_stack_trace
>   01ec  1f1c R_ARM_CALL   __gnu_mcount_nc
>   0218  1f1c R_ARM_CALL   __gnu_mcount_nc
>   0260  1c1c R_ARM_CALL   walk_stackframe
>   028c  0902 R_ARM_ABS32   003c   save_trace
>   0294  1f1c R_ARM_CALL   __gnu_mcount_nc
>   ...
> 
> and the unwanted entry in __mcount_loc is generated from the first line
> which isn't a call, but just the information that there is a bx call
> that needs a fixup for ARMv4 machines (that don't support the bx
> instruction).
> 
> For this entry get_mcountsym returns 0.
> 
> recordmcount.pl only operates on R_ARM_(CALL|PC24|THM_CALL) types for
> ARM and so does it right.

Hmm.. that means we need to check the reloc types?  It seems the
binutils treats R_ARM_THM_PC22 as R_ARM_THM_CALL.

in /usr/include/elf.h:
#define R_ARM_SBREL32   9
#define R_ARM_THM_PC22  10  /* PC relative 24 bit (Thumb32 BL).  */
#define R_ARM_THM_PC8   11  /* PC relative & 0x3FC

in binutils-gdb/include/elf/arm.h:
  RELOC_NUMBER (R_ARM_SBREL32,9)
  RELOC_NUMBER (R_ARM_THM_CALL,   10)
  RELOC_NUMBER (R_ARM_THM_PC8,11)


So following patch (untested) works for you?

Thanks,
Namhyung



diff --git a/scripts/recordmcount.c b/scripts/recordmcount.c
index e167592793a7..dcc7896dce25 100644
--- a/scripts/recordmcount.c
+++ b/scripts/recordmcount.c
@@ -398,6 +398,20 @@ static void MIPS64_r_info(Elf64_Rel *const rp, unsigned 
sym, unsigned type)
}).r_info;
 }
 
+static int ARM_is_fake_mcount(Elf32_Rel const *rp)
+{
+   unsigned r_type = ELF32_R_TYPE(w(rp->r_info));
+
+   switch (r_type) {
+   case R_ARM_CALL:
+   case R_ARM_PC24:
+   case R_ARM_THM_PC22:
+   return 0;
+   default:
+   return 1;
+   }
+}
+
 static void
 do_file(char const 

Re: livepatch: Update maintainers

[Jessica Yu]

+++ Josh Poimboeuf [16/03/16 10:03 -0500]:

Seth and Vojtech are no longer active maintainers of livepatch, so
remove them in favor of Jessica and Miroslav.

Also add Petr as a designated reviewer.

Signed-off-by: Josh Poimboeuf 
---
MAINTAINERS | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 860e306..e04e0a5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6583,9 +6583,10 @@ F:   drivers/platform/x86/hp_accel.c

LIVE PATCHING
M:  Josh Poimboeuf 
-M: Seth Jennings 
+M: Jessica Yu 
M:  Jiri Kosina 
-M: Vojtech Pavlik 
+M: Miroslav Benes 
+R: Petr Mladek 
S:  Maintained
F:  kernel/livepatch/
F:  include/linux/livepatch.h


Acked-by: Jessica Yu 


--
2.4.3

Re: livepatch: Update maintainers

[Jessica Yu]

+++ Josh Poimboeuf [16/03/16 10:03 -0500]:

Seth and Vojtech are no longer active maintainers of livepatch, so
remove them in favor of Jessica and Miroslav.

Also add Petr as a designated reviewer.

Signed-off-by: Josh Poimboeuf 
---
MAINTAINERS | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 860e306..e04e0a5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6583,9 +6583,10 @@ F:   drivers/platform/x86/hp_accel.c

LIVE PATCHING
M:  Josh Poimboeuf 
-M: Seth Jennings 
+M: Jessica Yu 
M:  Jiri Kosina 
-M: Vojtech Pavlik 
+M: Miroslav Benes 
+R: Petr Mladek 
S:  Maintained
F:  kernel/livepatch/
F:  include/linux/livepatch.h


Acked-by: Jessica Yu 


--
2.4.3

Re: [PATCH 2/6] net: arc_emac: add phy-reset-* are optional for device tree

[Rob Herring]

On Fri, Mar 11, 2016 at 06:55:27PM +0800, Caesar Wang wrote:
> This patch adds the following property for arc_emac.
> 
> 1) phy-reset-gpios:
> The phy-reset-gpios is an optional property for arc emac device tree boot.
> Change the binding document to match the driver code.
> 
> 2) phy-reset-duration:
> Different boards may require different phy reset duration. Add property
> phy-reset-duration for device tree probe, so that the boards that need
> a longer reset duration can specify it in their device tree.
> 
> 3) phy-reset-active-high:
> We need that for a custom hardware that needs the reverse reset
> sequence.
> 
> Anyway, we can add the above property for arc emac.
> 
> Signed-off-by: Caesar Wang 
> ---
> 
>  Documentation/devicetree/bindings/net/arc_emac.txt | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/arc_emac.txt 
> b/Documentation/devicetree/bindings/net/arc_emac.txt
> index a1d71eb..6389b00 100644
> --- a/Documentation/devicetree/bindings/net/arc_emac.txt
> +++ b/Documentation/devicetree/bindings/net/arc_emac.txt
> @@ -7,6 +7,16 @@ Required properties:
>  - max-speed: see ethernet.txt file in the same directory.
>  - phy: see ethernet.txt file in the same directory.
>  
> +Optional properties:
> +- phy-reset-gpios : Should specify the gpio for phy reset
> +- phy-reset-duration : Reset duration in milliseconds.  Should present

Append units please (-msec).

> +  only if property "phy-reset-gpios" is available.  Missing the property
> +  will have the duration be 1 millisecond.  Numbers greater than 1000 are
> +  invalid and 1 millisecond will be used instead.
> +- phy-reset-active-high : If present then the reset sequence using the GPIO
> +  specified in the "phy-reset-gpios" property is reversed (H=reset state,
> +  L=operation state).

These are really all properties of the phy, not the mac, so they would 
be more appropriately be in the phy node even though it is the mac 
driver that wants to control the gpio.

Rob

Re: [PATCH 2/6] net: arc_emac: add phy-reset-* are optional for device tree

[Rob Herring]

On Fri, Mar 11, 2016 at 06:55:27PM +0800, Caesar Wang wrote:
> This patch adds the following property for arc_emac.
> 
> 1) phy-reset-gpios:
> The phy-reset-gpios is an optional property for arc emac device tree boot.
> Change the binding document to match the driver code.
> 
> 2) phy-reset-duration:
> Different boards may require different phy reset duration. Add property
> phy-reset-duration for device tree probe, so that the boards that need
> a longer reset duration can specify it in their device tree.
> 
> 3) phy-reset-active-high:
> We need that for a custom hardware that needs the reverse reset
> sequence.
> 
> Anyway, we can add the above property for arc emac.
> 
> Signed-off-by: Caesar Wang 
> ---
> 
>  Documentation/devicetree/bindings/net/arc_emac.txt | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/arc_emac.txt 
> b/Documentation/devicetree/bindings/net/arc_emac.txt
> index a1d71eb..6389b00 100644
> --- a/Documentation/devicetree/bindings/net/arc_emac.txt
> +++ b/Documentation/devicetree/bindings/net/arc_emac.txt
> @@ -7,6 +7,16 @@ Required properties:
>  - max-speed: see ethernet.txt file in the same directory.
>  - phy: see ethernet.txt file in the same directory.
>  
> +Optional properties:
> +- phy-reset-gpios : Should specify the gpio for phy reset
> +- phy-reset-duration : Reset duration in milliseconds.  Should present

Append units please (-msec).

> +  only if property "phy-reset-gpios" is available.  Missing the property
> +  will have the duration be 1 millisecond.  Numbers greater than 1000 are
> +  invalid and 1 millisecond will be used instead.
> +- phy-reset-active-high : If present then the reset sequence using the GPIO
> +  specified in the "phy-reset-gpios" property is reversed (H=reset state,
> +  L=operation state).

These are really all properties of the phy, not the mac, so they would 
be more appropriately be in the phy node even though it is the mac 
driver that wants to control the gpio.

Rob

[RESEND] [PATCH v11 6/6] add-TC-G210-pci-driver

[Joao Pinto]

This patch adds a glue pci driver for the Synopsys G210 Test Chip.

Signed-off-by: Joao Pinto 
---
Changes v10->v11 (Arnd Bergmann):
- tc_type is now initialized to TC_G210_INV
- probe function checks if the test chip version is specified
Changes v0->v10:
- This patch only appeared in v10

 drivers/scsi/ufs/Kconfig   |   9 ++
 drivers/scsi/ufs/Makefile  |   1 +
 drivers/scsi/ufs/tc-dwc-g210-pci.c | 181 +
 3 files changed, 191 insertions(+)
 create mode 100644 drivers/scsi/ufs/tc-dwc-g210-pci.c

diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
index 5cfa87b..5a3fde7 100644
--- a/drivers/scsi/ufs/Kconfig
+++ b/drivers/scsi/ufs/Kconfig
@@ -99,3 +99,12 @@ config SCSI_UFS_DWC_TC_PLATFORM
  Synopsys Test Chip is a PHY for prototyping purposes.
 
  If unsure, say N."
+
+config SCSI_UFS_DWC_TC_PCI
+   tristate "DesignWare pci support using a G210 Test Chip"
+   depends on SCSI_UFSHCD_PCI
+   select SCSI_UFS_DWC_TC
+   ---help---
+ Synopsys Test Chip is a PHY for prototyping purposes.
+
+ If unsure, say N."
diff --git a/drivers/scsi/ufs/Makefile b/drivers/scsi/ufs/Makefile
index a977fe0..5303d85 100644
--- a/drivers/scsi/ufs/Makefile
+++ b/drivers/scsi/ufs/Makefile
@@ -2,6 +2,7 @@
 obj-$(CONFIG_SCSI_UFS_DWC) += ufshcd-dwc.o
 obj-$(CONFIG_SCSI_UFS_DWC_TC) += tc-dwc-g210.o
 obj-$(CONFIG_SCSI_UFS_DWC_TC_PLATFORM) += tc-dwc-g210-pltfrm.o
+obj-$(CONFIG_SCSI_UFS_DWC_TC_PCI) += tc-dwc-g210-pci.o
 obj-$(CONFIG_SCSI_UFS_QCOM) += ufs-qcom.o
 obj-$(CONFIG_SCSI_UFSHCD) += ufshcd.o
 obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o
diff --git a/drivers/scsi/ufs/tc-dwc-g210-pci.c 
b/drivers/scsi/ufs/tc-dwc-g210-pci.c
new file mode 100644
index 000..be8790f
--- /dev/null
+++ b/drivers/scsi/ufs/tc-dwc-g210-pci.c
@@ -0,0 +1,181 @@
+/*
+ * Synopsys G210 Test Chip driver
+ *
+ * Copyright (C) 2015-2016 Synopsys, Inc. (www.synopsys.com)
+ *
+ * Authors: Joao Pinto 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include "ufshcd.h"
+#include "ufshcd-dwc.h"
+#include "tc-dwc-g210.h"
+
+#include 
+#include 
+
+/* Test Chip type expected values */
+#define TC_G210_20BIT 20
+#define TC_G210_40BIT 40
+#define TC_G210_INV 0
+
+static int tc_type = TC_G210_INV;
+module_param(tc_type, int, 0);
+MODULE_PARM_DESC(tc_type, "Test Chip Type (20 = 20-bit, 40 = 40-bit)");
+
+static int tc_dwc_g210_pci_suspend(struct device *dev)
+{
+   return ufshcd_system_suspend(dev_get_drvdata(dev));
+}
+
+static int tc_dwc_g210_pci_resume(struct device *dev)
+{
+   return ufshcd_system_resume(dev_get_drvdata(dev));
+}
+
+static int tc_dwc_g210_pci_runtime_suspend(struct device *dev)
+{
+   return ufshcd_runtime_suspend(dev_get_drvdata(dev));
+}
+
+static int tc_dwc_g210_pci_runtime_resume(struct device *dev)
+{
+   return ufshcd_runtime_resume(dev_get_drvdata(dev));
+}
+
+static int tc_dwc_g210_pci_runtime_idle(struct device *dev)
+{
+   return ufshcd_runtime_idle(dev_get_drvdata(dev));
+}
+
+/**
+ * struct ufs_hba_dwc_vops - UFS DWC specific variant operations
+ */
+static struct ufs_hba_variant_ops tc_dwc_g210_pci_hba_vops = {
+   .name   = "tc-dwc-g210-pci",
+   .link_startup_notify= ufshcd_dwc_link_startup_notify,
+};
+
+/**
+ * tc_dwc_g210_pci_shutdown - main function to put the controller in reset 
state
+ * @pdev: pointer to PCI device handle
+ */
+static void tc_dwc_g210_pci_shutdown(struct pci_dev *pdev)
+{
+   ufshcd_shutdown((struct ufs_hba *)pci_get_drvdata(pdev));
+}
+
+/**
+ * tc_dwc_g210_pci_remove - de-allocate PCI/SCSI host and host memory space
+ * data structure memory
+ * @pdev - pointer to PCI handle
+ */
+static void tc_dwc_g210_pci_remove(struct pci_dev *pdev)
+{
+   struct ufs_hba *hba = pci_get_drvdata(pdev);
+
+   pm_runtime_forbid(>dev);
+   pm_runtime_get_noresume(>dev);
+   ufshcd_remove(hba);
+}
+
+/**
+ * tc_dwc_g210_pci_probe - probe routine of the driver
+ * @pdev: pointer to PCI device handle
+ * @id: PCI device id
+ *
+ * Returns 0 on success, non-zero value on failure
+ */
+static int
+tc_dwc_g210_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
+{
+   struct ufs_hba *hba;
+   void __iomem *mmio_base;
+   int err;
+
+   /* Check Test Chip type and set the specific setup routine */
+   if (tc_type == TC_G210_20BIT) {
+   tc_dwc_g210_pci_hba_vops.custom_phy_initialization =
+   tc_dwc_g210_config_20_bit;
+   } else if (tc_type == TC_G210_40BIT) {
+   tc_dwc_g210_pci_hba_vops.custom_phy_initialization =
+   tc_dwc_g210_config_40_bit;
+   } else {
+   dev_err(>dev, "test chip 

Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable

[Patrick Bellasi]

On 17-Mar 06:55, Steve Muckle wrote:
> On 03/17/2016 02:40 AM, Juri Lelli wrote:
> >> Could the default schedtune value not serve as the out of the box margin?
> >>
> > I'm not sure I understand you here. For me schedtune should be disabled
> > by default, so I'd say that it doesn't introduce any additional margin
> > by default. But we still need a margin to make the governor work without
> > schedtune in the mix.
> 
> Why not have schedtune be enabled always, and use it to add the margin?
> It seems like it'd simplify things.

Actually one of the effects we noticed when SchedTune and SchedFreq
are both in use is that we have a sort of "double boosting" effect.

SchedTune boosts the CPU utilization signal, thus already providing a
sort of margin for the selection of the OPP. This margin overlaps with
the SchedFreq margin, which in turns could results in the selection of
an OPP even more higher than required (with boost already accouned).
 
> I haven't looked at the schedtune code at all so I don't know whether
> this makes sense given its current implementation.

The current implementation requires review, of course ;-)
Last (and only) posting is based on top of SchedFreq code, as it was
at that time.

> But conceptually I don't know why we'd need or want one margin in
> schedutil which will be tunable, and then another mechanism for
> tuning as well.

I agree with Steve on the conceptual standpoint. The main goal of
SchedTune is actually to provide a "single tunable" to bias many
different subsystem in a "consistent" way. Thus, from a conceptual
standpoint, IMO it makes sens to investigate better how the boost value
can be linked with SchedFreq.

A possible option can be to:
1. use an hardcoded margin (M) defined by SchedFreq
   this margin is used to trigger OPP jumps
   when SchedTune _is not_ in use
2. "compose" the M margin with a boost value defined margin (B)
   when SchedTune _is_ in use

This means, e.g.
  schedfreq_margin = max(M, B)
Thus:
a) non boosted tasks (and in general when SchedTune is not in use)
   gets OPPs jumps based on the hardcoded M margin
b) boosted tasks can get more aggressive OPPs jumps based on the B
   margin

While the M margin is hardcoded, the B one is defined via CGroups
depending on the how much tasks needs to be boosted.

-- 
#include 

Patrick Bellasi

[RESEND] [PATCH v11 6/6] add-TC-G210-pci-driver

[Joao Pinto]

This patch adds a glue pci driver for the Synopsys G210 Test Chip.

Signed-off-by: Joao Pinto 
---
Changes v10->v11 (Arnd Bergmann):
- tc_type is now initialized to TC_G210_INV
- probe function checks if the test chip version is specified
Changes v0->v10:
- This patch only appeared in v10

 drivers/scsi/ufs/Kconfig   |   9 ++
 drivers/scsi/ufs/Makefile  |   1 +
 drivers/scsi/ufs/tc-dwc-g210-pci.c | 181 +
 3 files changed, 191 insertions(+)
 create mode 100644 drivers/scsi/ufs/tc-dwc-g210-pci.c

diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
index 5cfa87b..5a3fde7 100644
--- a/drivers/scsi/ufs/Kconfig
+++ b/drivers/scsi/ufs/Kconfig
@@ -99,3 +99,12 @@ config SCSI_UFS_DWC_TC_PLATFORM
  Synopsys Test Chip is a PHY for prototyping purposes.
 
  If unsure, say N."
+
+config SCSI_UFS_DWC_TC_PCI
+   tristate "DesignWare pci support using a G210 Test Chip"
+   depends on SCSI_UFSHCD_PCI
+   select SCSI_UFS_DWC_TC
+   ---help---
+ Synopsys Test Chip is a PHY for prototyping purposes.
+
+ If unsure, say N."
diff --git a/drivers/scsi/ufs/Makefile b/drivers/scsi/ufs/Makefile
index a977fe0..5303d85 100644
--- a/drivers/scsi/ufs/Makefile
+++ b/drivers/scsi/ufs/Makefile
@@ -2,6 +2,7 @@
 obj-$(CONFIG_SCSI_UFS_DWC) += ufshcd-dwc.o
 obj-$(CONFIG_SCSI_UFS_DWC_TC) += tc-dwc-g210.o
 obj-$(CONFIG_SCSI_UFS_DWC_TC_PLATFORM) += tc-dwc-g210-pltfrm.o
+obj-$(CONFIG_SCSI_UFS_DWC_TC_PCI) += tc-dwc-g210-pci.o
 obj-$(CONFIG_SCSI_UFS_QCOM) += ufs-qcom.o
 obj-$(CONFIG_SCSI_UFSHCD) += ufshcd.o
 obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o
diff --git a/drivers/scsi/ufs/tc-dwc-g210-pci.c 
b/drivers/scsi/ufs/tc-dwc-g210-pci.c
new file mode 100644
index 000..be8790f
--- /dev/null
+++ b/drivers/scsi/ufs/tc-dwc-g210-pci.c
@@ -0,0 +1,181 @@
+/*
+ * Synopsys G210 Test Chip driver
+ *
+ * Copyright (C) 2015-2016 Synopsys, Inc. (www.synopsys.com)
+ *
+ * Authors: Joao Pinto 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include "ufshcd.h"
+#include "ufshcd-dwc.h"
+#include "tc-dwc-g210.h"
+
+#include 
+#include 
+
+/* Test Chip type expected values */
+#define TC_G210_20BIT 20
+#define TC_G210_40BIT 40
+#define TC_G210_INV 0
+
+static int tc_type = TC_G210_INV;
+module_param(tc_type, int, 0);
+MODULE_PARM_DESC(tc_type, "Test Chip Type (20 = 20-bit, 40 = 40-bit)");
+
+static int tc_dwc_g210_pci_suspend(struct device *dev)
+{
+   return ufshcd_system_suspend(dev_get_drvdata(dev));
+}
+
+static int tc_dwc_g210_pci_resume(struct device *dev)
+{
+   return ufshcd_system_resume(dev_get_drvdata(dev));
+}
+
+static int tc_dwc_g210_pci_runtime_suspend(struct device *dev)
+{
+   return ufshcd_runtime_suspend(dev_get_drvdata(dev));
+}
+
+static int tc_dwc_g210_pci_runtime_resume(struct device *dev)
+{
+   return ufshcd_runtime_resume(dev_get_drvdata(dev));
+}
+
+static int tc_dwc_g210_pci_runtime_idle(struct device *dev)
+{
+   return ufshcd_runtime_idle(dev_get_drvdata(dev));
+}
+
+/**
+ * struct ufs_hba_dwc_vops - UFS DWC specific variant operations
+ */
+static struct ufs_hba_variant_ops tc_dwc_g210_pci_hba_vops = {
+   .name   = "tc-dwc-g210-pci",
+   .link_startup_notify= ufshcd_dwc_link_startup_notify,
+};
+
+/**
+ * tc_dwc_g210_pci_shutdown - main function to put the controller in reset 
state
+ * @pdev: pointer to PCI device handle
+ */
+static void tc_dwc_g210_pci_shutdown(struct pci_dev *pdev)
+{
+   ufshcd_shutdown((struct ufs_hba *)pci_get_drvdata(pdev));
+}
+
+/**
+ * tc_dwc_g210_pci_remove - de-allocate PCI/SCSI host and host memory space
+ * data structure memory
+ * @pdev - pointer to PCI handle
+ */
+static void tc_dwc_g210_pci_remove(struct pci_dev *pdev)
+{
+   struct ufs_hba *hba = pci_get_drvdata(pdev);
+
+   pm_runtime_forbid(>dev);
+   pm_runtime_get_noresume(>dev);
+   ufshcd_remove(hba);
+}
+
+/**
+ * tc_dwc_g210_pci_probe - probe routine of the driver
+ * @pdev: pointer to PCI device handle
+ * @id: PCI device id
+ *
+ * Returns 0 on success, non-zero value on failure
+ */
+static int
+tc_dwc_g210_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
+{
+   struct ufs_hba *hba;
+   void __iomem *mmio_base;
+   int err;
+
+   /* Check Test Chip type and set the specific setup routine */
+   if (tc_type == TC_G210_20BIT) {
+   tc_dwc_g210_pci_hba_vops.custom_phy_initialization =
+   tc_dwc_g210_config_20_bit;
+   } else if (tc_type == TC_G210_40BIT) {
+   tc_dwc_g210_pci_hba_vops.custom_phy_initialization =
+   tc_dwc_g210_config_40_bit;
+   } else {
+   dev_err(>dev, "test chip version not specified\n");
+   

Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable

[Patrick Bellasi]

On 17-Mar 06:55, Steve Muckle wrote:
> On 03/17/2016 02:40 AM, Juri Lelli wrote:
> >> Could the default schedtune value not serve as the out of the box margin?
> >>
> > I'm not sure I understand you here. For me schedtune should be disabled
> > by default, so I'd say that it doesn't introduce any additional margin
> > by default. But we still need a margin to make the governor work without
> > schedtune in the mix.
> 
> Why not have schedtune be enabled always, and use it to add the margin?
> It seems like it'd simplify things.

Actually one of the effects we noticed when SchedTune and SchedFreq
are both in use is that we have a sort of "double boosting" effect.

SchedTune boosts the CPU utilization signal, thus already providing a
sort of margin for the selection of the OPP. This margin overlaps with
the SchedFreq margin, which in turns could results in the selection of
an OPP even more higher than required (with boost already accouned).
 
> I haven't looked at the schedtune code at all so I don't know whether
> this makes sense given its current implementation.

The current implementation requires review, of course ;-)
Last (and only) posting is based on top of SchedFreq code, as it was
at that time.

> But conceptually I don't know why we'd need or want one margin in
> schedutil which will be tunable, and then another mechanism for
> tuning as well.

I agree with Steve on the conceptual standpoint. The main goal of
SchedTune is actually to provide a "single tunable" to bias many
different subsystem in a "consistent" way. Thus, from a conceptual
standpoint, IMO it makes sens to investigate better how the boost value
can be linked with SchedFreq.

A possible option can be to:
1. use an hardcoded margin (M) defined by SchedFreq
   this margin is used to trigger OPP jumps
   when SchedTune _is not_ in use
2. "compose" the M margin with a boost value defined margin (B)
   when SchedTune _is_ in use

This means, e.g.
  schedfreq_margin = max(M, B)
Thus:
a) non boosted tasks (and in general when SchedTune is not in use)
   gets OPPs jumps based on the hardcoded M margin
b) boosted tasks can get more aggressive OPPs jumps based on the B
   margin

While the M margin is hardcoded, the B one is defined via CGroups
depending on the how much tasks needs to be boosted.

-- 
#include 

Patrick Bellasi

Re: [PATCH v2 02/18] dt-bindings: timer: sp804: add timer-width property

[Robin Murphy]

Hi Rob,

On 17/03/16 17:09, Rob Herring wrote:

On Wed, Mar 09, 2016 at 11:24:04AM +0100, Neil Armstrong wrote:

Add timer-width optional property to specify a different vendor
specific timer counter bit-width.

Signed-off-by: Neil Armstrong 
---
  Documentation/devicetree/bindings/timer/arm,sp804.txt | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/timer/arm,sp804.txt 
b/Documentation/devicetree/bindings/timer/arm,sp804.txt
index 5cd8eee7..141e143 100644
--- a/Documentation/devicetree/bindings/timer/arm,sp804.txt
+++ b/Documentation/devicetree/bindings/timer/arm,sp804.txt
@@ -17,6 +17,8 @@ Optional properties:
  - arm,sp804-has-irq = <#>: In the case of only 1 timer irq line connected, 
this
specifies if the irq connection is for timer 1 or timer 2. A value of 1
or 2 should be used.
+- arm,timer-width: Should contain the width in number of bits of the counter,
+   is considered by default 32 but can be changed for vendor variants.


That would not be an SP804 nor would the vendor be ARM in that case. So
add a new compatible string for the vendor that decided to hack up ARM's
IP block.


By all accounts this is some ancient reference design[1] which later 
evolved _into_ the SP804, so that vendor would probably still be ARM ;)


A separate compatible string would indeed make more sense, though. Both 
semantically and in terms of letting the driver account for the 
differences automatically.


Robin.

[1]:http://infocenter.arm.com/help/topic/com.arm.doc.ddi0170a/I350250.html



Rob

___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 0/2] mcb: export FPGA information via sysfs

[Johannes Thumshirn]

The following series adds a way to obtain information about a MCB FPGA via
sysfs. This is viable i.e. for a field technician to check if the latest FPGA
bitstream version is applied to the hardware.

The first patch layes the foundation in order to get sysfs correctly working
with MCB and the second patch exports the bus information into sysfs.

Changes from v1:
* Address kbuild robots warning about broken bisectability

Johannes Thumshirn (2):
  mcb: Correctly initialize the bus's device
  mcb: export bus information via sysfs

 Documentation/ABI/testing/sysfs-bus-mcb | 29 
 drivers/mcb/mcb-core.c  | 79 +++--
 drivers/mcb/mcb-internal.h  |  1 -
 drivers/mcb/mcb-parse.c | 15 +++
 include/linux/mcb.h | 14 --
 5 files changed, 121 insertions(+), 17 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-mcb

-- 
2.7.2

[PATCH v4 0/3] Xen iopl fixes

[Andy Lutomirski]

Hi all-

For those who are seeing this for the first time: any 64-bit Xen PV
domain with IO port access privileges (in practice, this means dom0
AFAIK) and any user programs that use iopl(3) (various old X
drivers, presumably) is probably vulnerable to privilege escalations
by unprivileged programs running in the same PV domain.

There's a long public description of the issue here:

http://xenbits.xen.org/xsa/advisory-171.html

Changes from v3:
 - Add Jan's R-b.
 - No longer embargoed

Changes from v2: Pretend v2 never happened...

Changes from v1: Use xen/hypervisor.h instead of xen-ops.h (Jan)

Andy Lutomirski (3):
  selftests/x86: Add a iopl test
  x86/iopl/64: Properly context-switch IOPL on Xen PV
  x86/iopl: Fix iopl capability check on Xen PV

 arch/x86/include/asm/xen/hypervisor.h |   2 +
 arch/x86/kernel/ioport.c  |  12 ++-
 arch/x86/kernel/process_64.c  |  12 +++
 arch/x86/xen/enlighten.c  |   2 +-
 tools/testing/selftests/x86/Makefile  |   2 +-
 tools/testing/selftests/x86/iopl.c| 135 ++
 6 files changed, 160 insertions(+), 5 deletions(-)
 create mode 100644 tools/testing/selftests/x86/iopl.c

-- 
2.5.0

[PATCH 0/2] mcb: export FPGA information via sysfs

[Johannes Thumshirn]

The following series adds a way to obtain information about a MCB FPGA via
sysfs. This is viable i.e. for a field technician to check if the latest FPGA
bitstream version is applied to the hardware.

The first patch layes the foundation in order to get sysfs correctly working
with MCB and the second patch exports the bus information into sysfs.

Changes from v1:
* Address kbuild robots warning about broken bisectability

Johannes Thumshirn (2):
  mcb: Correctly initialize the bus's device
  mcb: export bus information via sysfs

 Documentation/ABI/testing/sysfs-bus-mcb | 29 
 drivers/mcb/mcb-core.c  | 79 +++--
 drivers/mcb/mcb-internal.h  |  1 -
 drivers/mcb/mcb-parse.c | 15 +++
 include/linux/mcb.h | 14 --
 5 files changed, 121 insertions(+), 17 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-mcb

-- 
2.7.2

[PATCH v4 0/3] Xen iopl fixes

[Andy Lutomirski]

Hi all-

For those who are seeing this for the first time: any 64-bit Xen PV
domain with IO port access privileges (in practice, this means dom0
AFAIK) and any user programs that use iopl(3) (various old X
drivers, presumably) is probably vulnerable to privilege escalations
by unprivileged programs running in the same PV domain.

There's a long public description of the issue here:

http://xenbits.xen.org/xsa/advisory-171.html

Changes from v3:
 - Add Jan's R-b.
 - No longer embargoed

Changes from v2: Pretend v2 never happened...

Changes from v1: Use xen/hypervisor.h instead of xen-ops.h (Jan)

Andy Lutomirski (3):
  selftests/x86: Add a iopl test
  x86/iopl/64: Properly context-switch IOPL on Xen PV
  x86/iopl: Fix iopl capability check on Xen PV

 arch/x86/include/asm/xen/hypervisor.h |   2 +
 arch/x86/kernel/ioport.c  |  12 ++-
 arch/x86/kernel/process_64.c  |  12 +++
 arch/x86/xen/enlighten.c  |   2 +-
 tools/testing/selftests/x86/Makefile  |   2 +-
 tools/testing/selftests/x86/iopl.c| 135 ++
 6 files changed, 160 insertions(+), 5 deletions(-)
 create mode 100644 tools/testing/selftests/x86/iopl.c

-- 
2.5.0

Re: [PATCH v2 02/18] dt-bindings: timer: sp804: add timer-width property

[Robin Murphy]

Hi Rob,

On 17/03/16 17:09, Rob Herring wrote:

On Wed, Mar 09, 2016 at 11:24:04AM +0100, Neil Armstrong wrote:

Add timer-width optional property to specify a different vendor
specific timer counter bit-width.

Signed-off-by: Neil Armstrong 
---
  Documentation/devicetree/bindings/timer/arm,sp804.txt | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/timer/arm,sp804.txt 
b/Documentation/devicetree/bindings/timer/arm,sp804.txt
index 5cd8eee7..141e143 100644
--- a/Documentation/devicetree/bindings/timer/arm,sp804.txt
+++ b/Documentation/devicetree/bindings/timer/arm,sp804.txt
@@ -17,6 +17,8 @@ Optional properties:
  - arm,sp804-has-irq = <#>: In the case of only 1 timer irq line connected, 
this
specifies if the irq connection is for timer 1 or timer 2. A value of 1
or 2 should be used.
+- arm,timer-width: Should contain the width in number of bits of the counter,
+   is considered by default 32 but can be changed for vendor variants.


That would not be an SP804 nor would the vendor be ARM in that case. So
add a new compatible string for the vendor that decided to hack up ARM's
IP block.


By all accounts this is some ancient reference design[1] which later 
evolved _into_ the SP804, so that vendor would probably still be ARM ;)


A separate compatible string would indeed make more sense, though. Both 
semantically and in terms of letting the driver account for the 
differences automatically.


Robin.

[1]:http://infocenter.arm.com/help/topic/com.arm.doc.ddi0170a/I350250.html



Rob

___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 06/15] irqdomain: Ensure type settings match for an existing mapping

[Jon Hunter]

When mapping an IRQ, if a mapping already exists, then we simply return
the virtual IRQ number. However, we do not check that the type settings
for the existing mapping match those for the mapping that is about to be
created. It may be unlikely that the type settings would not match, but
check for this and don't return a valid IRQ mapping if the type settings
do not match.

WARN if the type return by irq_domain_translate() has bits outside the
sense mask set and then clear these bits. If these bits are not cleared
then this will cause the comparision of the type settings for an
existing mapping to fail with that of the new mapping even if the sense
bit themselves match. The reason being is that the existing type
settings are read by calling irq_get_trigger_type() which will clear
any bits outside the sense mask. This will allow us to detect irqchips
that are not correctly clearing these bits and fix them.

Signed-off-by: Jon Hunter 
---
 kernel/irq/irqdomain.c | 59 --
 1 file changed, 43 insertions(+), 16 deletions(-)

diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 3a519a01118b..0ea285baa619 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -549,6 +549,13 @@ static int irq_domain_translate(struct irq_domain *d,
 fwspec->param, fwspec->param_count,
 hwirq, type);
 
+   /*
+* WARN if the irqchip returns a type with bits
+* outside the sense mask set and clear these bits.
+*/
+   if (WARN_ON(*type & ~IRQ_TYPE_SENSE_MASK))
+   *type &= IRQ_TYPE_SENSE_MASK;
+
/* If domain has no translation, then we assume interrupt line */
*hwirq = fwspec->param[0];
return 0;
@@ -570,6 +577,7 @@ unsigned int irq_create_fwspec_mapping(struct irq_fwspec 
*fwspec)
 {
struct irq_domain *domain;
irq_hw_number_t hwirq;
+   unsigned int cur_type = IRQ_TYPE_NONE;
unsigned int type = IRQ_TYPE_NONE;
int virq;
 
@@ -592,23 +600,42 @@ unsigned int irq_create_fwspec_mapping(struct irq_fwspec 
*fwspec)
if (irq_domain_translate(domain, fwspec, , ))
return 0;
 
-   if (irq_domain_is_hierarchy(domain)) {
-   /*
-* If we've already configured this interrupt,
-* don't do it again, or hell will break loose.
-*/
-   virq = irq_find_mapping(domain, hwirq);
-   if (virq)
-   return virq;
-
-   virq = irq_domain_alloc_irqs(domain, 1, NUMA_NO_NODE, fwspec);
-   if (virq <= 0)
-   return 0;
+   /*
+* If we've already configured this interrupt,
+* don't do it again, or hell will break loose.
+*/
+   virq = irq_find_mapping(domain, hwirq);
+   if (!virq) {
+   if (irq_domain_is_hierarchy(domain)) {
+   virq = irq_domain_alloc_irqs(domain, 1, NUMA_NO_NODE,
+fwspec);
+   if (virq <= 0)
+   return 0;
+   } else {
+   /* Create mapping */
+   virq = irq_create_mapping(domain, hwirq);
+   if (!virq)
+   return virq;
+   }
} else {
-   /* Create mapping */
-   virq = irq_create_mapping(domain, hwirq);
-   if (!virq)
-   return virq;
+   cur_type = irq_get_trigger_type(virq);
+   }
+
+   /*
+* If the trigger type is not specified or matches the current
+* trigger type then we are done so return the interrupt number.
+*/
+   if (type == IRQ_TYPE_NONE || type == cur_type)
+   return virq;
+
+   /*
+* If the trigger type is already set and does
+* not match this interrupt, then return 0.
+*/
+   if (cur_type != IRQ_TYPE_NONE) {
+   pr_warn("type mismatch, failed to map hwirq-%lu for %s!\n",
+   hwirq, of_node_full_name(to_of_node(fwspec->fwnode)));
+   return 0;
}
 
/* Set type if specified and different than the current one */
-- 
2.1.4

[PATCH 06/15] irqdomain: Ensure type settings match for an existing mapping

[Jon Hunter]

When mapping an IRQ, if a mapping already exists, then we simply return
the virtual IRQ number. However, we do not check that the type settings
for the existing mapping match those for the mapping that is about to be
created. It may be unlikely that the type settings would not match, but
check for this and don't return a valid IRQ mapping if the type settings
do not match.

WARN if the type return by irq_domain_translate() has bits outside the
sense mask set and then clear these bits. If these bits are not cleared
then this will cause the comparision of the type settings for an
existing mapping to fail with that of the new mapping even if the sense
bit themselves match. The reason being is that the existing type
settings are read by calling irq_get_trigger_type() which will clear
any bits outside the sense mask. This will allow us to detect irqchips
that are not correctly clearing these bits and fix them.

Signed-off-by: Jon Hunter 
---
 kernel/irq/irqdomain.c | 59 --
 1 file changed, 43 insertions(+), 16 deletions(-)

diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 3a519a01118b..0ea285baa619 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -549,6 +549,13 @@ static int irq_domain_translate(struct irq_domain *d,
 fwspec->param, fwspec->param_count,
 hwirq, type);
 
+   /*
+* WARN if the irqchip returns a type with bits
+* outside the sense mask set and clear these bits.
+*/
+   if (WARN_ON(*type & ~IRQ_TYPE_SENSE_MASK))
+   *type &= IRQ_TYPE_SENSE_MASK;
+
/* If domain has no translation, then we assume interrupt line */
*hwirq = fwspec->param[0];
return 0;
@@ -570,6 +577,7 @@ unsigned int irq_create_fwspec_mapping(struct irq_fwspec 
*fwspec)
 {
struct irq_domain *domain;
irq_hw_number_t hwirq;
+   unsigned int cur_type = IRQ_TYPE_NONE;
unsigned int type = IRQ_TYPE_NONE;
int virq;
 
@@ -592,23 +600,42 @@ unsigned int irq_create_fwspec_mapping(struct irq_fwspec 
*fwspec)
if (irq_domain_translate(domain, fwspec, , ))
return 0;
 
-   if (irq_domain_is_hierarchy(domain)) {
-   /*
-* If we've already configured this interrupt,
-* don't do it again, or hell will break loose.
-*/
-   virq = irq_find_mapping(domain, hwirq);
-   if (virq)
-   return virq;
-
-   virq = irq_domain_alloc_irqs(domain, 1, NUMA_NO_NODE, fwspec);
-   if (virq <= 0)
-   return 0;
+   /*
+* If we've already configured this interrupt,
+* don't do it again, or hell will break loose.
+*/
+   virq = irq_find_mapping(domain, hwirq);
+   if (!virq) {
+   if (irq_domain_is_hierarchy(domain)) {
+   virq = irq_domain_alloc_irqs(domain, 1, NUMA_NO_NODE,
+fwspec);
+   if (virq <= 0)
+   return 0;
+   } else {
+   /* Create mapping */
+   virq = irq_create_mapping(domain, hwirq);
+   if (!virq)
+   return virq;
+   }
} else {
-   /* Create mapping */
-   virq = irq_create_mapping(domain, hwirq);
-   if (!virq)
-   return virq;
+   cur_type = irq_get_trigger_type(virq);
+   }
+
+   /*
+* If the trigger type is not specified or matches the current
+* trigger type then we are done so return the interrupt number.
+*/
+   if (type == IRQ_TYPE_NONE || type == cur_type)
+   return virq;
+
+   /*
+* If the trigger type is already set and does
+* not match this interrupt, then return 0.
+*/
+   if (cur_type != IRQ_TYPE_NONE) {
+   pr_warn("type mismatch, failed to map hwirq-%lu for %s!\n",
+   hwirq, of_node_full_name(to_of_node(fwspec->fwnode)));
+   return 0;
}
 
/* Set type if specified and different than the current one */
-- 
2.1.4

Re: [PATCH 0/1] KVM: x86: using the fpu in interrupt context with a guest's xcr0

[David Matlack]

On Tue, Mar 15, 2016 at 8:48 PM, Andy Lutomirski  wrote:
>
> Why is it safe to rely on interrupted_kernel_fpu_idle?  That function
> is for interrupts, but is there any reason that KVM can't be preempted
> (or explicitly schedule) with XCR0 having some funny value?

KVM restores the host's xcr0 in the sched-out preempt notifier and
prior to returning to userspace.

Re: [PATCH 0/1] KVM: x86: using the fpu in interrupt context with a guest's xcr0

[David Matlack]

On Tue, Mar 15, 2016 at 8:48 PM, Andy Lutomirski  wrote:
>
> Why is it safe to rely on interrupted_kernel_fpu_idle?  That function
> is for interrupts, but is there any reason that KVM can't be preempted
> (or explicitly schedule) with XCR0 having some funny value?

KVM restores the host's xcr0 in the sched-out preempt notifier and
prior to returning to userspace.

[PATCH v4 03/13] clk: sunxi: Add APB1 clock for A83T

[Vishnu Patekar]

APB1 is similar to sun4i-a10-apb0-clk, except different dividers.

This adds support for apb1 on A83T.

Signed-off-by: Vishnu Patekar 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/clock/sunxi.txt |  1 +
 drivers/clk/sunxi/clk-sunxi.c | 13 +
 2 files changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt 
b/Documentation/devicetree/bindings/clock/sunxi.txt
index cba9fe55..291d366 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -51,6 +51,7 @@ Required properties:
"allwinner,sun8i-h3-apb0-gates-clk" - for the APB0 gates on H3
"allwinner,sun9i-a80-apb0-gates-clk" - for the APB0 gates on A80
"allwinner,sun4i-a10-apb1-clk" - for the APB1 clock
++  "allwinner,sun8i-a83t-apb1-clk" - for the APB1 clock on A83T
"allwinner,sun9i-a80-apb1-clk" - for the APB1 bus clock on A80
"allwinner,sun4i-a10-apb1-gates-clk" - for the APB1 gates on A10
"allwinner,sun5i-a13-apb1-gates-clk" - for the APB1 gates on A13
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index a7aab65..171282d 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -872,6 +872,12 @@ static const struct div_data sun4i_apb0_data __initconst = 
{
.table  = sun4i_apb0_table,
 };
 
+static const struct div_data sun8i_a83t_apb1_data __initconst = {
+   .shift  = 8,
+   .pow= 0,
+   .width  = 2,
+};
+
 static void __init sunxi_divider_clk_setup(struct device_node *node,
   const struct div_data *data)
 {
@@ -938,6 +944,13 @@ static void __init sun4i_apb0_clk_setup(struct device_node 
*node)
 CLK_OF_DECLARE(sun4i_apb0, "allwinner,sun4i-a10-apb0-clk",
   sun4i_apb0_clk_setup);
 
+static void __init sun8i_a83t_apb1_clk_setup(struct device_node *node)
+{
+   sunxi_divider_clk_setup(node, _a83t_apb1_data);
+}
+CLK_OF_DECLARE(sun8i_a83t_apb1, "allwinner,sun8i-a83t-apb1-clk",
+  sun8i_a83t_apb1_clk_setup);
+
 static void __init sun4i_axi_clk_setup(struct device_node *node)
 {
sunxi_divider_clk_setup(node, _axi_data);
-- 
1.9.1

[PATCH v4 03/13] clk: sunxi: Add APB1 clock for A83T

[Vishnu Patekar]

APB1 is similar to sun4i-a10-apb0-clk, except different dividers.

This adds support for apb1 on A83T.

Signed-off-by: Vishnu Patekar 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/clock/sunxi.txt |  1 +
 drivers/clk/sunxi/clk-sunxi.c | 13 +
 2 files changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt 
b/Documentation/devicetree/bindings/clock/sunxi.txt
index cba9fe55..291d366 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -51,6 +51,7 @@ Required properties:
"allwinner,sun8i-h3-apb0-gates-clk" - for the APB0 gates on H3
"allwinner,sun9i-a80-apb0-gates-clk" - for the APB0 gates on A80
"allwinner,sun4i-a10-apb1-clk" - for the APB1 clock
++  "allwinner,sun8i-a83t-apb1-clk" - for the APB1 clock on A83T
"allwinner,sun9i-a80-apb1-clk" - for the APB1 bus clock on A80
"allwinner,sun4i-a10-apb1-gates-clk" - for the APB1 gates on A10
"allwinner,sun5i-a13-apb1-gates-clk" - for the APB1 gates on A13
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index a7aab65..171282d 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -872,6 +872,12 @@ static const struct div_data sun4i_apb0_data __initconst = 
{
.table  = sun4i_apb0_table,
 };
 
+static const struct div_data sun8i_a83t_apb1_data __initconst = {
+   .shift  = 8,
+   .pow= 0,
+   .width  = 2,
+};
+
 static void __init sunxi_divider_clk_setup(struct device_node *node,
   const struct div_data *data)
 {
@@ -938,6 +944,13 @@ static void __init sun4i_apb0_clk_setup(struct device_node 
*node)
 CLK_OF_DECLARE(sun4i_apb0, "allwinner,sun4i-a10-apb0-clk",
   sun4i_apb0_clk_setup);
 
+static void __init sun8i_a83t_apb1_clk_setup(struct device_node *node)
+{
+   sunxi_divider_clk_setup(node, _a83t_apb1_data);
+}
+CLK_OF_DECLARE(sun8i_a83t_apb1, "allwinner,sun8i-a83t-apb1-clk",
+  sun8i_a83t_apb1_clk_setup);
+
 static void __init sun4i_axi_clk_setup(struct device_node *node)
 {
sunxi_divider_clk_setup(node, _axi_data);
-- 
1.9.1

Re: [PATCH 8/8] sched: prefer cpufreq_scale_freq_capacity

[Peter Zijlstra]

On Wed, Mar 16, 2016 at 08:47:52AM +0100, Peter Zijlstra wrote:
> On Tue, Mar 15, 2016 at 03:27:21PM -0700, Michael Turquette wrote:

> > I'm happy with it as a stop-gap, because it will initially work for
> > arm{64} and x86, but we'll still need run-time selection of
> > arch_scale_freq_capacity some day. Once we have that, I think that we
> > should favor a run-time provided implementation over the arch-provided
> > one.
> 
> Also, I'm thinking we don't need any of this. Your
> cpufreq_scale_freq_capacity() is completely and utterly pointless. 

Scrap that, while true to instant utilization, this isn't true for our
case, since our utilization numbers carry history, and any frequency
change in that window is relevant.

Re: [PATCH 8/8] sched: prefer cpufreq_scale_freq_capacity

[Peter Zijlstra]

On Wed, Mar 16, 2016 at 08:47:52AM +0100, Peter Zijlstra wrote:
> On Tue, Mar 15, 2016 at 03:27:21PM -0700, Michael Turquette wrote:

> > I'm happy with it as a stop-gap, because it will initially work for
> > arm{64} and x86, but we'll still need run-time selection of
> > arch_scale_freq_capacity some day. Once we have that, I think that we
> > should favor a run-time provided implementation over the arch-provided
> > one.
> 
> Also, I'm thinking we don't need any of this. Your
> cpufreq_scale_freq_capacity() is completely and utterly pointless. 

Scrap that, while true to instant utilization, this isn't true for our
case, since our utilization numbers carry history, and any frequency
change in that window is relevant.

[RFC v3 1/3] dt-bindings: soc: Add documentation for the MediaTek GCE unit

[HS Liao]

This adds documentation for the MediaTek Global Command Engine (GCE) unit
found in MT8173 SoCs.

Signed-off-by: HS Liao 
---
 .../devicetree/bindings/soc/mediatek/gce.txt   |   34 
 1 file changed, 34 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/mediatek/gce.txt

diff --git a/Documentation/devicetree/bindings/soc/mediatek/gce.txt 
b/Documentation/devicetree/bindings/soc/mediatek/gce.txt
new file mode 100644
index 000..eff07e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/gce.txt
@@ -0,0 +1,34 @@
+MediaTek GCE
+===
+
+The Global Command Engine (GCE) is used to help read/write registers with
+critical time limitation, such as updating display configuration during the
+vblank. The GCE can be used to implement the Command Queue (CMDQ) driver.
+
+Required properties:
+- compatible: Must be "mediatek,mt8173-gce"
+- reg: Address range of the GCE unit
+- interrupts: The interrupt signal from the GCE block
+- clock: Clocks according to the common clock binding
+- clock-names: Must be "gce" to stand for GCE clock
+
+Required properties for a client device:
+- mediatek,gce: Should point to the respective GCE block
+
+Example:
+
+   gce: gce@10212000 {
+   compatible = "mediatek,mt8173-gce";
+   reg = <0 0x10212000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_INFRA_GCE>;
+   clock-names = "gce";
+   };
+
+Example for a client device:
+
+   mmsys: clock-controller@1400 {
+   compatible = "mediatek,mt8173-mmsys";
+   mediatek,gce = <>;
+   ...
+   };
-- 
1.7.9.5

[RFC v3 1/3] dt-bindings: soc: Add documentation for the MediaTek GCE unit

[HS Liao]

This adds documentation for the MediaTek Global Command Engine (GCE) unit
found in MT8173 SoCs.

Signed-off-by: HS Liao 
---
 .../devicetree/bindings/soc/mediatek/gce.txt   |   34 
 1 file changed, 34 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/mediatek/gce.txt

diff --git a/Documentation/devicetree/bindings/soc/mediatek/gce.txt 
b/Documentation/devicetree/bindings/soc/mediatek/gce.txt
new file mode 100644
index 000..eff07e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/gce.txt
@@ -0,0 +1,34 @@
+MediaTek GCE
+===
+
+The Global Command Engine (GCE) is used to help read/write registers with
+critical time limitation, such as updating display configuration during the
+vblank. The GCE can be used to implement the Command Queue (CMDQ) driver.
+
+Required properties:
+- compatible: Must be "mediatek,mt8173-gce"
+- reg: Address range of the GCE unit
+- interrupts: The interrupt signal from the GCE block
+- clock: Clocks according to the common clock binding
+- clock-names: Must be "gce" to stand for GCE clock
+
+Required properties for a client device:
+- mediatek,gce: Should point to the respective GCE block
+
+Example:
+
+   gce: gce@10212000 {
+   compatible = "mediatek,mt8173-gce";
+   reg = <0 0x10212000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_INFRA_GCE>;
+   clock-names = "gce";
+   };
+
+Example for a client device:
+
+   mmsys: clock-controller@1400 {
+   compatible = "mediatek,mt8173-mmsys";
+   mediatek,gce = <>;
+   ...
+   };
-- 
1.7.9.5

[PATCH 3.19.y-ckt 43/70] USB: qcserial: add Sierra Wireless EM74xx device ID

[Kamal Mostafa]

v3.19.8-ckt17 -stable review patch.  If anyone has any objections, please let 
me know.

---8<

From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= 

commit 04fdbc825ffc02fb098964b92de802fff44e73fd upstream.

The MC74xx and EM74xx modules use different IDs by default, according
to the Lenovo EM7455 driver for Windows.

Signed-off-by: Bjørn Mork 
Signed-off-by: Johan Hovold 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/serial/qcserial.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index f1eb03e..f0a2ad1 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -155,8 +155,10 @@ static const struct usb_device_id id_table[] = {
{DEVICE_SWI(0x1199, 0x9056)},   /* Sierra Wireless Modem */
{DEVICE_SWI(0x1199, 0x9060)},   /* Sierra Wireless Modem */
{DEVICE_SWI(0x1199, 0x9061)},   /* Sierra Wireless Modem */
-   {DEVICE_SWI(0x1199, 0x9070)},   /* Sierra Wireless MC74xx/EM74xx */
-   {DEVICE_SWI(0x1199, 0x9071)},   /* Sierra Wireless MC74xx/EM74xx */
+   {DEVICE_SWI(0x1199, 0x9070)},   /* Sierra Wireless MC74xx */
+   {DEVICE_SWI(0x1199, 0x9071)},   /* Sierra Wireless MC74xx */
+   {DEVICE_SWI(0x1199, 0x9078)},   /* Sierra Wireless EM74xx */
+   {DEVICE_SWI(0x1199, 0x9079)},   /* Sierra Wireless EM74xx */
{DEVICE_SWI(0x413c, 0x81a2)},   /* Dell Wireless 5806 Gobi(TM) 4G LTE 
Mobile Broadband Card */
{DEVICE_SWI(0x413c, 0x81a3)},   /* Dell Wireless 5570 HSPA+ (42Mbps) 
Mobile Broadband Card */
{DEVICE_SWI(0x413c, 0x81a4)},   /* Dell Wireless 5570e HSPA+ (42Mbps) 
Mobile Broadband Card */
-- 
2.7.0

Re: [PATCH v2] ARC: axs10x - add Ethernet PHY description in .dts

[Vineet Gupta]

On Thursday 17 March 2016 05:29 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 3/17/2016 2:41 PM, Vineet Gupta wrote:
>
>  Following commit broke DW GMAC functionality on AXS10x boards:
>  http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e34d65696d2ef13dc32f2a162556c86c461ed763
 >>>  Note that scripts/checkpatch.pl now enforces certain format for 
 >>> citing
 >>> commits: commit <12-digit SHA1> ("").
>>> >> Frankly I haven't run that patch through checkpatch due to patch
>>> >> simplicity.
>>> >>
>>> >> But I'll try to not do any assumptions from now on and will try to
>>> >> use checkpatch for each and every thing I send :)
>>> >>
>>> >> Thanks for spotting all his!
>>> >>
> Sorry for not reporting everything on the 1st review.
>
>>> >> -Alexey
>> >
>> > Sergei, do you mind providing a Ack/Reviewed-by on the patch below
>  >
>
> Reviewed-by: Sergei Shtylyov 

Thx.

> The patch here is white space damaged however: tabs were converted to 
> spaces. :-(
>
> MBR, Sergei


That was just because of copy-paste into mailer before switching to plain-text.
Don't ask - corporate email !
I added it just to give u an idea of what fixup i did.

Tx,
-Vineet

[PATCH 3.19.y-ckt 43/70] USB: qcserial: add Sierra Wireless EM74xx device ID

[Kamal Mostafa]

v3.19.8-ckt17 -stable review patch.  If anyone has any objections, please let 
me know.

---8<

From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= 

commit 04fdbc825ffc02fb098964b92de802fff44e73fd upstream.

The MC74xx and EM74xx modules use different IDs by default, according
to the Lenovo EM7455 driver for Windows.

Signed-off-by: Bjørn Mork 
Signed-off-by: Johan Hovold 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/serial/qcserial.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index f1eb03e..f0a2ad1 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -155,8 +155,10 @@ static const struct usb_device_id id_table[] = {
{DEVICE_SWI(0x1199, 0x9056)},   /* Sierra Wireless Modem */
{DEVICE_SWI(0x1199, 0x9060)},   /* Sierra Wireless Modem */
{DEVICE_SWI(0x1199, 0x9061)},   /* Sierra Wireless Modem */
-   {DEVICE_SWI(0x1199, 0x9070)},   /* Sierra Wireless MC74xx/EM74xx */
-   {DEVICE_SWI(0x1199, 0x9071)},   /* Sierra Wireless MC74xx/EM74xx */
+   {DEVICE_SWI(0x1199, 0x9070)},   /* Sierra Wireless MC74xx */
+   {DEVICE_SWI(0x1199, 0x9071)},   /* Sierra Wireless MC74xx */
+   {DEVICE_SWI(0x1199, 0x9078)},   /* Sierra Wireless EM74xx */
+   {DEVICE_SWI(0x1199, 0x9079)},   /* Sierra Wireless EM74xx */
{DEVICE_SWI(0x413c, 0x81a2)},   /* Dell Wireless 5806 Gobi(TM) 4G LTE 
Mobile Broadband Card */
{DEVICE_SWI(0x413c, 0x81a3)},   /* Dell Wireless 5570 HSPA+ (42Mbps) 
Mobile Broadband Card */
{DEVICE_SWI(0x413c, 0x81a4)},   /* Dell Wireless 5570e HSPA+ (42Mbps) 
Mobile Broadband Card */
-- 
2.7.0

Re: [PATCH v2] ARC: axs10x - add Ethernet PHY description in .dts

[Vineet Gupta]

On Thursday 17 March 2016 05:29 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 3/17/2016 2:41 PM, Vineet Gupta wrote:
>
>  Following commit broke DW GMAC functionality on AXS10x boards:
>  http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e34d65696d2ef13dc32f2a162556c86c461ed763
 >>>  Note that scripts/checkpatch.pl now enforces certain format for 
 >>> citing
 >>> commits: commit <12-digit SHA1> ("").
>>> >> Frankly I haven't run that patch through checkpatch due to patch
>>> >> simplicity.
>>> >>
>>> >> But I'll try to not do any assumptions from now on and will try to
>>> >> use checkpatch for each and every thing I send :)
>>> >>
>>> >> Thanks for spotting all his!
>>> >>
> Sorry for not reporting everything on the 1st review.
>
>>> >> -Alexey
>> >
>> > Sergei, do you mind providing a Ack/Reviewed-by on the patch below
>  >
>
> Reviewed-by: Sergei Shtylyov 

Thx.

> The patch here is white space damaged however: tabs were converted to 
> spaces. :-(
>
> MBR, Sergei


That was just because of copy-paste into mailer before switching to plain-text.
Don't ask - corporate email !
I added it just to give u an idea of what fixup i did.

Tx,
-Vineet

Re: [PATCH] Staging: rtl8192e: fix line length coding style issue in rtllib_softmac.c

[Joe Perches]

On Fri, 2016-03-18 at 17:48 +, Yousof El-Sayed wrote:
> This is a patch to the rtllib_softmac.c file that fixes up all instances of
>  the 'line over 80 characters' warnings found by the checkpatch.pl tool.
[]
> diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c 
> b/drivers/staging/rtl8192e/rtllib_softmac.c
[]
> @@ -389,7 +389,8 @@ static void rtllib_send_beacon(struct rtllib_device *ieee)
>  
>   if (ieee->beacon_txing && ieee->ieee_up)
>   mod_timer(>beacon_timer, jiffies +
> -   
> (msecs_to_jiffies(ieee->current_network.beacon_interval - 5)));
> +   (msecs_to_jiffies
> +    (ieee->current_network.beacon_interval - 5)));

Long identifier names like "current_network.beacon_interval",
which is 31 chars long, make the 80 column limit somewhat silly.

It's OK to ignore checkpatch warnings when changing the code
is less readable.

Most all of these are less nice than the original.

For instance, if this were to be changed (and it doesn't
need to be) perhaps:

>   if (ieee->beacon_txing && ieee->ieee_up)
>   mod_timer(>beacon_timer, jiffies +
> -   
> (msecs_to_jiffies(ieee->current_network.beacon_interval - 5)));
> +   (msecs_to_jiffies
> +    (ieee->current_network.beacon_interval - 5)));


mod_timer(>beacon_timer,
  jiffies +
  
msecs_to_jiffies(ieee->current_network.beacon_interval - 5));

which is still > 80 columns, but it removes an unnecessary
set of parentheses.

Breaking the msecs_to_jiffies() at the function name is
otherwise rather unsightly.

Always strive for readability and clarity over serving
some mindless script.

Re: [PATCH] Staging: rtl8192e: fix line length coding style issue in rtllib_softmac.c

[Joe Perches]

On Fri, 2016-03-18 at 17:48 +, Yousof El-Sayed wrote:
> This is a patch to the rtllib_softmac.c file that fixes up all instances of
>  the 'line over 80 characters' warnings found by the checkpatch.pl tool.
[]
> diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c 
> b/drivers/staging/rtl8192e/rtllib_softmac.c
[]
> @@ -389,7 +389,8 @@ static void rtllib_send_beacon(struct rtllib_device *ieee)
>  
>   if (ieee->beacon_txing && ieee->ieee_up)
>   mod_timer(>beacon_timer, jiffies +
> -   
> (msecs_to_jiffies(ieee->current_network.beacon_interval - 5)));
> +   (msecs_to_jiffies
> +    (ieee->current_network.beacon_interval - 5)));

Long identifier names like "current_network.beacon_interval",
which is 31 chars long, make the 80 column limit somewhat silly.

It's OK to ignore checkpatch warnings when changing the code
is less readable.

Most all of these are less nice than the original.

For instance, if this were to be changed (and it doesn't
need to be) perhaps:

>   if (ieee->beacon_txing && ieee->ieee_up)
>   mod_timer(>beacon_timer, jiffies +
> -   
> (msecs_to_jiffies(ieee->current_network.beacon_interval - 5)));
> +   (msecs_to_jiffies
> +    (ieee->current_network.beacon_interval - 5)));


mod_timer(>beacon_timer,
  jiffies +
  
msecs_to_jiffies(ieee->current_network.beacon_interval - 5));

which is still > 80 columns, but it removes an unnecessary
set of parentheses.

Breaking the msecs_to_jiffies() at the function name is
otherwise rather unsightly.

Always strive for readability and clarity over serving
some mindless script.

[PATCH] staging: rtl8712: Removed copyright notice

[Parth Sane]

Removed copyright notice as per checkpatch check warning.

Signed-off-by: Parth Sane 

---
 drivers/staging/rtl8712/drv_types.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/staging/rtl8712/drv_types.h 
b/drivers/staging/rtl8712/drv_types.h
index 29e47e1..ae79047 100644
--- a/drivers/staging/rtl8712/drv_types.h
+++ b/drivers/staging/rtl8712/drv_types.h
@@ -11,10 +11,6 @@
  * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
  * more details.
  *
- * You should have received a copy of the GNU General Public License along with
- * this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor, Boston, MA 02110, USA
- *
  * Modifications for inclusion into the Linux staging tree are
  * Copyright(c) 2010 Larry Finger. All rights reserved.
  *
-- 
1.9.1

[PATCH] staging: rtl8712: Removed copyright notice

[Parth Sane]

Removed copyright notice as per checkpatch check warning.

Signed-off-by: Parth Sane 

---
 drivers/staging/rtl8712/drv_types.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/staging/rtl8712/drv_types.h 
b/drivers/staging/rtl8712/drv_types.h
index 29e47e1..ae79047 100644
--- a/drivers/staging/rtl8712/drv_types.h
+++ b/drivers/staging/rtl8712/drv_types.h
@@ -11,10 +11,6 @@
  * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
  * more details.
  *
- * You should have received a copy of the GNU General Public License along with
- * this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor, Boston, MA 02110, USA
- *
  * Modifications for inclusion into the Linux staging tree are
  * Copyright(c) 2010 Larry Finger. All rights reserved.
  *
-- 
1.9.1

Re: [patch] direct-io: propagate -ENOSPC errors

[Carlos Maiolino]

This looks good to me.

Reviewed-by: Carlos Maiolino 

On Mon, Mar 14, 2016 at 05:10:00PM -0400, Jeff Moyer wrote:
> dio_bio_complete turns all errors into -EIO.  This is historical,
> since you used to only get 1 bit precision for errors (BIO_UPTODATE).
> Now that we get actual error codes, we can return the appropriate
> code to userspace.  File systems seem to only propagate either EIO
> or ENOSPC, so I've followed suit in this patch.
> 
> This fixes an issue where -ENOSPC was being turned into -EIO when
> testing dm-thin.
> 
> Reported-by: Carlos Maiolino 
> Tested-by: Mike Snitzer 
> Signed-off-by: Jeff Moyer 
> 
> diff --git a/fs/direct-io.c b/fs/direct-io.c
> index d6a9012..990e0aa 100644
> --- a/fs/direct-io.c
> +++ b/fs/direct-io.c
> @@ -466,13 +466,15 @@ static int dio_bio_complete(struct dio *dio, struct bio 
> *bio)
>  {
>   struct bio_vec *bvec;
>   unsigned i;
> - int err;
>  
> - if (bio->bi_error)
> + /* Only EIO and ENOSPC should be returned to userspace. */
> + if (bio->bi_error == 0 ||
> + bio->bi_error == -ENOSPC || bio->bi_error == -EIO)
> + dio->io_error = bio->bi_error;
> + else
>   dio->io_error = -EIO;
>  
>   if (dio->is_async && dio->rw == READ && dio->should_dirty) {
> - err = bio->bi_error;
>   bio_check_pages_dirty(bio); /* transfers ownership */
>   } else {
>   bio_for_each_segment_all(bvec, bio, i) {
> @@ -483,10 +485,9 @@ static int dio_bio_complete(struct dio *dio, struct bio 
> *bio)
>   set_page_dirty_lock(page);
>   page_cache_release(page);
>   }
> - err = bio->bi_error;
>   bio_put(bio);
>   }
> - return err;
> + return dio->io_error;
>  }
>  
>  /*
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Carlos

Re: [patch] direct-io: propagate -ENOSPC errors

[Carlos Maiolino]

This looks good to me.

Reviewed-by: Carlos Maiolino 

On Mon, Mar 14, 2016 at 05:10:00PM -0400, Jeff Moyer wrote:
> dio_bio_complete turns all errors into -EIO.  This is historical,
> since you used to only get 1 bit precision for errors (BIO_UPTODATE).
> Now that we get actual error codes, we can return the appropriate
> code to userspace.  File systems seem to only propagate either EIO
> or ENOSPC, so I've followed suit in this patch.
> 
> This fixes an issue where -ENOSPC was being turned into -EIO when
> testing dm-thin.
> 
> Reported-by: Carlos Maiolino 
> Tested-by: Mike Snitzer 
> Signed-off-by: Jeff Moyer 
> 
> diff --git a/fs/direct-io.c b/fs/direct-io.c
> index d6a9012..990e0aa 100644
> --- a/fs/direct-io.c
> +++ b/fs/direct-io.c
> @@ -466,13 +466,15 @@ static int dio_bio_complete(struct dio *dio, struct bio 
> *bio)
>  {
>   struct bio_vec *bvec;
>   unsigned i;
> - int err;
>  
> - if (bio->bi_error)
> + /* Only EIO and ENOSPC should be returned to userspace. */
> + if (bio->bi_error == 0 ||
> + bio->bi_error == -ENOSPC || bio->bi_error == -EIO)
> + dio->io_error = bio->bi_error;
> + else
>   dio->io_error = -EIO;
>  
>   if (dio->is_async && dio->rw == READ && dio->should_dirty) {
> - err = bio->bi_error;
>   bio_check_pages_dirty(bio); /* transfers ownership */
>   } else {
>   bio_for_each_segment_all(bvec, bio, i) {
> @@ -483,10 +485,9 @@ static int dio_bio_complete(struct dio *dio, struct bio 
> *bio)
>   set_page_dirty_lock(page);
>   page_cache_release(page);
>   }
> - err = bio->bi_error;
>   bio_put(bio);
>   }
> - return err;
> + return dio->io_error;
>  }
>  
>  /*
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Carlos

Re: [PATCH] qla2xxx: avoid maybe_uninitialized warning

[Ewan D. Milne]

On Wed, 2016-03-16 at 16:03 +0100, Tomas Henzl wrote:
> On 15.3.2016 22:40, Arnd Bergmann wrote:
> > The qlt_check_reserve_free_req() function produces an incorrect warning
> > when CONFIG_PROFILE_ANNOTATED_BRANCHES is set:
> >
> > drivers/scsi/qla2xxx/qla_target.c: In function 'qlt_check_reserve_free_req':
> > drivers/scsi/qla2xxx/qla_target.c:1887:3: error: 'cnt_in' may be used 
> > uninitialized in this function [-Werror=maybe-uninitialized]
> >ql_dbg(ql_dbg_io, vha, 0x305a,
> >^~
> >"qla_target(%d): There is no room in the request ring: 
> > vha->req->ring_index=%d, vha->req->cnt=%d, req_cnt=%d Req-out=%d Req-in=%d 
> > Req-Length=%d\n",
> >
> > ~~~
> >vha->vp_idx, vha->req->ring_index,
> >~~
> >vha->req->cnt, req_cnt, cnt, cnt_in, vha->req->length);
> >~~
> > drivers/scsi/qla2xxx/qla_target.c:1887:3: error: 'cnt' may be used 
> > uninitialized in this function [-Werror=maybe-uninitialized]
> >
> > The problem is that gcc fails to track the state of the condition across
> > an annotated branch.
> >
> > This slightly rearranges the code to move the second if() block
> > into the first one, to avoid the warning while retaining the
> > behavior of the code.
> 
> When the first 'if' is true the vha->req->ring_index gets a new value 
> assigned - so it could be possible that the second 'if' wont be true any more.
> The code should not be merged into that single 'if', or am I missing 
> something?
> 
> tomash

If the first "if" is false, the second "if" will be false also, because
the vha->req->cnt value has not changed.  If the first "if" is true, the
nested second "if" will retest the condition.

The compiler is not at fault, because vha->req->cnt can't be tracked as
it could be modified by another thread/process.  It isn't, it's protected
by the ->hardware_lock, but the compiler doesn't know that.

-Ewan

> >
> > Signed-off-by: Arnd Bergmann 
> > ---
> >  drivers/scsi/qla2xxx/qla_target.c | 16 +---
> >  1 file changed, 9 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/scsi/qla2xxx/qla_target.c 
> > b/drivers/scsi/qla2xxx/qla_target.c
> > index 985231900aca..8a44d1541eb4 100644
> > --- a/drivers/scsi/qla2xxx/qla_target.c
> > +++ b/drivers/scsi/qla2xxx/qla_target.c
> > @@ -1881,15 +1881,17 @@ static int qlt_check_reserve_free_req(struct 
> > scsi_qla_host *vha,
> > else
> > vha->req->cnt = vha->req->length -
> > (vha->req->ring_index - cnt);
> > -   }
> >  
> > -   if (unlikely(vha->req->cnt < (req_cnt + 2))) {
> > -   ql_dbg(ql_dbg_io, vha, 0x305a,
> > -   "qla_target(%d): There is no room in the request ring: 
> > vha->req->ring_index=%d, vha->req->cnt=%d, req_cnt=%d Req-out=%d Req-in=%d 
> > Req-Length=%d\n",
> > -   vha->vp_idx, vha->req->ring_index,
> > -   vha->req->cnt, req_cnt, cnt, cnt_in, vha->req->length);
> > -   return -EAGAIN;
> > +   if (unlikely(vha->req->cnt < (req_cnt + 2))) {
> > +   ql_dbg(ql_dbg_io, vha, 0x305a,
> > +   "qla_target(%d): There is no room in the request 
> > ring: vha->req->ring_index=%d, vha->req->cnt=%d, req_cnt=%d Req-out=%d 
> > Req-in=%d Req-Length=%d\n",
> > +   vha->vp_idx, vha->req->ring_index,
> > +   vha->req->cnt, req_cnt, cnt, cnt_in,
> > +   vha->req->length);
> > +   return -EAGAIN;
> > +   }
> > }
> > +
> > vha->req->cnt -= req_cnt;
> >  
> > return 0;
> 

Re: [PATCH] qla2xxx: avoid maybe_uninitialized warning

[Ewan D. Milne]

On Wed, 2016-03-16 at 16:03 +0100, Tomas Henzl wrote:
> On 15.3.2016 22:40, Arnd Bergmann wrote:
> > The qlt_check_reserve_free_req() function produces an incorrect warning
> > when CONFIG_PROFILE_ANNOTATED_BRANCHES is set:
> >
> > drivers/scsi/qla2xxx/qla_target.c: In function 'qlt_check_reserve_free_req':
> > drivers/scsi/qla2xxx/qla_target.c:1887:3: error: 'cnt_in' may be used 
> > uninitialized in this function [-Werror=maybe-uninitialized]
> >ql_dbg(ql_dbg_io, vha, 0x305a,
> >^~
> >"qla_target(%d): There is no room in the request ring: 
> > vha->req->ring_index=%d, vha->req->cnt=%d, req_cnt=%d Req-out=%d Req-in=%d 
> > Req-Length=%d\n",
> >
> > ~~~
> >vha->vp_idx, vha->req->ring_index,
> >~~
> >vha->req->cnt, req_cnt, cnt, cnt_in, vha->req->length);
> >~~
> > drivers/scsi/qla2xxx/qla_target.c:1887:3: error: 'cnt' may be used 
> > uninitialized in this function [-Werror=maybe-uninitialized]
> >
> > The problem is that gcc fails to track the state of the condition across
> > an annotated branch.
> >
> > This slightly rearranges the code to move the second if() block
> > into the first one, to avoid the warning while retaining the
> > behavior of the code.
> 
> When the first 'if' is true the vha->req->ring_index gets a new value 
> assigned - so it could be possible that the second 'if' wont be true any more.
> The code should not be merged into that single 'if', or am I missing 
> something?
> 
> tomash

If the first "if" is false, the second "if" will be false also, because
the vha->req->cnt value has not changed.  If the first "if" is true, the
nested second "if" will retest the condition.

The compiler is not at fault, because vha->req->cnt can't be tracked as
it could be modified by another thread/process.  It isn't, it's protected
by the ->hardware_lock, but the compiler doesn't know that.

-Ewan

> >
> > Signed-off-by: Arnd Bergmann 
> > ---
> >  drivers/scsi/qla2xxx/qla_target.c | 16 +---
> >  1 file changed, 9 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/scsi/qla2xxx/qla_target.c 
> > b/drivers/scsi/qla2xxx/qla_target.c
> > index 985231900aca..8a44d1541eb4 100644
> > --- a/drivers/scsi/qla2xxx/qla_target.c
> > +++ b/drivers/scsi/qla2xxx/qla_target.c
> > @@ -1881,15 +1881,17 @@ static int qlt_check_reserve_free_req(struct 
> > scsi_qla_host *vha,
> > else
> > vha->req->cnt = vha->req->length -
> > (vha->req->ring_index - cnt);
> > -   }
> >  
> > -   if (unlikely(vha->req->cnt < (req_cnt + 2))) {
> > -   ql_dbg(ql_dbg_io, vha, 0x305a,
> > -   "qla_target(%d): There is no room in the request ring: 
> > vha->req->ring_index=%d, vha->req->cnt=%d, req_cnt=%d Req-out=%d Req-in=%d 
> > Req-Length=%d\n",
> > -   vha->vp_idx, vha->req->ring_index,
> > -   vha->req->cnt, req_cnt, cnt, cnt_in, vha->req->length);
> > -   return -EAGAIN;
> > +   if (unlikely(vha->req->cnt < (req_cnt + 2))) {
> > +   ql_dbg(ql_dbg_io, vha, 0x305a,
> > +   "qla_target(%d): There is no room in the request 
> > ring: vha->req->ring_index=%d, vha->req->cnt=%d, req_cnt=%d Req-out=%d 
> > Req-in=%d Req-Length=%d\n",
> > +   vha->vp_idx, vha->req->ring_index,
> > +   vha->req->cnt, req_cnt, cnt, cnt_in,
> > +   vha->req->length);
> > +   return -EAGAIN;
> > +   }
> > }
> > +
> > vha->req->cnt -= req_cnt;
> >  
> > return 0;
> 

[PATCH] PKCS#7: fix missing break on OID_sha224 case

[Colin King]

From: Colin Ian King 

The OID_sha224 case is missing a break and it falls through
to the -ENOPKG error default.  Since HASH_ALGO_SHA224 seems
to be supported, this looks like an unintentional missing break.

Fixes: 07f081fb5057 ("PKCS#7: Add OIDs for sha224, sha284 and sha512 hash algos 
and use them")
Cc:  # 4.2+
Signed-off-by: Colin Ian King 
---
 crypto/asymmetric_keys/pkcs7_parser.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/crypto/asymmetric_keys/pkcs7_parser.c 
b/crypto/asymmetric_keys/pkcs7_parser.c
index 40de03f..bdd0d753 100644
--- a/crypto/asymmetric_keys/pkcs7_parser.c
+++ b/crypto/asymmetric_keys/pkcs7_parser.c
@@ -237,6 +237,7 @@ int pkcs7_sig_note_digest_algo(void *context, size_t hdrlen,
break;
case OID_sha224:
ctx->sinfo->sig.hash_algo = "sha224";
+   break;
default:
printk("Unsupported digest algo: %u\n", ctx->last_oid);
return -ENOPKG;
-- 
2.7.3

[PATCH] PKCS#7: fix missing break on OID_sha224 case

[Colin King]

From: Colin Ian King 

The OID_sha224 case is missing a break and it falls through
to the -ENOPKG error default.  Since HASH_ALGO_SHA224 seems
to be supported, this looks like an unintentional missing break.

Fixes: 07f081fb5057 ("PKCS#7: Add OIDs for sha224, sha284 and sha512 hash algos 
and use them")
Cc:  # 4.2+
Signed-off-by: Colin Ian King 
---
 crypto/asymmetric_keys/pkcs7_parser.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/crypto/asymmetric_keys/pkcs7_parser.c 
b/crypto/asymmetric_keys/pkcs7_parser.c
index 40de03f..bdd0d753 100644
--- a/crypto/asymmetric_keys/pkcs7_parser.c
+++ b/crypto/asymmetric_keys/pkcs7_parser.c
@@ -237,6 +237,7 @@ int pkcs7_sig_note_digest_algo(void *context, size_t hdrlen,
break;
case OID_sha224:
ctx->sinfo->sig.hash_algo = "sha224";
+   break;
default:
printk("Unsupported digest algo: %u\n", ctx->last_oid);
return -ENOPKG;
-- 
2.7.3

[PATCH 1/2] of: Implement iterator for phandles

[Joerg Roedel]

From: Joerg Roedel 

Getting the arguments of phandles is somewhat limited at the
moement, because the number of arguments supported by core
code is limited to MAX_PHANDLE_ARGS, which is set to 16
currently.

In case of the arm smmu this is not enough, as the 128
supported stream-ids are encoded in device-tree with
arguments to phandles. On some systems with more than 16
stream-ids this causes a WARN_ON being triggered at boot and
an incomplete initialization of the smmu.

This patch-set implements an iterator interface over
phandles which allows to parse out arbitrary numbers of
arguments per phandle. The existing function for parsing
them, __of_parse_phandle_with_args(), is converted to make
use of the iterator.

Signed-off-by: Joerg Roedel 
---
 drivers/of/base.c  | 219 ++---
 include/linux/of.h |  95 +++
 2 files changed, 220 insertions(+), 94 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 017dd94..9a5f199 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1439,119 +1439,150 @@ void of_print_phandle_args(const char *msg, const 
struct of_phandle_args *args)
printk("\n");
 }
 
-static int __of_parse_phandle_with_args(const struct device_node *np,
-   const char *list_name,
-   const char *cells_name,
-   int cell_count, int index,
-   struct of_phandle_args *out_args)
+int of_phandle_iterator_init(struct of_phandle_iterator *it,
+const struct device_node *np,
+const char *list_name,
+const char *cells_name,
+int cell_count)
 {
-   const __be32 *list, *list_end;
-   int rc = 0, size, cur_index = 0;
-   uint32_t count = 0;
-   struct device_node *node = NULL;
-   phandle phandle;
+   const __be32 *list;
+   int size;
 
/* Retrieve the phandle list property */
list = of_get_property(np, list_name, );
if (!list)
return -ENOENT;
-   list_end = list + size / sizeof(*list);
 
-   /* Loop over the phandles until all the requested entry is found */
-   while (list < list_end) {
-   rc = -EINVAL;
-   count = 0;
+   it->np  = np;
+   it->node= NULL;
+   it->list= list;
+   it->phandle_end = list;
+   it->list_end= list + size / sizeof(*list);
+   it->cells_name  = cells_name;
+   it->cell_count  = cell_count;
+   it->cur_index   = -1;
 
-   /*
-* If phandle is 0, then it is an empty entry with no
-* arguments.  Skip forward to the next entry.
-*/
-   phandle = be32_to_cpup(list++);
-   if (phandle) {
-   /*
-* Find the provider node and parse the #*-cells
-* property to determine the argument length.
-*
-* This is not needed if the cell count is hard-coded
-* (i.e. cells_name not set, but cell_count is set),
-* except when we're going to return the found node
-* below.
-*/
-   if (cells_name || cur_index == index) {
-   node = of_find_node_by_phandle(phandle);
-   if (!node) {
-   pr_err("%s: could not find phandle\n",
-   np->full_name);
-   goto err;
-   }
-   }
+   return 0;
+}
 
-   if (cells_name) {
-   if (of_property_read_u32(node, cells_name,
-)) {
-   pr_err("%s: could not get %s for %s\n",
-   np->full_name, cells_name,
-   node->full_name);
-   goto err;
-   }
-   } else {
-   count = cell_count;
-   }
+int of_phandle_iterator_next(struct of_phandle_iterator *it)
+{
+   phandle phandle = 0;
+   uint32_t count = 0;
 
-   /*
-* Make sure that the arguments actually fit in the
-* remaining property data length
-*/
-   if (list + count > list_end) {
-   pr_err("%s: arguments longer than property\n",
-

[PATCH 1/2] of: Implement iterator for phandles

[Joerg Roedel]

From: Joerg Roedel 

Getting the arguments of phandles is somewhat limited at the
moement, because the number of arguments supported by core
code is limited to MAX_PHANDLE_ARGS, which is set to 16
currently.

In case of the arm smmu this is not enough, as the 128
supported stream-ids are encoded in device-tree with
arguments to phandles. On some systems with more than 16
stream-ids this causes a WARN_ON being triggered at boot and
an incomplete initialization of the smmu.

This patch-set implements an iterator interface over
phandles which allows to parse out arbitrary numbers of
arguments per phandle. The existing function for parsing
them, __of_parse_phandle_with_args(), is converted to make
use of the iterator.

Signed-off-by: Joerg Roedel 
---
 drivers/of/base.c  | 219 ++---
 include/linux/of.h |  95 +++
 2 files changed, 220 insertions(+), 94 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 017dd94..9a5f199 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1439,119 +1439,150 @@ void of_print_phandle_args(const char *msg, const 
struct of_phandle_args *args)
printk("\n");
 }
 
-static int __of_parse_phandle_with_args(const struct device_node *np,
-   const char *list_name,
-   const char *cells_name,
-   int cell_count, int index,
-   struct of_phandle_args *out_args)
+int of_phandle_iterator_init(struct of_phandle_iterator *it,
+const struct device_node *np,
+const char *list_name,
+const char *cells_name,
+int cell_count)
 {
-   const __be32 *list, *list_end;
-   int rc = 0, size, cur_index = 0;
-   uint32_t count = 0;
-   struct device_node *node = NULL;
-   phandle phandle;
+   const __be32 *list;
+   int size;
 
/* Retrieve the phandle list property */
list = of_get_property(np, list_name, );
if (!list)
return -ENOENT;
-   list_end = list + size / sizeof(*list);
 
-   /* Loop over the phandles until all the requested entry is found */
-   while (list < list_end) {
-   rc = -EINVAL;
-   count = 0;
+   it->np  = np;
+   it->node= NULL;
+   it->list= list;
+   it->phandle_end = list;
+   it->list_end= list + size / sizeof(*list);
+   it->cells_name  = cells_name;
+   it->cell_count  = cell_count;
+   it->cur_index   = -1;
 
-   /*
-* If phandle is 0, then it is an empty entry with no
-* arguments.  Skip forward to the next entry.
-*/
-   phandle = be32_to_cpup(list++);
-   if (phandle) {
-   /*
-* Find the provider node and parse the #*-cells
-* property to determine the argument length.
-*
-* This is not needed if the cell count is hard-coded
-* (i.e. cells_name not set, but cell_count is set),
-* except when we're going to return the found node
-* below.
-*/
-   if (cells_name || cur_index == index) {
-   node = of_find_node_by_phandle(phandle);
-   if (!node) {
-   pr_err("%s: could not find phandle\n",
-   np->full_name);
-   goto err;
-   }
-   }
+   return 0;
+}
 
-   if (cells_name) {
-   if (of_property_read_u32(node, cells_name,
-)) {
-   pr_err("%s: could not get %s for %s\n",
-   np->full_name, cells_name,
-   node->full_name);
-   goto err;
-   }
-   } else {
-   count = cell_count;
-   }
+int of_phandle_iterator_next(struct of_phandle_iterator *it)
+{
+   phandle phandle = 0;
+   uint32_t count = 0;
 
-   /*
-* Make sure that the arguments actually fit in the
-* remaining property data length
-*/
-   if (list + count > list_end) {
-   pr_err("%s: arguments longer than property\n",
-np->full_name);
- 

Re: Suspicious error for CMA stress test

[Lucas Stach]

Hi Vlastimil, Joonsoo,

Am Freitag, den 18.03.2016, 00:52 +0900 schrieb Joonsoo Kim:
> 2016-03-18 0:43 GMT+09:00 Vlastimil Babka :
> > On 03/17/2016 10:24 AM, Hanjun Guo wrote:
> >>
> >> On 2016/3/17 14:54, Joonsoo Kim wrote:
> >>>
> >>> On Wed, Mar 16, 2016 at 05:44:28PM +0800, Hanjun Guo wrote:
> 
>  On 2016/3/14 15:18, Joonsoo Kim wrote:
> >
> > On Mon, Mar 14, 2016 at 08:06:16AM +0100, Vlastimil Babka wrote:
> >>
> >> On 03/14/2016 07:49 AM, Joonsoo Kim wrote:
> >>>
> >>> On Fri, Mar 11, 2016 at 06:07:40PM +0100, Vlastimil Babka wrote:
> 
>  On 03/11/2016 04:00 PM, Joonsoo Kim wrote:
> 
>  How about something like this? Just and idea, probably buggy
>  (off-by-one etc.).
>  Should keep away cost from   expense of the
>  relatively fewer >pageblock_order iterations.
> >>>
> >>> Hmm... I tested this and found that it's code size is a little bit
> >>> larger than mine. I'm not sure why this happens exactly but I guess
> >>> it would be
> >>> related to compiler optimization. In this case, I'm in favor of my
> >>> implementation because it looks like well abstraction. It adds one
> >>> unlikely branch to the merge loop but compiler would optimize it to
> >>> check it once.
> >>
> >> I would be surprised if compiler optimized that to check it once, as
> >> order increases with each loop iteration. But maybe it's smart
> >> enough to do something like I did by hand? Guess I'll check the
> >> disassembly.
> >
> > Okay. I used following slightly optimized version and I need to
> > add 'max_order = min_t(unsigned int, MAX_ORDER, pageblock_order + 1)'
> > to yours. Please consider it, too.
> 
>  Hmm, this one is not work, I still can see the bug is there after
>  applying
>  this patch, did I miss something?
> >>>
> >>> I may find that there is a bug which was introduced by me some time
> >>> ago. Could you test following change in __free_one_page() on top of
> >>> Vlastimil's patch?
> >>>
> >>> -page_idx = pfn & ((1 << max_order) - 1);
> >>> +page_idx = pfn & ((1 << MAX_ORDER) - 1);
> >>
> >>
> >> I tested Vlastimil's patch + your change with stress for more than half
> >> hour, the bug
> >> I reported is gone :)
> >
> >
> > Oh, ok, will try to send proper patch, once I figure out what to write in
> > the changelog :)
> 
> Thanks in advance!

After digging into the "PFN busy" race in CMA (see [1]), I believe we
should just prevent any buddy merging in isolated ranges. This fixes the
race I'm seeing without the need to hold the zone lock for extend
periods of time.
Also any merging done in an isolated range is likely to be completely
wasted work, as higher order buddy pages are broken up again into single
pages in isolate_freepages.

If we do that the patch to fix the bug in question for this report would
boil down to a check if the current pages buddy is isolated and abort
merging at that point, right? undo_isolate_page_range will then do all
necessary merging that has been skipped while the range was isolated.

Do you see issues with this approach?

Regards,
Lucas

[1] http://thread.gmane.org/gmane.linux.kernel.mm/148383

Re: Suspicious error for CMA stress test

[Lucas Stach]

Hi Vlastimil, Joonsoo,

Am Freitag, den 18.03.2016, 00:52 +0900 schrieb Joonsoo Kim:
> 2016-03-18 0:43 GMT+09:00 Vlastimil Babka :
> > On 03/17/2016 10:24 AM, Hanjun Guo wrote:
> >>
> >> On 2016/3/17 14:54, Joonsoo Kim wrote:
> >>>
> >>> On Wed, Mar 16, 2016 at 05:44:28PM +0800, Hanjun Guo wrote:
> 
>  On 2016/3/14 15:18, Joonsoo Kim wrote:
> >
> > On Mon, Mar 14, 2016 at 08:06:16AM +0100, Vlastimil Babka wrote:
> >>
> >> On 03/14/2016 07:49 AM, Joonsoo Kim wrote:
> >>>
> >>> On Fri, Mar 11, 2016 at 06:07:40PM +0100, Vlastimil Babka wrote:
> 
>  On 03/11/2016 04:00 PM, Joonsoo Kim wrote:
> 
>  How about something like this? Just and idea, probably buggy
>  (off-by-one etc.).
>  Should keep away cost from   expense of the
>  relatively fewer >pageblock_order iterations.
> >>>
> >>> Hmm... I tested this and found that it's code size is a little bit
> >>> larger than mine. I'm not sure why this happens exactly but I guess
> >>> it would be
> >>> related to compiler optimization. In this case, I'm in favor of my
> >>> implementation because it looks like well abstraction. It adds one
> >>> unlikely branch to the merge loop but compiler would optimize it to
> >>> check it once.
> >>
> >> I would be surprised if compiler optimized that to check it once, as
> >> order increases with each loop iteration. But maybe it's smart
> >> enough to do something like I did by hand? Guess I'll check the
> >> disassembly.
> >
> > Okay. I used following slightly optimized version and I need to
> > add 'max_order = min_t(unsigned int, MAX_ORDER, pageblock_order + 1)'
> > to yours. Please consider it, too.
> 
>  Hmm, this one is not work, I still can see the bug is there after
>  applying
>  this patch, did I miss something?
> >>>
> >>> I may find that there is a bug which was introduced by me some time
> >>> ago. Could you test following change in __free_one_page() on top of
> >>> Vlastimil's patch?
> >>>
> >>> -page_idx = pfn & ((1 << max_order) - 1);
> >>> +page_idx = pfn & ((1 << MAX_ORDER) - 1);
> >>
> >>
> >> I tested Vlastimil's patch + your change with stress for more than half
> >> hour, the bug
> >> I reported is gone :)
> >
> >
> > Oh, ok, will try to send proper patch, once I figure out what to write in
> > the changelog :)
> 
> Thanks in advance!

After digging into the "PFN busy" race in CMA (see [1]), I believe we
should just prevent any buddy merging in isolated ranges. This fixes the
race I'm seeing without the need to hold the zone lock for extend
periods of time.
Also any merging done in an isolated range is likely to be completely
wasted work, as higher order buddy pages are broken up again into single
pages in isolate_freepages.

If we do that the patch to fix the bug in question for this report would
boil down to a check if the current pages buddy is isolated and abort
merging at that point, right? undo_isolate_page_range will then do all
necessary merging that has been skipped while the range was isolated.

Do you see issues with this approach?

Regards,
Lucas

[1] http://thread.gmane.org/gmane.linux.kernel.mm/148383

[PATCH v3 2/3] ARM: DTS: da850/am4372/am33xx: Use generic node name for ehrpwm

[Franklin S Cooper Jr]

When possible generic node names should be used. So change the node name
from ehrpwm to pwm.

Signed-off-by: Franklin S Cooper Jr 
---
Version 3 changes:
Also update am335x-shc.dts

 arch/arm/boot/dts/am335x-shc.dts |  2 +-
 arch/arm/boot/dts/am33xx.dtsi|  6 +++---
 arch/arm/boot/dts/am4372.dtsi| 12 ++--
 arch/arm/boot/dts/da850.dtsi |  4 ++--
 4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-shc.dts b/arch/arm/boot/dts/am335x-shc.dts
index 1b5b044..a10f8be 100644
--- a/arch/arm/boot/dts/am335x-shc.dts
+++ b/arch/arm/boot/dts/am335x-shc.dts
@@ -138,7 +138,7 @@
  {
status = "okay";
 
-   ehrpwm1: ehrpwm@48302200 {
+   ehrpwm1: pwm@48302200 {
pinctrl-names = "default";
pinctrl-0 = <_pins>;
status = "okay";
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 1fafaad..4016254 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -688,7 +688,7 @@
status = "disabled";
};
 
-   ehrpwm0: ehrpwm@48300200 {
+   ehrpwm0: pwm@48300200 {
compatible = "ti,am33xx-ehrpwm";
#pwm-cells = <3>;
reg = <0x48300200 0x80>;
@@ -718,7 +718,7 @@
status = "disabled";
};
 
-   ehrpwm1: ehrpwm@48302200 {
+   ehrpwm1: pwm@48302200 {
compatible = "ti,am33xx-ehrpwm";
#pwm-cells = <3>;
reg = <0x48302200 0x80>;
@@ -748,7 +748,7 @@
status = "disabled";
};
 
-   ehrpwm2: ehrpwm@48304200 {
+   ehrpwm2: pwm@48304200 {
compatible = "ti,am33xx-ehrpwm";
#pwm-cells = <3>;
reg = <0x48304200 0x80>;
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 92068fb..33f417c 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -679,7 +679,7 @@
status = "disabled";
};
 
-   ehrpwm0: ehrpwm@48300200 {
+   ehrpwm0: pwm@48300200 {
compatible = 
"ti,am4372-ehrpwm","ti,am33xx-ehrpwm";
#pwm-cells = <3>;
reg = <0x48300200 0x80>;
@@ -705,7 +705,7 @@
status = "disabled";
};
 
-   ehrpwm1: ehrpwm@48302200 {
+   ehrpwm1: pwm@48302200 {
compatible = 
"ti,am4372-ehrpwm","ti,am33xx-ehrpwm";
#pwm-cells = <3>;
reg = <0x48302200 0x80>;
@@ -731,7 +731,7 @@
status = "disabled";
};
 
-   ehrpwm2: ehrpwm@48304200 {
+   ehrpwm2: pwm@48304200 {
compatible = 
"ti,am4372-ehrpwm","ti,am33xx-ehrpwm";
#pwm-cells = <3>;
reg = <0x48304200 0x80>;
@@ -749,7 +749,7 @@
ti,hwmods = "epwmss3";
status = "disabled";
 
-   ehrpwm3: ehrpwm@48306200 {
+   ehrpwm3: pwm@48306200 {
compatible = 
"ti,am4372-ehrpwm","ti,am33xx-ehrpwm";
#pwm-cells = <3>;
reg = <0x48306200 0x80>;
@@ -767,7 +767,7 @@
ti,hwmods = "epwmss4";
status = "disabled";
 
-   ehrpwm4: ehrpwm@48308200 {
+   ehrpwm4: pwm@48308200 {
compatible = 
"ti,am4372-ehrpwm","ti,am33xx-ehrpwm";
#pwm-cells = <3>;
reg = <0x48308200 0x80>;
@@ -785,7 +785,7 @@
ti,hwmods = "epwmss5";
status = "disabled";
 
-   ehrpwm5: ehrpwm@4830a200 {
+   ehrpwm5: pwm@4830a200 {
compatible = 
"ti,am4372-ehrpwm","ti,am33xx-ehrpwm";
#pwm-cells = <3>;
reg = <0x4830a200 0x80>;
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 226cda7..c3910e2 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -247,13 +247,13 @@
dma-names = "rx", "tx";
status = 

[PATCH v3 2/3] ARM: DTS: da850/am4372/am33xx: Use generic node name for ehrpwm

[Franklin S Cooper Jr]

When possible generic node names should be used. So change the node name
from ehrpwm to pwm.

Signed-off-by: Franklin S Cooper Jr 
---
Version 3 changes:
Also update am335x-shc.dts

 arch/arm/boot/dts/am335x-shc.dts |  2 +-
 arch/arm/boot/dts/am33xx.dtsi|  6 +++---
 arch/arm/boot/dts/am4372.dtsi| 12 ++--
 arch/arm/boot/dts/da850.dtsi |  4 ++--
 4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-shc.dts b/arch/arm/boot/dts/am335x-shc.dts
index 1b5b044..a10f8be 100644
--- a/arch/arm/boot/dts/am335x-shc.dts
+++ b/arch/arm/boot/dts/am335x-shc.dts
@@ -138,7 +138,7 @@
  {
status = "okay";
 
-   ehrpwm1: ehrpwm@48302200 {
+   ehrpwm1: pwm@48302200 {
pinctrl-names = "default";
pinctrl-0 = <_pins>;
status = "okay";
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 1fafaad..4016254 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -688,7 +688,7 @@
status = "disabled";
};
 
-   ehrpwm0: ehrpwm@48300200 {
+   ehrpwm0: pwm@48300200 {
compatible = "ti,am33xx-ehrpwm";
#pwm-cells = <3>;
reg = <0x48300200 0x80>;
@@ -718,7 +718,7 @@
status = "disabled";
};
 
-   ehrpwm1: ehrpwm@48302200 {
+   ehrpwm1: pwm@48302200 {
compatible = "ti,am33xx-ehrpwm";
#pwm-cells = <3>;
reg = <0x48302200 0x80>;
@@ -748,7 +748,7 @@
status = "disabled";
};
 
-   ehrpwm2: ehrpwm@48304200 {
+   ehrpwm2: pwm@48304200 {
compatible = "ti,am33xx-ehrpwm";
#pwm-cells = <3>;
reg = <0x48304200 0x80>;
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 92068fb..33f417c 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -679,7 +679,7 @@
status = "disabled";
};
 
-   ehrpwm0: ehrpwm@48300200 {
+   ehrpwm0: pwm@48300200 {
compatible = 
"ti,am4372-ehrpwm","ti,am33xx-ehrpwm";
#pwm-cells = <3>;
reg = <0x48300200 0x80>;
@@ -705,7 +705,7 @@
status = "disabled";
};
 
-   ehrpwm1: ehrpwm@48302200 {
+   ehrpwm1: pwm@48302200 {
compatible = 
"ti,am4372-ehrpwm","ti,am33xx-ehrpwm";
#pwm-cells = <3>;
reg = <0x48302200 0x80>;
@@ -731,7 +731,7 @@
status = "disabled";
};
 
-   ehrpwm2: ehrpwm@48304200 {
+   ehrpwm2: pwm@48304200 {
compatible = 
"ti,am4372-ehrpwm","ti,am33xx-ehrpwm";
#pwm-cells = <3>;
reg = <0x48304200 0x80>;
@@ -749,7 +749,7 @@
ti,hwmods = "epwmss3";
status = "disabled";
 
-   ehrpwm3: ehrpwm@48306200 {
+   ehrpwm3: pwm@48306200 {
compatible = 
"ti,am4372-ehrpwm","ti,am33xx-ehrpwm";
#pwm-cells = <3>;
reg = <0x48306200 0x80>;
@@ -767,7 +767,7 @@
ti,hwmods = "epwmss4";
status = "disabled";
 
-   ehrpwm4: ehrpwm@48308200 {
+   ehrpwm4: pwm@48308200 {
compatible = 
"ti,am4372-ehrpwm","ti,am33xx-ehrpwm";
#pwm-cells = <3>;
reg = <0x48308200 0x80>;
@@ -785,7 +785,7 @@
ti,hwmods = "epwmss5";
status = "disabled";
 
-   ehrpwm5: ehrpwm@4830a200 {
+   ehrpwm5: pwm@4830a200 {
compatible = 
"ti,am4372-ehrpwm","ti,am33xx-ehrpwm";
#pwm-cells = <3>;
reg = <0x4830a200 0x80>;
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 226cda7..c3910e2 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -247,13 +247,13 @@
dma-names = "rx", "tx";
status = "disabled";
 

Re: kernel/irq: Null-ptr deref on handle_irq_event_percpu function

[Thomas Gleixner]

On Wed, 16 Mar 2016, Baozeng Ding wrote:

> +linux-kernel and irq maitainer.
> 
> On Thu, Feb 25, 2016 at 04:16:10AM -0500, Red Hat Product Security wrote:
> > >
> > > I cannot produce the bug, but by taking a look at the
> > > code(irq/handle.c line176), it may
> > > casue a null pointer deref:
> > >
> > > http://lxr.free-electrons.com/source/kernel/irq/handle.c#L176

That's the upstream code which is different from what you are pasting.

> > > 174 retval |= res;
> > > 175 action = action->next;
> > > 176 } while (action); //when action is null, it will
> > > //cause a null pointer deref.

That lacks upstream commit 570540d507 or stable 4.4.y commit 827685a637

Thanks,

tglx

Re: kernel/irq: Null-ptr deref on handle_irq_event_percpu function

[Thomas Gleixner]

On Wed, 16 Mar 2016, Baozeng Ding wrote:

> +linux-kernel and irq maitainer.
> 
> On Thu, Feb 25, 2016 at 04:16:10AM -0500, Red Hat Product Security wrote:
> > >
> > > I cannot produce the bug, but by taking a look at the
> > > code(irq/handle.c line176), it may
> > > casue a null pointer deref:
> > >
> > > http://lxr.free-electrons.com/source/kernel/irq/handle.c#L176

That's the upstream code which is different from what you are pasting.

> > > 174 retval |= res;
> > > 175 action = action->next;
> > > 176 } while (action); //when action is null, it will
> > > //cause a null pointer deref.

That lacks upstream commit 570540d507 or stable 4.4.y commit 827685a637

Thanks,

tglx

Re: [PATCH 2/2] x86/mtrr: Refactor PAT initialization code

[Joe Lawrence]

On 03/14/2016 08:37 PM, Toshi Kani wrote:
[... snip ...]
>> Joe at Stratus also hit this issue but on a system where MTRR is enabled.
>> He sent his report only to me as he thought it was caused by the
>> ioremap_wc() changes and his driver was one that got it. In his case
>> though he modified the driver significantly, and upon inspection of that
>> code saw how it used a secondary backup PCI device for failover for a
>> framebuffer device... The changes to the driver in place are rather
>> complex though and as such it made no sense to further review unless he
>> moved his changes upstream.  It is still worth noting this issue has been
>> seeing elsehwere, but the root cause is still not known.  The error Joe
>> got is:
>>
>> x86/PAT: Xorg:37506 map pfn expected mapping type uncached-minus for [mem
>> 0x9f00-0x9f7f], got write-combining
>>
>> Even though the driver is custom (and actually I even saw another
>> unrelated proprietary driver loaded) I figured its worth noting others
>> have seen this error without MTRR being disabled.
> 
> The error message looks the same.  So, this could be the same issue if WC
> is redirected to UC without disabling PAT properly on his env.  I need a
> whole dmesg output to confirm if this is the case.  Another way to hit this
> error is that the driver called remap_pfn_range() with UC to a range where
> WC map was set by ioremap_wc() already.

As mentioned in the other thread, our driver is very custom and performs
some page table parlor tricks to failover the frame buffer from one PCI
adapter to another.  I need some time to fully digest these
customizations before I can really be of much help here.  My current
theory is that we have bug when do:

  ioremap_wc( backup adapter fb )
  iounmap   ( backup adapter fb )  << I'm unclear why this occurs
  ioremap_wc( primary adapter fb )

to failover, we stop_machine and remap the framebuffer (heavily
summarized: iterate through its pages, lookup_address to get a ptep, get
its __pgprot and then rewrite the pte to the new physical address and
the old pgprot_val.  A tlb flush on the way out of stop_machine).

Since this is all out-of-tree custom work, I'm not asking for any
support.  If we're too far off the reservation to be useful to the
conversation here, no worries.  I'm just trying to help if there is an
upstream bug.

>> The second thread you referred to seems to say that if you built-in the
>> code the error does not come up. What the hell. Joe, can you try building
>> your driver built-in to see if you also see this go away? Even though I
>> don't want to support your custom hacked up driver I do want to know if
>> your issue goes away with built-in as well.
> 
> I do not have sufficient info to support this case, and do not have
> technical explanation for it, either.

Luis -- I tried last night to reproduce (built as a module) without any
luck.  Going back through my test logs, it looks like the warning is
relatively sporadic and may take a few days to hit.  Without having a
better repro case, I think my warning is caused by that dodgy page table
work mentioned above (or at least timing related).  Let me see if I can
try to provoke the warning into happening more frequently first.

Regards,

-- Joe

Re: [PATCH 2/2] x86/mtrr: Refactor PAT initialization code

[Joe Lawrence]

On 03/14/2016 08:37 PM, Toshi Kani wrote:
[... snip ...]
>> Joe at Stratus also hit this issue but on a system where MTRR is enabled.
>> He sent his report only to me as he thought it was caused by the
>> ioremap_wc() changes and his driver was one that got it. In his case
>> though he modified the driver significantly, and upon inspection of that
>> code saw how it used a secondary backup PCI device for failover for a
>> framebuffer device... The changes to the driver in place are rather
>> complex though and as such it made no sense to further review unless he
>> moved his changes upstream.  It is still worth noting this issue has been
>> seeing elsehwere, but the root cause is still not known.  The error Joe
>> got is:
>>
>> x86/PAT: Xorg:37506 map pfn expected mapping type uncached-minus for [mem
>> 0x9f00-0x9f7f], got write-combining
>>
>> Even though the driver is custom (and actually I even saw another
>> unrelated proprietary driver loaded) I figured its worth noting others
>> have seen this error without MTRR being disabled.
> 
> The error message looks the same.  So, this could be the same issue if WC
> is redirected to UC without disabling PAT properly on his env.  I need a
> whole dmesg output to confirm if this is the case.  Another way to hit this
> error is that the driver called remap_pfn_range() with UC to a range where
> WC map was set by ioremap_wc() already.

As mentioned in the other thread, our driver is very custom and performs
some page table parlor tricks to failover the frame buffer from one PCI
adapter to another.  I need some time to fully digest these
customizations before I can really be of much help here.  My current
theory is that we have bug when do:

  ioremap_wc( backup adapter fb )
  iounmap   ( backup adapter fb )  << I'm unclear why this occurs
  ioremap_wc( primary adapter fb )

to failover, we stop_machine and remap the framebuffer (heavily
summarized: iterate through its pages, lookup_address to get a ptep, get
its __pgprot and then rewrite the pte to the new physical address and
the old pgprot_val.  A tlb flush on the way out of stop_machine).

Since this is all out-of-tree custom work, I'm not asking for any
support.  If we're too far off the reservation to be useful to the
conversation here, no worries.  I'm just trying to help if there is an
upstream bug.

>> The second thread you referred to seems to say that if you built-in the
>> code the error does not come up. What the hell. Joe, can you try building
>> your driver built-in to see if you also see this go away? Even though I
>> don't want to support your custom hacked up driver I do want to know if
>> your issue goes away with built-in as well.
> 
> I do not have sufficient info to support this case, and do not have
> technical explanation for it, either.

Luis -- I tried last night to reproduce (built as a module) without any
luck.  Going back through my test logs, it looks like the warning is
relatively sporadic and may take a few days to hit.  Without having a
better repro case, I think my warning is caused by that dodgy page table
work mentioned above (or at least timing related).  Let me see if I can
try to provoke the warning into happening more frequently first.

Regards,

-- Joe

[PATCH v3 3/3] pwm: pwm-tiehrpwm: Update dt binding document to use generic node name

[Franklin S Cooper Jr]

Now that the node name has been changed from ehrpwm to pwm the document
should show this proper usage. Also change the unit address in the example
from 0 to the proper physical address value that should be used.

Signed-off-by: Franklin S Cooper Jr 
---
Version 3 changes:
N/A

Version 2 changes:
Changed the unit address for da850 to match the value in the reg property.

 Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt 
b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
index 9c100b2..0f9ba50 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
@@ -15,14 +15,14 @@ Optional properties:
 
 Example:
 
-ehrpwm0: ehrpwm@0 { /* EHRPWM on am33xx */
+ehrpwm0: pwm@48300200 { /* EHRPWM on am33xx */
compatible = "ti,am33xx-ehrpwm";
#pwm-cells = <3>;
reg = <0x48300200 0x100>;
ti,hwmods = "ehrpwm0";
 };
 
-ehrpwm0: ehrpwm@0 { /* EHRPWM on da850 */
+ehrpwm0: pwm@30 { /* EHRPWM on da850 */
compatible = "ti,da850-ehrpwm", "ti,am33xx-ehrpwm";
#pwm-cells = <3>;
reg = <0x30 0x2000>;
-- 
2.7.0

[PATCH v3 3/3] pwm: pwm-tiehrpwm: Update dt binding document to use generic node name

[Franklin S Cooper Jr]

Now that the node name has been changed from ehrpwm to pwm the document
should show this proper usage. Also change the unit address in the example
from 0 to the proper physical address value that should be used.

Signed-off-by: Franklin S Cooper Jr 
---
Version 3 changes:
N/A

Version 2 changes:
Changed the unit address for da850 to match the value in the reg property.

 Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt 
b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
index 9c100b2..0f9ba50 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
@@ -15,14 +15,14 @@ Optional properties:
 
 Example:
 
-ehrpwm0: ehrpwm@0 { /* EHRPWM on am33xx */
+ehrpwm0: pwm@48300200 { /* EHRPWM on am33xx */
compatible = "ti,am33xx-ehrpwm";
#pwm-cells = <3>;
reg = <0x48300200 0x100>;
ti,hwmods = "ehrpwm0";
 };
 
-ehrpwm0: ehrpwm@0 { /* EHRPWM on da850 */
+ehrpwm0: pwm@30 { /* EHRPWM on da850 */
compatible = "ti,da850-ehrpwm", "ti,am33xx-ehrpwm";
#pwm-cells = <3>;
reg = <0x30 0x2000>;
-- 
2.7.0

Re: [PATCH] mmc: mmc_spi: Add Card Detect comments and fix CD GPIO case

[Ulf Hansson]

On 4 March 2016 at 10:41, Ulf Hansson  wrote:
> On 3 March 2016 at 16:28, Ulf Hansson  wrote:
>> On 16 February 2016 at 05:06, Magnus Damm  wrote:
>>> From: Magnus Damm 
>>>
>>> This patch adds comments to describe the various ways card detection
>>> may be implemented and when polling is needed. Also a fix is included
>>> to prevent the MMC SPI driver from polling when a CD GPIO that supports
>>> interrupts is specified using the gpios DT property (case 1).
>>>
>>> Without this patch the DT node below results in the following output:
>>>
>>>  spi_gpio: spi-gpio { /* SD2 @ CN12 */
>>>  compatible = "spi-gpio";
>>>  #address-cells = <1>;
>>>  #size-cells = <0>;
>>>  gpio-sck = < 16 GPIO_ACTIVE_HIGH>;
>>>  gpio-mosi = < 17 GPIO_ACTIVE_HIGH>;
>>>  gpio-miso = < 18 GPIO_ACTIVE_HIGH>;
>>>  num-chipselects = <1>;
>>>  cs-gpios = < 21 GPIO_ACTIVE_LOW>;
>>>  status = "okay";
>>>
>>>  spi@0 {
>>>  compatible = "mmc-spi-slot";
>>>  reg = <0>;
>>>  voltage-ranges = <3200 3400>;
>>>  spi-max-frequency = <2500>;
>>>  gpios = < 22 GPIO_ACTIVE_LOW>;   /* CD */
>>>  };
>>>  };
>>>
>>>  # dmesg | grep mmc
>>>  mmc_spi spi32766.0: SD/MMC host mmc0, no WP, no poweroff, cd polling
>>>  mmc0: host does not support reading read-only switch, assuming write-enable
>>>  mmc0: new SDHC card on SPI
>>>  mmcblk0: mmc0: SU04G 3.69 GiB
>>>  mmcblk0: p1
>>>
>>>  With this patch applied the "cd polling" portion above disappears.
>>>
>>> Signed-off-by: Magnus Damm 
>>
>> This looks good to me. Although do you think we need this for @stable as 
>> well?
>
> Ehh, as I am soon will be travelling and wanted this to be tested in
> linux next, I took the liberty to remove the comments, updated the
> change log and applied a stable tag.
>
> If think the comments are useful, please send a separate patch on top.
>
> So applied for fixes! Please have a look to make sure I looks okay to you.

Unfortunate I failed to send this in a PR to Linus within the 4.5 rc
cycle, apologize for the inconvenience!
Instead I have this queued for 4.6 and I have added a stable tag to it.

[...]

Kind regards
Uffe

Re: [PATCH] mmc: mmc_spi: Add Card Detect comments and fix CD GPIO case

[Ulf Hansson]

On 4 March 2016 at 10:41, Ulf Hansson  wrote:
> On 3 March 2016 at 16:28, Ulf Hansson  wrote:
>> On 16 February 2016 at 05:06, Magnus Damm  wrote:
>>> From: Magnus Damm 
>>>
>>> This patch adds comments to describe the various ways card detection
>>> may be implemented and when polling is needed. Also a fix is included
>>> to prevent the MMC SPI driver from polling when a CD GPIO that supports
>>> interrupts is specified using the gpios DT property (case 1).
>>>
>>> Without this patch the DT node below results in the following output:
>>>
>>>  spi_gpio: spi-gpio { /* SD2 @ CN12 */
>>>  compatible = "spi-gpio";
>>>  #address-cells = <1>;
>>>  #size-cells = <0>;
>>>  gpio-sck = < 16 GPIO_ACTIVE_HIGH>;
>>>  gpio-mosi = < 17 GPIO_ACTIVE_HIGH>;
>>>  gpio-miso = < 18 GPIO_ACTIVE_HIGH>;
>>>  num-chipselects = <1>;
>>>  cs-gpios = < 21 GPIO_ACTIVE_LOW>;
>>>  status = "okay";
>>>
>>>  spi@0 {
>>>  compatible = "mmc-spi-slot";
>>>  reg = <0>;
>>>  voltage-ranges = <3200 3400>;
>>>  spi-max-frequency = <2500>;
>>>  gpios = < 22 GPIO_ACTIVE_LOW>;   /* CD */
>>>  };
>>>  };
>>>
>>>  # dmesg | grep mmc
>>>  mmc_spi spi32766.0: SD/MMC host mmc0, no WP, no poweroff, cd polling
>>>  mmc0: host does not support reading read-only switch, assuming write-enable
>>>  mmc0: new SDHC card on SPI
>>>  mmcblk0: mmc0: SU04G 3.69 GiB
>>>  mmcblk0: p1
>>>
>>>  With this patch applied the "cd polling" portion above disappears.
>>>
>>> Signed-off-by: Magnus Damm 
>>
>> This looks good to me. Although do you think we need this for @stable as 
>> well?
>
> Ehh, as I am soon will be travelling and wanted this to be tested in
> linux next, I took the liberty to remove the comments, updated the
> change log and applied a stable tag.
>
> If think the comments are useful, please send a separate patch on top.
>
> So applied for fixes! Please have a look to make sure I looks okay to you.

Unfortunate I failed to send this in a PR to Linus within the 4.5 rc
cycle, apologize for the inconvenience!
Instead I have this queued for 4.6 and I have added a stable tag to it.

[...]

Kind regards
Uffe

[PATCH 1/1] linux-firmware: Update AMD microcode patch firmware

[Sherry Hurwitz]

For AMD Family 15h Processors to fix bugs in prior microcode patch
file: amd-ucode/microcode_amd_fam15h.bin
md5sum: 2384ef1d8ec8ca3930b62d82ea5a3813 

Version: 2016_03_16

Signed-off-by: Sherry Hurwitz 
---
 WHENCE |   2 +-
 amd-ucode/microcode_amd_fam15h.bin | Bin 7876 -> 7876 bytes
 amd-ucode/microcode_amd_fam15h.bin.asc |  14 +++---
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/WHENCE b/WHENCE
index 25f91d9..cecac23 100644
--- a/WHENCE
+++ b/WHENCE
@@ -2777,7 +2777,7 @@ Driver: microcode_amd - AMD CPU Microcode Update Driver 
for Linux
 File: amd-ucode/microcode_amd.bin
 Version: 2013-07-10
 File: amd-ucode/microcode_amd_fam15h.bin
-Version: 2014-10-28
+Version: 2016-03-16
 File: amd-ucode/microcode_amd_fam16h.bin
 Version: 2014-10-28
 
diff --git a/amd-ucode/microcode_amd_fam15h.bin 
b/amd-ucode/microcode_amd_fam15h.bin
index 
ec48ec0a18134832d70a4cd8cbf744bfe0ae1bd3..fc4278900493525f8bb122033aef9b818274b378
 100644
GIT binary patch
delta 2603
zcmV+`3e@$)J;Xh*dD3zGY}PU~Gy-E9C(f$~~Z%+44^>gLRQFPm|FHOZ92xu-
zQ1?+c%LDb{R}CJ7BP9sO&)20Ve*^szJXMx={7Pg_t&?$ICpGnnF9}%u5O;$CwZkiS
zUfz>#Qm>06=KQy=EP0t_`t;_VX%2cBE}GlNMbDTof8fOzf@F3nd{Jn
zgDf
zL(%kQtLFYp3l~+5kuI-jvSh;l8=LYQbrAG}(Tc4;h@4gNPcW2}tTNmnuuD|ww1L|d
zjuXDG1)F%o{Vyc(`vuw2f4n-z1hIyAU)gBKVo+%L=?!)P@a6@X%*9)mu^X=Rr-K`Z
z6Aofl^Yk#TV}0GdlEOjg!=wgIiJd#@p0yIVe;yW{G4~VQ20Y9@
zYkcKCda}IoO3}^HgOtJfBT|;%ljw=R(}XBvECL_o{k%FS_dzC*`CGMC
z4ATtJ9+Y#BT%*D3N-2s5`KWu6`PFHN#Y{qYdi=c{IcQFf(~mrz;7(YMINzOmrKslzUFvt}^u}?+
zuKdr0uC`ns+}^8fI%%`r5v%UKaopNkOpJS%I{{QH$LANzpw@I>^$xUNolGh5mpDGB
z_qDsZ{Iy(-`qC~8YAZ%GG{?8H;+yNj2KTA%ViNiH7YVo#e=<+n0YLY6imo>is2b-!?)l*+^am4Qu7#oJj^xfwa%$2;M?8cu*6<
zJHslUK;>E6Ad_eOt*;W2zeM=uI((Z!GV{NFJrpZK-kQSL(I!tPR?B`JqXuf9J1}FI
z?m=(cDm|Sve*|`iv(`t5+8ZVYubdjyXGXpj85!SACdpSC!ZJHN4hd73X08qTG1_jQ
zNtkc_taLL>)J70ayKl4@3^T1533OD*N^?sovcEp$r#)P?5&~nK@8{#;)^<}$PJjI2
z4wv9`zqD~hDsc>QH25AEUn-~;=({G(s1Hy64=hAZskr?3N(n|Rns59mJ4Tp)$JJ0!nyy~Rm1Ymprb^*4K-9PV
zzTcQU4QXi9kv?1oA?13Q4eWf1D96g>f8m7#isYB+rrSL7`q{FS|1C)_JCXO8+Luao
zf_VgatPj1qV4+ktNBF8(G+PP0)9H=um}d~#DY++V$@F|s|7iBVc`I-|q
zhyDeWU@=@6rwqRKxXUD$z&>UB0h&!7fczD?=q<6Fd4;0WCV&36
zNhg02%&>$k?qsJ9FbhD?*LN^+K-}6=$gs@MCaJf2Re6^L#JNt-RAnG(6EHobN`a_Sw4OnyZs*`%f){*pSHfBmI>I>DsC
zDBG%kBzY(3`%?YwsyqDEF-5#-d7WTXIt)@)t)vo(@jAf21);Su?-e2LJbL#{34Ca{
zcrznFs{FB9^o#++jl5%X{cfn1gg_jyWXpgs#%%^Ce2C&$|>N~o)4p0x@C

[PATCH 1/1] linux-firmware: Update AMD microcode patch firmware

[Sherry Hurwitz]

For AMD Family 15h Processors to fix bugs in prior microcode patch
file: amd-ucode/microcode_amd_fam15h.bin
md5sum: 2384ef1d8ec8ca3930b62d82ea5a3813 

Version: 2016_03_16

Signed-off-by: Sherry Hurwitz 
---
 WHENCE |   2 +-
 amd-ucode/microcode_amd_fam15h.bin | Bin 7876 -> 7876 bytes
 amd-ucode/microcode_amd_fam15h.bin.asc |  14 +++---
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/WHENCE b/WHENCE
index 25f91d9..cecac23 100644
--- a/WHENCE
+++ b/WHENCE
@@ -2777,7 +2777,7 @@ Driver: microcode_amd - AMD CPU Microcode Update Driver 
for Linux
 File: amd-ucode/microcode_amd.bin
 Version: 2013-07-10
 File: amd-ucode/microcode_amd_fam15h.bin
-Version: 2014-10-28
+Version: 2016-03-16
 File: amd-ucode/microcode_amd_fam16h.bin
 Version: 2014-10-28
 
diff --git a/amd-ucode/microcode_amd_fam15h.bin 
b/amd-ucode/microcode_amd_fam15h.bin
index 
ec48ec0a18134832d70a4cd8cbf744bfe0ae1bd3..fc4278900493525f8bb122033aef9b818274b378
 100644
GIT binary patch
delta 2603
zcmV+`3e@$)J;Xh*dD3zGY}PU~Gy-E9C(f$~~Z%+44^>gLRQFPm|FHOZ92xu-
zQ1?+c%LDb{R}CJ7BP9sO&)20Ve*^szJXMx={7Pg_t&?$ICpGnnF9}%u5O;$CwZkiS
zUfz>#Qm>06=KQy=EP0t_`t;_VX%2cBE}GlNMbDTof8fOzf@F3nd{Jn
zgDfSmj#76
zKY@Vz?g2PAPKD%-Qx<
zL(%kQtLFYp3l~+5kuI-jvSh;l8=LYQbrAG}(Tc4;h@4gNPcW2}tTNmnuuD|ww1L|d
zjuXDG1)F%o{Vyc(`vuw2f4n-z1hIyAU)gBKVo+%L=?!)P@a6@X%*9)mu^X=Rr-K`Z
z6Aofl^Yk#TV}0GdlEOjg!=wgIiJd#@p0yIVe;yW{G4~VQ20Y9@
zYkcKCda}IoO3}^HgOtJfBT|;%ljw=R(}XBvECL_o{k%FS_dzC*`CGMC
z4ATtJ9+Y#BT%*D3N-2s5`KWu6`PFHN#Y{qYdi=c{IcQFf(~mrz;7(YMINzOmrKslzUFvt}^u}?+
zuKdr0uC`ns+}^8fI%%`r5v%UKaopNkOpJS%I{{QH$LANzpw@I>^$xUNolGh5mpDGB
z_qDsZ{Iy(-`qC~8YAZ%GG{?8H;+yNj2KTA%ViNiH7YVo#e=<+n0YLY6imo>is2b-!?)l*+^am4Qu7#oJj^xfwa%$2;M?8cu*6<
zJHslUK;>E6Ad_eOt*;W2zeM=uI((Z!GV{NFJrpZK-kQSL(I!tPR?B`JqXuf9J1}FI
z?m=(cDm|Sve*|`iv(`t5+8ZVYubdjyXGXpj85!SACdpSC!ZJHN4hd73X08qTG1_jQ
zNtkc_taLL>)J70ayKl4@3^T1533OD*N^?sovcEp$r#)P?5&~nK@8{#;)^<}$PJjI2
z4wv9`zqD~hDsc>QH25AEUn-~;=({G(s1Hy64=hAZskr?3N(n|Rns59mJ4Tp)$JJ08{WqxPjk-N!SHNoy?LoY-n@NHtBEr!nyy~Rm1Ymprb^*4K-9PV
zzTcQU4QXi9kv?1oA?13Q4eWf1D96g>f8m7#isYB+rrSL7`q{FS|1C)_JCXO8+Luao
zf_VgatPj1qV4+ktNBF8(G+PP0)9H=um}d~#DY++V$@F|s|7iBVc`I-|q
zhyDeWU@=@6rwqRKxXUD$z&>UB0h&!7fczD?=q<6Fd4;0WCV&36
zNhg02%&>$k?qsJ9FbhD?*LN^+K-}6=$gs@MCaJf2Re6^L#JNt-RAnG(6EHobN`a_Sw4OnyZs*`%f){*pSHfBmI>I>DsC
zDBG%kBzY(3`%?YwsyqDEF-5#-d7WTXIt)@)t)vo(@jAf21);Su?-e2LJbL#{34Ca{
zcrznFs{FB9^o#++jl5%X{cfn1gg_jyWXpgs#%%^Ce2C&$|>N~o)4p0x@C
zlpY!L6hB~20%$Ivanc?Re*LP7V);~Z^po3%O)lvPAu0;(OSFK1-DZx#H
z--XDfj(pHBO>BuZmG9FUwT?1s+`T+-}vvl4x~i%
zGlY#WsHjSY;z)UPlU$tBddWVED}HLuM>l#{cPxAhkeYCKHSKbmI#`Bz9lSb8!+H9V?a{!Sg>4S3!zwOXI$B;{SwP$
zeTjUWBh9Fl*i9c|%!hRG6o0l_WfGtsH(2rI0j?a4bq!iwMSZ@@8m0AxL+c{O70>L$A3gobznt~^6qlAlkwAhP2jfT)sB6_@5)S|X

delta 2603
zcmV+`3e@$)J;Xh*dtM2H5Nl6*5_~rEV
zE54pxosKLvq=vb(6Bc)fm_p3UDZqot4*`I|>j}9;1tnPAk~_ZE5=){p>HdudF0NhS
z4l^Ur93kcGNvvYMymhT)ff6t3D^;F2mezlA7Ho{_c{tSssWU&7I=OeF#HI@lt_
zo2+~~A~L%2rGfe7e^p_5GMy<&{2ze)p
zzALazk8EKbg|>u!FB__Vykp$i1+Ls#ck(H{U=5Qbdea;|oZp#UXH1!;3QKpBB7Sp4
z5?C)BEb3EC{`g2O+3?o?z~TB
z2V>zWKgX@ibrZcu=S1?bQAJi#cF(Lz^|6B6e;{aWo{}y!^
zGyijW*Emh7wej1@ZED}T(VbV)eI`{pCI^7oy$sKS9nTL4jrn!s!7Zv`N(1GXIM
zyFRew6D8o0D^=e>-ZGNYIFpf4PQOH@7@v!1fs$y|kdt58{oyQ>So}nMcn7<8&
zUYr*juOf7>5Hi^@QiB($@SW2;7vuf)$NfjS*a?Gl4v#A2N#~?DrM-ENQf3{}2aXSA1S8vQRWtD6dwaa;mQ(Dp&${&8an-k>LR}xdY?-V
z*7239f0$#*ZqKs&{!}bsrB?0Af>`;-or#6OE{gVu|(WdPso$taS;E8{|127Tlq8
zTJhxh{k5%B4Jj+wVa>S6kIslA;!nsM8Xe@m;c%R4-d_UX^8Grxj^r%`z8`13Jf
z8cFP=oxf8YfDB%MV3gY3Y0T|+{Fh|TCo?iAYE)Pw6O5s^k69Mh-fMw?%)chz$FDAA
z+|Wcc>Gh5*b)Fpx7WidNd2G1vwNU3od)T5U;Kxl2`jF0v4-#;15#oRuc;XepMRA5n
zf2`pO>cMIIIqyarCtxN{lLraK#PcqtfbHW8xWEDQ_!cJpjaJxLuoYvyDfq!@|1SDCby(#1-)2%REvF=bdF
z!#(PUGZ?w0e{00^;FcTVwAvUI0**gb#7uxi4qDy*MWn6ekwZv?#r7(37?lM-Vo$9_suMo2?KnelV
z+kYzY|FfssQ4hxn;R3BhW^bnLe+4$Ka)Xf}n6~f;s*%x{lQp^6vMm)14+j#g%Hd#C
zqtz-KNtFa07G{SbFgCUh8#A}Vhp|Lul&6{Qfz|3C%4zV-#lVKa{?PLtl%B6Xj
zKc6F(n2Q$x&9h~S{pbl2^n7dIP4HB8|Ai#n>HSiq_<{>SBRI4gAfCoE2kslsE~x{$BK;EIjV_7X+48#$yNx
z1i$Az7D_5aRfw>b#rLTYB5R6q3(C?LcyT5O>rz(%BIRa{(
zC>etA^32B6>5{B41$xFCYY)gQd=8UzdUn(Z#@g(QIke1(V1Q-Df0a_2f2(sP@rqDe
zRX?@t;A@GZPsj9+f3Fp`8l0GU!X>;6UIh;`Il?a_(+X>Xgt4U=O0m-?(RV)~t2b`|
z9U7n%oF2Wbx`VZJrIGR0JvuZ+@2{wxB=8mgoIq^gtEdPTDnlTtaoz9pB>{z8dfc262M(*UnE;7w01jeU`#*p;y9
zcT~*`3L9r=V+taxSI1AGO>{WlDiAhU>EF(6z0NTMRFunr^g+{_9}7)
ND5M%y)w7%wC<>q00PO$(

diff --git a/amd-ucode/microcode_amd_fam15h.bin.asc 
b/amd-ucode/microcode_amd_fam15h.bin.asc
index 3bc803f..f303a1b 100644
--- a/amd-ucode/microcode_amd_fam15h.bin.asc
+++ b/amd-ucode/microcode_amd_fam15h.bin.asc
@@ -1,11 +1,11 @@
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1
 
-iQEcBAABAgAGBQJUTqLvAAoJEOS+UznzKK5zyaIIAKZcXmU+sBO4YGH5Aq2SdRYe
-rlwE5oeYNh+AdzzLm9EqHwSC+MciFI7HqQz8PvKAsfaoD17mQjonIXga8l2/w3OW
-/vIJjJnu9QB2C9XpjAiQCxS5QaMtIfEEjVld+MeHs6Ld3PwGuAXCkxKcJ2sHLZd3
-UcwwHxcm98KYouogjVZoJeb226cjz6fzUVJK9t9yi2S+SWmIvkjSZEI6W0WFoFCL
-x0jM7lFNcusGtg5K6UsyAdwPwvfbBN5FoV29/DaP+/HA4GP/W/cgbQxS72skDJg5
-c/icP0ntAND2iprtTQXF9//mWdX2FLYD55eu+pShZmO8t4Qvq4tJgiVz3hJiK+U=
-=KBP3