[PATCH V2 03/10] Documentation: devicetree: thermal: da9062/61 TJUNC temperature binding

[Steve Twiss]

From: Steve Twiss 

Device tree binding information for DA9062 and DA9061 thermal junction
temperature monitor.

Binding descriptions for the DA9061 and DA9062 thermal TJUNC supervisor
device driver, using a single THERMAL_TRIP_HOT trip-wire and allowing for
a configurable polling period for over-temperature polling.

Signed-off-by: Steve Twiss 

---
This patch applies against linux-next and v4.8

v1 -> v2
 - Patch renamed from [PATCH V1 08/10] to [PATCH V2 03/10] -- these
   changes were made to fix checkpatch warnings caused by the patch
   set dependency order
 - A second example for DA9061 is provided to highlight the use of a
   fall-back compatible option for the DA9062 watchdog driver

Hi,

This patch depends on acceptance of the main code for the thermal device
driver:
  [PATCH V2 09/10] thermal: da9061: TJUNC temperature driver 

The previous [PATCH V1 08/10] was acked-by: Rob Herring, however this has
not been added because changes have been made to add a new binding
example. This describes the use of DA9061.
This addition was made after alterations to the device driver meant that a
fall-back compatible string could reuse the DA9062 device driver.
 
Regards,
Steve Twiss, Dialog Semiconductor Ltd.


 .../devicetree/bindings/thermal/da9062-thermal.txt | 37 ++
 1 file changed, 37 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/thermal/da9062-thermal.txt

diff --git a/Documentation/devicetree/bindings/thermal/da9062-thermal.txt 
b/Documentation/devicetree/bindings/thermal/da9062-thermal.txt
new file mode 100644
index 000..fb207ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/da9062-thermal.txt
@@ -0,0 +1,37 @@
+* Dialog DA9062/61 TJUNC Thermal Module
+
+This module is part of the DA9061/DA9062. For more details about entire
+DA9062 and DA9061 chips see Documentation/devicetree/bindings/mfd/da9062.txt
+
+Junction temperature thermal module uses an interrupt signal to identify
+high THERMAL_TRIP_HOT temperatures for the PMIC device.
+
+Required properties:
+
+- compatible: should be one of:
+dlg,da9061-thermal
+dlg,da9062-thermal
+
+Optional properties:
+
+- dlg,tjunc-temp-polling-period-ms : Specify the polling period, measured
+in milliseconds, between thermal zone device update checks.
+
+Example: DA9061
+
+   pmic0: da9062@58 {
+   thermal {
+   compatible = "dlg,da9062-thermal";
+   dlg,tjunc-temp-polling-period-ms = <3000>;
+   };
+   };
+
+Example: DA9061 using a fall-back compatible for the DA9062 onkey driver
+
+   pmic0: da9061@58 {
+   thermal {
+   compatible = "dlg,da9061-thermal", "dlg,da9062-thermal";
+   dlg,tjunc-temp-polling-period-ms = <3000>;
+   };
+   };
+
-- 
end-of-patch for PATCH V2

Re: [PATCH 2/2] scsi: ufs: Use the resource-managed function to add devfreq device

[Subhash Jadavani]

On 2016-10-26 00:38, Chanwoo Choi wrote:

This patch uses the resource-managed to add the devfreq device.
This function will make it easy to handle the devfreq device.

- struct devfreq *devm_devfreq_add_device(struct device *dev,
  struct devfreq_dev_profile *profile,
  const char *governor_name,
  void *data);
Cc: Vinayak Holikatti 
Cc: James E.J. Bottomley 
Cc: Martin K. Petersen 
Cc: linux-s...@vger.kernel.org
Signed-off-by: Chanwoo Choi 
---
 drivers/scsi/ufs/ufshcd.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index f08d41a2d70b..e639071fd3a1 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -6198,8 +6198,6 @@ void ufshcd_remove(struct ufs_hba *hba)
scsi_host_put(hba->host);

ufshcd_exit_clk_gating(hba);
-   if (ufshcd_is_clkscaling_enabled(hba))
-   devfreq_remove_device(hba->devfreq);
ufshcd_hba_exit(hba);
 }
 EXPORT_SYMBOL_GPL(ufshcd_remove);
@@ -6495,7 +6493,7 @@ int ufshcd_init(struct ufs_hba *hba, void
__iomem *mmio_base, unsigned int irq)
}

if (ufshcd_is_clkscaling_enabled(hba)) {
-   hba->devfreq = devfreq_add_device(dev, _devfreq_profile,
+   hba->devfreq = devm_devfreq_add_device(dev, 
_devfreq_profile,
   "simple_ondemand", NULL);
if (IS_ERR(hba->devfreq)) {
dev_err(hba->dev, "Unable to register with devfreq 
%ld\n",


This change looks good to me but this will have merge conflicts if this 
gets in after my patch series "	[PATCH v1 00/11] scsi: ufs: bug fixes 
patch series #1" (due to "[PATCH v1 06/11] scsi: ufs: suspend clock 
scaling for failed runtime_resume"). so if you can, please pull in my 
patch series and rebase your change on top of it and send it out again.


Thanks,
Subhash

--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH V2 04/10] Documentation: devicetree: mfd: da9062/61 MFD binding

[Steve Twiss]

From: Steve Twiss 

Extend existing DA9062 binding information to include the DA9061 PMIC for
MFD core and regulators.

Add a da9062-onkey link to the existing onkey binding file.

Add a da9062-thermal link to the new temperature monitoring binding file
found in [PATCH V2 03/10].

Delete the da9062-watchdog section and replace it with a link to the new
DA9061/62 binding information file added by [PATCH V2 02/10].

Signed-off-by: Steve Twiss 

---
This patch applies against linux-next and v4.8

v1 -> v2
 - Patch renamed from [PATCH V1 09/10] to [PATCH V2 04/10] -- these
   changes were made to fix checkpatch warnings caused by the patch
   set dependency order

Hi,

This patch depends on acceptance of the main code for the DA9061 MFD:

- [PATCH V2 1/10] mfd: da9061: MFD core support

and also from the following binding file changes:

- [PATCH V2 01/10] Binding for onkey
- [PATCH V2 02/10] Binding for watchdog
- [PATCH V2 03/10] Binding for thermal

Regards,
Steve Twiss, Dialog Semiconductor Ltd.


 Documentation/devicetree/bindings/mfd/da9062.txt | 45 +---
 1 file changed, 33 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt 
b/Documentation/devicetree/bindings/mfd/da9062.txt
index 38802b5..38ba5e2 100644
--- a/Documentation/devicetree/bindings/mfd/da9062.txt
+++ b/Documentation/devicetree/bindings/mfd/da9062.txt
@@ -1,22 +1,32 @@
 * Dialog DA9062 Power Management Integrated Circuit (PMIC)
 
-DA9062 consists of a large and varied group of sub-devices:
+The DA9062 driver is compatible with the DA9062 and DA9061 devices.
+
+Product information can be found here:
+- http://www.dialog-semiconductor.com/products/da9062
+- http://www.dialog-semiconductor.com/products/da9061
+
+DA9062 driver consists of a large and varied group of sub-devices:
 
 Device   Supply NamesDescription
 --   ---
 da9062-regulator:   : LDOs & BUCKs
 da9062-rtc  :   : Real-Time Clock
+da9062-onkey:   : On Key
 da9062-watchdog :   : Watchdog Timer
+da9062-thermal  :   : Thermal
 
 ==
 
 Required properties:
 
-- compatible : Should be "dlg,da9062".
+- compatible : Should be
+"dlg,da9062" for DA9062
+"dlg,da9061" for DA9061
 - reg : Specifies the I2C slave address (this defaults to 0x58 but it can be
   modified to match the chip's OTP settings).
 - interrupt-parent : Specifies the reference to the interrupt controller for
-  the DA9062.
+  the DA9062 or DA9061.
 - interrupts : IRQ line information.
 - interrupt-controller
 
@@ -25,8 +35,8 @@ further information on IRQ bindings.
 
 Sub-nodes:
 
-- regulators : This node defines the settings for the LDOs and BUCKs. The
-  DA9062 regulators are bound using their names listed below:
+- regulators : This node defines the settings for the LDOs and BUCKs.
+  The DA9062 regulators are bound using their names listed below:
 
 buck1: BUCK_1
 buck2: BUCK_2
@@ -37,6 +47,16 @@ Sub-nodes:
 ldo3 : LDO_3
 ldo4 : LDO_4
 
+  The DA9061 regulators are bound using their names listed below:
+
+buck1: BUCK_1
+buck2: BUCK_2
+buck3: BUCK_3
+ldo1 : LDO_1
+ldo2 : LDO_2
+ldo3 : LDO_3
+ldo4 : LDO_4
+
   The component follows the standard regulator framework and the bindings
   details of individual regulator device can be found in:
   Documentation/devicetree/bindings/regulator/regulator.txt
@@ -46,9 +66,14 @@ Sub-nodes:
   with the DA9062. There are currently no entries in this binding, however
   compatible = "dlg,da9062-rtc" should be added if a node is created.
 
-- watchdog: This node defines the settings for the watchdog driver associated
-  with the DA9062 PMIC. The compatible = "dlg,da9062-watchdog" should be added
-  if a node is created.
+
+- onkey : See ../input/da9062-onkey.txt
+
+
+- watchdog: See ../watchdog/da9062-watchdog.txt
+
+
+- thermal : See ../thermal/da9062-thermal.txt
 
 
 Example:
@@ -64,10 +89,6 @@ Example:
compatible = "dlg,da9062-rtc";
};
 
-   watchdog {
-   compatible = "dlg,da9062-watchdog";
-   };
-
regulators {
DA9062_BUCK1: buck1 {
regulator-name = "BUCK1";
-- 
end-of-patch for PATCH V2

[PATCH V2 08/10] watchdog: da9062/61: watchdog driver

[Steve Twiss]

From: Steve Twiss 

The of_device_id match array is added to support "dlg,da9062-watchdog"
as a valid .compatible string.

The watchdog_info structure is linked to this device tree compatible
string in the .data section. Extra code is added into the probe function to
search-for and assign this match data.

This patch now assumes the use of a DA9062 fallback compatible string for
the DTS to pick up the DA9062 device driver for use with the DA9061
watchdog hardware.

Copyright header is updated to add DA9061 in its description and the module
description macro is extended to include DA9061.

Kconfig is updated to reflect support for DA9061/62.

Signed-off-by: Steve Twiss 

---
This patch applies against linux-next and v4.8

v1 -> v2
 - Patch renamed from [PATCH V1 04/10] to [PATCH V2 08/10] -- these
   changes were made to fix checkpatch warnings caused by the patch
   set dependency order
 - Removal of the DA9061 compatible entries for this device driver.
 - Additional explanation in the patch description for the use of a
   fall-back compatible DTS string

Guenter,

Alterations have been made in accordance with the previous e-mail thread
on the use of compatible strings: https://lkml.org/lkml/2016/10/7/641
This patch now assumes the use of a fallback compatible string in the DTS.
Of the form: compatible = "dlg,da9061-watchdog", "dlg,da9062-watchdog";

Regards,
Steve Twiss, Dialog Semiconductor Ltd.


 drivers/watchdog/Kconfig  |  4 ++--
 drivers/watchdog/da9062_wdt.c | 18 +++---
 2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 1bffe00..d6b4088 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -104,11 +104,11 @@ config DA9063_WATCHDOG
  This driver can be built as a module. The module name is da9063_wdt.
 
 config DA9062_WATCHDOG
-   tristate "Dialog DA9062 Watchdog"
+   tristate "Dialog DA9062/61 Watchdog"
depends on MFD_DA9062
select WATCHDOG_CORE
help
- Support for the watchdog in the DA9062 PMIC.
+ Support for the watchdog in the DA9062 and DA9061 PMICs.
 
  This driver can be built as a module. The module name is da9062_wdt.
 
diff --git a/drivers/watchdog/da9062_wdt.c b/drivers/watchdog/da9062_wdt.c
index 7386111..4b20b7a 100644
--- a/drivers/watchdog/da9062_wdt.c
+++ b/drivers/watchdog/da9062_wdt.c
@@ -1,5 +1,5 @@
 /*
- * da9062_wdt.c - WDT device driver for DA9062
+ * Watchdog device driver for DA9062 and DA9061 PMICs
  * Copyright (C) 2015  Dialog Semiconductor Ltd.
  *
  * This program is free software; you can redistribute it and/or
@@ -188,23 +188,34 @@ static const struct watchdog_ops da9062_watchdog_ops = {
.set_timeout = da9062_wdt_set_timeout,
 };
 
+static const struct of_device_id da9062_compatible_id_table[] = {
+   { .compatible = "dlg,da9062-watchdog", .data = _watchdog_info },
+   { },
+};
+
 static int da9062_wdt_probe(struct platform_device *pdev)
 {
int ret;
struct da9062 *chip;
struct da9062_watchdog *wdt;
+   const struct of_device_id *match;
 
chip = dev_get_drvdata(pdev->dev.parent);
if (!chip)
return -EINVAL;
 
+   match = of_match_node(da9062_compatible_id_table,
+ pdev->dev.of_node);
+   if (!match)
+   return -ENXIO;
+
wdt = devm_kzalloc(>dev, sizeof(*wdt), GFP_KERNEL);
if (!wdt)
return -ENOMEM;
 
wdt->hw = chip;
 
-   wdt->wdtdev.info = _watchdog_info;
+   wdt->wdtdev.info = (const struct watchdog_info *)match->data;
wdt->wdtdev.ops = _watchdog_ops;
wdt->wdtdev.min_timeout = DA9062_WDT_MIN_TIMEOUT;
wdt->wdtdev.max_timeout = DA9062_WDT_MAX_TIMEOUT;
@@ -244,11 +255,12 @@ static struct platform_driver da9062_wdt_driver = {
.remove = da9062_wdt_remove,
.driver = {
.name = "da9062-watchdog",
+   .of_match_table = da9062_compatible_id_table,
},
 };
 module_platform_driver(da9062_wdt_driver);
 
 MODULE_AUTHOR("S Twiss ");
-MODULE_DESCRIPTION("WDT device driver for Dialog DA9062");
+MODULE_DESCRIPTION("WDT device driver for Dialog DA9062 and DA9061");
 MODULE_LICENSE("GPL");
 MODULE_ALIAS("platform:da9062-watchdog");
-- 
end-of-patch for PATCH V2

Re: [Intel-wired-lan] [net-next PATCH 27/27] igb: Revert "igb: Revert support for build_skb in igb"

[Jeff Kirsher]

On Tue, 2016-10-25 at 11:39 -0400, Alexander Duyck wrote:
> This reverts commit f9d40f6a9921 ("igb: Revert support for build_skb in
> igb") and adds a few changes to update it to work with the latest version
> of igb. We are now able to revert the removal of this due to the fact
> that with the recent changes to the page count and the use of
> DMA_ATTR_SKIP_CPU_SYNC we can make the pages writable so we should not be
> invalidating the additional data added when we call build_skb.
> 
> The biggest risk with this change is that we are now not able to support
> full jumbo frames when using build_skb.  Instead we can only support up
> to
> 2K minus the skb overhead and padding offset.
> 
> Signed-off-by: Alexander Duyck 

Acked-by: Jeff Kirsher 

signature.asc
Description: This is a digitally signed message part

[PATCH V2 05/10] mfd: da9061: MFD core support

[Steve Twiss]

From: Steve Twiss 

MFD support for DA9061 is provided as part of the DA9062 device driver.

The registers header file adds two new chip variant IDs defined in DA9061
and DA9062 hardware. The core header file adds new software enumerations
for listing the valid DA9061 IRQs and a da9062_compatible_types enumeration
for distinguishing between DA9061/62 devices in software.

The core source code adds a new .compatible of_device_id entry. This is
extended from DA9062 to support both "dlg,da9061" and "dlg,da9062". The
.data entry now holds a reference to the enumerated device type.

A new regmap_irq_chip model is added for DA9061 and this supports the new
list of regmap_irq entries. A new mfd_cell da9061_devs[] array lists the
new sub system components for DA9061. Support is added for a new DA9061
regmap_config which lists the correct readable, writable and volatile
ranges for this chip.

The probe function uses the device tree compatible string to switch on the
da9062_compatible_types and configure the correct mfd cells, irq chip and
regmap config.
 
Kconfig is updated to reflect support for DA9061 and DA9062 PMICs.

Signed-off-by: Steve Twiss 

---
This patch applies against linux-next and v4.8

v1 -> v2
 - Patch renamed from [PATCH V1 01/10] to [PATCH V2 05/10] -- these
   changes were made to fix checkpatch warnings caused by the patch
   set dependency order
 - Fixed typo in the commit message "readble" to "readable"
 - Removed the explicit cross-check to decide if there is a conflict
   between the device tree compatible string and the hardware definition.
   This patch assumes the device tree is correctly written and therefore
   removes the need for a hardware/DT sanity check.
 - Removed extra semicolon in drivers/mfd/da9062-core.c:877
 - Re-write compatible entries into numerical order

Lee,

This patch adds support for the DA9061 PMIC. This is done as part of the
existing DA9062 device driver by extending the of_device_id match table.
This in turn allows new MFD cells, irq chip and regmap definitions to
support DA9061.

Regards,
Steve Twiss, Dialog Semiconductor Ltd.


 drivers/mfd/Kconfig  |   5 +-
 drivers/mfd/da9062-core.c| 427 +--
 include/linux/mfd/da9062/core.h  |  27 ++-
 include/linux/mfd/da9062/registers.h |   2 +
 4 files changed, 441 insertions(+), 20 deletions(-)

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 2d1fb64..533798a 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -236,13 +236,14 @@ config MFD_DA9055
  called "da9055"
 
 config MFD_DA9062
-   tristate "Dialog Semiconductor DA9062 PMIC Support"
+   tristate "Dialog Semiconductor DA9062/61 PMIC Support"
select MFD_CORE
select REGMAP_I2C
select REGMAP_IRQ
depends on I2C
help
- Say yes here for support for the Dialog Semiconductor DA9062 PMIC.
+ Say yes here for support for the Dialog Semiconductor DA9061 and
+ DA9062 PMICs.
  This includes the I2C driver and core APIs.
  Additional drivers must be enabled in order to use the functionality
  of the device.
diff --git a/drivers/mfd/da9062-core.c b/drivers/mfd/da9062-core.c
index 8f873866..6585ad6 100644
--- a/drivers/mfd/da9062-core.c
+++ b/drivers/mfd/da9062-core.c
@@ -1,5 +1,5 @@
 /*
- * Core, IRQ and I2C device driver for DA9062 PMIC
+ * Core, IRQ and I2C device driver for DA9061 and DA9062 PMICs
  * Copyright (C) 2015  Dialog Semiconductor Ltd.
  *
  * This program is free software; you can redistribute it and/or
@@ -30,6 +30,70 @@
 #defineDA9062_REG_EVENT_B_OFFSET   1
 #defineDA9062_REG_EVENT_C_OFFSET   2
 
+static struct regmap_irq da9061_irqs[] = {
+   /* EVENT A */
+   [DA9061_IRQ_ONKEY] = {
+   .reg_offset = DA9062_REG_EVENT_A_OFFSET,
+   .mask = DA9062AA_M_NONKEY_MASK,
+   },
+   [DA9061_IRQ_WDG_WARN] = {
+   .reg_offset = DA9062_REG_EVENT_A_OFFSET,
+   .mask = DA9062AA_M_WDG_WARN_MASK,
+   },
+   [DA9061_IRQ_SEQ_RDY] = {
+   .reg_offset = DA9062_REG_EVENT_A_OFFSET,
+   .mask = DA9062AA_M_SEQ_RDY_MASK,
+   },
+   /* EVENT B */
+   [DA9061_IRQ_TEMP] = {
+   .reg_offset = DA9062_REG_EVENT_B_OFFSET,
+   .mask = DA9062AA_M_TEMP_MASK,
+   },
+   [DA9061_IRQ_LDO_LIM] = {
+   .reg_offset = DA9062_REG_EVENT_B_OFFSET,
+   .mask = DA9062AA_M_LDO_LIM_MASK,
+   },
+   [DA9061_IRQ_DVC_RDY] = {
+   .reg_offset = DA9062_REG_EVENT_B_OFFSET,
+   .mask = DA9062AA_M_DVC_RDY_MASK,
+   },
+   [DA9061_IRQ_VDD_WARN] = {
+   .reg_offset = DA9062_REG_EVENT_B_OFFSET,
+   .mask = DA9062AA_M_VDD_WARN_MASK,
+   },
+   /* EVENT C */
+   [DA9061_IRQ_GPI0] = {
+   .reg_offset = 

[PATCH V2 08/10] watchdog: da9062/61: watchdog driver

[Steve Twiss]

From: Steve Twiss 

The of_device_id match array is added to support "dlg,da9062-watchdog"
as a valid .compatible string.

The watchdog_info structure is linked to this device tree compatible
string in the .data section. Extra code is added into the probe function to
search-for and assign this match data.

This patch now assumes the use of a DA9062 fallback compatible string for
the DTS to pick up the DA9062 device driver for use with the DA9061
watchdog hardware.

Copyright header is updated to add DA9061 in its description and the module
description macro is extended to include DA9061.

Kconfig is updated to reflect support for DA9061/62.

Signed-off-by: Steve Twiss 

---
This patch applies against linux-next and v4.8

v1 -> v2
 - Patch renamed from [PATCH V1 04/10] to [PATCH V2 08/10] -- these
   changes were made to fix checkpatch warnings caused by the patch
   set dependency order
 - Removal of the DA9061 compatible entries for this device driver.
 - Additional explanation in the patch description for the use of a
   fall-back compatible DTS string

Guenter,

Alterations have been made in accordance with the previous e-mail thread
on the use of compatible strings: https://lkml.org/lkml/2016/10/7/641
This patch now assumes the use of a fallback compatible string in the DTS.
Of the form: compatible = "dlg,da9061-watchdog", "dlg,da9062-watchdog";

Regards,
Steve Twiss, Dialog Semiconductor Ltd.


 drivers/watchdog/Kconfig  |  4 ++--
 drivers/watchdog/da9062_wdt.c | 18 +++---
 2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 1bffe00..d6b4088 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -104,11 +104,11 @@ config DA9063_WATCHDOG
  This driver can be built as a module. The module name is da9063_wdt.
 
 config DA9062_WATCHDOG
-   tristate "Dialog DA9062 Watchdog"
+   tristate "Dialog DA9062/61 Watchdog"
depends on MFD_DA9062
select WATCHDOG_CORE
help
- Support for the watchdog in the DA9062 PMIC.
+ Support for the watchdog in the DA9062 and DA9061 PMICs.
 
  This driver can be built as a module. The module name is da9062_wdt.
 
diff --git a/drivers/watchdog/da9062_wdt.c b/drivers/watchdog/da9062_wdt.c
index 7386111..4b20b7a 100644
--- a/drivers/watchdog/da9062_wdt.c
+++ b/drivers/watchdog/da9062_wdt.c
@@ -1,5 +1,5 @@
 /*
- * da9062_wdt.c - WDT device driver for DA9062
+ * Watchdog device driver for DA9062 and DA9061 PMICs
  * Copyright (C) 2015  Dialog Semiconductor Ltd.
  *
  * This program is free software; you can redistribute it and/or
@@ -188,23 +188,34 @@ static const struct watchdog_ops da9062_watchdog_ops = {
.set_timeout = da9062_wdt_set_timeout,
 };
 
+static const struct of_device_id da9062_compatible_id_table[] = {
+   { .compatible = "dlg,da9062-watchdog", .data = _watchdog_info },
+   { },
+};
+
 static int da9062_wdt_probe(struct platform_device *pdev)
 {
int ret;
struct da9062 *chip;
struct da9062_watchdog *wdt;
+   const struct of_device_id *match;
 
chip = dev_get_drvdata(pdev->dev.parent);
if (!chip)
return -EINVAL;
 
+   match = of_match_node(da9062_compatible_id_table,
+ pdev->dev.of_node);
+   if (!match)
+   return -ENXIO;
+
wdt = devm_kzalloc(>dev, sizeof(*wdt), GFP_KERNEL);
if (!wdt)
return -ENOMEM;
 
wdt->hw = chip;
 
-   wdt->wdtdev.info = _watchdog_info;
+   wdt->wdtdev.info = (const struct watchdog_info *)match->data;
wdt->wdtdev.ops = _watchdog_ops;
wdt->wdtdev.min_timeout = DA9062_WDT_MIN_TIMEOUT;
wdt->wdtdev.max_timeout = DA9062_WDT_MAX_TIMEOUT;
@@ -244,11 +255,12 @@ static struct platform_driver da9062_wdt_driver = {
.remove = da9062_wdt_remove,
.driver = {
.name = "da9062-watchdog",
+   .of_match_table = da9062_compatible_id_table,
},
 };
 module_platform_driver(da9062_wdt_driver);
 
 MODULE_AUTHOR("S Twiss ");
-MODULE_DESCRIPTION("WDT device driver for Dialog DA9062");
+MODULE_DESCRIPTION("WDT device driver for Dialog DA9062 and DA9061");
 MODULE_LICENSE("GPL");
 MODULE_ALIAS("platform:da9062-watchdog");
-- 
end-of-patch for PATCH V2

Re: [Intel-wired-lan] [net-next PATCH 27/27] igb: Revert "igb: Revert support for build_skb in igb"

[Jeff Kirsher]

On Tue, 2016-10-25 at 11:39 -0400, Alexander Duyck wrote:
> This reverts commit f9d40f6a9921 ("igb: Revert support for build_skb in
> igb") and adds a few changes to update it to work with the latest version
> of igb. We are now able to revert the removal of this due to the fact
> that with the recent changes to the page count and the use of
> DMA_ATTR_SKIP_CPU_SYNC we can make the pages writable so we should not be
> invalidating the additional data added when we call build_skb.
> 
> The biggest risk with this change is that we are now not able to support
> full jumbo frames when using build_skb.  Instead we can only support up
> to
> 2K minus the skb overhead and padding offset.
> 
> Signed-off-by: Alexander Duyck 

Acked-by: Jeff Kirsher 

signature.asc
Description: This is a digitally signed message part

[PATCH V2 05/10] mfd: da9061: MFD core support

[Steve Twiss]

From: Steve Twiss 

MFD support for DA9061 is provided as part of the DA9062 device driver.

The registers header file adds two new chip variant IDs defined in DA9061
and DA9062 hardware. The core header file adds new software enumerations
for listing the valid DA9061 IRQs and a da9062_compatible_types enumeration
for distinguishing between DA9061/62 devices in software.

The core source code adds a new .compatible of_device_id entry. This is
extended from DA9062 to support both "dlg,da9061" and "dlg,da9062". The
.data entry now holds a reference to the enumerated device type.

A new regmap_irq_chip model is added for DA9061 and this supports the new
list of regmap_irq entries. A new mfd_cell da9061_devs[] array lists the
new sub system components for DA9061. Support is added for a new DA9061
regmap_config which lists the correct readable, writable and volatile
ranges for this chip.

The probe function uses the device tree compatible string to switch on the
da9062_compatible_types and configure the correct mfd cells, irq chip and
regmap config.
 
Kconfig is updated to reflect support for DA9061 and DA9062 PMICs.

Signed-off-by: Steve Twiss 

---
This patch applies against linux-next and v4.8

v1 -> v2
 - Patch renamed from [PATCH V1 01/10] to [PATCH V2 05/10] -- these
   changes were made to fix checkpatch warnings caused by the patch
   set dependency order
 - Fixed typo in the commit message "readble" to "readable"
 - Removed the explicit cross-check to decide if there is a conflict
   between the device tree compatible string and the hardware definition.
   This patch assumes the device tree is correctly written and therefore
   removes the need for a hardware/DT sanity check.
 - Removed extra semicolon in drivers/mfd/da9062-core.c:877
 - Re-write compatible entries into numerical order

Lee,

This patch adds support for the DA9061 PMIC. This is done as part of the
existing DA9062 device driver by extending the of_device_id match table.
This in turn allows new MFD cells, irq chip and regmap definitions to
support DA9061.

Regards,
Steve Twiss, Dialog Semiconductor Ltd.


 drivers/mfd/Kconfig  |   5 +-
 drivers/mfd/da9062-core.c| 427 +--
 include/linux/mfd/da9062/core.h  |  27 ++-
 include/linux/mfd/da9062/registers.h |   2 +
 4 files changed, 441 insertions(+), 20 deletions(-)

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 2d1fb64..533798a 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -236,13 +236,14 @@ config MFD_DA9055
  called "da9055"
 
 config MFD_DA9062
-   tristate "Dialog Semiconductor DA9062 PMIC Support"
+   tristate "Dialog Semiconductor DA9062/61 PMIC Support"
select MFD_CORE
select REGMAP_I2C
select REGMAP_IRQ
depends on I2C
help
- Say yes here for support for the Dialog Semiconductor DA9062 PMIC.
+ Say yes here for support for the Dialog Semiconductor DA9061 and
+ DA9062 PMICs.
  This includes the I2C driver and core APIs.
  Additional drivers must be enabled in order to use the functionality
  of the device.
diff --git a/drivers/mfd/da9062-core.c b/drivers/mfd/da9062-core.c
index 8f873866..6585ad6 100644
--- a/drivers/mfd/da9062-core.c
+++ b/drivers/mfd/da9062-core.c
@@ -1,5 +1,5 @@
 /*
- * Core, IRQ and I2C device driver for DA9062 PMIC
+ * Core, IRQ and I2C device driver for DA9061 and DA9062 PMICs
  * Copyright (C) 2015  Dialog Semiconductor Ltd.
  *
  * This program is free software; you can redistribute it and/or
@@ -30,6 +30,70 @@
 #defineDA9062_REG_EVENT_B_OFFSET   1
 #defineDA9062_REG_EVENT_C_OFFSET   2
 
+static struct regmap_irq da9061_irqs[] = {
+   /* EVENT A */
+   [DA9061_IRQ_ONKEY] = {
+   .reg_offset = DA9062_REG_EVENT_A_OFFSET,
+   .mask = DA9062AA_M_NONKEY_MASK,
+   },
+   [DA9061_IRQ_WDG_WARN] = {
+   .reg_offset = DA9062_REG_EVENT_A_OFFSET,
+   .mask = DA9062AA_M_WDG_WARN_MASK,
+   },
+   [DA9061_IRQ_SEQ_RDY] = {
+   .reg_offset = DA9062_REG_EVENT_A_OFFSET,
+   .mask = DA9062AA_M_SEQ_RDY_MASK,
+   },
+   /* EVENT B */
+   [DA9061_IRQ_TEMP] = {
+   .reg_offset = DA9062_REG_EVENT_B_OFFSET,
+   .mask = DA9062AA_M_TEMP_MASK,
+   },
+   [DA9061_IRQ_LDO_LIM] = {
+   .reg_offset = DA9062_REG_EVENT_B_OFFSET,
+   .mask = DA9062AA_M_LDO_LIM_MASK,
+   },
+   [DA9061_IRQ_DVC_RDY] = {
+   .reg_offset = DA9062_REG_EVENT_B_OFFSET,
+   .mask = DA9062AA_M_DVC_RDY_MASK,
+   },
+   [DA9061_IRQ_VDD_WARN] = {
+   .reg_offset = DA9062_REG_EVENT_B_OFFSET,
+   .mask = DA9062AA_M_VDD_WARN_MASK,
+   },
+   /* EVENT C */
+   [DA9061_IRQ_GPI0] = {
+   .reg_offset = DA9062_REG_EVENT_C_OFFSET,
+   .mask = 

[PATCH V2 03/10] Documentation: devicetree: thermal: da9062/61 TJUNC temperature binding

[Steve Twiss]

From: Steve Twiss 

Device tree binding information for DA9062 and DA9061 thermal junction
temperature monitor.

Binding descriptions for the DA9061 and DA9062 thermal TJUNC supervisor
device driver, using a single THERMAL_TRIP_HOT trip-wire and allowing for
a configurable polling period for over-temperature polling.

Signed-off-by: Steve Twiss 

---
This patch applies against linux-next and v4.8

v1 -> v2
 - Patch renamed from [PATCH V1 08/10] to [PATCH V2 03/10] -- these
   changes were made to fix checkpatch warnings caused by the patch
   set dependency order
 - A second example for DA9061 is provided to highlight the use of a
   fall-back compatible option for the DA9062 watchdog driver

Hi,

This patch depends on acceptance of the main code for the thermal device
driver:
  [PATCH V2 09/10] thermal: da9061: TJUNC temperature driver 

The previous [PATCH V1 08/10] was acked-by: Rob Herring, however this has
not been added because changes have been made to add a new binding
example. This describes the use of DA9061.
This addition was made after alterations to the device driver meant that a
fall-back compatible string could reuse the DA9062 device driver.
 
Regards,
Steve Twiss, Dialog Semiconductor Ltd.


 .../devicetree/bindings/thermal/da9062-thermal.txt | 37 ++
 1 file changed, 37 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/thermal/da9062-thermal.txt

diff --git a/Documentation/devicetree/bindings/thermal/da9062-thermal.txt 
b/Documentation/devicetree/bindings/thermal/da9062-thermal.txt
new file mode 100644
index 000..fb207ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/da9062-thermal.txt
@@ -0,0 +1,37 @@
+* Dialog DA9062/61 TJUNC Thermal Module
+
+This module is part of the DA9061/DA9062. For more details about entire
+DA9062 and DA9061 chips see Documentation/devicetree/bindings/mfd/da9062.txt
+
+Junction temperature thermal module uses an interrupt signal to identify
+high THERMAL_TRIP_HOT temperatures for the PMIC device.
+
+Required properties:
+
+- compatible: should be one of:
+dlg,da9061-thermal
+dlg,da9062-thermal
+
+Optional properties:
+
+- dlg,tjunc-temp-polling-period-ms : Specify the polling period, measured
+in milliseconds, between thermal zone device update checks.
+
+Example: DA9061
+
+   pmic0: da9062@58 {
+   thermal {
+   compatible = "dlg,da9062-thermal";
+   dlg,tjunc-temp-polling-period-ms = <3000>;
+   };
+   };
+
+Example: DA9061 using a fall-back compatible for the DA9062 onkey driver
+
+   pmic0: da9061@58 {
+   thermal {
+   compatible = "dlg,da9061-thermal", "dlg,da9062-thermal";
+   dlg,tjunc-temp-polling-period-ms = <3000>;
+   };
+   };
+
-- 
end-of-patch for PATCH V2

Re: [PATCH 2/2] scsi: ufs: Use the resource-managed function to add devfreq device

[Subhash Jadavani]

On 2016-10-26 00:38, Chanwoo Choi wrote:

This patch uses the resource-managed to add the devfreq device.
This function will make it easy to handle the devfreq device.

- struct devfreq *devm_devfreq_add_device(struct device *dev,
  struct devfreq_dev_profile *profile,
  const char *governor_name,
  void *data);
Cc: Vinayak Holikatti 
Cc: James E.J. Bottomley 
Cc: Martin K. Petersen 
Cc: linux-s...@vger.kernel.org
Signed-off-by: Chanwoo Choi 
---
 drivers/scsi/ufs/ufshcd.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index f08d41a2d70b..e639071fd3a1 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -6198,8 +6198,6 @@ void ufshcd_remove(struct ufs_hba *hba)
scsi_host_put(hba->host);

ufshcd_exit_clk_gating(hba);
-   if (ufshcd_is_clkscaling_enabled(hba))
-   devfreq_remove_device(hba->devfreq);
ufshcd_hba_exit(hba);
 }
 EXPORT_SYMBOL_GPL(ufshcd_remove);
@@ -6495,7 +6493,7 @@ int ufshcd_init(struct ufs_hba *hba, void
__iomem *mmio_base, unsigned int irq)
}

if (ufshcd_is_clkscaling_enabled(hba)) {
-   hba->devfreq = devfreq_add_device(dev, _devfreq_profile,
+   hba->devfreq = devm_devfreq_add_device(dev, 
_devfreq_profile,
   "simple_ondemand", NULL);
if (IS_ERR(hba->devfreq)) {
dev_err(hba->dev, "Unable to register with devfreq 
%ld\n",


This change looks good to me but this will have merge conflicts if this 
gets in after my patch series "	[PATCH v1 00/11] scsi: ufs: bug fixes 
patch series #1" (due to "[PATCH v1 06/11] scsi: ufs: suspend clock 
scaling for failed runtime_resume"). so if you can, please pull in my 
patch series and rebase your change on top of it and send it out again.


Thanks,
Subhash

--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH V2 04/10] Documentation: devicetree: mfd: da9062/61 MFD binding

[Steve Twiss]

From: Steve Twiss 

Extend existing DA9062 binding information to include the DA9061 PMIC for
MFD core and regulators.

Add a da9062-onkey link to the existing onkey binding file.

Add a da9062-thermal link to the new temperature monitoring binding file
found in [PATCH V2 03/10].

Delete the da9062-watchdog section and replace it with a link to the new
DA9061/62 binding information file added by [PATCH V2 02/10].

Signed-off-by: Steve Twiss 

---
This patch applies against linux-next and v4.8

v1 -> v2
 - Patch renamed from [PATCH V1 09/10] to [PATCH V2 04/10] -- these
   changes were made to fix checkpatch warnings caused by the patch
   set dependency order

Hi,

This patch depends on acceptance of the main code for the DA9061 MFD:

- [PATCH V2 1/10] mfd: da9061: MFD core support

and also from the following binding file changes:

- [PATCH V2 01/10] Binding for onkey
- [PATCH V2 02/10] Binding for watchdog
- [PATCH V2 03/10] Binding for thermal

Regards,
Steve Twiss, Dialog Semiconductor Ltd.


 Documentation/devicetree/bindings/mfd/da9062.txt | 45 +---
 1 file changed, 33 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt 
b/Documentation/devicetree/bindings/mfd/da9062.txt
index 38802b5..38ba5e2 100644
--- a/Documentation/devicetree/bindings/mfd/da9062.txt
+++ b/Documentation/devicetree/bindings/mfd/da9062.txt
@@ -1,22 +1,32 @@
 * Dialog DA9062 Power Management Integrated Circuit (PMIC)
 
-DA9062 consists of a large and varied group of sub-devices:
+The DA9062 driver is compatible with the DA9062 and DA9061 devices.
+
+Product information can be found here:
+- http://www.dialog-semiconductor.com/products/da9062
+- http://www.dialog-semiconductor.com/products/da9061
+
+DA9062 driver consists of a large and varied group of sub-devices:
 
 Device   Supply NamesDescription
 --   ---
 da9062-regulator:   : LDOs & BUCKs
 da9062-rtc  :   : Real-Time Clock
+da9062-onkey:   : On Key
 da9062-watchdog :   : Watchdog Timer
+da9062-thermal  :   : Thermal
 
 ==
 
 Required properties:
 
-- compatible : Should be "dlg,da9062".
+- compatible : Should be
+"dlg,da9062" for DA9062
+"dlg,da9061" for DA9061
 - reg : Specifies the I2C slave address (this defaults to 0x58 but it can be
   modified to match the chip's OTP settings).
 - interrupt-parent : Specifies the reference to the interrupt controller for
-  the DA9062.
+  the DA9062 or DA9061.
 - interrupts : IRQ line information.
 - interrupt-controller
 
@@ -25,8 +35,8 @@ further information on IRQ bindings.
 
 Sub-nodes:
 
-- regulators : This node defines the settings for the LDOs and BUCKs. The
-  DA9062 regulators are bound using their names listed below:
+- regulators : This node defines the settings for the LDOs and BUCKs.
+  The DA9062 regulators are bound using their names listed below:
 
 buck1: BUCK_1
 buck2: BUCK_2
@@ -37,6 +47,16 @@ Sub-nodes:
 ldo3 : LDO_3
 ldo4 : LDO_4
 
+  The DA9061 regulators are bound using their names listed below:
+
+buck1: BUCK_1
+buck2: BUCK_2
+buck3: BUCK_3
+ldo1 : LDO_1
+ldo2 : LDO_2
+ldo3 : LDO_3
+ldo4 : LDO_4
+
   The component follows the standard regulator framework and the bindings
   details of individual regulator device can be found in:
   Documentation/devicetree/bindings/regulator/regulator.txt
@@ -46,9 +66,14 @@ Sub-nodes:
   with the DA9062. There are currently no entries in this binding, however
   compatible = "dlg,da9062-rtc" should be added if a node is created.
 
-- watchdog: This node defines the settings for the watchdog driver associated
-  with the DA9062 PMIC. The compatible = "dlg,da9062-watchdog" should be added
-  if a node is created.
+
+- onkey : See ../input/da9062-onkey.txt
+
+
+- watchdog: See ../watchdog/da9062-watchdog.txt
+
+
+- thermal : See ../thermal/da9062-thermal.txt
 
 
 Example:
@@ -64,10 +89,6 @@ Example:
compatible = "dlg,da9062-rtc";
};
 
-   watchdog {
-   compatible = "dlg,da9062-watchdog";
-   };
-
regulators {
DA9062_BUCK1: buck1 {
regulator-name = "BUCK1";
-- 
end-of-patch for PATCH V2

Re: [PATCH v2 4/5] ARC: MCIP: Set an initial affinity value in idu_irq_map

[Vineet Gupta]

On 10/26/2016 09:36 AM, Marc Zyngier wrote:
> On Wed, Oct 26 2016 at 05:17:34 PM, Vineet Gupta  
> wrote:
>> On 10/26/2016 07:05 AM, Marc Zyngier wrote:
>>> It definitely feels weird to encode the interrupt affinity in the DT
>>> (the kernel and possible userspace usually know much better than the
>>> firmware). What is the actual reason for storing the affinity there?
>>
>> The IDU intc supports various interrupt distribution modes (Round
>> Robin, send to one cpu only etc) whcih in turn map to affinity
>> setting. When doing the DT binding, we decided to add that this to DT
>> to get the "seed" value for affinity - which user could optionally
>> changed after boot. This seemed like a benign design choice at the
>> time.
> 
> Right. But is this initial setting something that the kernel has to
> absolutely honor? 

Not necessarily.

> The usual behavior is to let kernel pick something
> sensible, and let the user mess with it afterwards.

Right !


> Is there any part of the kernel that would otherwise depend on this
> affinity being set to a particular mode? If the answer is "none", then I
> believe we can safely ignore that part of the binding (and maybe
> deprecate it in the documentation).

Not really. It was relevant for initial bring up of IDU software and hardware.
e.g. checking that uart behind idu works fine in both modes for very first user
mode prints, which is before you could make the init script cmds to change the
affinity etc. But that bridge has long been crossed.

So agree that we will ignore the affinity settings from DT and deprecate the 
binding.

Thx for steering us in the right direction. Much appreciated.

-Vineet

Re: [Intel-wired-lan] [net-next PATCH 25/27] igb: Update driver to make use of DMA_ATTR_SKIP_CPU_SYNC

[Jeff Kirsher]

On Tue, 2016-10-25 at 11:39 -0400, Alexander Duyck wrote:
> The ARM architecture provides a mechanism for deferring cache line
> invalidation in the case of map/unmap.  This patch makes use of this
> mechanism to avoid unnecessary synchronization.
> 
> A secondary effect of this change is that the portion of the page that
> has
> been synchronized for use by the CPU should be writable and could be
> passed
> up the stack (at least on ARM).
> 
> The last bit that occurred to me is that on architectures where the
> sync_for_cpu call invalidates cache lines we were prefetching and then
> invalidating the first 128 bytes of the packet.  To avoid that I have
> moved
> the sync up to before we perform the prefetch and allocate the skbuff so
> that we can actually make use of it.
> 
> Signed-off-by: Alexander Duyck 
> 

Acked-by: Jeff Kirsher 

signature.asc
Description: This is a digitally signed message part

[PATCH V2 09/10] thermal: da9062/61: Thermal junction temperature monitoring driver

[Steve Twiss]

From: Steve Twiss 

Add junction temperature monitoring supervisor device driver, compatible
with the DA9062 and DA9061 PMICs.

If the PMIC's internal junction temperature rises above TEMP_WARN (125
degC) an interrupt is issued. This TEMP_WARN level is defined as the
THERMAL_TRIP_HOT trip-wire inside the device driver.

The thermal triggering mechanism is interrupt based and happens when the
temperature rises above a given threshold level. The component cannot
return an exact temperature, it only has knowledge if the temperature is
above or below a given threshold value. A status bit must be polled to
detect when the temperature falls below that threshold level again. A
kernel work queue is configured to repeatedly poll and detect when the
temperature falls below this trip-wire, between 1 and 10 second intervals
(defaulting at 3 seconds).

This first level of temperature supervision is intended for non-invasive
temperature control, where the necessary measures for cooling the system
down are left to the host software.

Signed-off-by: Steve Twiss 

---
This patch applies against linux-next and v4.8

v1 -> v2
 - Patch renamed from [PATCH V1 05/10] to [PATCH V2 09/10] -- these
   changes were made to fix checkpatch warnings caused by the patch
   set dependency order
 - List the header files in alphabetical order
 - Remove "GPL v2" and replace with MODULE_LICENSE("GPL") to match the
   copyright "GNU Public License v2 or later" option in the header
   comment for this file. See the allowed identifiers in the file
   include/linux/module.h +170
 - Remove notify function "da9062_thermal_notify" function.
 - MODULE_AUTHOR() macros removes Company Name and just gives Name in
   accordance with include/linux/module.h +200
 - Remove the compatible "dlg,da9061-thermal" option in the of_device_id
   struct table. This patch now assumes the use of a DA9062 fallback
   compatible string in the DTS when using the DA9061 thermal component
   of the DA9061 device.
 - Re-ordered some assignments earlier in the probe() for thermal->hw,
   thermal->polling_period, thermal->mode, thermal->dev
 - Added further information in the patch description to explain the use
   of the device driver's built-in work-queue.

Regards,
Steve Twiss, Dialog Semiconductor Ltd.


 drivers/thermal/Kconfig  |  10 ++
 drivers/thermal/Makefile |   1 +
 drivers/thermal/da9062-thermal.c | 289 +++
 3 files changed, 300 insertions(+)
 create mode 100644 drivers/thermal/da9062-thermal.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 2d702ca..da58e54 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -272,6 +272,16 @@ config DB8500_CPUFREQ_COOLING
  bound cpufreq cooling device turns active to set CPU frequency low to
  cool down the CPU.
 
+config DA9062_THERMAL
+   tristate "DA9062/DA9061 Dialog Semiconductor thermal driver"
+   depends on MFD_DA9062
+   depends on OF
+   help
+ Enable this for the Dialog Semiconductor thermal sensor driver.
+ This will report PMIC junction over-temperature for one thermal trip
+ zone.
+ Compatible with the DA9062 and DA9061 PMICs.
+
 config INTEL_POWERCLAMP
tristate "Intel PowerClamp idle injection driver"
depends on THERMAL
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 10b07c1..0a2b3f2 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_ARMADA_THERMAL)  += armada_thermal.o
 obj-$(CONFIG_TANGO_THERMAL)+= tango_thermal.o
 obj-$(CONFIG_IMX_THERMAL)  += imx_thermal.o
 obj-$(CONFIG_DB8500_CPUFREQ_COOLING)   += db8500_cpufreq_cooling.o
+obj-$(CONFIG_DA9062_THERMAL)   += da9062-thermal.o
 obj-$(CONFIG_INTEL_POWERCLAMP) += intel_powerclamp.o
 obj-$(CONFIG_X86_PKG_TEMP_THERMAL) += x86_pkg_temp_thermal.o
 obj-$(CONFIG_INTEL_SOC_DTS_IOSF_CORE)  += intel_soc_dts_iosf.o
diff --git a/drivers/thermal/da9062-thermal.c b/drivers/thermal/da9062-thermal.c
new file mode 100644
index 000..e0d2b1b
--- /dev/null
+++ b/drivers/thermal/da9062-thermal.c
@@ -0,0 +1,289 @@
+/*
+ * Thermal device driver for DA9062 and DA9061
+ * Copyright (C) 2016  Dialog Semiconductor Ltd.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; 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 
+#include 
+#include 
+
+#include 
+#include 
+
+#define 

[PATCH V2 09/10] thermal: da9062/61: Thermal junction temperature monitoring driver

[Steve Twiss]

From: Steve Twiss 

Add junction temperature monitoring supervisor device driver, compatible
with the DA9062 and DA9061 PMICs.

If the PMIC's internal junction temperature rises above TEMP_WARN (125
degC) an interrupt is issued. This TEMP_WARN level is defined as the
THERMAL_TRIP_HOT trip-wire inside the device driver.

The thermal triggering mechanism is interrupt based and happens when the
temperature rises above a given threshold level. The component cannot
return an exact temperature, it only has knowledge if the temperature is
above or below a given threshold value. A status bit must be polled to
detect when the temperature falls below that threshold level again. A
kernel work queue is configured to repeatedly poll and detect when the
temperature falls below this trip-wire, between 1 and 10 second intervals
(defaulting at 3 seconds).

This first level of temperature supervision is intended for non-invasive
temperature control, where the necessary measures for cooling the system
down are left to the host software.

Signed-off-by: Steve Twiss 

---
This patch applies against linux-next and v4.8

v1 -> v2
 - Patch renamed from [PATCH V1 05/10] to [PATCH V2 09/10] -- these
   changes were made to fix checkpatch warnings caused by the patch
   set dependency order
 - List the header files in alphabetical order
 - Remove "GPL v2" and replace with MODULE_LICENSE("GPL") to match the
   copyright "GNU Public License v2 or later" option in the header
   comment for this file. See the allowed identifiers in the file
   include/linux/module.h +170
 - Remove notify function "da9062_thermal_notify" function.
 - MODULE_AUTHOR() macros removes Company Name and just gives Name in
   accordance with include/linux/module.h +200
 - Remove the compatible "dlg,da9061-thermal" option in the of_device_id
   struct table. This patch now assumes the use of a DA9062 fallback
   compatible string in the DTS when using the DA9061 thermal component
   of the DA9061 device.
 - Re-ordered some assignments earlier in the probe() for thermal->hw,
   thermal->polling_period, thermal->mode, thermal->dev
 - Added further information in the patch description to explain the use
   of the device driver's built-in work-queue.

Regards,
Steve Twiss, Dialog Semiconductor Ltd.


 drivers/thermal/Kconfig  |  10 ++
 drivers/thermal/Makefile |   1 +
 drivers/thermal/da9062-thermal.c | 289 +++
 3 files changed, 300 insertions(+)
 create mode 100644 drivers/thermal/da9062-thermal.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 2d702ca..da58e54 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -272,6 +272,16 @@ config DB8500_CPUFREQ_COOLING
  bound cpufreq cooling device turns active to set CPU frequency low to
  cool down the CPU.
 
+config DA9062_THERMAL
+   tristate "DA9062/DA9061 Dialog Semiconductor thermal driver"
+   depends on MFD_DA9062
+   depends on OF
+   help
+ Enable this for the Dialog Semiconductor thermal sensor driver.
+ This will report PMIC junction over-temperature for one thermal trip
+ zone.
+ Compatible with the DA9062 and DA9061 PMICs.
+
 config INTEL_POWERCLAMP
tristate "Intel PowerClamp idle injection driver"
depends on THERMAL
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 10b07c1..0a2b3f2 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_ARMADA_THERMAL)  += armada_thermal.o
 obj-$(CONFIG_TANGO_THERMAL)+= tango_thermal.o
 obj-$(CONFIG_IMX_THERMAL)  += imx_thermal.o
 obj-$(CONFIG_DB8500_CPUFREQ_COOLING)   += db8500_cpufreq_cooling.o
+obj-$(CONFIG_DA9062_THERMAL)   += da9062-thermal.o
 obj-$(CONFIG_INTEL_POWERCLAMP) += intel_powerclamp.o
 obj-$(CONFIG_X86_PKG_TEMP_THERMAL) += x86_pkg_temp_thermal.o
 obj-$(CONFIG_INTEL_SOC_DTS_IOSF_CORE)  += intel_soc_dts_iosf.o
diff --git a/drivers/thermal/da9062-thermal.c b/drivers/thermal/da9062-thermal.c
new file mode 100644
index 000..e0d2b1b
--- /dev/null
+++ b/drivers/thermal/da9062-thermal.c
@@ -0,0 +1,289 @@
+/*
+ * Thermal device driver for DA9062 and DA9061
+ * Copyright (C) 2016  Dialog Semiconductor Ltd.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; 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 
+#include 
+#include 
+
+#include 
+#include 
+
+#define DA9062_DEFAULT_POLLING_MS_PERIOD   3000
+#define DA9062_MAX_POLLING_MS_PERIOD   

Re: [PATCH v2 4/5] ARC: MCIP: Set an initial affinity value in idu_irq_map

[Vineet Gupta]

On 10/26/2016 09:36 AM, Marc Zyngier wrote:
> On Wed, Oct 26 2016 at 05:17:34 PM, Vineet Gupta  
> wrote:
>> On 10/26/2016 07:05 AM, Marc Zyngier wrote:
>>> It definitely feels weird to encode the interrupt affinity in the DT
>>> (the kernel and possible userspace usually know much better than the
>>> firmware). What is the actual reason for storing the affinity there?
>>
>> The IDU intc supports various interrupt distribution modes (Round
>> Robin, send to one cpu only etc) whcih in turn map to affinity
>> setting. When doing the DT binding, we decided to add that this to DT
>> to get the "seed" value for affinity - which user could optionally
>> changed after boot. This seemed like a benign design choice at the
>> time.
> 
> Right. But is this initial setting something that the kernel has to
> absolutely honor? 

Not necessarily.

> The usual behavior is to let kernel pick something
> sensible, and let the user mess with it afterwards.

Right !


> Is there any part of the kernel that would otherwise depend on this
> affinity being set to a particular mode? If the answer is "none", then I
> believe we can safely ignore that part of the binding (and maybe
> deprecate it in the documentation).

Not really. It was relevant for initial bring up of IDU software and hardware.
e.g. checking that uart behind idu works fine in both modes for very first user
mode prints, which is before you could make the init script cmds to change the
affinity etc. But that bridge has long been crossed.

So agree that we will ignore the affinity settings from DT and deprecate the 
binding.

Thx for steering us in the right direction. Much appreciated.

-Vineet

Re: [Intel-wired-lan] [net-next PATCH 25/27] igb: Update driver to make use of DMA_ATTR_SKIP_CPU_SYNC

[Jeff Kirsher]

On Tue, 2016-10-25 at 11:39 -0400, Alexander Duyck wrote:
> The ARM architecture provides a mechanism for deferring cache line
> invalidation in the case of map/unmap.  This patch makes use of this
> mechanism to avoid unnecessary synchronization.
> 
> A secondary effect of this change is that the portion of the page that
> has
> been synchronized for use by the CPU should be writable and could be
> passed
> up the stack (at least on ARM).
> 
> The last bit that occurred to me is that on architectures where the
> sync_for_cpu call invalidates cache lines we were prefetching and then
> invalidating the first 128 bytes of the packet.  To avoid that I have
> moved
> the sync up to before we perform the prefetch and allocate the skbuff so
> that we can actually make use of it.
> 
> Signed-off-by: Alexander Duyck 
> 

Acked-by: Jeff Kirsher 

signature.asc
Description: This is a digitally signed message part

[PATCH V2 10/10] MAINTAINERS: da9062/61 updates to the Dialog Semiconductor search terms

[Steve Twiss]

From: Steve Twiss 

Hi,

Dialog Semiconductor support would like to add to the MAINTAINERS search
terms. This update will allow us to follow files for device tree bindings
and source code relating to input onkey drivers, chip thermal monitoring
and watchdog timers.

Signed-off-by: Steve Twiss 

---
This patch applies against linux-next and v4.8

v1 -> v2
 NO CHANGE

Hi,

This patch depends on acceptance of the following from this patch set:

- [PATCH V2 09/10] PMIC temperature monitoring

and also from the following binding file changes:

- [PATCH V2 01/10] Binding for onkey
- [PATCH V2 02/10] Binding for watchdog
- [PATCH V2 03/10] Binding for thermal

Regards,
Steve Twiss, Dialog Semiconductor Ltd.


 MAINTAINERS | 4 
 1 file changed, 4 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f593300..a7fd809 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3752,7 +3752,10 @@ W:   http://www.dialog-semiconductor.com/products
 S: Supported
 F: Documentation/hwmon/da90??
 F: Documentation/devicetree/bindings/mfd/da90*.txt
+F: Documentation/devicetree/bindings/input/da90??-onkey.txt
+F: Documentation/devicetree/bindings/thermal/da90??-thermal.txt
 F: Documentation/devicetree/bindings/regulator/da92*.txt
+F: Documentation/devicetree/bindings/watchdog/da92??-wdt.txt
 F: Documentation/devicetree/bindings/sound/da[79]*.txt
 F: drivers/gpio/gpio-da90??.c
 F: drivers/hwmon/da90??-hwmon.c
@@ -3767,6 +3770,7 @@ F:drivers/power/da9052-battery.c
 F: drivers/power/da91??-*.c
 F: drivers/regulator/da903x.c
 F: drivers/regulator/da9???-regulator.[ch]
+F: drivers/thermal/da90??-thermal.c
 F: drivers/rtc/rtc-da90??.c
 F: drivers/video/backlight/da90??_bl.c
 F: drivers/watchdog/da90??_wdt.c
-- 
end-of-patch for PATCH V2

[PATCH V2 10/10] MAINTAINERS: da9062/61 updates to the Dialog Semiconductor search terms

[Steve Twiss]

From: Steve Twiss 

Hi,

Dialog Semiconductor support would like to add to the MAINTAINERS search
terms. This update will allow us to follow files for device tree bindings
and source code relating to input onkey drivers, chip thermal monitoring
and watchdog timers.

Signed-off-by: Steve Twiss 

---
This patch applies against linux-next and v4.8

v1 -> v2
 NO CHANGE

Hi,

This patch depends on acceptance of the following from this patch set:

- [PATCH V2 09/10] PMIC temperature monitoring

and also from the following binding file changes:

- [PATCH V2 01/10] Binding for onkey
- [PATCH V2 02/10] Binding for watchdog
- [PATCH V2 03/10] Binding for thermal

Regards,
Steve Twiss, Dialog Semiconductor Ltd.


 MAINTAINERS | 4 
 1 file changed, 4 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f593300..a7fd809 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3752,7 +3752,10 @@ W:   http://www.dialog-semiconductor.com/products
 S: Supported
 F: Documentation/hwmon/da90??
 F: Documentation/devicetree/bindings/mfd/da90*.txt
+F: Documentation/devicetree/bindings/input/da90??-onkey.txt
+F: Documentation/devicetree/bindings/thermal/da90??-thermal.txt
 F: Documentation/devicetree/bindings/regulator/da92*.txt
+F: Documentation/devicetree/bindings/watchdog/da92??-wdt.txt
 F: Documentation/devicetree/bindings/sound/da[79]*.txt
 F: drivers/gpio/gpio-da90??.c
 F: drivers/hwmon/da90??-hwmon.c
@@ -3767,6 +3770,7 @@ F:drivers/power/da9052-battery.c
 F: drivers/power/da91??-*.c
 F: drivers/regulator/da903x.c
 F: drivers/regulator/da9???-regulator.[ch]
+F: drivers/thermal/da90??-thermal.c
 F: drivers/rtc/rtc-da90??.c
 F: drivers/video/backlight/da90??_bl.c
 F: drivers/watchdog/da90??_wdt.c
-- 
end-of-patch for PATCH V2

Re: [Intel-wired-lan] [net-next PATCH 26/27] igb: Update code to better handle incrementing page count

[Jeff Kirsher]

On Tue, 2016-10-25 at 11:39 -0400, Alexander Duyck wrote:
> This patch updates the driver code so that we do bulk updates of the page
> reference count instead of just incrementing it by one reference at a
> time.
> The advantage to doing this is that we cut down on atomic operations and
> this in turn should give us a slight improvement in cycles per packet. 
> In
> addition if we eventually move this over to using build_skb the gains
> will
> be more noticeable.
> 
> Signed-off-by: Alexander Duyck 

Acked-by: Jeff Kirsher 

signature.asc
Description: This is a digitally signed message part

Re: [Intel-wired-lan] [net-next PATCH 26/27] igb: Update code to better handle incrementing page count

[Jeff Kirsher]

On Tue, 2016-10-25 at 11:39 -0400, Alexander Duyck wrote:
> This patch updates the driver code so that we do bulk updates of the page
> reference count instead of just incrementing it by one reference at a
> time.
> The advantage to doing this is that we cut down on atomic operations and
> this in turn should give us a slight improvement in cycles per packet. 
> In
> addition if we eventually move this over to using build_skb the gains
> will
> be more noticeable.
> 
> Signed-off-by: Alexander Duyck 

Acked-by: Jeff Kirsher 

signature.asc
Description: This is a digitally signed message part

[PATCH V2 02/10] Documentation: devicetree: watchdog: da9062/61 watchdog timer binding

[Steve Twiss]

From: Steve Twiss 

Add binding information for DA9062 and DA9061 watchdog.

Example bindings for both devices are added.

The original binding for DA9062 (only) used to reside inside the
Documentation/devicetree/bindings/mfd/da9062.txt MFD document.
The da9062-watchdog section was deleted in that file and replaced
with a link to the new DA9061/62 binding information stored in this
patch.

Signed-off-by: Steve Twiss 

---
This patch applies against linux-next and v4.8

v1 -> v2
 - Patch renamed from [PATCH V1 07/10] to [PATCH V2 02/10] -- these
   changes were made to fix checkpatch warnings caused by the patch
   set dependency order
 - Updated the patch description to be explicit about where parts of
   this binding had originally been stored
 - A second example for DA9061 is provided to highlight the use of a
   fall-back compatible option for the DA9062 watchdog driver

Hi,

This patch depends on the acceptance of DA9061 watchdog driver:
  [PATCH V2 08/10] watchdog: da9061: watchdog driver

This previous [PATCH V1 07/10] was acked-by: Rob Herring, however changes
in the Linux device driver have meant an additional binding example is
necessary to describe the use of DA9061.

The Linux device driver changes for DA9061 were rejected after
conversations with the watchdog maintainers, specifically about
compatibility between DA9061 and DA9062 watchdog hardware components. In
the case of the watchdog the DA9062 device driver is compatible with the
DA9061 and for this reason there is minimal change required to the DA9062
watchdog device driver and so the example for the DA9061 watchdog shows
the use of a fall-back compatible string.
 
Regards,
Steve Twiss, Dialog Semiconductor Ltd.


 .../devicetree/bindings/watchdog/da9062-wdt.txt | 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/watchdog/da9062-wdt.txt

diff --git a/Documentation/devicetree/bindings/watchdog/da9062-wdt.txt 
b/Documentation/devicetree/bindings/watchdog/da9062-wdt.txt
new file mode 100644
index 000..1f8255c
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/da9062-wdt.txt
@@ -0,0 +1,21 @@
+* Dialog Semiconductor DA9062/61 Watchdog Timer
+
+Required properties:
+- compatible: "dlg,da9062-watchdog"
+  "dlg,da9061-watchdog"
+
+Example: DA9062
+
+   pmic0: da9062@58 {
+   watchdog {
+   compatible = "dlg,da9062-watchdog";
+   };
+   };
+
+Example: DA9061 using a fall-back compatible for the DA9062 watchdog driver
+
+   pmic0: da9061@58 {
+   watchdog {
+   compatible = "dlg,da9061-watchdog", 
"dlg,da9062-watchdog";
+   };
+   };
-- 
end-of-patch for PATCH V2

[PATCH V2 02/10] Documentation: devicetree: watchdog: da9062/61 watchdog timer binding

[Steve Twiss]

From: Steve Twiss 

Add binding information for DA9062 and DA9061 watchdog.

Example bindings for both devices are added.

The original binding for DA9062 (only) used to reside inside the
Documentation/devicetree/bindings/mfd/da9062.txt MFD document.
The da9062-watchdog section was deleted in that file and replaced
with a link to the new DA9061/62 binding information stored in this
patch.

Signed-off-by: Steve Twiss 

---
This patch applies against linux-next and v4.8

v1 -> v2
 - Patch renamed from [PATCH V1 07/10] to [PATCH V2 02/10] -- these
   changes were made to fix checkpatch warnings caused by the patch
   set dependency order
 - Updated the patch description to be explicit about where parts of
   this binding had originally been stored
 - A second example for DA9061 is provided to highlight the use of a
   fall-back compatible option for the DA9062 watchdog driver

Hi,

This patch depends on the acceptance of DA9061 watchdog driver:
  [PATCH V2 08/10] watchdog: da9061: watchdog driver

This previous [PATCH V1 07/10] was acked-by: Rob Herring, however changes
in the Linux device driver have meant an additional binding example is
necessary to describe the use of DA9061.

The Linux device driver changes for DA9061 were rejected after
conversations with the watchdog maintainers, specifically about
compatibility between DA9061 and DA9062 watchdog hardware components. In
the case of the watchdog the DA9062 device driver is compatible with the
DA9061 and for this reason there is minimal change required to the DA9062
watchdog device driver and so the example for the DA9061 watchdog shows
the use of a fall-back compatible string.
 
Regards,
Steve Twiss, Dialog Semiconductor Ltd.


 .../devicetree/bindings/watchdog/da9062-wdt.txt | 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/watchdog/da9062-wdt.txt

diff --git a/Documentation/devicetree/bindings/watchdog/da9062-wdt.txt 
b/Documentation/devicetree/bindings/watchdog/da9062-wdt.txt
new file mode 100644
index 000..1f8255c
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/da9062-wdt.txt
@@ -0,0 +1,21 @@
+* Dialog Semiconductor DA9062/61 Watchdog Timer
+
+Required properties:
+- compatible: "dlg,da9062-watchdog"
+  "dlg,da9061-watchdog"
+
+Example: DA9062
+
+   pmic0: da9062@58 {
+   watchdog {
+   compatible = "dlg,da9062-watchdog";
+   };
+   };
+
+Example: DA9061 using a fall-back compatible for the DA9062 watchdog driver
+
+   pmic0: da9061@58 {
+   watchdog {
+   compatible = "dlg,da9061-watchdog", 
"dlg,da9062-watchdog";
+   };
+   };
-- 
end-of-patch for PATCH V2

Re: complete_all and "forever" completions

[Dmitry Torokhov]

On Wed, Oct 26, 2016 at 05:12:36PM +, Nicholas Mc Guire wrote:
> On Wed, Oct 26, 2016 at 05:42:13PM +0200, Peter Zijlstra wrote:
> > On Wed, Oct 26, 2016 at 05:10:01AM -0700, Dmitry Torokhov wrote:
> > > On Wed, Oct 26, 2016 at 10:45:35AM +0200, Peter Zijlstra wrote:
> > > > On Tue, Oct 25, 2016 at 03:30:54PM -0700, Dmitry Torokhov wrote:
> > 
> > > > > Or do we need something like this in
> > > > > do_wait_for_common():
> > > > > 
> > > > >   if (x->done < UINT_MAX/2)
> > > > >   x->done--;
> > > > 
> > > > Depends a bit, do you really want this? Seems a bit daft to keep asking
> > > > if its done already, seems like a waste of cycles to me.
> > > > 
> > > 
> > > The use case I am after is:
> > > 
> > > 1. There is a device that is extremely dumb without firmware
> > > 2. The driver uses request_firmware_nowait() and signals completion from
> > > the firmware loading callback to let the reset of the driver know that
> > > firmware has been done loading (successfully or otherwise)
> > > 3. The driver uses wait_for_completion() in both remove() and suspend()
> > > methods to wait for the firmware to finish loading.
> > > 
> > > While remove() happens at most once per device instance, suspend() may
> > > happen unbound number of times (theoretically).
> > > 
> > > So the question is: should complete_all have this "forever" semantic
> > > (IOW is documentation right about the intent) or do we need a new
> > > primitive for this? From the cursory glance of users of complete_all()
> > > all of them expect completion to stay in signalled state either forever,
> > > or until they call reinit_completion() explicitly.
> > 
> > Nah, if we need this we should fix this one. Adding similar but slightly
> > different primitives is a pain.
> > 
> > But I think you might need slightly more than the proposed change, the
> > case I worry about is doing complete_all() when done != 0 (which isn't
> > all that strange).
> 
> I do not quite see how that would work out for the Use-Case noted
> if completion calls complete_all() once at the first firmware load
> and at that point that completion object is "completed" forever then
> the suspend() would not wait for any completion in this model.

That is correct. In the use case above the firmware is loaded only once
upon binding device and driver and is not reloaded unless device is
completely unbound and then re-bound again. So we do not want suspend()
to wait after the firmware is loaded.

Note that I said we are using request_firmware_nowait() so that firmware
loading is done by the thread other than probe() thread and probe()
returns before firmware is loaded. Which means that suspend() (however
unlikely it is) may start executing before firmware loading completes,
and we want suspend to pause in this case. Once firmware is loaded
suspend should no longer wait.

> 
> Im probably simply misunderstanding something here - but a 
> complete_all() seems to have been intended for a logically single
> case of concurrent initialization but not for this use-case
> I do think that this is a broken design - if the suspend()/resume()
> needed to reload the firware then it also would need to wait for
> the same and that would not occure without reinitializing the
> completion object.
> 
> what am I missing ?

The fact that we only load firmware once in the case I described.

Thanks.

-- 
Dmitry

Re: complete_all and "forever" completions

[Dmitry Torokhov]

On Wed, Oct 26, 2016 at 05:12:36PM +, Nicholas Mc Guire wrote:
> On Wed, Oct 26, 2016 at 05:42:13PM +0200, Peter Zijlstra wrote:
> > On Wed, Oct 26, 2016 at 05:10:01AM -0700, Dmitry Torokhov wrote:
> > > On Wed, Oct 26, 2016 at 10:45:35AM +0200, Peter Zijlstra wrote:
> > > > On Tue, Oct 25, 2016 at 03:30:54PM -0700, Dmitry Torokhov wrote:
> > 
> > > > > Or do we need something like this in
> > > > > do_wait_for_common():
> > > > > 
> > > > >   if (x->done < UINT_MAX/2)
> > > > >   x->done--;
> > > > 
> > > > Depends a bit, do you really want this? Seems a bit daft to keep asking
> > > > if its done already, seems like a waste of cycles to me.
> > > > 
> > > 
> > > The use case I am after is:
> > > 
> > > 1. There is a device that is extremely dumb without firmware
> > > 2. The driver uses request_firmware_nowait() and signals completion from
> > > the firmware loading callback to let the reset of the driver know that
> > > firmware has been done loading (successfully or otherwise)
> > > 3. The driver uses wait_for_completion() in both remove() and suspend()
> > > methods to wait for the firmware to finish loading.
> > > 
> > > While remove() happens at most once per device instance, suspend() may
> > > happen unbound number of times (theoretically).
> > > 
> > > So the question is: should complete_all have this "forever" semantic
> > > (IOW is documentation right about the intent) or do we need a new
> > > primitive for this? From the cursory glance of users of complete_all()
> > > all of them expect completion to stay in signalled state either forever,
> > > or until they call reinit_completion() explicitly.
> > 
> > Nah, if we need this we should fix this one. Adding similar but slightly
> > different primitives is a pain.
> > 
> > But I think you might need slightly more than the proposed change, the
> > case I worry about is doing complete_all() when done != 0 (which isn't
> > all that strange).
> 
> I do not quite see how that would work out for the Use-Case noted
> if completion calls complete_all() once at the first firmware load
> and at that point that completion object is "completed" forever then
> the suspend() would not wait for any completion in this model.

That is correct. In the use case above the firmware is loaded only once
upon binding device and driver and is not reloaded unless device is
completely unbound and then re-bound again. So we do not want suspend()
to wait after the firmware is loaded.

Note that I said we are using request_firmware_nowait() so that firmware
loading is done by the thread other than probe() thread and probe()
returns before firmware is loaded. Which means that suspend() (however
unlikely it is) may start executing before firmware loading completes,
and we want suspend to pause in this case. Once firmware is loaded
suspend should no longer wait.

> 
> Im probably simply misunderstanding something here - but a 
> complete_all() seems to have been intended for a logically single
> case of concurrent initialization but not for this use-case
> I do think that this is a broken design - if the suspend()/resume()
> needed to reload the firware then it also would need to wait for
> the same and that would not occure without reinitializing the
> completion object.
> 
> what am I missing ?

The fact that we only load firmware once in the case I described.

Thanks.

-- 
Dmitry

[PATCH V2 01/10] Documentation: devicetree: input: additions for da9061 onkey driver

[Steve Twiss]

From: Steve Twiss 

Add binding information for DA9061 onkey.

This patch updates the compatible string "dlg,da9061-onkey" to support
DA9061, removes the reference to KEY_SLEEP (which the driver no longer
supports) and fixes a typo in the example for DA9063.

It also adds two new examples, one for DA9062 and one for DA9061. The
DA9061 examples uses a fall-back compatible string for the DA9062 onkey
driver.

Signed-off-by: Steve Twiss 

---
This patch applies against linux-next and v4.8

v1 -> v2
 - Patch renamed from [PATCH V1 06/10] to [PATCH V2 01/10] -- these
   changes were made to fix checkpatch warnings caused by the patch
   set dependency order
 - Typo s/ther/the/ in commit message
 - Explanation about why KEY_SLEEP was removed (see below)
 - Addition of DA9062 example
 - Addition of a DA9061 example to follow the driver fall-back compatible
   convention being applied for this device driver

Hi,

This patch depends on the acceptance of the main code for the onkey:
  [PATCH V2 07/10] Input: da9061: onkey driver.

The device driver no longer supports KEY_SLEEP. It only supports
KEY_POWER. This change was sent a while ago for the DA9063 ONKEY driver,
but the docs were not updated.

Supporting KEY_SLEEP was not the general convention and the typical
solution should have been for KEY_POWER to support both cases of suspend
and S/W power off.

There is also new binding examples for DA9062 and DA9061. Importantly,
the Linux device driver changes for DA9061 were rejected because the
DA9062 device driver can be reused. For this reason, the DA9061 example
uses a fall-back compatible string.

Regards,
Steve Twiss, Dialog Semiconductor Ltd.


 .../devicetree/bindings/input/da9062-onkey.txt | 39 +++---
 1 file changed, 27 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/da9062-onkey.txt 
b/Documentation/devicetree/bindings/input/da9062-onkey.txt
index ab0e048..e5a0469 100644
--- a/Documentation/devicetree/bindings/input/da9062-onkey.txt
+++ b/Documentation/devicetree/bindings/input/da9062-onkey.txt
@@ -1,32 +1,47 @@
-* Dialog DA9062/63 OnKey Module
+* Dialog DA9061/62/63 OnKey Module
 
-This module is part of the DA9062/DA9063. For more details about entire
-chips see Documentation/devicetree/bindings/mfd/da9062.txt and
-Documentation/devicetree/bindings/mfd/da9063.txt
+This module is part of the DA9061/DA9062/DA9063. For more details about entire
+DA9062 and DA9061 chips see Documentation/devicetree/bindings/mfd/da9062.txt
+For DA9063 see Documentation/devicetree/bindings/mfd/da9063.txt
 
-This module provides KEY_POWER, KEY_SLEEP and events.
+This module provides the KEY_POWER event.
 
 Required properties:
 
 - compatible: should be one of:
+   dlg,da9061-onkey
dlg,da9062-onkey
dlg,da9063-onkey
 
 Optional properties:
 
-  - dlg,disable-key-power : Disable power-down using a long key-press. If this
+- dlg,disable-key-power : Disable power-down using a long key-press. If this
 entry exists the OnKey driver will remove support for the KEY_POWER key
-press. If this entry does not exist then by default the key-press
-triggered power down is enabled and the OnKey will support both KEY_POWER
-and KEY_SLEEP.
+press when triggered using a long press of the OnKey.
 
-Example:
-
-   pmic0: da9062@58 {
+Example: DA9063
 
+   pmic0: da9063@58 {
onkey {
compatible = "dlg,da9063-onkey";
dlg,disable-key-power;
};
+   };
+
+Example: DA9062
+
+   pmic0: da9062@58 {
+   onkey {
+   compatible = "dlg,da9062-onkey";
+   dlg,disable-key-power;
+   };
+   };
+
+Example: DA9061 using a fall-back compatible for the DA9062 onkey driver
 
+   pmic0: da9061@58 {
+   onkey {
+   compatible = "dlg,da9061-onkey", "dlg,da9062-onkey";
+   dlg,disable-key-power;
+   };
};
-- 
end-of-patch for PATCH V2

[PATCH V2 06/10] regulator: da9061: BUCK and LDO regulator driver

[Steve Twiss]

From: Steve Twiss 

Regulator support for the DA9061 is added into the DA9062 regulator driver.
 
The regulators for DA9061 differ from those of DA9062.
A new DA9061 enumeration list for the LDOs and Bucks supported by this
device is added. Regulator information added: the old regulator
information for DA9062 is renamed from local_regulator_info[] to
local_da9062_regulator_info[] and a new array is added to support
local_da9061_regulator_info[].

The probe() function switches on the da9062_compatible_types enumeration
and configures the correct da9062_regulator_info array and number of
regulator entries.

Kconfig is updated to reflect support for DA9061 and DA9062 regulators.

Signed-off-by: Steve Twiss 

---
This patch applies against linux-next and v4.8

v1 -> v2
 - Patch renamed from [PATCH V1 02/10] to [PATCH V2 06/10] -- these
   changes were made to fix checkpatch warnings caused by the patch
   set dependency order
 - Updated header to use DA9061 and DA9062

Mark,

These changes depend on a header file provided as part of an earlier
patch [PATCH V2 05/10] from this set. The regulator probe() switches on
the chip_type which uses enum da9062_compatible_types in core.h from this
patch.

Regards,
Steve Twiss, Dialog Semiconductor Ltd.


 drivers/regulator/Kconfig|   4 +-
 drivers/regulator/da9062-regulator.c | 301 +--
 2 files changed, 292 insertions(+), 13 deletions(-)

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 6c88e31..c4f678fe 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -188,11 +188,11 @@ config REGULATOR_DA9055
  will be called da9055-regulator.
 
 config REGULATOR_DA9062
-   tristate "Dialog Semiconductor DA9062 regulators"
+   tristate "Dialog Semiconductor DA9061/62 regulators"
depends on MFD_DA9062
help
  Say y here to support the BUCKs and LDOs regulators found on
- DA9062 PMICs.
+ DA9061 and DA9062 PMICs.
 
  This driver can also be built as a module. If so, the module
  will be called da9062-regulator.
diff --git a/drivers/regulator/da9062-regulator.c 
b/drivers/regulator/da9062-regulator.c
index 0638c8b..931be68 100644
--- a/drivers/regulator/da9062-regulator.c
+++ b/drivers/regulator/da9062-regulator.c
@@ -1,5 +1,5 @@
 /*
- * da9062-regulator.c - REGULATOR device driver for DA9062
+ * Regulator device driver for DA9061 and DA9062.
  * Copyright (C) 2015  Dialog Semiconductor Ltd.
  *
  * This program is free software; you can redistribute it and/or
@@ -28,6 +28,17 @@
 
 /* Regulator IDs */
 enum {
+   DA9061_ID_BUCK1,
+   DA9061_ID_BUCK2,
+   DA9061_ID_BUCK3,
+   DA9061_ID_LDO1,
+   DA9061_ID_LDO2,
+   DA9061_ID_LDO3,
+   DA9061_ID_LDO4,
+   DA9061_MAX_REGULATORS,
+};
+
+enum {
DA9062_ID_BUCK1,
DA9062_ID_BUCK2,
DA9062_ID_BUCK3,
@@ -88,15 +99,21 @@ enum {
 
 /* Regulator operations */
 
-/* Current limits array (in uA) BUCK1 and BUCK3.
-   Entry indexes corresponds to register values. */
+/* Current limits array (in uA)
+ * - DA9061_ID_[BUCK1|BUCK3]
+ * - DA9062_ID_[BUCK1|BUCK2|BUCK4]
+ * Entry indexes corresponds to register values.
+ */
 static const int da9062_buck_a_limits[] = {
 50,  60,  70,  80,  90, 100, 110, 120,
130, 140, 150, 160, 170, 180, 190, 200
 };
 
-/* Current limits array (in uA) for BUCK2.
-   Entry indexes corresponds to register values. */
+/* Current limits array (in uA)
+ * - DA9061_ID_BUCK2
+ * - DA9062_ID_BUCK3
+ * Entry indexes corresponds to register values.
+ */
 static const int da9062_buck_b_limits[] = {
150, 160, 170, 180, 190, 200, 210, 220,
230, 240, 250, 260, 270, 280, 290, 300
@@ -405,8 +422,254 @@ static const struct regulator_ops da9062_ldo_ops = {
.set_suspend_mode   = da9062_ldo_set_suspend_mode,
 };
 
-/* Regulator information */
-static const struct da9062_regulator_info local_regulator_info[] = {
+/* DA9061 Regulator information */
+static const struct da9062_regulator_info local_da9061_regulator_info[] = {
+   {
+   .desc.id = DA9061_ID_BUCK1,
+   .desc.name = "DA9061 BUCK1",
+   .desc.of_match = of_match_ptr("buck1"),
+   .desc.regulators_node = of_match_ptr("regulators"),
+   .desc.ops = _buck_ops,
+   .desc.min_uV = (300) * 1000,
+   .desc.uV_step = (10) * 1000,
+   .desc.n_voltages = ((1570) - (300))/(10) + 1,
+   .current_limits = da9062_buck_a_limits,
+   .n_current_limits = ARRAY_SIZE(da9062_buck_a_limits),
+   .desc.enable_reg = DA9062AA_BUCK1_CONT,
+   .desc.enable_mask = DA9062AA_BUCK1_EN_MASK,
+   .desc.vsel_reg = 

[PATCH V2 07/10] Input: da9061: onkey driver

[Steve Twiss]

From: Steve Twiss 

Copyright header is updated to add DA9061 in its description and the module
description macro is extended to include DA9061.

Minor change to the code, alters dev_dbg() statements to report a generic
"PMIC" instead of DA9063. This device driver is compatible with DA9061,
DA9062 and DA9063.

Kconfig is updated to reflect support for DA9061/62/63.

Signed-off-by: Steve Twiss 

---
This patch applies against linux-next and v4.8

v1 -> v2
 - Patch renamed from [PATCH V1 03/10] to [PATCH V2 07/10] -- these
   changes were made to fix checkpatch warnings caused by the patch
   set dependency order
 - Revert changes for DA9061 specific compatible changes.

Dmitry,

Alterations made in accordance with previous e-mail thread on the use of
compatible strings: https://lkml.org/lkml/2016/10/7/641
Now assuming the use of a fallback compatible string in the DT.
compatible = "dlg,da9061-onkey", "dlg,da9062-onkey";

Regards,
Steve Twiss, Dialog Semiconductor Ltd.


 drivers/input/misc/Kconfig| 7 ---
 drivers/input/misc/da9063_onkey.c | 8 
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index efb0ca8..57cc9c2 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -613,11 +613,12 @@ config INPUT_DA9055_ONKEY
  will be called da9055_onkey.
 
 config INPUT_DA9063_ONKEY
-   tristate "Dialog DA9062/63 OnKey"
+   tristate "Dialog DA9063/62/61 OnKey"
depends on MFD_DA9063 || MFD_DA9062
help
- Support the ONKEY of Dialog DA9063 and DA9062 Power Management ICs
- as an input device capable of reporting the power button status.
+ Support the ONKEY of Dialog DA9063, DA9062 and DA9061 Power
+ Management ICs as an input device capable of reporting the
+ power button status.
 
  To compile this driver as a module, choose M here: the module
  will be called da9063_onkey.
diff --git a/drivers/input/misc/da9063_onkey.c 
b/drivers/input/misc/da9063_onkey.c
index bb863e0..dff6fe5 100644
--- a/drivers/input/misc/da9063_onkey.c
+++ b/drivers/input/misc/da9063_onkey.c
@@ -1,5 +1,5 @@
 /*
- * OnKey device driver for DA9063 and DA9062 PMICs
+ * OnKey device driver for DA9063, DA9062 and DA9061 PMICs
  * Copyright (C) 2015  Dialog Semiconductor Ltd.
  *
  * This program is free software; you can redistribute it and/or
@@ -149,13 +149,13 @@ static void da9063_poll_on(struct work_struct *work)
 * and then send shutdown command
 */
dev_dbg(>input->dev,
-   "Sending SHUTDOWN to DA9063 ...\n");
+   "Sending SHUTDOWN to PMIC ...\n");
error = regmap_write(onkey->regmap,
 config->onkey_shutdown,
 config->onkey_shutdown_mask);
if (error)
dev_err(>input->dev,
-   "Cannot SHUTDOWN DA9063: %d\n",
+   "Cannot SHUTDOWN PMIC: %d\n",
error);
}
}
@@ -300,6 +300,6 @@ static struct platform_driver da9063_onkey_driver = {
 module_platform_driver(da9063_onkey_driver);
 
 MODULE_AUTHOR("S Twiss ");
-MODULE_DESCRIPTION("Onkey device driver for Dialog DA9063 and DA9062");
+MODULE_DESCRIPTION("Onkey device driver for Dialog DA9063, DA9062 and DA9061");
 MODULE_LICENSE("GPL");
 MODULE_ALIAS("platform:" DA9063_DRVNAME_ONKEY);
-- 
end-of-patch for PATCH V2

[PATCH V2 00/10] da9061: DA9061 driver submission

[Steve Twiss]

From: Steve Twiss 

This patch set adds support for the Dialog DA9061 Power Management IC.
Support is made by altering the existing DA9062 device driver, where
appropriate.

In this patch set the following is provided:

[PATCH V2 01/10] Binding for onkey
[PATCH V2 02/10] Binding for watchdog
[PATCH V2 03/10] Binding for thermal supervisor
[PATCH V2 04/10] Binding for MFD and regulators
[PATCH V2 05/10] MFD core support
[PATCH V2 06/10] BUCKs and LDOs
[PATCH V2 07/10] Onkey 
[PATCH V2 08/10] Watchdog
[PATCH V2 09/10] PMIC temperature monitoring
[PATCH V2 10/10] MAINTAINERS update

This patch applies against linux-next and v4.8 

Thank you,
Steve Twiss, Dialog Semiconductor Ltd.

Steve Twiss (10):
  Documentation: devicetree: input: additions for da9061 onkey driver
  Documentation: devicetree: watchdog: da9062/61 watchdog timer binding
  Documentation: devicetree: thermal: da9062/61 TJUNC temperature
binding
  Documentation: devicetree: mfd: da9062/61 MFD binding
  mfd: da9061: MFD core support
  regulator: da9061: BUCK and LDO regulator driver
  Input: da9061: onkey driver
  watchdog: da9062/61: watchdog driver
  thermal: da9062/61: Thermal junction temperature monitoring driver
  MAINTAINERS: da9062/61 updates to the Dialog Semiconductor search
terms

 .../devicetree/bindings/input/da9062-onkey.txt |  39 +-
 Documentation/devicetree/bindings/mfd/da9062.txt   |  45 ++-
 .../devicetree/bindings/thermal/da9062-thermal.txt |  37 ++
 .../devicetree/bindings/watchdog/da9062-wdt.txt|  21 +
 MAINTAINERS|   4 +
 drivers/input/misc/Kconfig |   7 +-
 drivers/input/misc/da9063_onkey.c  |   8 +-
 drivers/mfd/Kconfig|   5 +-
 drivers/mfd/da9062-core.c  | 427 -
 drivers/regulator/Kconfig  |   4 +-
 drivers/regulator/da9062-regulator.c   | 301 ++-
 drivers/thermal/Kconfig|  10 +
 drivers/thermal/Makefile   |   1 +
 drivers/thermal/da9062-thermal.c   | 289 ++
 drivers/watchdog/Kconfig   |   4 +-
 drivers/watchdog/da9062_wdt.c  |  18 +-
 include/linux/mfd/da9062/core.h|  27 +-
 include/linux/mfd/da9062/registers.h   |   2 +
 18 files changed, 1180 insertions(+), 69 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/thermal/da9062-thermal.txt
 create mode 100644 Documentation/devicetree/bindings/watchdog/da9062-wdt.txt
 create mode 100644 drivers/thermal/da9062-thermal.c

-- 
end-of-patch for PATCH V2

[PATCH V2 01/10] Documentation: devicetree: input: additions for da9061 onkey driver

[Steve Twiss]

From: Steve Twiss 

Add binding information for DA9061 onkey.

This patch updates the compatible string "dlg,da9061-onkey" to support
DA9061, removes the reference to KEY_SLEEP (which the driver no longer
supports) and fixes a typo in the example for DA9063.

It also adds two new examples, one for DA9062 and one for DA9061. The
DA9061 examples uses a fall-back compatible string for the DA9062 onkey
driver.

Signed-off-by: Steve Twiss 

---
This patch applies against linux-next and v4.8

v1 -> v2
 - Patch renamed from [PATCH V1 06/10] to [PATCH V2 01/10] -- these
   changes were made to fix checkpatch warnings caused by the patch
   set dependency order
 - Typo s/ther/the/ in commit message
 - Explanation about why KEY_SLEEP was removed (see below)
 - Addition of DA9062 example
 - Addition of a DA9061 example to follow the driver fall-back compatible
   convention being applied for this device driver

Hi,

This patch depends on the acceptance of the main code for the onkey:
  [PATCH V2 07/10] Input: da9061: onkey driver.

The device driver no longer supports KEY_SLEEP. It only supports
KEY_POWER. This change was sent a while ago for the DA9063 ONKEY driver,
but the docs were not updated.

Supporting KEY_SLEEP was not the general convention and the typical
solution should have been for KEY_POWER to support both cases of suspend
and S/W power off.

There is also new binding examples for DA9062 and DA9061. Importantly,
the Linux device driver changes for DA9061 were rejected because the
DA9062 device driver can be reused. For this reason, the DA9061 example
uses a fall-back compatible string.

Regards,
Steve Twiss, Dialog Semiconductor Ltd.


 .../devicetree/bindings/input/da9062-onkey.txt | 39 +++---
 1 file changed, 27 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/da9062-onkey.txt 
b/Documentation/devicetree/bindings/input/da9062-onkey.txt
index ab0e048..e5a0469 100644
--- a/Documentation/devicetree/bindings/input/da9062-onkey.txt
+++ b/Documentation/devicetree/bindings/input/da9062-onkey.txt
@@ -1,32 +1,47 @@
-* Dialog DA9062/63 OnKey Module
+* Dialog DA9061/62/63 OnKey Module
 
-This module is part of the DA9062/DA9063. For more details about entire
-chips see Documentation/devicetree/bindings/mfd/da9062.txt and
-Documentation/devicetree/bindings/mfd/da9063.txt
+This module is part of the DA9061/DA9062/DA9063. For more details about entire
+DA9062 and DA9061 chips see Documentation/devicetree/bindings/mfd/da9062.txt
+For DA9063 see Documentation/devicetree/bindings/mfd/da9063.txt
 
-This module provides KEY_POWER, KEY_SLEEP and events.
+This module provides the KEY_POWER event.
 
 Required properties:
 
 - compatible: should be one of:
+   dlg,da9061-onkey
dlg,da9062-onkey
dlg,da9063-onkey
 
 Optional properties:
 
-  - dlg,disable-key-power : Disable power-down using a long key-press. If this
+- dlg,disable-key-power : Disable power-down using a long key-press. If this
 entry exists the OnKey driver will remove support for the KEY_POWER key
-press. If this entry does not exist then by default the key-press
-triggered power down is enabled and the OnKey will support both KEY_POWER
-and KEY_SLEEP.
+press when triggered using a long press of the OnKey.
 
-Example:
-
-   pmic0: da9062@58 {
+Example: DA9063
 
+   pmic0: da9063@58 {
onkey {
compatible = "dlg,da9063-onkey";
dlg,disable-key-power;
};
+   };
+
+Example: DA9062
+
+   pmic0: da9062@58 {
+   onkey {
+   compatible = "dlg,da9062-onkey";
+   dlg,disable-key-power;
+   };
+   };
+
+Example: DA9061 using a fall-back compatible for the DA9062 onkey driver
 
+   pmic0: da9061@58 {
+   onkey {
+   compatible = "dlg,da9061-onkey", "dlg,da9062-onkey";
+   dlg,disable-key-power;
+   };
};
-- 
end-of-patch for PATCH V2

[PATCH V2 06/10] regulator: da9061: BUCK and LDO regulator driver

[Steve Twiss]

From: Steve Twiss 

Regulator support for the DA9061 is added into the DA9062 regulator driver.
 
The regulators for DA9061 differ from those of DA9062.
A new DA9061 enumeration list for the LDOs and Bucks supported by this
device is added. Regulator information added: the old regulator
information for DA9062 is renamed from local_regulator_info[] to
local_da9062_regulator_info[] and a new array is added to support
local_da9061_regulator_info[].

The probe() function switches on the da9062_compatible_types enumeration
and configures the correct da9062_regulator_info array and number of
regulator entries.

Kconfig is updated to reflect support for DA9061 and DA9062 regulators.

Signed-off-by: Steve Twiss 

---
This patch applies against linux-next and v4.8

v1 -> v2
 - Patch renamed from [PATCH V1 02/10] to [PATCH V2 06/10] -- these
   changes were made to fix checkpatch warnings caused by the patch
   set dependency order
 - Updated header to use DA9061 and DA9062

Mark,

These changes depend on a header file provided as part of an earlier
patch [PATCH V2 05/10] from this set. The regulator probe() switches on
the chip_type which uses enum da9062_compatible_types in core.h from this
patch.

Regards,
Steve Twiss, Dialog Semiconductor Ltd.


 drivers/regulator/Kconfig|   4 +-
 drivers/regulator/da9062-regulator.c | 301 +--
 2 files changed, 292 insertions(+), 13 deletions(-)

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 6c88e31..c4f678fe 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -188,11 +188,11 @@ config REGULATOR_DA9055
  will be called da9055-regulator.
 
 config REGULATOR_DA9062
-   tristate "Dialog Semiconductor DA9062 regulators"
+   tristate "Dialog Semiconductor DA9061/62 regulators"
depends on MFD_DA9062
help
  Say y here to support the BUCKs and LDOs regulators found on
- DA9062 PMICs.
+ DA9061 and DA9062 PMICs.
 
  This driver can also be built as a module. If so, the module
  will be called da9062-regulator.
diff --git a/drivers/regulator/da9062-regulator.c 
b/drivers/regulator/da9062-regulator.c
index 0638c8b..931be68 100644
--- a/drivers/regulator/da9062-regulator.c
+++ b/drivers/regulator/da9062-regulator.c
@@ -1,5 +1,5 @@
 /*
- * da9062-regulator.c - REGULATOR device driver for DA9062
+ * Regulator device driver for DA9061 and DA9062.
  * Copyright (C) 2015  Dialog Semiconductor Ltd.
  *
  * This program is free software; you can redistribute it and/or
@@ -28,6 +28,17 @@
 
 /* Regulator IDs */
 enum {
+   DA9061_ID_BUCK1,
+   DA9061_ID_BUCK2,
+   DA9061_ID_BUCK3,
+   DA9061_ID_LDO1,
+   DA9061_ID_LDO2,
+   DA9061_ID_LDO3,
+   DA9061_ID_LDO4,
+   DA9061_MAX_REGULATORS,
+};
+
+enum {
DA9062_ID_BUCK1,
DA9062_ID_BUCK2,
DA9062_ID_BUCK3,
@@ -88,15 +99,21 @@ enum {
 
 /* Regulator operations */
 
-/* Current limits array (in uA) BUCK1 and BUCK3.
-   Entry indexes corresponds to register values. */
+/* Current limits array (in uA)
+ * - DA9061_ID_[BUCK1|BUCK3]
+ * - DA9062_ID_[BUCK1|BUCK2|BUCK4]
+ * Entry indexes corresponds to register values.
+ */
 static const int da9062_buck_a_limits[] = {
 50,  60,  70,  80,  90, 100, 110, 120,
130, 140, 150, 160, 170, 180, 190, 200
 };
 
-/* Current limits array (in uA) for BUCK2.
-   Entry indexes corresponds to register values. */
+/* Current limits array (in uA)
+ * - DA9061_ID_BUCK2
+ * - DA9062_ID_BUCK3
+ * Entry indexes corresponds to register values.
+ */
 static const int da9062_buck_b_limits[] = {
150, 160, 170, 180, 190, 200, 210, 220,
230, 240, 250, 260, 270, 280, 290, 300
@@ -405,8 +422,254 @@ static const struct regulator_ops da9062_ldo_ops = {
.set_suspend_mode   = da9062_ldo_set_suspend_mode,
 };
 
-/* Regulator information */
-static const struct da9062_regulator_info local_regulator_info[] = {
+/* DA9061 Regulator information */
+static const struct da9062_regulator_info local_da9061_regulator_info[] = {
+   {
+   .desc.id = DA9061_ID_BUCK1,
+   .desc.name = "DA9061 BUCK1",
+   .desc.of_match = of_match_ptr("buck1"),
+   .desc.regulators_node = of_match_ptr("regulators"),
+   .desc.ops = _buck_ops,
+   .desc.min_uV = (300) * 1000,
+   .desc.uV_step = (10) * 1000,
+   .desc.n_voltages = ((1570) - (300))/(10) + 1,
+   .current_limits = da9062_buck_a_limits,
+   .n_current_limits = ARRAY_SIZE(da9062_buck_a_limits),
+   .desc.enable_reg = DA9062AA_BUCK1_CONT,
+   .desc.enable_mask = DA9062AA_BUCK1_EN_MASK,
+   .desc.vsel_reg = DA9062AA_VBUCK1_A,
+   .desc.vsel_mask = 

[PATCH V2 07/10] Input: da9061: onkey driver

[Steve Twiss]

From: Steve Twiss 

Copyright header is updated to add DA9061 in its description and the module
description macro is extended to include DA9061.

Minor change to the code, alters dev_dbg() statements to report a generic
"PMIC" instead of DA9063. This device driver is compatible with DA9061,
DA9062 and DA9063.

Kconfig is updated to reflect support for DA9061/62/63.

Signed-off-by: Steve Twiss 

---
This patch applies against linux-next and v4.8

v1 -> v2
 - Patch renamed from [PATCH V1 03/10] to [PATCH V2 07/10] -- these
   changes were made to fix checkpatch warnings caused by the patch
   set dependency order
 - Revert changes for DA9061 specific compatible changes.

Dmitry,

Alterations made in accordance with previous e-mail thread on the use of
compatible strings: https://lkml.org/lkml/2016/10/7/641
Now assuming the use of a fallback compatible string in the DT.
compatible = "dlg,da9061-onkey", "dlg,da9062-onkey";

Regards,
Steve Twiss, Dialog Semiconductor Ltd.


 drivers/input/misc/Kconfig| 7 ---
 drivers/input/misc/da9063_onkey.c | 8 
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index efb0ca8..57cc9c2 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -613,11 +613,12 @@ config INPUT_DA9055_ONKEY
  will be called da9055_onkey.
 
 config INPUT_DA9063_ONKEY
-   tristate "Dialog DA9062/63 OnKey"
+   tristate "Dialog DA9063/62/61 OnKey"
depends on MFD_DA9063 || MFD_DA9062
help
- Support the ONKEY of Dialog DA9063 and DA9062 Power Management ICs
- as an input device capable of reporting the power button status.
+ Support the ONKEY of Dialog DA9063, DA9062 and DA9061 Power
+ Management ICs as an input device capable of reporting the
+ power button status.
 
  To compile this driver as a module, choose M here: the module
  will be called da9063_onkey.
diff --git a/drivers/input/misc/da9063_onkey.c 
b/drivers/input/misc/da9063_onkey.c
index bb863e0..dff6fe5 100644
--- a/drivers/input/misc/da9063_onkey.c
+++ b/drivers/input/misc/da9063_onkey.c
@@ -1,5 +1,5 @@
 /*
- * OnKey device driver for DA9063 and DA9062 PMICs
+ * OnKey device driver for DA9063, DA9062 and DA9061 PMICs
  * Copyright (C) 2015  Dialog Semiconductor Ltd.
  *
  * This program is free software; you can redistribute it and/or
@@ -149,13 +149,13 @@ static void da9063_poll_on(struct work_struct *work)
 * and then send shutdown command
 */
dev_dbg(>input->dev,
-   "Sending SHUTDOWN to DA9063 ...\n");
+   "Sending SHUTDOWN to PMIC ...\n");
error = regmap_write(onkey->regmap,
 config->onkey_shutdown,
 config->onkey_shutdown_mask);
if (error)
dev_err(>input->dev,
-   "Cannot SHUTDOWN DA9063: %d\n",
+   "Cannot SHUTDOWN PMIC: %d\n",
error);
}
}
@@ -300,6 +300,6 @@ static struct platform_driver da9063_onkey_driver = {
 module_platform_driver(da9063_onkey_driver);
 
 MODULE_AUTHOR("S Twiss ");
-MODULE_DESCRIPTION("Onkey device driver for Dialog DA9063 and DA9062");
+MODULE_DESCRIPTION("Onkey device driver for Dialog DA9063, DA9062 and DA9061");
 MODULE_LICENSE("GPL");
 MODULE_ALIAS("platform:" DA9063_DRVNAME_ONKEY);
-- 
end-of-patch for PATCH V2

[PATCH V2 00/10] da9061: DA9061 driver submission

[Steve Twiss]

From: Steve Twiss 

This patch set adds support for the Dialog DA9061 Power Management IC.
Support is made by altering the existing DA9062 device driver, where
appropriate.

In this patch set the following is provided:

[PATCH V2 01/10] Binding for onkey
[PATCH V2 02/10] Binding for watchdog
[PATCH V2 03/10] Binding for thermal supervisor
[PATCH V2 04/10] Binding for MFD and regulators
[PATCH V2 05/10] MFD core support
[PATCH V2 06/10] BUCKs and LDOs
[PATCH V2 07/10] Onkey 
[PATCH V2 08/10] Watchdog
[PATCH V2 09/10] PMIC temperature monitoring
[PATCH V2 10/10] MAINTAINERS update

This patch applies against linux-next and v4.8 

Thank you,
Steve Twiss, Dialog Semiconductor Ltd.

Steve Twiss (10):
  Documentation: devicetree: input: additions for da9061 onkey driver
  Documentation: devicetree: watchdog: da9062/61 watchdog timer binding
  Documentation: devicetree: thermal: da9062/61 TJUNC temperature
binding
  Documentation: devicetree: mfd: da9062/61 MFD binding
  mfd: da9061: MFD core support
  regulator: da9061: BUCK and LDO regulator driver
  Input: da9061: onkey driver
  watchdog: da9062/61: watchdog driver
  thermal: da9062/61: Thermal junction temperature monitoring driver
  MAINTAINERS: da9062/61 updates to the Dialog Semiconductor search
terms

 .../devicetree/bindings/input/da9062-onkey.txt |  39 +-
 Documentation/devicetree/bindings/mfd/da9062.txt   |  45 ++-
 .../devicetree/bindings/thermal/da9062-thermal.txt |  37 ++
 .../devicetree/bindings/watchdog/da9062-wdt.txt|  21 +
 MAINTAINERS|   4 +
 drivers/input/misc/Kconfig |   7 +-
 drivers/input/misc/da9063_onkey.c  |   8 +-
 drivers/mfd/Kconfig|   5 +-
 drivers/mfd/da9062-core.c  | 427 -
 drivers/regulator/Kconfig  |   4 +-
 drivers/regulator/da9062-regulator.c   | 301 ++-
 drivers/thermal/Kconfig|  10 +
 drivers/thermal/Makefile   |   1 +
 drivers/thermal/da9062-thermal.c   | 289 ++
 drivers/watchdog/Kconfig   |   4 +-
 drivers/watchdog/da9062_wdt.c  |  18 +-
 include/linux/mfd/da9062/core.h|  27 +-
 include/linux/mfd/da9062/registers.h   |   2 +
 18 files changed, 1180 insertions(+), 69 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/thermal/da9062-thermal.txt
 create mode 100644 Documentation/devicetree/bindings/watchdog/da9062-wdt.txt
 create mode 100644 drivers/thermal/da9062-thermal.c

-- 
end-of-patch for PATCH V2

Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit

[Linus Torvalds]

On Wed, Oct 26, 2016 at 9:32 AM, Linus Torvalds
 wrote:
>
> Quite frankly, I think the solution is to just rip out all the insane
> zone crap.

IOW, something like the attached.

Advantage:

 - just look at the number of garbage lines removed!  21
insertions(+), 182 deletions(-)

 - it will actually speed up even the current case for all common
situations: no idiotic extra indirections that will take extra cache
misses

 - because the bit_wait_table array is now denser (256 entries is
about 6kB of data on 64-bit with no spinlock debugging, so ~100
cachelines), maybe it gets fewer cache misses too

 - we know how to handle the page_waitqueue contention issue, and it
has nothing to do with the stupid NUMA zones

The only case you actually get real page wait activity is IO, and I
suspect that hashing it out over ~100 cachelines will be more than
sufficient to avoid excessive contention, plus it's a cache-miss vs an
IO, so nobody sane cares.

The only reason it did that insane per-zone thing in the first place
that right now we access those wait-queues even when we damn well
shouldn't, and we have the solution for that.

Guys, holler if you hate this, but I think it's realistically the only
sane solution to the "wait queue on stack" issue.

Oh, and the patch is obviously entirely untested. I wouldn't want to
ruin my reputation by *testing* the patches I send out. What would be
the fun in that?

 Linus
 include/linux/mmzone.h |  30 +
 kernel/sched/core.c|  16 +++
 kernel/sched/wait.c|  10 -
 mm/filemap.c   |   4 +-
 mm/memory_hotplug.c|  28 
 mm/page_alloc.c| 115 +
 6 files changed, 21 insertions(+), 182 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 7f2ae99e5daf..0f088f3a2fed 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -440,33 +440,7 @@ struct zone {
seqlock_t   span_seqlock;
 #endif
 
-   /*
-* wait_table   -- the array holding the hash table
-* wait_table_hash_nr_entries   -- the size of the hash table array
-* wait_table_bits  -- wait_table_size == (1 << wait_table_bits)
-*
-* The purpose of all these is to keep track of the people
-* waiting for a page to become available and make them
-* runnable again when possible. The trouble is that this
-* consumes a lot of space, especially when so few things
-* wait on pages at a given time. So instead of using
-* per-page waitqueues, we use a waitqueue hash table.
-*
-* The bucket discipline is to sleep on the same queue when
-* colliding and wake all in that wait queue when removing.
-* When something wakes, it must check to be sure its page is
-* truly available, a la thundering herd. The cost of a
-* collision is great, but given the expected load of the
-* table, they should be so rare as to be outweighed by the
-* benefits from the saved space.
-*
-* __wait_on_page_locked() and unlock_page() in mm/filemap.c, are the
-* primary users of these fields, and in mm/page_alloc.c
-* free_area_init_core() performs the initialization of them.
-*/
-   wait_queue_head_t   *wait_table;
-   unsigned long   wait_table_hash_nr_entries;
-   unsigned long   wait_table_bits;
+   int initialized;
 
/* Write-intensive fields used from the page allocator */
ZONE_PADDING(_pad1_)
@@ -546,7 +520,7 @@ static inline bool zone_spans_pfn(const struct zone *zone, 
unsigned long pfn)
 
 static inline bool zone_is_initialized(struct zone *zone)
 {
-   return !!zone->wait_table;
+   return zone->initialized;
 }
 
 static inline bool zone_is_empty(struct zone *zone)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 94732d1ab00a..42d4027f9e26 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -7515,11 +7515,27 @@ static struct kmem_cache *task_group_cache 
__read_mostly;
 DECLARE_PER_CPU(cpumask_var_t, load_balance_mask);
 DECLARE_PER_CPU(cpumask_var_t, select_idle_mask);
 
+#define WAIT_TABLE_BITS 8
+#define WAIT_TABLE_SIZE (1 << WAIT_TABLE_BITS)
+static wait_queue_head_t bit_wait_table[WAIT_TABLE_SIZE] __cacheline_aligned;
+
+wait_queue_head_t *bit_waitqueue(void *word, int bit)
+{
+   const int shift = BITS_PER_LONG == 32 ? 5 : 6;
+   unsigned long val = (unsigned long)word << shift | bit;
+
+   return bit_wait_table + hash_long(val, WAIT_TABLE_BITS);
+}
+EXPORT_SYMBOL(bit_waitqueue);
+
 void __init sched_init(void)
 {
int i, j;
unsigned long alloc_size = 0, ptr;
 
+   for (i = 0; i < WAIT_TABLE_SIZE; i++)
+   init_waitqueue_head(bit_wait_table + i);
+
 #ifdef CONFIG_FAIR_GROUP_SCHED
alloc_size += 2 * nr_cpu_ids * sizeof(void **);
 

Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit

[Linus Torvalds]

On Wed, Oct 26, 2016 at 9:32 AM, Linus Torvalds
 wrote:
>
> Quite frankly, I think the solution is to just rip out all the insane
> zone crap.

IOW, something like the attached.

Advantage:

 - just look at the number of garbage lines removed!  21
insertions(+), 182 deletions(-)

 - it will actually speed up even the current case for all common
situations: no idiotic extra indirections that will take extra cache
misses

 - because the bit_wait_table array is now denser (256 entries is
about 6kB of data on 64-bit with no spinlock debugging, so ~100
cachelines), maybe it gets fewer cache misses too

 - we know how to handle the page_waitqueue contention issue, and it
has nothing to do with the stupid NUMA zones

The only case you actually get real page wait activity is IO, and I
suspect that hashing it out over ~100 cachelines will be more than
sufficient to avoid excessive contention, plus it's a cache-miss vs an
IO, so nobody sane cares.

The only reason it did that insane per-zone thing in the first place
that right now we access those wait-queues even when we damn well
shouldn't, and we have the solution for that.

Guys, holler if you hate this, but I think it's realistically the only
sane solution to the "wait queue on stack" issue.

Oh, and the patch is obviously entirely untested. I wouldn't want to
ruin my reputation by *testing* the patches I send out. What would be
the fun in that?

 Linus
 include/linux/mmzone.h |  30 +
 kernel/sched/core.c|  16 +++
 kernel/sched/wait.c|  10 -
 mm/filemap.c   |   4 +-
 mm/memory_hotplug.c|  28 
 mm/page_alloc.c| 115 +
 6 files changed, 21 insertions(+), 182 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 7f2ae99e5daf..0f088f3a2fed 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -440,33 +440,7 @@ struct zone {
seqlock_t   span_seqlock;
 #endif
 
-   /*
-* wait_table   -- the array holding the hash table
-* wait_table_hash_nr_entries   -- the size of the hash table array
-* wait_table_bits  -- wait_table_size == (1 << wait_table_bits)
-*
-* The purpose of all these is to keep track of the people
-* waiting for a page to become available and make them
-* runnable again when possible. The trouble is that this
-* consumes a lot of space, especially when so few things
-* wait on pages at a given time. So instead of using
-* per-page waitqueues, we use a waitqueue hash table.
-*
-* The bucket discipline is to sleep on the same queue when
-* colliding and wake all in that wait queue when removing.
-* When something wakes, it must check to be sure its page is
-* truly available, a la thundering herd. The cost of a
-* collision is great, but given the expected load of the
-* table, they should be so rare as to be outweighed by the
-* benefits from the saved space.
-*
-* __wait_on_page_locked() and unlock_page() in mm/filemap.c, are the
-* primary users of these fields, and in mm/page_alloc.c
-* free_area_init_core() performs the initialization of them.
-*/
-   wait_queue_head_t   *wait_table;
-   unsigned long   wait_table_hash_nr_entries;
-   unsigned long   wait_table_bits;
+   int initialized;
 
/* Write-intensive fields used from the page allocator */
ZONE_PADDING(_pad1_)
@@ -546,7 +520,7 @@ static inline bool zone_spans_pfn(const struct zone *zone, 
unsigned long pfn)
 
 static inline bool zone_is_initialized(struct zone *zone)
 {
-   return !!zone->wait_table;
+   return zone->initialized;
 }
 
 static inline bool zone_is_empty(struct zone *zone)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 94732d1ab00a..42d4027f9e26 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -7515,11 +7515,27 @@ static struct kmem_cache *task_group_cache 
__read_mostly;
 DECLARE_PER_CPU(cpumask_var_t, load_balance_mask);
 DECLARE_PER_CPU(cpumask_var_t, select_idle_mask);
 
+#define WAIT_TABLE_BITS 8
+#define WAIT_TABLE_SIZE (1 << WAIT_TABLE_BITS)
+static wait_queue_head_t bit_wait_table[WAIT_TABLE_SIZE] __cacheline_aligned;
+
+wait_queue_head_t *bit_waitqueue(void *word, int bit)
+{
+   const int shift = BITS_PER_LONG == 32 ? 5 : 6;
+   unsigned long val = (unsigned long)word << shift | bit;
+
+   return bit_wait_table + hash_long(val, WAIT_TABLE_BITS);
+}
+EXPORT_SYMBOL(bit_waitqueue);
+
 void __init sched_init(void)
 {
int i, j;
unsigned long alloc_size = 0, ptr;
 
+   for (i = 0; i < WAIT_TABLE_SIZE; i++)
+   init_waitqueue_head(bit_wait_table + i);
+
 #ifdef CONFIG_FAIR_GROUP_SCHED
alloc_size += 2 * nr_cpu_ids * sizeof(void **);
 #endif
diff --git 

Re: [PATCH v6 1/5] ARM: davinci: da8xx: add usb phy clocks

[Sekhar Nori]

On Wednesday 26 October 2016 10:07 PM, David Lechner wrote:
> On 10/26/2016 02:59 AM, Sekhar Nori wrote:
>> On Wednesday 26 October 2016 08:36 AM, David Lechner wrote:
>>> Up to this point, the USB phy clock configuration was handled
>>> manually in
>>> the board files and in the usb drivers. This adds proper clocks so that
>>> the usb drivers can use clk_get and clk_enable and not have to worry
>>> about
>>> the details. Also, the related code is removed from the board files and
>>> replaced with the new clock registration functions.
>>>
>>> Signed-off-by: David Lechner 
>>> Signed-off-by: Axel Haslam 
>>> ---
>>>
>>> I have added "ARM: davinci: da8xx: Enable the usb20 "per" clk on
>>> phy_clk_enable"
>>> from Axel Haslam to this patch.
>>>
>>> In the review of Axel's patch, Sekhar said:
>>>
 We should not be using a NULL device pointer here. Can you pass the
 musb
 device pointer available in the same file? Also, da850_clks[] in
 da850.c
 needs to be fixed to add the matching device name.
>>>
>>> However, the musb device may not be registered. The usb20_clk can be
>>> used to
>>> supply a 48MHz clock to USB 1.1 (ohci) without using the musb device.
>>> So, I am
>>> inclined to leave this as NULL.
>>
>> But clock look-up has nothing to do with device being registered AFAICT.
>> It is used to identify the clock consumer. Passing NULL there means the
>> clock is not associated with any device. Which is not correct as we are
>> specifically looking at MUSB module clock.
>>
>> Thanks,
>> Sekhar
>>
> 
> FWIW, clk_get() uses dev_name() to get the device name, which will
> return NULL until after the platform device is registered.

I believe you can set init_name in the device to setup an initial name
until registration.

> 
> I can add the device references anyway. However, this is complicated by
> the fact that the musb platform device declaration is inside of an #if
> IS_ENABLED(CONFIG_USB_MUSB_HDRC). I can either remove the #if or add
> more #if's. Do you have a preference on this?

Please remove the #if's. Usually device registration is never done
conditionally based on whether the driver is built or not. So this seems
incorrect anyway.

Thanks,
Sekhar

Re: [PATCH v6 1/5] ARM: davinci: da8xx: add usb phy clocks

[Sekhar Nori]

On Wednesday 26 October 2016 10:07 PM, David Lechner wrote:
> On 10/26/2016 02:59 AM, Sekhar Nori wrote:
>> On Wednesday 26 October 2016 08:36 AM, David Lechner wrote:
>>> Up to this point, the USB phy clock configuration was handled
>>> manually in
>>> the board files and in the usb drivers. This adds proper clocks so that
>>> the usb drivers can use clk_get and clk_enable and not have to worry
>>> about
>>> the details. Also, the related code is removed from the board files and
>>> replaced with the new clock registration functions.
>>>
>>> Signed-off-by: David Lechner 
>>> Signed-off-by: Axel Haslam 
>>> ---
>>>
>>> I have added "ARM: davinci: da8xx: Enable the usb20 "per" clk on
>>> phy_clk_enable"
>>> from Axel Haslam to this patch.
>>>
>>> In the review of Axel's patch, Sekhar said:
>>>
 We should not be using a NULL device pointer here. Can you pass the
 musb
 device pointer available in the same file? Also, da850_clks[] in
 da850.c
 needs to be fixed to add the matching device name.
>>>
>>> However, the musb device may not be registered. The usb20_clk can be
>>> used to
>>> supply a 48MHz clock to USB 1.1 (ohci) without using the musb device.
>>> So, I am
>>> inclined to leave this as NULL.
>>
>> But clock look-up has nothing to do with device being registered AFAICT.
>> It is used to identify the clock consumer. Passing NULL there means the
>> clock is not associated with any device. Which is not correct as we are
>> specifically looking at MUSB module clock.
>>
>> Thanks,
>> Sekhar
>>
> 
> FWIW, clk_get() uses dev_name() to get the device name, which will
> return NULL until after the platform device is registered.

I believe you can set init_name in the device to setup an initial name
until registration.

> 
> I can add the device references anyway. However, this is complicated by
> the fact that the musb platform device declaration is inside of an #if
> IS_ENABLED(CONFIG_USB_MUSB_HDRC). I can either remove the #if or add
> more #if's. Do you have a preference on this?

Please remove the #if's. Usually device registration is never done
conditionally based on whether the driver is built or not. So this seems
incorrect anyway.

Thanks,
Sekhar

Re: complete_all and "forever" completions

[Nicholas Mc Guire]

On Wed, Oct 26, 2016 at 05:42:13PM +0200, Peter Zijlstra wrote:
> On Wed, Oct 26, 2016 at 05:10:01AM -0700, Dmitry Torokhov wrote:
> > On Wed, Oct 26, 2016 at 10:45:35AM +0200, Peter Zijlstra wrote:
> > > On Tue, Oct 25, 2016 at 03:30:54PM -0700, Dmitry Torokhov wrote:
> 
> > > > Or do we need something like this in
> > > > do_wait_for_common():
> > > > 
> > > > if (x->done < UINT_MAX/2)
> > > > x->done--;
> > > 
> > > Depends a bit, do you really want this? Seems a bit daft to keep asking
> > > if its done already, seems like a waste of cycles to me.
> > > 
> > 
> > The use case I am after is:
> > 
> > 1. There is a device that is extremely dumb without firmware
> > 2. The driver uses request_firmware_nowait() and signals completion from
> > the firmware loading callback to let the reset of the driver know that
> > firmware has been done loading (successfully or otherwise)
> > 3. The driver uses wait_for_completion() in both remove() and suspend()
> > methods to wait for the firmware to finish loading.
> > 
> > While remove() happens at most once per device instance, suspend() may
> > happen unbound number of times (theoretically).
> > 
> > So the question is: should complete_all have this "forever" semantic
> > (IOW is documentation right about the intent) or do we need a new
> > primitive for this? From the cursory glance of users of complete_all()
> > all of them expect completion to stay in signalled state either forever,
> > or until they call reinit_completion() explicitly.
> 
> Nah, if we need this we should fix this one. Adding similar but slightly
> different primitives is a pain.
> 
> But I think you might need slightly more than the proposed change, the
> case I worry about is doing complete_all() when done != 0 (which isn't
> all that strange).

I do not quite see how that would work out for the Use-Case noted
if completion calls complete_all() once at the first firmware load
and at that point that completion object is "completed" forever then
the suspend() would not wait for any completion in this model.

Im probably simply misunderstanding something here - but a 
complete_all() seems to have been intended for a logically single
case of concurrent initialization but not for this use-case
I do think that this is a broken design - if the suspend()/resume()
needed to reload the firware then it also would need to wait for
the same and that would not occure without reinitializing the
completion object.

what am I missing ?

thx!
hofrat

Re: complete_all and "forever" completions

[Nicholas Mc Guire]

On Wed, Oct 26, 2016 at 05:42:13PM +0200, Peter Zijlstra wrote:
> On Wed, Oct 26, 2016 at 05:10:01AM -0700, Dmitry Torokhov wrote:
> > On Wed, Oct 26, 2016 at 10:45:35AM +0200, Peter Zijlstra wrote:
> > > On Tue, Oct 25, 2016 at 03:30:54PM -0700, Dmitry Torokhov wrote:
> 
> > > > Or do we need something like this in
> > > > do_wait_for_common():
> > > > 
> > > > if (x->done < UINT_MAX/2)
> > > > x->done--;
> > > 
> > > Depends a bit, do you really want this? Seems a bit daft to keep asking
> > > if its done already, seems like a waste of cycles to me.
> > > 
> > 
> > The use case I am after is:
> > 
> > 1. There is a device that is extremely dumb without firmware
> > 2. The driver uses request_firmware_nowait() and signals completion from
> > the firmware loading callback to let the reset of the driver know that
> > firmware has been done loading (successfully or otherwise)
> > 3. The driver uses wait_for_completion() in both remove() and suspend()
> > methods to wait for the firmware to finish loading.
> > 
> > While remove() happens at most once per device instance, suspend() may
> > happen unbound number of times (theoretically).
> > 
> > So the question is: should complete_all have this "forever" semantic
> > (IOW is documentation right about the intent) or do we need a new
> > primitive for this? From the cursory glance of users of complete_all()
> > all of them expect completion to stay in signalled state either forever,
> > or until they call reinit_completion() explicitly.
> 
> Nah, if we need this we should fix this one. Adding similar but slightly
> different primitives is a pain.
> 
> But I think you might need slightly more than the proposed change, the
> case I worry about is doing complete_all() when done != 0 (which isn't
> all that strange).

I do not quite see how that would work out for the Use-Case noted
if completion calls complete_all() once at the first firmware load
and at that point that completion object is "completed" forever then
the suspend() would not wait for any completion in this model.

Im probably simply misunderstanding something here - but a 
complete_all() seems to have been intended for a logically single
case of concurrent initialization but not for this use-case
I do think that this is a broken design - if the suspend()/resume()
needed to reload the firware then it also would need to wait for
the same and that would not occure without reinitializing the
completion object.

what am I missing ?

thx!
hofrat

Re: [v12, 5/8] soc: fsl: add GUTS driver for QorIQ platforms

[Scott Wood]

On Wed, 2016-09-21 at 14:57 +0800, Yangbo Lu wrote:
> diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
> new file mode 100644
> index 000..b99764c
> --- /dev/null
> +++ b/drivers/soc/fsl/Kconfig
> @@ -0,0 +1,19 @@
> +#
> +# Freescale SOC drivers
> +#
> +
> +source "drivers/soc/fsl/qe/Kconfig"
> +
> +config FSL_GUTS
> + bool "Freescale QorIQ GUTS driver"
> + select SOC_BUS
> + help
> +   The global utilities block controls power management, I/O device
> +   enabling, power-onreset(POR) configuration monitoring, alternate
> +   function selection for multiplexed signals,and clock control.
> +   This driver is to manage and access global utilities block.
> +   Initially only reading SVR and registering soc device are
> supported.
> +   Other guts accesses, such as reading RCW, should eventually be
> moved
> +   into this driver as well.
> +
> +   If you want GUTS driver support, you should say Y here.

This is user-enablable without dependencies, which means it will break some
randconfigs.  If this is to be enabled via select then remove the text after
"bool".

> +/* SoC die attribute definition for QorIQ platform */
> +static const struct fsl_soc_die_attr fsl_soc_die[] = {
> +#ifdef CONFIG_PPC
> + /*
> +  * Power Architecture-based SoCs T Series
> +  */
> +
> + /* Die: T4240, SoC: T4240/T4160/T4080 */
> + { .die  = "T4240",
> +   .svr  = 0x8240,
> +   .mask = 0xfff0,
> + },
> + /* Die: T1040, SoC: T1040/T1020/T1042/T1022 */
> + { .die  = "T1040",
> +   .svr  = 0x8520,
> +   .mask = 0xfff0,
> + },
> + /* Die: T2080, SoC: T2080/T2081 */
> + { .die  = "T2080",
> +   .svr  = 0x8530,
> +   .mask = 0xfff0,
> + },
> + /* Die: T1024, SoC: T1024/T1014/T1023/T1013 */
> + { .die  = "T1024",
> +   .svr  = 0x8540,
> +   .mask = 0xfff0,
> + },
> +#endif /* CONFIG_PPC */
> +#if defined(CONFIG_ARCH_MXC) || defined(CONFIG_ARCH_LAYERSCAPE)

Will this driver ever be probed on MXC?  Why do we need these ifdefs at all?


> + /*
> +  * ARM-based SoCs LS Series
> +  */
> +
> + /* Die: LS1043A, SoC: LS1043A/LS1023A */
> + { .die  = "LS1043A",
> +   .svr  = 0x8792,
> +   .mask = 0x,
> + },
> + /* Die: LS2080A, SoC: LS2080A/LS2040A/LS2085A */
> + { .die  = "LS2080A",
> +   .svr  = 0x8701,
> +   .mask = 0xff3f,
> + },
> + /* Die: LS1088A, SoC: LS1088A/LS1048A/LS1084A/LS1044A */
> + { .die  = "LS1088A",
> +   .svr  = 0x8703,
> +   .mask = 0xff3f,
> + },
> + /* Die: LS1012A, SoC: LS1012A */
> + { .die  = "LS1012A",
> +   .svr  = 0x8704,
> +   .mask = 0x,
> + },
> + /* Die: LS1046A, SoC: LS1046A/LS1026A */
> + { .die  = "LS1046A",
> +   .svr  = 0x8707,
> +   .mask = 0x,
> + },
> + /* Die: LS2088A, SoC: LS2088A/LS2048A/LS2084A/LS2044A */
> + { .die  = "LS2088A",
> +   .svr  = 0x8709,
> +   .mask = 0xff3f,
> + },
> + /* Die: LS1021A, SoC: LS1021A/LS1020A/LS1022A
> +  * Note: Put this die at the end in cause of incorrect
> identification
> +  */
> + { .die  = "LS1021A",
> +   .svr  = 0x8700,
> +   .mask = 0xfff0,
> + },
> +#endif /* CONFIG_ARCH_MXC || CONFIG_ARCH_LAYERSCAPE */

Instead of relying on ordering, add more bits to the mask so that there's no
overlap.  I think 0xfff7 would work.

> +out:
> + kfree(soc_dev_attr.machine);
> + kfree(soc_dev_attr.family);
> + kfree(soc_dev_attr.soc_id);
> + kfree(soc_dev_attr.revision);
> + iounmap(guts->regs);
> +out_free:
> + kfree(guts);
> + return ret;
> +}

Please use devm.

-Scott

Re: [v12, 5/8] soc: fsl: add GUTS driver for QorIQ platforms

[Scott Wood]

On Wed, 2016-09-21 at 14:57 +0800, Yangbo Lu wrote:
> diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
> new file mode 100644
> index 000..b99764c
> --- /dev/null
> +++ b/drivers/soc/fsl/Kconfig
> @@ -0,0 +1,19 @@
> +#
> +# Freescale SOC drivers
> +#
> +
> +source "drivers/soc/fsl/qe/Kconfig"
> +
> +config FSL_GUTS
> + bool "Freescale QorIQ GUTS driver"
> + select SOC_BUS
> + help
> +   The global utilities block controls power management, I/O device
> +   enabling, power-onreset(POR) configuration monitoring, alternate
> +   function selection for multiplexed signals,and clock control.
> +   This driver is to manage and access global utilities block.
> +   Initially only reading SVR and registering soc device are
> supported.
> +   Other guts accesses, such as reading RCW, should eventually be
> moved
> +   into this driver as well.
> +
> +   If you want GUTS driver support, you should say Y here.

This is user-enablable without dependencies, which means it will break some
randconfigs.  If this is to be enabled via select then remove the text after
"bool".

> +/* SoC die attribute definition for QorIQ platform */
> +static const struct fsl_soc_die_attr fsl_soc_die[] = {
> +#ifdef CONFIG_PPC
> + /*
> +  * Power Architecture-based SoCs T Series
> +  */
> +
> + /* Die: T4240, SoC: T4240/T4160/T4080 */
> + { .die  = "T4240",
> +   .svr  = 0x8240,
> +   .mask = 0xfff0,
> + },
> + /* Die: T1040, SoC: T1040/T1020/T1042/T1022 */
> + { .die  = "T1040",
> +   .svr  = 0x8520,
> +   .mask = 0xfff0,
> + },
> + /* Die: T2080, SoC: T2080/T2081 */
> + { .die  = "T2080",
> +   .svr  = 0x8530,
> +   .mask = 0xfff0,
> + },
> + /* Die: T1024, SoC: T1024/T1014/T1023/T1013 */
> + { .die  = "T1024",
> +   .svr  = 0x8540,
> +   .mask = 0xfff0,
> + },
> +#endif /* CONFIG_PPC */
> +#if defined(CONFIG_ARCH_MXC) || defined(CONFIG_ARCH_LAYERSCAPE)

Will this driver ever be probed on MXC?  Why do we need these ifdefs at all?


> + /*
> +  * ARM-based SoCs LS Series
> +  */
> +
> + /* Die: LS1043A, SoC: LS1043A/LS1023A */
> + { .die  = "LS1043A",
> +   .svr  = 0x8792,
> +   .mask = 0x,
> + },
> + /* Die: LS2080A, SoC: LS2080A/LS2040A/LS2085A */
> + { .die  = "LS2080A",
> +   .svr  = 0x8701,
> +   .mask = 0xff3f,
> + },
> + /* Die: LS1088A, SoC: LS1088A/LS1048A/LS1084A/LS1044A */
> + { .die  = "LS1088A",
> +   .svr  = 0x8703,
> +   .mask = 0xff3f,
> + },
> + /* Die: LS1012A, SoC: LS1012A */
> + { .die  = "LS1012A",
> +   .svr  = 0x8704,
> +   .mask = 0x,
> + },
> + /* Die: LS1046A, SoC: LS1046A/LS1026A */
> + { .die  = "LS1046A",
> +   .svr  = 0x8707,
> +   .mask = 0x,
> + },
> + /* Die: LS2088A, SoC: LS2088A/LS2048A/LS2084A/LS2044A */
> + { .die  = "LS2088A",
> +   .svr  = 0x8709,
> +   .mask = 0xff3f,
> + },
> + /* Die: LS1021A, SoC: LS1021A/LS1020A/LS1022A
> +  * Note: Put this die at the end in cause of incorrect
> identification
> +  */
> + { .die  = "LS1021A",
> +   .svr  = 0x8700,
> +   .mask = 0xfff0,
> + },
> +#endif /* CONFIG_ARCH_MXC || CONFIG_ARCH_LAYERSCAPE */

Instead of relying on ordering, add more bits to the mask so that there's no
overlap.  I think 0xfff7 would work.

> +out:
> + kfree(soc_dev_attr.machine);
> + kfree(soc_dev_attr.family);
> + kfree(soc_dev_attr.soc_id);
> + kfree(soc_dev_attr.revision);
> + iounmap(guts->regs);
> +out_free:
> + kfree(guts);
> + return ret;
> +}

Please use devm.

-Scott

Re: [PATCH] net: Reset skb to network header in neigh_hh_output

[Eric Dumazet]

On Wed, 2016-10-26 at 18:53 +0200, Abdelrhman Ahmed wrote:
> I think it's at the right place as the current one is a little different from 
> the
> commit e1f165032c8bade3a6bdf546f8faf61fda4dd01c.
> 
> In the next lines, skb_push is called after copying the hardware header and 
> there
> is no change to the data pointer inside the retry loop. We only need to reset
> before this loop.
> 
> __skb_pull(skb, skb_network_offset(skb));
> 
> do {
>   seq = read_seqbegin(>hh_lock);
>   hh_len = hh->hh_len;
>   if (likely(hh_len <= HH_DATA_MOD)) {
>   /* this is inlined by gcc */
>   memcpy(skb->data - HH_DATA_MOD, hh->hh_data, HH_DATA_MOD);
>   } else {
>   int hh_alen = HH_DATA_ALIGN(hh_len);
> 
>   memcpy(skb->data - hh_alen, hh->hh_data, hh_alen);
>   }
> } while (read_seqretry(>hh_lock, seq));
> 
> skb_push(skb, hh_len);
> 
> In the commit e1f165032c8bade3a6bdf546f8faf61fda4dd01c, dev_hard_header which
> calls create method for adding hardware header (uses skb_push) so it was
> required to reset to network header in the beginning of the retry loop.

Right you are, thanks for the clarification !

Back to the cause of the bug then.

If netfilter is the only case this might be needed, can't this be fixed
in netfilter ?

neigh_hh_output() is in fast path, it is quite annoying adding this
operation.

Re: [PATCH] net: Reset skb to network header in neigh_hh_output

[Eric Dumazet]

On Wed, 2016-10-26 at 18:53 +0200, Abdelrhman Ahmed wrote:
> I think it's at the right place as the current one is a little different from 
> the
> commit e1f165032c8bade3a6bdf546f8faf61fda4dd01c.
> 
> In the next lines, skb_push is called after copying the hardware header and 
> there
> is no change to the data pointer inside the retry loop. We only need to reset
> before this loop.
> 
> __skb_pull(skb, skb_network_offset(skb));
> 
> do {
>   seq = read_seqbegin(>hh_lock);
>   hh_len = hh->hh_len;
>   if (likely(hh_len <= HH_DATA_MOD)) {
>   /* this is inlined by gcc */
>   memcpy(skb->data - HH_DATA_MOD, hh->hh_data, HH_DATA_MOD);
>   } else {
>   int hh_alen = HH_DATA_ALIGN(hh_len);
> 
>   memcpy(skb->data - hh_alen, hh->hh_data, hh_alen);
>   }
> } while (read_seqretry(>hh_lock, seq));
> 
> skb_push(skb, hh_len);
> 
> In the commit e1f165032c8bade3a6bdf546f8faf61fda4dd01c, dev_hard_header which
> calls create method for adding hardware header (uses skb_push) so it was
> required to reset to network header in the beginning of the retry loop.

Right you are, thanks for the clarification !

Back to the cause of the bug then.

If netfilter is the only case this might be needed, can't this be fixed
in netfilter ?

neigh_hh_output() is in fast path, it is quite annoying adding this
operation.

[PATCH 3/3] crypto: testmgr - Add missing tests for internal sha512-mb implementation

[Marcelo Cerri]

Add null tests for the internal algorithm to avoid errors when running
in FIPS mode.

Signed-off-by: Marcelo Cerri 
---
 crypto/testmgr.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 58f903d..cfafd24 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -2313,6 +2313,10 @@ static const struct alg_test_desc alg_test_descs[] = {
.test = alg_test_null,
.fips_allowed = 1,
}, {
+   .alg = "__intel_sha512-mb",
+   .test = alg_test_null,
+   .fips_allowed = 1,
+   }, {
.alg = "ansi_cprng",
.test = alg_test_cprng,
.suite = {
@@ -3766,6 +3770,10 @@ static const struct alg_test_desc alg_test_descs[] = {
.test = alg_test_null,
.fips_allowed = 1,
}, {
+   .alg = "mcryptd(__intel_sha512-mb)",
+   .test = alg_test_null,
+   .fips_allowed = 1,
+   }, {
.alg = "md4",
.test = alg_test_hash,
.suite = {
-- 
2.7.4

[PATCH 3/3] crypto: testmgr - Add missing tests for internal sha512-mb implementation

[Marcelo Cerri]

Add null tests for the internal algorithm to avoid errors when running
in FIPS mode.

Signed-off-by: Marcelo Cerri 
---
 crypto/testmgr.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 58f903d..cfafd24 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -2313,6 +2313,10 @@ static const struct alg_test_desc alg_test_descs[] = {
.test = alg_test_null,
.fips_allowed = 1,
}, {
+   .alg = "__intel_sha512-mb",
+   .test = alg_test_null,
+   .fips_allowed = 1,
+   }, {
.alg = "ansi_cprng",
.test = alg_test_cprng,
.suite = {
@@ -3766,6 +3770,10 @@ static const struct alg_test_desc alg_test_descs[] = {
.test = alg_test_null,
.fips_allowed = 1,
}, {
+   .alg = "mcryptd(__intel_sha512-mb)",
+   .test = alg_test_null,
+   .fips_allowed = 1,
+   }, {
.alg = "md4",
.test = alg_test_hash,
.suite = {
-- 
2.7.4

[PATCH 2/3] crypto: testmgr - Add missing tests for internal sha256-mb implementation

[Marcelo Cerri]

Add null tests for the internal algorithm to avoid errors when running
in FIPS mode.

Signed-off-by: Marcelo Cerri 
---
 crypto/testmgr.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index d999373..58f903d 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -2309,6 +2309,10 @@ static const struct alg_test_desc alg_test_descs[] = {
.test = alg_test_null,
.fips_allowed = 1,
}, {
+   .alg = "__intel_sha256-mb",
+   .test = alg_test_null,
+   .fips_allowed = 1,
+   }, {
.alg = "ansi_cprng",
.test = alg_test_cprng,
.suite = {
@@ -3758,6 +3762,10 @@ static const struct alg_test_desc alg_test_descs[] = {
.test = alg_test_null,
.fips_allowed = 1,
}, {
+   .alg = "mcryptd(__intel_sha256-mb)",
+   .test = alg_test_null,
+   .fips_allowed = 1,
+   }, {
.alg = "md4",
.test = alg_test_hash,
.suite = {
-- 
2.7.4

[PATCH 1/3] crypto: testmgr - Add missing tests for internal sha1-mb implementation

[Marcelo Cerri]

Add null tests for the internal algorithm to avoid errors when running
in FIPS mode.

Signed-off-by: Marcelo Cerri 
---
 crypto/testmgr.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index ded50b6..d999373 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -2305,6 +2305,10 @@ static const struct alg_test_desc alg_test_descs[] = {
.test = alg_test_null,
.fips_allowed = 1,
}, {
+   .alg = "__intel_sha1-mb",
+   .test = alg_test_null,
+   .fips_allowed = 1,
+   }, {
.alg = "ansi_cprng",
.test = alg_test_cprng,
.suite = {
@@ -3750,6 +3754,10 @@ static const struct alg_test_desc alg_test_descs[] = {
}
}
}, {
+   .alg = "mcryptd(__intel_sha1-mb)",
+   .test = alg_test_null,
+   .fips_allowed = 1,
+   }, {
.alg = "md4",
.test = alg_test_hash,
.suite = {
-- 
2.7.4

[PATCH 2/3] crypto: testmgr - Add missing tests for internal sha256-mb implementation

[Marcelo Cerri]

Add null tests for the internal algorithm to avoid errors when running
in FIPS mode.

Signed-off-by: Marcelo Cerri 
---
 crypto/testmgr.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index d999373..58f903d 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -2309,6 +2309,10 @@ static const struct alg_test_desc alg_test_descs[] = {
.test = alg_test_null,
.fips_allowed = 1,
}, {
+   .alg = "__intel_sha256-mb",
+   .test = alg_test_null,
+   .fips_allowed = 1,
+   }, {
.alg = "ansi_cprng",
.test = alg_test_cprng,
.suite = {
@@ -3758,6 +3762,10 @@ static const struct alg_test_desc alg_test_descs[] = {
.test = alg_test_null,
.fips_allowed = 1,
}, {
+   .alg = "mcryptd(__intel_sha256-mb)",
+   .test = alg_test_null,
+   .fips_allowed = 1,
+   }, {
.alg = "md4",
.test = alg_test_hash,
.suite = {
-- 
2.7.4

[PATCH 1/3] crypto: testmgr - Add missing tests for internal sha1-mb implementation

[Marcelo Cerri]

Add null tests for the internal algorithm to avoid errors when running
in FIPS mode.

Signed-off-by: Marcelo Cerri 
---
 crypto/testmgr.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index ded50b6..d999373 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -2305,6 +2305,10 @@ static const struct alg_test_desc alg_test_descs[] = {
.test = alg_test_null,
.fips_allowed = 1,
}, {
+   .alg = "__intel_sha1-mb",
+   .test = alg_test_null,
+   .fips_allowed = 1,
+   }, {
.alg = "ansi_cprng",
.test = alg_test_cprng,
.suite = {
@@ -3750,6 +3754,10 @@ static const struct alg_test_desc alg_test_descs[] = {
}
}
}, {
+   .alg = "mcryptd(__intel_sha1-mb)",
+   .test = alg_test_null,
+   .fips_allowed = 1,
+   }, {
.alg = "md4",
.test = alg_test_hash,
.suite = {
-- 
2.7.4

tmpfs returns incorrect data on concurrent pread() and truncate()

[Jakob Unterwurzacher]

tmpfs seems to be incorrectly returning 0-bytes when reading from
a file that is concurrently being truncated.

This is causing crashes in gocryptfs, a cryptographic FUSE overlay,
when it reads a nonce from disk that should absolutely positively
never be all-zero.

I have written a reproducer in C that triggers this issue on
both boxes I tested, Linux 4.7.2 and 3.16.7, both amd64.

It can be downloaded from here:

https://gist.github.com/rfjakob/d01281c737db38075767f90bf03fc475

or, alternatively, I have attached it to this email at the bottom.

The reproducer:
1) Creates a 10MB file filled with 'x' at /dev/shm/x
2) Spawns a thread that truncates the file 3 bytes at a time
3) Spawns another thread that pread()s the file 1 byte at a time
   starting from the top
4) Prints "wrong data" whenever the pread() gets something that
   is not 'x' or an empty result.

Example run:

$ gcc -Wall -lpthread truncate_read.c && ./a.out
wrong data: 0
wrong data: 0
wrong data: 0
wrong data: 0
wrong data: 0
wrong data: 0
wrong data: 0
wrong data: 0
wrong data: 0
wrong data: 0
[...]


Best regards,
Jakob


-
truncate_read.c
--8<---


// Compile and run:
// gcc -Wall -lpthread truncate_read.c && ./a.out

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

int fd;
int l = 10*1024*1024;
pthread_t tid[2];

void* read_thread(void *arg){
int o,n;
char b;
for(o=l; o>0; o--) {
b = 'a';
n = pread(fd, , 1, o);
if(n==0) {
continue;
}
if(b != 'x') {
printf("wrong data: %x\n", b);
}
}
return NULL;
}

void* truncate_thread(void *arg){
// Parent = Truncater
int o,n;
// "3" seems to be the sweet spot to trigger the most errors.
for(o=l; o>0; o-=3) {
n = ftruncate(fd, o);
if(n!=0) {
perror("ftruncate err");
}
}
return NULL;
}

int main(int argc, char *argv[]) {
fd = open("/dev/shm/x", O_RDWR | O_TRUNC | O_CREAT, 0666);
if(fd < 0) {
printf("open failed\n");
exit(1);
}
char* x = malloc(l);
memset(x, 'x', l);
write(fd, x, l);

pthread_create(&(tid[0]), NULL, _thread, NULL);
pthread_create(&(tid[1]), NULL, _thread, NULL);

void *res;
pthread_join(tid[0], );
pthread_join(tid[1], );

return 0;
}

tmpfs returns incorrect data on concurrent pread() and truncate()

[Jakob Unterwurzacher]

tmpfs seems to be incorrectly returning 0-bytes when reading from
a file that is concurrently being truncated.

This is causing crashes in gocryptfs, a cryptographic FUSE overlay,
when it reads a nonce from disk that should absolutely positively
never be all-zero.

I have written a reproducer in C that triggers this issue on
both boxes I tested, Linux 4.7.2 and 3.16.7, both amd64.

It can be downloaded from here:

https://gist.github.com/rfjakob/d01281c737db38075767f90bf03fc475

or, alternatively, I have attached it to this email at the bottom.

The reproducer:
1) Creates a 10MB file filled with 'x' at /dev/shm/x
2) Spawns a thread that truncates the file 3 bytes at a time
3) Spawns another thread that pread()s the file 1 byte at a time
   starting from the top
4) Prints "wrong data" whenever the pread() gets something that
   is not 'x' or an empty result.

Example run:

$ gcc -Wall -lpthread truncate_read.c && ./a.out
wrong data: 0
wrong data: 0
wrong data: 0
wrong data: 0
wrong data: 0
wrong data: 0
wrong data: 0
wrong data: 0
wrong data: 0
wrong data: 0
[...]


Best regards,
Jakob


-
truncate_read.c
--8<---


// Compile and run:
// gcc -Wall -lpthread truncate_read.c && ./a.out

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

int fd;
int l = 10*1024*1024;
pthread_t tid[2];

void* read_thread(void *arg){
int o,n;
char b;
for(o=l; o>0; o--) {
b = 'a';
n = pread(fd, , 1, o);
if(n==0) {
continue;
}
if(b != 'x') {
printf("wrong data: %x\n", b);
}
}
return NULL;
}

void* truncate_thread(void *arg){
// Parent = Truncater
int o,n;
// "3" seems to be the sweet spot to trigger the most errors.
for(o=l; o>0; o-=3) {
n = ftruncate(fd, o);
if(n!=0) {
perror("ftruncate err");
}
}
return NULL;
}

int main(int argc, char *argv[]) {
fd = open("/dev/shm/x", O_RDWR | O_TRUNC | O_CREAT, 0666);
if(fd < 0) {
printf("open failed\n");
exit(1);
}
char* x = malloc(l);
memset(x, 'x', l);
write(fd, x, l);

pthread_create(&(tid[0]), NULL, _thread, NULL);
pthread_create(&(tid[1]), NULL, _thread, NULL);

void *res;
pthread_join(tid[0], );
pthread_join(tid[1], );

return 0;
}

[PATCH 0/3] crypto: testmgr - Add missing tests for internal sha*-mb implementations

[Marcelo Cerri]

This series adds null tests for all sha*-mb internal algorithms so they can
be used in FIPS mode without further problems.

Since they are 3 separated modules I decided to use a separated commit for
each one.

Marcelo Cerri (3):
  crypto: testmgr - Add missing tests for internal sha1-mb
implementation
  crypto: testmgr - Add missing tests for internal sha256-mb
implementation
  crypto: testmgr - Add missing tests for internal sha512-mb
implementation

 crypto/testmgr.c | 24 
 1 file changed, 24 insertions(+)

-- 
2.7.4

[PATCH 0/3] crypto: testmgr - Add missing tests for internal sha*-mb implementations

[Marcelo Cerri]

This series adds null tests for all sha*-mb internal algorithms so they can
be used in FIPS mode without further problems.

Since they are 3 separated modules I decided to use a separated commit for
each one.

Marcelo Cerri (3):
  crypto: testmgr - Add missing tests for internal sha1-mb
implementation
  crypto: testmgr - Add missing tests for internal sha256-mb
implementation
  crypto: testmgr - Add missing tests for internal sha512-mb
implementation

 crypto/testmgr.c | 24 
 1 file changed, 24 insertions(+)

-- 
2.7.4

Re: [PATCH v4 4/5] mm: make processing of movable_node arch-specific

[Reza Arbab]

On Wed, Oct 26, 2016 at 09:52:53PM +1100, Michael Ellerman wrote:

As far as I know, power has nothing like the SRAT that tells us, at
boot, which memory is hotpluggable.


On pseries we have the ibm,dynamic-memory device tree property, which
can contain ranges of memory that are not yet "assigned to the
partition" - ie. can be hotplugged later.

So in general that statement is not true.

But I think you're focused on bare-metal, in which case you might be
right. But that doesn't mean we couldn't have a similar property, if
skiboot/hostboot knew what the ranges of memory were going to be.


Yes, sorry, I should have qualified that statement to say I wasn't 
talking about pseries.


I can amend this set to actually implement movable_node on power too, 
but we'd have to settle on a name for the dt property. Is 
"linux,movable-node" too on the nose?


--
Reza Arbab

Re: [PATCH v4 4/5] mm: make processing of movable_node arch-specific

[Reza Arbab]

On Wed, Oct 26, 2016 at 09:52:53PM +1100, Michael Ellerman wrote:

As far as I know, power has nothing like the SRAT that tells us, at
boot, which memory is hotpluggable.


On pseries we have the ibm,dynamic-memory device tree property, which
can contain ranges of memory that are not yet "assigned to the
partition" - ie. can be hotplugged later.

So in general that statement is not true.

But I think you're focused on bare-metal, in which case you might be
right. But that doesn't mean we couldn't have a similar property, if
skiboot/hostboot knew what the ranges of memory were going to be.


Yes, sorry, I should have qualified that statement to say I wasn't 
talking about pseries.


I can amend this set to actually implement movable_node on power too, 
but we'd have to settle on a name for the dt property. Is 
"linux,movable-node" too on the nose?


--
Reza Arbab

Re: [RFC v4 00/18] Landlock LSM: Unprivileged sandboxing

[Mickaël Salaün]

On 26/10/2016 16:52, Jann Horn wrote:
> On Wed, Oct 26, 2016 at 08:56:36AM +0200, Mickaël Salaün wrote:
>> The loaded Landlock eBPF programs can be triggered by a seccomp filter
>> returning RET_LANDLOCK. In addition, a cookie (16-bit value) can be passed 
>> from
>> a seccomp filter to eBPF programs. This allow flexible security policies
>> between seccomp and Landlock.
> 
> Is this still up to date, or was that removed in v3?
> 

I forgot to remove this part. In this v4 series, as describe in the
(small) patch 11/18, a Landlock rule cannot be triggered by a seccomp
filter. So there is no more RET_LANDLOCK nor cookie.



signature.asc
Description: OpenPGP digital signature

Re: [RFC v4 00/18] Landlock LSM: Unprivileged sandboxing

[Mickaël Salaün]

On 26/10/2016 16:52, Jann Horn wrote:
> On Wed, Oct 26, 2016 at 08:56:36AM +0200, Mickaël Salaün wrote:
>> The loaded Landlock eBPF programs can be triggered by a seccomp filter
>> returning RET_LANDLOCK. In addition, a cookie (16-bit value) can be passed 
>> from
>> a seccomp filter to eBPF programs. This allow flexible security policies
>> between seccomp and Landlock.
> 
> Is this still up to date, or was that removed in v3?
> 

I forgot to remove this part. In this v4 series, as describe in the
(small) patch 11/18, a Landlock rule cannot be triggered by a seccomp
filter. So there is no more RET_LANDLOCK nor cookie.



signature.asc
Description: OpenPGP digital signature

Re: [RESEND PATCH] arm: assabet_defconfig: disable IDE subsystem

[Bartlomiej Zolnierkiewicz]

Hi,

On Wednesday, July 13, 2016 04:37:31 PM Arnd Bergmann wrote:
> On Wednesday, July 13, 2016 12:59:23 PM CEST Bartlomiej Zolnierkiewicz wrote:
> > 
> > On Friday, July 08, 2016 10:23:48 PM Arnd Bergmann wrote:
> > > On Friday, July 8, 2016 5:24:41 PM CEST Bartlomiej Zolnierkiewicz wrote:
> > > > This patch disables deprecated IDE subsystem in assabet_defconfig
> > > > (no IDE host drivers are selected in this config so there is no
> > > > valid reason to enable IDE subsystem itself).
> > > > 
> > > > Cc: Dmitry Eremin-Solenikov 
> > > > Signed-off-by: Bartlomiej Zolnierkiewicz 
> > > 
> > > I think the series makes a lot of sense. I have checked your assertions
> > > in the changelogs and found no flaws in your logic, so I think we should
> > > take them all through arm-soc unless there are other concerns.
> > 
> > Thank you.
> > 
> > Should I resend everything or just patches that were not reposted yet
> > (the ones that were marked as RFT initially and got no feedback)?
> 
> I'd be fine with just getting a pull request with all the patches that
> had no negative feedback and that were not already applied (if any).

Here it is (sorry for taking so long).

The following changes since commit 07d9a380680d1c0eb51ef87ff2eab5c994949e69:

  Linux 4.9-rc2 (2016-10-23 17:10:14 -0700)

are available in the git repository at:

  https://github.com/bzolnier/linux.git v4.9-rc2-arm-configs-pata

for you to fetch changes up to bc9c6cc857849ec0d83bd13c1812bae9345dc553:

  arm: spitz_defconfig: convert to use libata PATA drivers (2016-10-26 18:43:33 
+0200)


Bartlomiej Zolnierkiewicz (16):
  arm: assabet_defconfig: disable IDE subsystem
  arm: badge4_defconfig: disable IDE subsystem
  arm: cerfcube_defconfig: disable IDE subsystem
  arm: lart_defconfig: disable IDE subsystem
  arm: mainstone_defconfig: disable IDE subsystem
  arm: shannon_defconfig: disable IDE subsystem
  arm: collie_defconfig: convert to use libata PATA drivers
  arm: omap1_defconfig: convert to use libata PATA drivers
  arm: am200epdkit_defconfig: convert to use libata PATA drivers
  arm: corgi_defconfig: convert to use libata PATA drivers
  arm: h3600_defconfig: convert to use libata PATA drivers
  arm: ixp4xx_defconfig: convert to use libata PATA drivers
  arm: jornada720_defconfig: convert to use libata PATA drivers
  arm: netwinder_defconfig: convert to use libata PATA drivers
  arm: s3c2410_defconfig: convert to use libata PATA drivers
  arm: spitz_defconfig: convert to use libata PATA drivers

 arch/arm/configs/am200epdkit_defconfig |  5 +++--
 arch/arm/configs/assabet_defconfig |  1 -
 arch/arm/configs/badge4_defconfig  |  2 --
 arch/arm/configs/cerfcube_defconfig|  1 -
 arch/arm/configs/collie_defconfig  |  5 +++--
 arch/arm/configs/corgi_defconfig   |  7 +++
 arch/arm/configs/h3600_defconfig   |  5 +++--
 arch/arm/configs/ixp4xx_defconfig  |  9 +
 arch/arm/configs/jornada720_defconfig  |  5 +++--
 arch/arm/configs/lart_defconfig|  2 --
 arch/arm/configs/mainstone_defconfig   |  1 -
 arch/arm/configs/netwinder_defconfig   |  7 ---
 arch/arm/configs/omap1_defconfig   |  4 ++--
 arch/arm/configs/s3c2410_defconfig | 10 +++---
 arch/arm/configs/shannon_defconfig |  1 -
 arch/arm/configs/spitz_defconfig   |  8 +++-
 16 files changed, 32 insertions(+), 41 deletions(-)

Re: [RESEND PATCH] arm: assabet_defconfig: disable IDE subsystem

[Bartlomiej Zolnierkiewicz]

Hi,

On Wednesday, July 13, 2016 04:37:31 PM Arnd Bergmann wrote:
> On Wednesday, July 13, 2016 12:59:23 PM CEST Bartlomiej Zolnierkiewicz wrote:
> > 
> > On Friday, July 08, 2016 10:23:48 PM Arnd Bergmann wrote:
> > > On Friday, July 8, 2016 5:24:41 PM CEST Bartlomiej Zolnierkiewicz wrote:
> > > > This patch disables deprecated IDE subsystem in assabet_defconfig
> > > > (no IDE host drivers are selected in this config so there is no
> > > > valid reason to enable IDE subsystem itself).
> > > > 
> > > > Cc: Dmitry Eremin-Solenikov 
> > > > Signed-off-by: Bartlomiej Zolnierkiewicz 
> > > 
> > > I think the series makes a lot of sense. I have checked your assertions
> > > in the changelogs and found no flaws in your logic, so I think we should
> > > take them all through arm-soc unless there are other concerns.
> > 
> > Thank you.
> > 
> > Should I resend everything or just patches that were not reposted yet
> > (the ones that were marked as RFT initially and got no feedback)?
> 
> I'd be fine with just getting a pull request with all the patches that
> had no negative feedback and that were not already applied (if any).

Here it is (sorry for taking so long).

The following changes since commit 07d9a380680d1c0eb51ef87ff2eab5c994949e69:

  Linux 4.9-rc2 (2016-10-23 17:10:14 -0700)

are available in the git repository at:

  https://github.com/bzolnier/linux.git v4.9-rc2-arm-configs-pata

for you to fetch changes up to bc9c6cc857849ec0d83bd13c1812bae9345dc553:

  arm: spitz_defconfig: convert to use libata PATA drivers (2016-10-26 18:43:33 
+0200)


Bartlomiej Zolnierkiewicz (16):
  arm: assabet_defconfig: disable IDE subsystem
  arm: badge4_defconfig: disable IDE subsystem
  arm: cerfcube_defconfig: disable IDE subsystem
  arm: lart_defconfig: disable IDE subsystem
  arm: mainstone_defconfig: disable IDE subsystem
  arm: shannon_defconfig: disable IDE subsystem
  arm: collie_defconfig: convert to use libata PATA drivers
  arm: omap1_defconfig: convert to use libata PATA drivers
  arm: am200epdkit_defconfig: convert to use libata PATA drivers
  arm: corgi_defconfig: convert to use libata PATA drivers
  arm: h3600_defconfig: convert to use libata PATA drivers
  arm: ixp4xx_defconfig: convert to use libata PATA drivers
  arm: jornada720_defconfig: convert to use libata PATA drivers
  arm: netwinder_defconfig: convert to use libata PATA drivers
  arm: s3c2410_defconfig: convert to use libata PATA drivers
  arm: spitz_defconfig: convert to use libata PATA drivers

 arch/arm/configs/am200epdkit_defconfig |  5 +++--
 arch/arm/configs/assabet_defconfig |  1 -
 arch/arm/configs/badge4_defconfig  |  2 --
 arch/arm/configs/cerfcube_defconfig|  1 -
 arch/arm/configs/collie_defconfig  |  5 +++--
 arch/arm/configs/corgi_defconfig   |  7 +++
 arch/arm/configs/h3600_defconfig   |  5 +++--
 arch/arm/configs/ixp4xx_defconfig  |  9 +
 arch/arm/configs/jornada720_defconfig  |  5 +++--
 arch/arm/configs/lart_defconfig|  2 --
 arch/arm/configs/mainstone_defconfig   |  1 -
 arch/arm/configs/netwinder_defconfig   |  7 ---
 arch/arm/configs/omap1_defconfig   |  4 ++--
 arch/arm/configs/s3c2410_defconfig | 10 +++---
 arch/arm/configs/shannon_defconfig |  1 -
 arch/arm/configs/spitz_defconfig   |  8 +++-
 16 files changed, 32 insertions(+), 41 deletions(-)

Re: [RFC] HID:hid-lg4ff: Delay to allow wheels to center after plug-in

[Dmitry Torokhov]

On Wed, Oct 26, 2016 at 12:36 AM, Michal Malý  wrote:
> Hi all,
>
> maybe instead of stalling the entire init() function it'd be better to put a
> request to disable autocentering on a workqueue and start a delayed work once
> the init() function is done setting the wheel up? There'd be a bit more code
> to write though...
>

Yeah, if device happens to be plugged at boot time it will wait that
long before even getting to mount rootfs if driver is built into the
kernel.

This is also interesting way to say "msleep(8000)".

> Michal
>
> On Tuesday, October 25, 2016 7:26:12 PM CEST Simon Wood wrote:
>> A number of wheels (G27/etc) do a little full right/full left 'dance'
>> when first plugged in. This patch inserts a delay so that this 'dance'
>> is completed before we disable (set to zero) the autocenter spring.
>>
>> A side benefit is that the DFGT was confused without the delay, and is
>> now correctly being set to 900' rotation mode.
>>
>> Side Effect - and the reason I am sending as RFC. This 8s delay seems
>> to have an effect on other wheels connected at the same time.
>>
>> With 3 wheels on a hub, and then the hub connected to PC. The wheel
>> on the right in video below waits for G27 to complete this 8s, before
>> it will do it's 'dance' and register with the system.
>>
>> https://www.youtube.com/watch?v=xCVpCw_yGgA
>>
>> I don't know if this is a problem, or if someone here has suggestions
>> on a better way to implement the delay...
>> ---
>>  drivers/hid/hid-lg4ff.c | 10 ++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/hid/hid-lg4ff.c b/drivers/hid/hid-lg4ff.c
>> index af3a8ec..3eee920 100644
>> --- a/drivers/hid/hid-lg4ff.c
>> +++ b/drivers/hid/hid-lg4ff.c
>> @@ -1248,6 +1248,8 @@ int lg4ff_init(struct hid_device *hid)
>>   /* Check if autocentering is available and
>>* set the centering force to zero by default */
>>   if (test_bit(FF_AUTOCENTER, dev->ffbit)) {
>> + wait_queue_head_t wait;
>> +
>>   /* Formula Force EX expects different autocentering command */
>>   if ((bcdDevice >> 8) == LG4FF_FFEX_REV_MAJ &&
>>   (bcdDevice & 0xff) == LG4FF_FFEX_REV_MIN)
>> @@ -1255,6 +1257,14 @@ int lg4ff_init(struct hid_device *hid)
>>   else
>>   dev->ff->set_autocenter = lg4ff_set_autocenter_default;
>>
>> + /* insert a 8s delay to allow DFGT/G25/G27/G29 wheels to 
>> return to
> center
>> position*/ +  if (lg4ff_devices[i].product_id ==
>> USB_DEVICE_ID_LOGITECH_DFGT_WHEEL || +
> lg4ff_devices[i].product_id ==
>> USB_DEVICE_ID_LOGITECH_G25_WHEEL || + 
>> lg4ff_devices[i].product_id
> ==
>> USB_DEVICE_ID_LOGITECH_G27_WHEEL || + 
>> lg4ff_devices[i].product_id
> ==
>> USB_DEVICE_ID_LOGITECH_G29_WHEEL) { + init_waitqueue_head 
>> ();
>> + wait_event_interruptible_timeout(wait, 0, 
>> msecs_to_jiffies(8000));
>> + }
>>   dev->ff->set_autocenter(dev, 0);
>>   }
>

Thanks.

-- 
Dmitry

Re: [RFC] HID:hid-lg4ff: Delay to allow wheels to center after plug-in

[Dmitry Torokhov]

On Wed, Oct 26, 2016 at 12:36 AM, Michal Malý  wrote:
> Hi all,
>
> maybe instead of stalling the entire init() function it'd be better to put a
> request to disable autocentering on a workqueue and start a delayed work once
> the init() function is done setting the wheel up? There'd be a bit more code
> to write though...
>

Yeah, if device happens to be plugged at boot time it will wait that
long before even getting to mount rootfs if driver is built into the
kernel.

This is also interesting way to say "msleep(8000)".

> Michal
>
> On Tuesday, October 25, 2016 7:26:12 PM CEST Simon Wood wrote:
>> A number of wheels (G27/etc) do a little full right/full left 'dance'
>> when first plugged in. This patch inserts a delay so that this 'dance'
>> is completed before we disable (set to zero) the autocenter spring.
>>
>> A side benefit is that the DFGT was confused without the delay, and is
>> now correctly being set to 900' rotation mode.
>>
>> Side Effect - and the reason I am sending as RFC. This 8s delay seems
>> to have an effect on other wheels connected at the same time.
>>
>> With 3 wheels on a hub, and then the hub connected to PC. The wheel
>> on the right in video below waits for G27 to complete this 8s, before
>> it will do it's 'dance' and register with the system.
>>
>> https://www.youtube.com/watch?v=xCVpCw_yGgA
>>
>> I don't know if this is a problem, or if someone here has suggestions
>> on a better way to implement the delay...
>> ---
>>  drivers/hid/hid-lg4ff.c | 10 ++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/hid/hid-lg4ff.c b/drivers/hid/hid-lg4ff.c
>> index af3a8ec..3eee920 100644
>> --- a/drivers/hid/hid-lg4ff.c
>> +++ b/drivers/hid/hid-lg4ff.c
>> @@ -1248,6 +1248,8 @@ int lg4ff_init(struct hid_device *hid)
>>   /* Check if autocentering is available and
>>* set the centering force to zero by default */
>>   if (test_bit(FF_AUTOCENTER, dev->ffbit)) {
>> + wait_queue_head_t wait;
>> +
>>   /* Formula Force EX expects different autocentering command */
>>   if ((bcdDevice >> 8) == LG4FF_FFEX_REV_MAJ &&
>>   (bcdDevice & 0xff) == LG4FF_FFEX_REV_MIN)
>> @@ -1255,6 +1257,14 @@ int lg4ff_init(struct hid_device *hid)
>>   else
>>   dev->ff->set_autocenter = lg4ff_set_autocenter_default;
>>
>> + /* insert a 8s delay to allow DFGT/G25/G27/G29 wheels to 
>> return to
> center
>> position*/ +  if (lg4ff_devices[i].product_id ==
>> USB_DEVICE_ID_LOGITECH_DFGT_WHEEL || +
> lg4ff_devices[i].product_id ==
>> USB_DEVICE_ID_LOGITECH_G25_WHEEL || + 
>> lg4ff_devices[i].product_id
> ==
>> USB_DEVICE_ID_LOGITECH_G27_WHEEL || + 
>> lg4ff_devices[i].product_id
> ==
>> USB_DEVICE_ID_LOGITECH_G29_WHEEL) { + init_waitqueue_head 
>> ();
>> + wait_event_interruptible_timeout(wait, 0, 
>> msecs_to_jiffies(8000));
>> + }
>>   dev->ff->set_autocenter(dev, 0);
>>   }
>

Thanks.

-- 
Dmitry

Re: [PATCH 02/12] ASoC: dapm: Implement stereo mixer control support

[Mark Brown]

On Mon, Oct 03, 2016 at 07:07:54PM +0800, Chen-Yu Tsai wrote:

> While DAPM is mono or single channel, its controls can be shared between
> widgets, such as sharing one stereo mixer control between the left and
> right channel widgets.

> This patch introduces support for such shared mixer controls.

Based on this changelog I'm really not sure what the intended semantic
of this change is which makes it difficult to review.  What are you
expecting these controls to look like and how are you expecting them to
work?

> -static void dapm_set_mixer_path_status(struct snd_soc_dapm_path *p, int i)
> +static void dapm_set_mixer_path_status(struct snd_soc_dapm_path *p, int i,
> +int nth_path)

It looks like the goal is to attach more than one path to a single
control somehow?


signature.asc
Description: PGP signature

Re: [PATCH 02/12] ASoC: dapm: Implement stereo mixer control support

[Mark Brown]

On Mon, Oct 03, 2016 at 07:07:54PM +0800, Chen-Yu Tsai wrote:

> While DAPM is mono or single channel, its controls can be shared between
> widgets, such as sharing one stereo mixer control between the left and
> right channel widgets.

> This patch introduces support for such shared mixer controls.

Based on this changelog I'm really not sure what the intended semantic
of this change is which makes it difficult to review.  What are you
expecting these controls to look like and how are you expecting them to
work?

> -static void dapm_set_mixer_path_status(struct snd_soc_dapm_path *p, int i)
> +static void dapm_set_mixer_path_status(struct snd_soc_dapm_path *p, int i,
> +int nth_path)

It looks like the goal is to attach more than one path to a single
control somehow?


signature.asc
Description: PGP signature

Re: [PATCH] net: Reset skb to network header in neigh_hh_output

[Abdelrhman Ahmed]

I think it's at the right place as the current one is a little different from 
the
commit e1f165032c8bade3a6bdf546f8faf61fda4dd01c.

In the next lines, skb_push is called after copying the hardware header and 
there
is no change to the data pointer inside the retry loop. We only need to reset
before this loop.

__skb_pull(skb, skb_network_offset(skb));

do {
seq = read_seqbegin(>hh_lock);
hh_len = hh->hh_len;
if (likely(hh_len <= HH_DATA_MOD)) {
/* this is inlined by gcc */
memcpy(skb->data - HH_DATA_MOD, hh->hh_data, HH_DATA_MOD);
} else {
int hh_alen = HH_DATA_ALIGN(hh_len);

memcpy(skb->data - hh_alen, hh->hh_data, hh_alen);
}
} while (read_seqretry(>hh_lock, seq));

skb_push(skb, hh_len);

In the commit e1f165032c8bade3a6bdf546f8faf61fda4dd01c, dev_hard_header which
calls create method for adding hardware header (uses skb_push) so it was
required to reset to network header in the beginning of the retry loop.


  On Wed, 26 Oct 2016 02:12:22 +0200 Eric Dumazet  
wrote  
 > On Wed, 2016-10-26 at 01:57 +0200, Abdelrhman Ahmed wrote: 
 > >  > What is the issue you want to fix exactly ?  
 > >  > Please describe the use case.  
 > >  
 > > When netfilter hook uses skb_push to add a specific header between network 
 > > header and hardware header. 
 > > For the first time(s) before caching hardware header, this header will be 
 > > removed / overwritten by hardware header due to resetting to network 
 > > header. 
 > > After using the cached hardware header, this header will be kept as we do 
 > > not 
 > > reset. I think this behavior is inconsistent, so we need to reset in both 
 > > cases. 
 > >  
 > >  > Otherwise, your fix is in fact adding a critical bug.  
 > >  
 > > Could you explain more as it's not clear to me? 
 > >  
 >  
 > Maybe my wording was not good here. 
 >  
 > What I intended to say is that the  
 > __skb_pull(skb, skb_network_offset(skb)) might not be at the right 
 > place. 
 >  
 > Look at commit e1f165032c8bade3a6bdf546f8faf61fda4dd01c to find the 
 > reason. 
 >  
 >  
 > >  
 > >  
 > >   On Fri, 07 Oct 2016 23:10:56 +0200 Eric Dumazet 
 > >  wrote   
 > >  > On Fri, 2016-10-07 at 16:14 +0200, Abdelrhman Ahmed wrote:  
 > >  > > When hardware header is added without using cached one, 
 > > neigh_resolve_output  
 > >  > > and neigh_connected_output reset skb to network header before adding 
 > > it.  
 > >  > > When cached one is used, neigh_hh_output does not reset the skb to 
 > > network  
 > >  > > header.  
 > >  > >   
 > >  > > The fix is to reset skb to network header before adding cached 
 > > hardware header  
 > >  > > to keep the behavior consistent in all cases.  
 > >  >   
 > >  > What is the issue you want to fix exactly ?  
 > >  >   
 > >  > Please describe the use case.  
 > >  >   
 > >  > I highly suggest you take a look at commit  
 > >  >   
 > >  > e1f165032c8bade3a6bdf546f8faf61fda4dd01c  
 > >  > ("net: Fix skb_under_panic oops in neigh_resolve_output")  
 > >  >   
 > >  > Otherwise, your fix is in fact adding a critical bug.  
 > >  >   
 > >  >   
 > >  >  
 > >  
 >  
 >  
 > 

Re: [PATCH] net: Reset skb to network header in neigh_hh_output

[Abdelrhman Ahmed]

I think it's at the right place as the current one is a little different from 
the
commit e1f165032c8bade3a6bdf546f8faf61fda4dd01c.

In the next lines, skb_push is called after copying the hardware header and 
there
is no change to the data pointer inside the retry loop. We only need to reset
before this loop.

__skb_pull(skb, skb_network_offset(skb));

do {
seq = read_seqbegin(>hh_lock);
hh_len = hh->hh_len;
if (likely(hh_len <= HH_DATA_MOD)) {
/* this is inlined by gcc */
memcpy(skb->data - HH_DATA_MOD, hh->hh_data, HH_DATA_MOD);
} else {
int hh_alen = HH_DATA_ALIGN(hh_len);

memcpy(skb->data - hh_alen, hh->hh_data, hh_alen);
}
} while (read_seqretry(>hh_lock, seq));

skb_push(skb, hh_len);

In the commit e1f165032c8bade3a6bdf546f8faf61fda4dd01c, dev_hard_header which
calls create method for adding hardware header (uses skb_push) so it was
required to reset to network header in the beginning of the retry loop.


  On Wed, 26 Oct 2016 02:12:22 +0200 Eric Dumazet  
wrote  
 > On Wed, 2016-10-26 at 01:57 +0200, Abdelrhman Ahmed wrote: 
 > >  > What is the issue you want to fix exactly ?  
 > >  > Please describe the use case.  
 > >  
 > > When netfilter hook uses skb_push to add a specific header between network 
 > > header and hardware header. 
 > > For the first time(s) before caching hardware header, this header will be 
 > > removed / overwritten by hardware header due to resetting to network 
 > > header. 
 > > After using the cached hardware header, this header will be kept as we do 
 > > not 
 > > reset. I think this behavior is inconsistent, so we need to reset in both 
 > > cases. 
 > >  
 > >  > Otherwise, your fix is in fact adding a critical bug.  
 > >  
 > > Could you explain more as it's not clear to me? 
 > >  
 >  
 > Maybe my wording was not good here. 
 >  
 > What I intended to say is that the  
 > __skb_pull(skb, skb_network_offset(skb)) might not be at the right 
 > place. 
 >  
 > Look at commit e1f165032c8bade3a6bdf546f8faf61fda4dd01c to find the 
 > reason. 
 >  
 >  
 > >  
 > >  
 > >   On Fri, 07 Oct 2016 23:10:56 +0200 Eric Dumazet 
 > >  wrote   
 > >  > On Fri, 2016-10-07 at 16:14 +0200, Abdelrhman Ahmed wrote:  
 > >  > > When hardware header is added without using cached one, 
 > > neigh_resolve_output  
 > >  > > and neigh_connected_output reset skb to network header before adding 
 > > it.  
 > >  > > When cached one is used, neigh_hh_output does not reset the skb to 
 > > network  
 > >  > > header.  
 > >  > >   
 > >  > > The fix is to reset skb to network header before adding cached 
 > > hardware header  
 > >  > > to keep the behavior consistent in all cases.  
 > >  >   
 > >  > What is the issue you want to fix exactly ?  
 > >  >   
 > >  > Please describe the use case.  
 > >  >   
 > >  > I highly suggest you take a look at commit  
 > >  >   
 > >  > e1f165032c8bade3a6bdf546f8faf61fda4dd01c  
 > >  > ("net: Fix skb_under_panic oops in neigh_resolve_output")  
 > >  >   
 > >  > Otherwise, your fix is in fact adding a critical bug.  
 > >  >   
 > >  >   
 > >  >  
 > >  
 >  
 >  
 > 

[PATCH v2 3/3] x86/vmware: Add paravirt sched clock

[Alexey Makhalov]

Set pv_time_ops.sched_clock to vmware_sched_clock(). It is simplified
version of native_sched_clock() without ring buffer of mult/shift/offset
triplets and preempt toggling.
Since VMware hypervisor provides constant tsc we can use constant
mult/shift/offset triplet calculated at boot time.

no-vmw-sched-clock kernel parameter is added to disable the paravirt
sched clock.

Signed-off-by: Alexey Makhalov 
Acked-by: Alok N Kataria 
---
 Documentation/kernel-parameters.txt |  4 
 arch/x86/kernel/cpu/vmware.c| 41 +
 2 files changed, 45 insertions(+)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 37babf9..b3b2ec0 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2754,6 +2754,10 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
no-kvmapf   [X86,KVM] Disable paravirtualized asynchronous page
fault handling.
 
+   no-vmw-sched-clock
+   [X86,PV_OPS] Disable paravirtualized VMware scheduler
+   clock and use the default one.
+
no-steal-acc[X86,KVM] Disable paravirtualized steal time accounting.
steal time is computed, but won't influence scheduler
behaviour
diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index e3fb320..e284ebf 100644
--- a/arch/x86/kernel/cpu/vmware.c
+++ b/arch/x86/kernel/cpu/vmware.c
@@ -24,10 +24,15 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
+
+#undef pr_fmt
+#define pr_fmt(fmt)"vmware: " fmt
 
 #define CPUID_VMWARE_INFO_LEAF 0x4000
 #define VMWARE_HYPERVISOR_MAGIC0x564D5868
@@ -62,10 +67,46 @@ static unsigned long vmware_get_tsc_khz(void)
 }
 
 #ifdef CONFIG_PARAVIRT
+static struct cyc2ns_data vmware_cyc2ns __ro_after_init;
+static int vmw_sched_clock __initdata = 1;
+
+static __init int setup_vmw_sched_clock(char *s)
+{
+   vmw_sched_clock = 0;
+   return 0;
+}
+early_param("no-vmw-sched-clock", setup_vmw_sched_clock);
+
+static unsigned long long vmware_sched_clock(void)
+{
+   unsigned long long ns;
+
+   ns = mul_u64_u32_shr(rdtsc(), vmware_cyc2ns.cyc2ns_mul,
+vmware_cyc2ns.cyc2ns_shift);
+   ns -= vmware_cyc2ns.cyc2ns_offset;
+   return ns;
+}
+
 static void __init vmware_paravirt_ops_setup(void)
 {
pv_info.name = "VMware";
pv_cpu_ops.io_delay = paravirt_nop;
+
+   if (vmware_tsc_khz && vmw_sched_clock) {
+   unsigned long long tsc_now = rdtsc();
+
+   clocks_calc_mult_shift(_cyc2ns.cyc2ns_mul,
+  _cyc2ns.cyc2ns_shift,
+  vmware_tsc_khz,
+  NSEC_PER_MSEC, 0);
+   vmware_cyc2ns.cyc2ns_offset =
+   mul_u64_u32_shr(tsc_now, vmware_cyc2ns.cyc2ns_mul,
+   vmware_cyc2ns.cyc2ns_shift);
+
+   pv_time_ops.sched_clock = vmware_sched_clock;
+   pr_info("using sched offset of %llu ns\n",
+   vmware_cyc2ns.cyc2ns_offset);
+   }
 }
 #else
 #define vmware_paravirt_ops_setup() do {} while (0)
-- 
2.10.1

[PATCH v2 3/3] x86/vmware: Add paravirt sched clock

[Alexey Makhalov]

Set pv_time_ops.sched_clock to vmware_sched_clock(). It is simplified
version of native_sched_clock() without ring buffer of mult/shift/offset
triplets and preempt toggling.
Since VMware hypervisor provides constant tsc we can use constant
mult/shift/offset triplet calculated at boot time.

no-vmw-sched-clock kernel parameter is added to disable the paravirt
sched clock.

Signed-off-by: Alexey Makhalov 
Acked-by: Alok N Kataria 
---
 Documentation/kernel-parameters.txt |  4 
 arch/x86/kernel/cpu/vmware.c| 41 +
 2 files changed, 45 insertions(+)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 37babf9..b3b2ec0 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2754,6 +2754,10 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
no-kvmapf   [X86,KVM] Disable paravirtualized asynchronous page
fault handling.
 
+   no-vmw-sched-clock
+   [X86,PV_OPS] Disable paravirtualized VMware scheduler
+   clock and use the default one.
+
no-steal-acc[X86,KVM] Disable paravirtualized steal time accounting.
steal time is computed, but won't influence scheduler
behaviour
diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index e3fb320..e284ebf 100644
--- a/arch/x86/kernel/cpu/vmware.c
+++ b/arch/x86/kernel/cpu/vmware.c
@@ -24,10 +24,15 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
+
+#undef pr_fmt
+#define pr_fmt(fmt)"vmware: " fmt
 
 #define CPUID_VMWARE_INFO_LEAF 0x4000
 #define VMWARE_HYPERVISOR_MAGIC0x564D5868
@@ -62,10 +67,46 @@ static unsigned long vmware_get_tsc_khz(void)
 }
 
 #ifdef CONFIG_PARAVIRT
+static struct cyc2ns_data vmware_cyc2ns __ro_after_init;
+static int vmw_sched_clock __initdata = 1;
+
+static __init int setup_vmw_sched_clock(char *s)
+{
+   vmw_sched_clock = 0;
+   return 0;
+}
+early_param("no-vmw-sched-clock", setup_vmw_sched_clock);
+
+static unsigned long long vmware_sched_clock(void)
+{
+   unsigned long long ns;
+
+   ns = mul_u64_u32_shr(rdtsc(), vmware_cyc2ns.cyc2ns_mul,
+vmware_cyc2ns.cyc2ns_shift);
+   ns -= vmware_cyc2ns.cyc2ns_offset;
+   return ns;
+}
+
 static void __init vmware_paravirt_ops_setup(void)
 {
pv_info.name = "VMware";
pv_cpu_ops.io_delay = paravirt_nop;
+
+   if (vmware_tsc_khz && vmw_sched_clock) {
+   unsigned long long tsc_now = rdtsc();
+
+   clocks_calc_mult_shift(_cyc2ns.cyc2ns_mul,
+  _cyc2ns.cyc2ns_shift,
+  vmware_tsc_khz,
+  NSEC_PER_MSEC, 0);
+   vmware_cyc2ns.cyc2ns_offset =
+   mul_u64_u32_shr(tsc_now, vmware_cyc2ns.cyc2ns_mul,
+   vmware_cyc2ns.cyc2ns_shift);
+
+   pv_time_ops.sched_clock = vmware_sched_clock;
+   pr_info("using sched offset of %llu ns\n",
+   vmware_cyc2ns.cyc2ns_offset);
+   }
 }
 #else
 #define vmware_paravirt_ops_setup() do {} while (0)
-- 
2.10.1

Re: [PATCH] drm/i915/vlv: Prevent enabling hpd polling in late suspend

[Ville Syrjälä]

On Wed, Oct 26, 2016 at 12:36:09PM -0400, Lyude wrote:
> One of the CI machines began to run into issues with the hpd poller
> suddenly waking up in the midst of the late suspend phase. It looks like
> this is getting caused by the fact we now deinitialize power wells in
> late suspend, which means that intel_hpd_poll_init() gets called in late
> suspend causing polling to get re-enabled. So, when deinitializing power
> wells on valleyview we now refrain from enabling polling in the midst of
> suspend.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98040
> Fixes: 19625e85c6ec ("drm/i915: Enable polling when we don't have hpd")
> Signed-off-by: Lyude 
> Cc: Ville Syrjälä 
> Cc: Jani Saarinen 
> Cc: Petry Latvala 
> ---
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 82edba2..ac85482 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -1138,7 +1138,9 @@ static void vlv_display_power_well_deinit(struct 
> drm_i915_private *dev_priv)
>  
>   intel_power_sequencer_reset(dev_priv);
>  
> - intel_hpd_poll_init(dev_priv);
> + /* Prevent us from re-enabling polling on accident in late suspend */
> + if (!dev_priv->drm.dev->power.is_suspended)
> + intel_hpd_poll_init(dev_priv);

The flag would appear to get set between suspend and suspend_late, so
looks like this should be sufficient for our purposes.

Reviewed-by: Ville Syrjälä 

>  }
>  
>  static void vlv_display_power_well_enable(struct drm_i915_private *dev_priv,
> -- 
> 2.7.4

-- 
Ville Syrjälä
Intel OTC

Re: [PATCH] drm/i915/vlv: Prevent enabling hpd polling in late suspend

[Ville Syrjälä]

On Wed, Oct 26, 2016 at 12:36:09PM -0400, Lyude wrote:
> One of the CI machines began to run into issues with the hpd poller
> suddenly waking up in the midst of the late suspend phase. It looks like
> this is getting caused by the fact we now deinitialize power wells in
> late suspend, which means that intel_hpd_poll_init() gets called in late
> suspend causing polling to get re-enabled. So, when deinitializing power
> wells on valleyview we now refrain from enabling polling in the midst of
> suspend.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98040
> Fixes: 19625e85c6ec ("drm/i915: Enable polling when we don't have hpd")
> Signed-off-by: Lyude 
> Cc: Ville Syrjälä 
> Cc: Jani Saarinen 
> Cc: Petry Latvala 
> ---
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 82edba2..ac85482 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -1138,7 +1138,9 @@ static void vlv_display_power_well_deinit(struct 
> drm_i915_private *dev_priv)
>  
>   intel_power_sequencer_reset(dev_priv);
>  
> - intel_hpd_poll_init(dev_priv);
> + /* Prevent us from re-enabling polling on accident in late suspend */
> + if (!dev_priv->drm.dev->power.is_suspended)
> + intel_hpd_poll_init(dev_priv);

The flag would appear to get set between suspend and suspend_late, so
looks like this should be sufficient for our purposes.

Reviewed-by: Ville Syrjälä 

>  }
>  
>  static void vlv_display_power_well_enable(struct drm_i915_private *dev_priv,
> -- 
> 2.7.4

-- 
Ville Syrjälä
Intel OTC

Re: bio linked list corruption.

[Linus Torvalds]

On Wed, Oct 26, 2016 at 9:30 AM, Dave Jones  wrote:
>
> I gave this a go last thing last night. It crashed within 5 minutes,
> but it was one we've already seen (the bad page map trace) with nothing
> additional that looked interesting.

Did the bad page map trace have any registers that looked like they
had 0xd0d0d0d0d0d0 in them?

I assume not, but worth checking.

> Heisenbugs man, literally the worst.

I know you already had this in some email, but I lost it. I think you
narrowed it down to a specific set of system calls that seems to
trigger this best. fallocate and xattrs or something?

  Linus

Re: bio linked list corruption.

[Linus Torvalds]

On Wed, Oct 26, 2016 at 9:30 AM, Dave Jones  wrote:
>
> I gave this a go last thing last night. It crashed within 5 minutes,
> but it was one we've already seen (the bad page map trace) with nothing
> additional that looked interesting.

Did the bad page map trace have any registers that looked like they
had 0xd0d0d0d0d0d0 in them?

I assume not, but worth checking.

> Heisenbugs man, literally the worst.

I know you already had this in some email, but I lost it. I think you
narrowed it down to a specific set of system calls that seems to
trigger this best. fallocate and xattrs or something?

  Linus

Re: [PATCH v7] spi: sun4i: Allow transfers larger than FIFO size

[Mark Brown]

On Wed, Oct 26, 2016 at 09:06:31AM -0700, Alex Gagniuc wrote:

> Thanks for the heads up! Sorry about that. Do you want me to resend
> this as a single mail?

It's fine, no need.


signature.asc
Description: PGP signature

Re: [PATCH v7] spi: sun4i: Allow transfers larger than FIFO size

[Mark Brown]

On Wed, Oct 26, 2016 at 09:06:31AM -0700, Alex Gagniuc wrote:

> Thanks for the heads up! Sorry about that. Do you want me to resend
> this as a single mail?

It's fine, no need.


signature.asc
Description: PGP signature

Re: [PATCH] objtool: fix rare switch jump table pattern detection

[Josh Poimboeuf]

On Wed, Oct 26, 2016 at 06:03:44PM +0200, Arnd Bergmann wrote:
> On Wednesday, October 26, 2016 10:34:08 AM CEST Josh Poimboeuf wrote:
> > The following commit:
> > 
> >   3732710ff6f2 ("objtool: Improve rare switch jump table pattern detection")
> > 
> > ... improved objtool's ability to detect gcc switch statement jump
> > tables for gcc 6.  However the check to allow short jumps with the
> > scanned range of instructions wasn't quite right.  The pattern detection
> > should allow jumps to the indirect jump instruction itself.
> > 
> > This fixes the following warning:
> > 
> >   drivers/infiniband/sw/rxe/rxe_comp.o: warning: objtool: 
> > rxe_completer()+0x315: sibling call from callable instruction with changed 
> > frame pointer
> > 
> > Reported-by: Arnd Bergmann 
> > Fixes: 3732710ff6f2 ("objtool: Improve rare switch jump table pattern 
> > detection")
> > Signed-off-by: Josh Poimboeuf 
> 
> Tested-by: Arnd Bergmann 
> 
> It fixes the mlx4/resource_tracker.o problem, but not the other
> one for ttusb-dec/ttusb_dec.o, as you mentioned.
> 
> Do you need any more help creating a testcase for that one?

No, I can recreate the ttusb_dec.o warning with the config you gave me
for this one.  Thanks!

-- 
Josh

Re: [PATCH] objtool: fix rare switch jump table pattern detection

[Josh Poimboeuf]

On Wed, Oct 26, 2016 at 06:03:44PM +0200, Arnd Bergmann wrote:
> On Wednesday, October 26, 2016 10:34:08 AM CEST Josh Poimboeuf wrote:
> > The following commit:
> > 
> >   3732710ff6f2 ("objtool: Improve rare switch jump table pattern detection")
> > 
> > ... improved objtool's ability to detect gcc switch statement jump
> > tables for gcc 6.  However the check to allow short jumps with the
> > scanned range of instructions wasn't quite right.  The pattern detection
> > should allow jumps to the indirect jump instruction itself.
> > 
> > This fixes the following warning:
> > 
> >   drivers/infiniband/sw/rxe/rxe_comp.o: warning: objtool: 
> > rxe_completer()+0x315: sibling call from callable instruction with changed 
> > frame pointer
> > 
> > Reported-by: Arnd Bergmann 
> > Fixes: 3732710ff6f2 ("objtool: Improve rare switch jump table pattern 
> > detection")
> > Signed-off-by: Josh Poimboeuf 
> 
> Tested-by: Arnd Bergmann 
> 
> It fixes the mlx4/resource_tracker.o problem, but not the other
> one for ttusb-dec/ttusb_dec.o, as you mentioned.
> 
> Do you need any more help creating a testcase for that one?

No, I can recreate the ttusb_dec.o warning with the config you gave me
for this one.  Thanks!

-- 
Josh

Re: [PATCH v2 2/3] phy: da8xx-usb: Configure CFGCHIP2 to support OTG workaround

[Alexandre Bailon]

On 10/26/2016 05:40 PM, David Lechner wrote:
> On 10/26/2016 05:58 AM, Alexandre Bailon wrote:
>> If we configure the da8xx OTG phy in OTG mode, neither device or host
>> mode will work. That is because the PHY is not able to detect and notify
>> the driver that value of ID pin changed.
>> To work despite this hardware limitation, the da8xx glue implement a
>> workaround.
>> But to work, the workaround require the VBUS sense and the session end
>> comparator to enabled.
>> Enable them if the phy is configured in OTG mode.
>>
>> Signed-off-by: Alexandre Bailon 
>> ---
>>  drivers/phy/phy-da8xx-usb.c | 17 -
>>  1 file changed, 12 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/phy/phy-da8xx-usb.c b/drivers/phy/phy-da8xx-usb.c
>> index 32ae78c..fd39292 100644
>> --- a/drivers/phy/phy-da8xx-usb.c
>> +++ b/drivers/phy/phy-da8xx-usb.c
>> @@ -93,24 +93,31 @@ static int da8xx_usb20_phy_power_off(struct phy *phy)
>>  static int da8xx_usb20_phy_set_mode(struct phy *phy, enum phy_mode mode)
>>  {
>>  struct da8xx_usb_phy *d_phy = phy_get_drvdata(phy);
>> +int ret;
>>  u32 val;
>>
>> +ret = regmap_read(d_phy->regmap, CFGCHIP(2), );
>> +if (ret)
>> +return ret;
>> +
>> +val &= ~CFGCHIP2_OTGMODE_MASK;
>> +
>>  switch (mode) {
>>  case PHY_MODE_USB_HOST:/* Force VBUS valid, ID = 0 */
>> -val = CFGCHIP2_OTGMODE_FORCE_HOST;
>> +val |= CFGCHIP2_OTGMODE_FORCE_HOST;
>>  break;
>>  case PHY_MODE_USB_DEVICE:/* Force VBUS valid, ID = 1 */
>> -val = CFGCHIP2_OTGMODE_FORCE_DEVICE;
>> +val |= CFGCHIP2_OTGMODE_FORCE_DEVICE;
>>  break;
>>  case PHY_MODE_USB_OTG:/* Don't override the VBUS/ID
>> comparators */
>> -val = CFGCHIP2_OTGMODE_NO_OVERRIDE;
>> +val |= CFGCHIP2_OTGMODE_NO_OVERRIDE |
>> +CFGCHIP2_SESENDEN | CFGCHIP2_VBDTCTEN;
> 
> The AM1808 TRM indicates that CFGCHIP2_SESENDEN and CFGCHIP2_VBDTCTEN
> (and CFGCHIP2_DATPOL) should be on for normal operation of the USB 2.0
> PHY. They do not appear to be associated with the OTG mode specifically.
I agree but the function assigned to these bit is highly tied to OTG.
And in TI BSP, there is a comment that let me think that is only needed
for OTG.
/*
 * We have to override VBUS/ID signals when MUSB is configured into the
 * host-only mode -- ID pin will float if no cable is connected, so the
 * controller won't be able to drive VBUS thinking that it's a B-device.
 * Otherwise, we want to use the OTG mode and enable VBUS comparators.
 */
cfgchip2 &= ~CFGCHIP2_OTGMODE;
#ifdef  CONFIG_USB_MUSB_HOST
cfgchip2 |=  CFGCHIP2_FORCE_HOST;
#else
cfgchip2 |=  CFGCHIP2_SESENDEN | CFGCHIP2_VBDTCTEN;
#endif
> 
> It seems to me that it would be more appropriate to set these in
> da8xx_usb20_phy_power_on() instead of here in da8xx_usb20_phy_set_mode().
I tried both the phy forced in device or host mode with theses bit set
or clear and I haven't see any issues, so I think we could set them in
da8xx_usb20_phy_power_on() as you suggested.
> 
> 
>>  break;
>>  default:
>>  return -EINVAL;
>>  }
>>
>> -regmap_write_bits(d_phy->regmap, CFGCHIP(2), CFGCHIP2_OTGMODE_MASK,
>> -  val);
>> +regmap_write(d_phy->regmap, CFGCHIP(2), val);
>>
>>  return 0;
>>  }
>>
> 
> Also cc'ing phy maintainer since this is a phy driver.
> 
> 

Re: [PATCH v2 2/3] phy: da8xx-usb: Configure CFGCHIP2 to support OTG workaround

[Alexandre Bailon]

On 10/26/2016 05:40 PM, David Lechner wrote:
> On 10/26/2016 05:58 AM, Alexandre Bailon wrote:
>> If we configure the da8xx OTG phy in OTG mode, neither device or host
>> mode will work. That is because the PHY is not able to detect and notify
>> the driver that value of ID pin changed.
>> To work despite this hardware limitation, the da8xx glue implement a
>> workaround.
>> But to work, the workaround require the VBUS sense and the session end
>> comparator to enabled.
>> Enable them if the phy is configured in OTG mode.
>>
>> Signed-off-by: Alexandre Bailon 
>> ---
>>  drivers/phy/phy-da8xx-usb.c | 17 -
>>  1 file changed, 12 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/phy/phy-da8xx-usb.c b/drivers/phy/phy-da8xx-usb.c
>> index 32ae78c..fd39292 100644
>> --- a/drivers/phy/phy-da8xx-usb.c
>> +++ b/drivers/phy/phy-da8xx-usb.c
>> @@ -93,24 +93,31 @@ static int da8xx_usb20_phy_power_off(struct phy *phy)
>>  static int da8xx_usb20_phy_set_mode(struct phy *phy, enum phy_mode mode)
>>  {
>>  struct da8xx_usb_phy *d_phy = phy_get_drvdata(phy);
>> +int ret;
>>  u32 val;
>>
>> +ret = regmap_read(d_phy->regmap, CFGCHIP(2), );
>> +if (ret)
>> +return ret;
>> +
>> +val &= ~CFGCHIP2_OTGMODE_MASK;
>> +
>>  switch (mode) {
>>  case PHY_MODE_USB_HOST:/* Force VBUS valid, ID = 0 */
>> -val = CFGCHIP2_OTGMODE_FORCE_HOST;
>> +val |= CFGCHIP2_OTGMODE_FORCE_HOST;
>>  break;
>>  case PHY_MODE_USB_DEVICE:/* Force VBUS valid, ID = 1 */
>> -val = CFGCHIP2_OTGMODE_FORCE_DEVICE;
>> +val |= CFGCHIP2_OTGMODE_FORCE_DEVICE;
>>  break;
>>  case PHY_MODE_USB_OTG:/* Don't override the VBUS/ID
>> comparators */
>> -val = CFGCHIP2_OTGMODE_NO_OVERRIDE;
>> +val |= CFGCHIP2_OTGMODE_NO_OVERRIDE |
>> +CFGCHIP2_SESENDEN | CFGCHIP2_VBDTCTEN;
> 
> The AM1808 TRM indicates that CFGCHIP2_SESENDEN and CFGCHIP2_VBDTCTEN
> (and CFGCHIP2_DATPOL) should be on for normal operation of the USB 2.0
> PHY. They do not appear to be associated with the OTG mode specifically.
I agree but the function assigned to these bit is highly tied to OTG.
And in TI BSP, there is a comment that let me think that is only needed
for OTG.
/*
 * We have to override VBUS/ID signals when MUSB is configured into the
 * host-only mode -- ID pin will float if no cable is connected, so the
 * controller won't be able to drive VBUS thinking that it's a B-device.
 * Otherwise, we want to use the OTG mode and enable VBUS comparators.
 */
cfgchip2 &= ~CFGCHIP2_OTGMODE;
#ifdef  CONFIG_USB_MUSB_HOST
cfgchip2 |=  CFGCHIP2_FORCE_HOST;
#else
cfgchip2 |=  CFGCHIP2_SESENDEN | CFGCHIP2_VBDTCTEN;
#endif
> 
> It seems to me that it would be more appropriate to set these in
> da8xx_usb20_phy_power_on() instead of here in da8xx_usb20_phy_set_mode().
I tried both the phy forced in device or host mode with theses bit set
or clear and I haven't see any issues, so I think we could set them in
da8xx_usb20_phy_power_on() as you suggested.
> 
> 
>>  break;
>>  default:
>>  return -EINVAL;
>>  }
>>
>> -regmap_write_bits(d_phy->regmap, CFGCHIP(2), CFGCHIP2_OTGMODE_MASK,
>> -  val);
>> +regmap_write(d_phy->regmap, CFGCHIP(2), val);
>>
>>  return 0;
>>  }
>>
> 
> Also cc'ing phy maintainer since this is a phy driver.
> 
> 

[PATCH] cpufreq: dt: add Socionext UniPhier SoCs support

[Masahiro Yamada]

Add compatible strings for Pro5, PXs2, LD6b, LD11, LD20 SoCs to use
the generic cpufreq driver.

Signed-off-by: Masahiro Yamada 
---

 drivers/cpufreq/cpufreq-dt-platdev.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c 
b/drivers/cpufreq/cpufreq-dt-platdev.c
index 7126762..f3c9a0e 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -72,6 +72,12 @@
 
{ .compatible = "sigma,tango4" },
 
+   { .compatible = "socionext,uniphier-pro5", },
+   { .compatible = "socionext,uniphier-pxs2", },
+   { .compatible = "socionext,uniphier-ld6b", },
+   { .compatible = "socionext,uniphier-ld11", },
+   { .compatible = "socionext,uniphier-ld20", },
+
{ .compatible = "ti,am33xx", },
{ .compatible = "ti,dra7", },
{ .compatible = "ti,omap2", },
-- 
1.9.1

[PATCH] cpufreq: dt: add Socionext UniPhier SoCs support

[Masahiro Yamada]

Add compatible strings for Pro5, PXs2, LD6b, LD11, LD20 SoCs to use
the generic cpufreq driver.

Signed-off-by: Masahiro Yamada 
---

 drivers/cpufreq/cpufreq-dt-platdev.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c 
b/drivers/cpufreq/cpufreq-dt-platdev.c
index 7126762..f3c9a0e 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -72,6 +72,12 @@
 
{ .compatible = "sigma,tango4" },
 
+   { .compatible = "socionext,uniphier-pro5", },
+   { .compatible = "socionext,uniphier-pxs2", },
+   { .compatible = "socionext,uniphier-ld6b", },
+   { .compatible = "socionext,uniphier-ld11", },
+   { .compatible = "socionext,uniphier-ld20", },
+
{ .compatible = "ti,am33xx", },
{ .compatible = "ti,dra7", },
{ .compatible = "ti,omap2", },
-- 
1.9.1

Re: [RFC PATCH 4/5] w1: add a callback to call slave when a new device is connected

[Mathieu Poirier]

On 26 October 2016 at 08:57, Antoine Tenart
 wrote:
> This patch adds the possibility for slave drivers to register a
> callback, to be called whenever a new device matching the slave ID
> is connected.
>
> Signed-off-by: Antoine Tenart 
> ---
>  drivers/w1/w1.c| 10 ++
>  drivers/w1/w1_family.h |  2 ++
>  2 files changed, 12 insertions(+)
>
> diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
> index 80d0cc4e6e7f..7010ffd1ea93 100644
> --- a/drivers/w1/w1.c
> +++ b/drivers/w1/w1.c
> @@ -659,6 +659,16 @@ static int w1_family_notify(unsigned long action, struct 
> w1_slave *sl)
> return err;
> }
> }
> +   if (fops->callback) {
> +   err = fops->callback(sl);
> +   /*
> +* Do not return an error as the slave driver 
> correctly
> +* probed.
> +*/

I don't get this part.  What's the point of calling a callback if a
failure is not important - maybe I'm just missing something.

> +   if (err)
> +   dev_err(>dev,
> +   "callback call failed. err=%d\n", 
> err);
> +   }
>
> break;
> case BUS_NOTIFY_DEL_DEVICE:
> diff --git a/drivers/w1/w1_family.h b/drivers/w1/w1_family.h
> index 10a7a0767187..5e165babc6f3 100644
> --- a/drivers/w1/w1_family.h
> +++ b/drivers/w1/w1_family.h
> @@ -55,11 +55,13 @@ struct w1_slave;
>   * @add_slave: add_slave
>   * @remove_slave: remove_slave
>   * @groups: sysfs group
> + * @callback: called when a new device is discovered
>   */
>  struct w1_family_ops
>  {
> int  (* add_slave)(struct w1_slave *);
> void (* remove_slave)(struct w1_slave *);
> +   int  (* callback)(struct w1_slave *);
> const struct attribute_group **groups;
>  };
>
> --
> 2.10.1
>

Re: [RFC PATCH 4/5] w1: add a callback to call slave when a new device is connected

[Mathieu Poirier]

On 26 October 2016 at 08:57, Antoine Tenart
 wrote:
> This patch adds the possibility for slave drivers to register a
> callback, to be called whenever a new device matching the slave ID
> is connected.
>
> Signed-off-by: Antoine Tenart 
> ---
>  drivers/w1/w1.c| 10 ++
>  drivers/w1/w1_family.h |  2 ++
>  2 files changed, 12 insertions(+)
>
> diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
> index 80d0cc4e6e7f..7010ffd1ea93 100644
> --- a/drivers/w1/w1.c
> +++ b/drivers/w1/w1.c
> @@ -659,6 +659,16 @@ static int w1_family_notify(unsigned long action, struct 
> w1_slave *sl)
> return err;
> }
> }
> +   if (fops->callback) {
> +   err = fops->callback(sl);
> +   /*
> +* Do not return an error as the slave driver 
> correctly
> +* probed.
> +*/

I don't get this part.  What's the point of calling a callback if a
failure is not important - maybe I'm just missing something.

> +   if (err)
> +   dev_err(>dev,
> +   "callback call failed. err=%d\n", 
> err);
> +   }
>
> break;
> case BUS_NOTIFY_DEL_DEVICE:
> diff --git a/drivers/w1/w1_family.h b/drivers/w1/w1_family.h
> index 10a7a0767187..5e165babc6f3 100644
> --- a/drivers/w1/w1_family.h
> +++ b/drivers/w1/w1_family.h
> @@ -55,11 +55,13 @@ struct w1_slave;
>   * @add_slave: add_slave
>   * @remove_slave: remove_slave
>   * @groups: sysfs group
> + * @callback: called when a new device is discovered
>   */
>  struct w1_family_ops
>  {
> int  (* add_slave)(struct w1_slave *);
> void (* remove_slave)(struct w1_slave *);
> +   int  (* callback)(struct w1_slave *);
> const struct attribute_group **groups;
>  };
>
> --
> 2.10.1
>

[PATCH 1/2] ARM: dts: uniphier: add CPU clocks and OPP table for Pro5 SoC

[Masahiro Yamada]

Add a CPU clock to every CPU node and a CPU OPP table to use the
generic cpufreq driver.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/boot/dts/uniphier-pro5.dtsi | 74 
 1 file changed, 74 insertions(+)

diff --git a/arch/arm/boot/dts/uniphier-pro5.dtsi 
b/arch/arm/boot/dts/uniphier-pro5.dtsi
index 5357ea9..5bd6068 100644
--- a/arch/arm/boot/dts/uniphier-pro5.dtsi
+++ b/arch/arm/boot/dts/uniphier-pro5.dtsi
@@ -56,16 +56,90 @@
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
+   clocks = <_clk 32>;
enable-method = "psci";
next-level-cache = <>;
+   operating-points-v2 = <_opp>;
};
 
cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
+   clocks = <_clk 32>;
enable-method = "psci";
next-level-cache = <>;
+   operating-points-v2 = <_opp>;
+   };
+   };
+
+   cpu_opp: opp_table {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@1 {
+   opp-hz = /bits/ 64 <1>;
+   clock-latency-ns = <300>;
+   };
+   opp@116667000 {
+   opp-hz = /bits/ 64 <116667000>;
+   clock-latency-ns = <300>;
+   };
+   opp@15000 {
+   opp-hz = /bits/ 64 <15000>;
+   clock-latency-ns = <300>;
+   };
+   opp@17500 {
+   opp-hz = /bits/ 64 <17500>;
+   clock-latency-ns = <300>;
+   };
+   opp@2 {
+   opp-hz = /bits/ 64 <2>;
+   clock-latency-ns = <300>;
+   };
+   opp@24000 {
+   opp-hz = /bits/ 64 <24000>;
+   clock-latency-ns = <300>;
+   };
+   opp@3 {
+   opp-hz = /bits/ 64 <3>;
+   clock-latency-ns = <300>;
+   };
+   opp@35000 {
+   opp-hz = /bits/ 64 <35000>;
+   clock-latency-ns = <300>;
+   };
+   opp@4 {
+   opp-hz = /bits/ 64 <4>;
+   clock-latency-ns = <300>;
+   };
+   opp@47000 {
+   opp-hz = /bits/ 64 <47000>;
+   clock-latency-ns = <300>;
+   };
+   opp@6 {
+   opp-hz = /bits/ 64 <6>;
+   clock-latency-ns = <300>;
+   };
+   opp@7 {
+   opp-hz = /bits/ 64 <7>;
+   clock-latency-ns = <300>;
+   };
+   opp@8 {
+   opp-hz = /bits/ 64 <8>;
+   clock-latency-ns = <300>;
+   };
+   opp@94000 {
+   opp-hz = /bits/ 64 <94000>;
+   clock-latency-ns = <300>;
+   };
+   opp@12 {
+   opp-hz = /bits/ 64 <12>;
+   clock-latency-ns = <300>;
+   };
+   opp@14 {
+   opp-hz = /bits/ 64 <14>;
+   clock-latency-ns = <300>;
};
};
 
-- 
1.9.1

[PATCH 2/2] ARM: dts: uniphier: add CPU clocks and OPP table for PXs2 SoC

[Masahiro Yamada]

Add a CPU clock to every CPU node and a CPU OPP table to use the
generic cpufreq driver.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/boot/dts/uniphier-pxs2.dtsi | 46 
 1 file changed, 46 insertions(+)

diff --git a/arch/arm/boot/dts/uniphier-pxs2.dtsi 
b/arch/arm/boot/dts/uniphier-pxs2.dtsi
index 950f07b..83ba3e6 100644
--- a/arch/arm/boot/dts/uniphier-pxs2.dtsi
+++ b/arch/arm/boot/dts/uniphier-pxs2.dtsi
@@ -56,32 +56,78 @@
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
+   clocks = <_clk 32>;
enable-method = "psci";
next-level-cache = <>;
+   operating-points-v2 = <_opp>;
};
 
cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
+   clocks = <_clk 32>;
enable-method = "psci";
next-level-cache = <>;
+   operating-points-v2 = <_opp>;
};
 
cpu@2 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <2>;
+   clocks = <_clk 32>;
enable-method = "psci";
next-level-cache = <>;
+   operating-points-v2 = <_opp>;
};
 
cpu@3 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <3>;
+   clocks = <_clk 32>;
enable-method = "psci";
next-level-cache = <>;
+   operating-points-v2 = <_opp>;
+   };
+   };
+
+   cpu_opp: opp_table {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@1 {
+   opp-hz = /bits/ 64 <1>;
+   clock-latency-ns = <300>;
+   };
+   opp@15000 {
+   opp-hz = /bits/ 64 <15000>;
+   clock-latency-ns = <300>;
+   };
+   opp@2 {
+   opp-hz = /bits/ 64 <2>;
+   clock-latency-ns = <300>;
+   };
+   opp@3 {
+   opp-hz = /bits/ 64 <3>;
+   clock-latency-ns = <300>;
+   };
+   opp@4 {
+   opp-hz = /bits/ 64 <4>;
+   clock-latency-ns = <300>;
+   };
+   opp@6 {
+   opp-hz = /bits/ 64 <6>;
+   clock-latency-ns = <300>;
+   };
+   opp@8 {
+   opp-hz = /bits/ 64 <8>;
+   clock-latency-ns = <300>;
+   };
+   opp@12 {
+   opp-hz = /bits/ 64 <12>;
+   clock-latency-ns = <300>;
};
};
 
-- 
1.9.1

[PATCH 1/2] ARM: dts: uniphier: add CPU clocks and OPP table for Pro5 SoC

[Masahiro Yamada]

Add a CPU clock to every CPU node and a CPU OPP table to use the
generic cpufreq driver.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/boot/dts/uniphier-pro5.dtsi | 74 
 1 file changed, 74 insertions(+)

diff --git a/arch/arm/boot/dts/uniphier-pro5.dtsi 
b/arch/arm/boot/dts/uniphier-pro5.dtsi
index 5357ea9..5bd6068 100644
--- a/arch/arm/boot/dts/uniphier-pro5.dtsi
+++ b/arch/arm/boot/dts/uniphier-pro5.dtsi
@@ -56,16 +56,90 @@
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
+   clocks = <_clk 32>;
enable-method = "psci";
next-level-cache = <>;
+   operating-points-v2 = <_opp>;
};
 
cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
+   clocks = <_clk 32>;
enable-method = "psci";
next-level-cache = <>;
+   operating-points-v2 = <_opp>;
+   };
+   };
+
+   cpu_opp: opp_table {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@1 {
+   opp-hz = /bits/ 64 <1>;
+   clock-latency-ns = <300>;
+   };
+   opp@116667000 {
+   opp-hz = /bits/ 64 <116667000>;
+   clock-latency-ns = <300>;
+   };
+   opp@15000 {
+   opp-hz = /bits/ 64 <15000>;
+   clock-latency-ns = <300>;
+   };
+   opp@17500 {
+   opp-hz = /bits/ 64 <17500>;
+   clock-latency-ns = <300>;
+   };
+   opp@2 {
+   opp-hz = /bits/ 64 <2>;
+   clock-latency-ns = <300>;
+   };
+   opp@24000 {
+   opp-hz = /bits/ 64 <24000>;
+   clock-latency-ns = <300>;
+   };
+   opp@3 {
+   opp-hz = /bits/ 64 <3>;
+   clock-latency-ns = <300>;
+   };
+   opp@35000 {
+   opp-hz = /bits/ 64 <35000>;
+   clock-latency-ns = <300>;
+   };
+   opp@4 {
+   opp-hz = /bits/ 64 <4>;
+   clock-latency-ns = <300>;
+   };
+   opp@47000 {
+   opp-hz = /bits/ 64 <47000>;
+   clock-latency-ns = <300>;
+   };
+   opp@6 {
+   opp-hz = /bits/ 64 <6>;
+   clock-latency-ns = <300>;
+   };
+   opp@7 {
+   opp-hz = /bits/ 64 <7>;
+   clock-latency-ns = <300>;
+   };
+   opp@8 {
+   opp-hz = /bits/ 64 <8>;
+   clock-latency-ns = <300>;
+   };
+   opp@94000 {
+   opp-hz = /bits/ 64 <94000>;
+   clock-latency-ns = <300>;
+   };
+   opp@12 {
+   opp-hz = /bits/ 64 <12>;
+   clock-latency-ns = <300>;
+   };
+   opp@14 {
+   opp-hz = /bits/ 64 <14>;
+   clock-latency-ns = <300>;
};
};
 
-- 
1.9.1

[PATCH 2/2] ARM: dts: uniphier: add CPU clocks and OPP table for PXs2 SoC

[Masahiro Yamada]

Add a CPU clock to every CPU node and a CPU OPP table to use the
generic cpufreq driver.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/boot/dts/uniphier-pxs2.dtsi | 46 
 1 file changed, 46 insertions(+)

diff --git a/arch/arm/boot/dts/uniphier-pxs2.dtsi 
b/arch/arm/boot/dts/uniphier-pxs2.dtsi
index 950f07b..83ba3e6 100644
--- a/arch/arm/boot/dts/uniphier-pxs2.dtsi
+++ b/arch/arm/boot/dts/uniphier-pxs2.dtsi
@@ -56,32 +56,78 @@
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
+   clocks = <_clk 32>;
enable-method = "psci";
next-level-cache = <>;
+   operating-points-v2 = <_opp>;
};
 
cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
+   clocks = <_clk 32>;
enable-method = "psci";
next-level-cache = <>;
+   operating-points-v2 = <_opp>;
};
 
cpu@2 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <2>;
+   clocks = <_clk 32>;
enable-method = "psci";
next-level-cache = <>;
+   operating-points-v2 = <_opp>;
};
 
cpu@3 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <3>;
+   clocks = <_clk 32>;
enable-method = "psci";
next-level-cache = <>;
+   operating-points-v2 = <_opp>;
+   };
+   };
+
+   cpu_opp: opp_table {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@1 {
+   opp-hz = /bits/ 64 <1>;
+   clock-latency-ns = <300>;
+   };
+   opp@15000 {
+   opp-hz = /bits/ 64 <15000>;
+   clock-latency-ns = <300>;
+   };
+   opp@2 {
+   opp-hz = /bits/ 64 <2>;
+   clock-latency-ns = <300>;
+   };
+   opp@3 {
+   opp-hz = /bits/ 64 <3>;
+   clock-latency-ns = <300>;
+   };
+   opp@4 {
+   opp-hz = /bits/ 64 <4>;
+   clock-latency-ns = <300>;
+   };
+   opp@6 {
+   opp-hz = /bits/ 64 <6>;
+   clock-latency-ns = <300>;
+   };
+   opp@8 {
+   opp-hz = /bits/ 64 <8>;
+   clock-latency-ns = <300>;
+   };
+   opp@12 {
+   opp-hz = /bits/ 64 <12>;
+   clock-latency-ns = <300>;
};
};
 
-- 
1.9.1

Re: [RFC PATCH 3/5] w1: report errors returned by w1_family_notify

[Mathieu Poirier]

On 26 October 2016 at 08:57, Antoine Tenart
 wrote:

GKH won't accept an empty commit log.

> Signed-off-by: Antoine Tenart 
> ---
>  drivers/w1/w1.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
> index bb34362e930a..80d0cc4e6e7f 100644
> --- a/drivers/w1/w1.c
> +++ b/drivers/w1/w1.c
> @@ -702,7 +702,9 @@ static int __w1_attach_slave_device(struct w1_slave *sl)
> dev_name(>dev), err);
> return err;
> }
> -   w1_family_notify(BUS_NOTIFY_ADD_DEVICE, sl);
> +   err = w1_family_notify(BUS_NOTIFY_ADD_DEVICE, sl);
> +   if (err)
> +   return err;
>
> dev_set_uevent_suppress(>dev, false);
> kobject_uevent(>dev.kobj, KOBJ_ADD);
> --
> 2.10.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 3/5] w1: report errors returned by w1_family_notify

[Mathieu Poirier]

On 26 October 2016 at 08:57, Antoine Tenart
 wrote:

GKH won't accept an empty commit log.

> Signed-off-by: Antoine Tenart 
> ---
>  drivers/w1/w1.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
> index bb34362e930a..80d0cc4e6e7f 100644
> --- a/drivers/w1/w1.c
> +++ b/drivers/w1/w1.c
> @@ -702,7 +702,9 @@ static int __w1_attach_slave_device(struct w1_slave *sl)
> dev_name(>dev), err);
> return err;
> }
> -   w1_family_notify(BUS_NOTIFY_ADD_DEVICE, sl);
> +   err = w1_family_notify(BUS_NOTIFY_ADD_DEVICE, sl);
> +   if (err)
> +   return err;
>
> dev_set_uevent_suppress(>dev, false);
> kobject_uevent(>dev.kobj, KOBJ_ADD);
> --
> 2.10.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/5] ARC: MCIP: Set an initial affinity value in idu_irq_map

[Marc Zyngier]

On Wed, Oct 26 2016 at 05:17:34 PM, Vineet Gupta  
wrote:
> On 10/26/2016 07:05 AM, Marc Zyngier wrote:
>> It definitely feels weird to encode the interrupt affinity in the DT
>> (the kernel and possible userspace usually know much better than the
>> firmware). What is the actual reason for storing the affinity there?
>
> The IDU intc supports various interrupt distribution modes (Round
> Robin, send to one cpu only etc) whcih in turn map to affinity
> setting. When doing the DT binding, we decided to add that this to DT
> to get the "seed" value for affinity - which user could optionally
> changed after boot. This seemed like a benign design choice at the
> time.

Right. But is this initial setting something that the kernel has to
absolutely honor? The usual behavior is to let kernel pick something
sensible, and let the user mess with it afterwards.

Is there any part of the kernel that would otherwise depend on this
affinity being set to a particular mode? If the answer is "none", then I
believe we can safely ignore that part of the binding (and maybe
deprecate it in the documentation).

Thanks,

M.
-- 
Jazz is not dead. It just smells funny.

[PATCH] drm/i915/vlv: Prevent enabling hpd polling in late suspend

[Lyude]

One of the CI machines began to run into issues with the hpd poller
suddenly waking up in the midst of the late suspend phase. It looks like
this is getting caused by the fact we now deinitialize power wells in
late suspend, which means that intel_hpd_poll_init() gets called in late
suspend causing polling to get re-enabled. So, when deinitializing power
wells on valleyview we now refrain from enabling polling in the midst of
suspend.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98040
Fixes: 19625e85c6ec ("drm/i915: Enable polling when we don't have hpd")
Signed-off-by: Lyude 
Cc: Ville Syrjälä 
Cc: Jani Saarinen 
Cc: Petry Latvala 
---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 82edba2..ac85482 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -1138,7 +1138,9 @@ static void vlv_display_power_well_deinit(struct 
drm_i915_private *dev_priv)
 
intel_power_sequencer_reset(dev_priv);
 
-   intel_hpd_poll_init(dev_priv);
+   /* Prevent us from re-enabling polling on accident in late suspend */
+   if (!dev_priv->drm.dev->power.is_suspended)
+   intel_hpd_poll_init(dev_priv);
 }
 
 static void vlv_display_power_well_enable(struct drm_i915_private *dev_priv,
-- 
2.7.4

Re: [PATCH v2 4/5] ARC: MCIP: Set an initial affinity value in idu_irq_map

[Marc Zyngier]

On Wed, Oct 26 2016 at 05:17:34 PM, Vineet Gupta  
wrote:
> On 10/26/2016 07:05 AM, Marc Zyngier wrote:
>> It definitely feels weird to encode the interrupt affinity in the DT
>> (the kernel and possible userspace usually know much better than the
>> firmware). What is the actual reason for storing the affinity there?
>
> The IDU intc supports various interrupt distribution modes (Round
> Robin, send to one cpu only etc) whcih in turn map to affinity
> setting. When doing the DT binding, we decided to add that this to DT
> to get the "seed" value for affinity - which user could optionally
> changed after boot. This seemed like a benign design choice at the
> time.

Right. But is this initial setting something that the kernel has to
absolutely honor? The usual behavior is to let kernel pick something
sensible, and let the user mess with it afterwards.

Is there any part of the kernel that would otherwise depend on this
affinity being set to a particular mode? If the answer is "none", then I
believe we can safely ignore that part of the binding (and maybe
deprecate it in the documentation).

Thanks,

M.
-- 
Jazz is not dead. It just smells funny.

[PATCH] drm/i915/vlv: Prevent enabling hpd polling in late suspend

[Lyude]

One of the CI machines began to run into issues with the hpd poller
suddenly waking up in the midst of the late suspend phase. It looks like
this is getting caused by the fact we now deinitialize power wells in
late suspend, which means that intel_hpd_poll_init() gets called in late
suspend causing polling to get re-enabled. So, when deinitializing power
wells on valleyview we now refrain from enabling polling in the midst of
suspend.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98040
Fixes: 19625e85c6ec ("drm/i915: Enable polling when we don't have hpd")
Signed-off-by: Lyude 
Cc: Ville Syrjälä 
Cc: Jani Saarinen 
Cc: Petry Latvala 
---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 82edba2..ac85482 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -1138,7 +1138,9 @@ static void vlv_display_power_well_deinit(struct 
drm_i915_private *dev_priv)
 
intel_power_sequencer_reset(dev_priv);
 
-   intel_hpd_poll_init(dev_priv);
+   /* Prevent us from re-enabling polling on accident in late suspend */
+   if (!dev_priv->drm.dev->power.is_suspended)
+   intel_hpd_poll_init(dev_priv);
 }
 
 static void vlv_display_power_well_enable(struct drm_i915_private *dev_priv,
-- 
2.7.4

Re: [PATCH v6 1/5] ARM: davinci: da8xx: add usb phy clocks

[David Lechner]

On 10/26/2016 02:59 AM, Sekhar Nori wrote:

On Wednesday 26 October 2016 08:36 AM, David Lechner wrote:

Up to this point, the USB phy clock configuration was handled manually in
the board files and in the usb drivers. This adds proper clocks so that
the usb drivers can use clk_get and clk_enable and not have to worry about
the details. Also, the related code is removed from the board files and
replaced with the new clock registration functions.

Signed-off-by: David Lechner 
Signed-off-by: Axel Haslam 
---

I have added "ARM: davinci: da8xx: Enable the usb20 "per" clk on phy_clk_enable"
from Axel Haslam to this patch.

In the review of Axel's patch, Sekhar said:


We should not be using a NULL device pointer here. Can you pass the musb
device pointer available in the same file? Also, da850_clks[] in da850.c
needs to be fixed to add the matching device name.


However, the musb device may not be registered. The usb20_clk can be used to
supply a 48MHz clock to USB 1.1 (ohci) without using the musb device. So, I am
inclined to leave this as NULL.


But clock look-up has nothing to do with device being registered AFAICT.
It is used to identify the clock consumer. Passing NULL there means the
clock is not associated with any device. Which is not correct as we are
specifically looking at MUSB module clock.

Thanks,
Sekhar



FWIW, clk_get() uses dev_name() to get the device name, which will 
return NULL until after the platform device is registered.


I can add the device references anyway. However, this is complicated by 
the fact that the musb platform device declaration is inside of an #if 
IS_ENABLED(CONFIG_USB_MUSB_HDRC). I can either remove the #if or add 
more #if's. Do you have a preference on this?

Re: [PATCH v6 1/5] ARM: davinci: da8xx: add usb phy clocks

[David Lechner]

On 10/26/2016 02:59 AM, Sekhar Nori wrote:

On Wednesday 26 October 2016 08:36 AM, David Lechner wrote:

Up to this point, the USB phy clock configuration was handled manually in
the board files and in the usb drivers. This adds proper clocks so that
the usb drivers can use clk_get and clk_enable and not have to worry about
the details. Also, the related code is removed from the board files and
replaced with the new clock registration functions.

Signed-off-by: David Lechner 
Signed-off-by: Axel Haslam 
---

I have added "ARM: davinci: da8xx: Enable the usb20 "per" clk on phy_clk_enable"
from Axel Haslam to this patch.

In the review of Axel's patch, Sekhar said:


We should not be using a NULL device pointer here. Can you pass the musb
device pointer available in the same file? Also, da850_clks[] in da850.c
needs to be fixed to add the matching device name.


However, the musb device may not be registered. The usb20_clk can be used to
supply a 48MHz clock to USB 1.1 (ohci) without using the musb device. So, I am
inclined to leave this as NULL.


But clock look-up has nothing to do with device being registered AFAICT.
It is used to identify the clock consumer. Passing NULL there means the
clock is not associated with any device. Which is not correct as we are
specifically looking at MUSB module clock.

Thanks,
Sekhar



FWIW, clk_get() uses dev_name() to get the device name, which will 
return NULL until after the platform device is registered.


I can add the device references anyway. However, this is complicated by 
the fact that the musb platform device declaration is inside of an #if 
IS_ENABLED(CONFIG_USB_MUSB_HDRC). I can either remove the #if or add 
more #if's. Do you have a preference on this?

Re: [PATCH v3 0/6] perf report: Show branch flags/cycles in --branch-history callgraph view

[Andi Kleen]

On Wed, Oct 26, 2016 at 09:23:41AM +0800, Jin, Yao wrote:
> If I change it to, for example: removed iterations: 20%
> 
> Is that OK?

No it should be average iterations, not percentage.

Also "iterations", not "removed iterations"

-Andi

Re: [PATCH v3 0/6] perf report: Show branch flags/cycles in --branch-history callgraph view

[Andi Kleen]

On Wed, Oct 26, 2016 at 09:23:41AM +0800, Jin, Yao wrote:
> If I change it to, for example: removed iterations: 20%
> 
> Is that OK?

No it should be average iterations, not percentage.

Also "iterations", not "removed iterations"

-Andi

Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit

[Linus Torvalds]

On Wed, Oct 26, 2016 at 8:51 AM, Andy Lutomirski  wrote:
>>
>> I get the following BUG with 4.9-rc2, CONFIG_VMAP_STACK and
>> CONFIG_DEBUG_VIRTUAL turned on:
>>
>>   kernel BUG at arch/x86/mm/physaddr.c:26!
>
> const struct zone *zone = page_zone(virt_to_page(word));
>
> If the stack is vmalloced, then you can't find the page's zone like
> that.  We could look it up the slow way (ick!), but maybe another
> solution would be to do:

Christ. It's that damn bit-wait craziness again with the idiotic zone lookup.

I complained about it a couple of weeks ago for entirely unrelated
reasons: it absolutely sucks donkey ass through a straw from a cache
standpoint too. It makes the page_waitqueue() thing very expensive, to
the point where it shows up as taking up 3% of CPU time on a real
load.,

PeterZ had a patch that fixed most of the performance trouble because
the page_waitqueue is actually never realistically contested, and by
making the bit-waiting use *two* bits you can avoid the slow-path cost
entirely.

But here we have a totally different issue, namely that we want to
wait on a virtual address.

Quite frankly, I think the solution is to just rip out all the insane
zone crap. The most important use (by far) for the bit-waitqueue is
for the page locking, and with the "use a second bit to show
contention", there is absolutely no reason to try to do some crazy
per-zone thing. It's a slow-path that never matters, and rather than
make things scale well, the only thing it does is to pretty much
guarantee at least one extra cache miss.

Adding MelG and the mm list to the cc (PeterZ was already there) here
just for the heads up.

   Linus

Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit

[Linus Torvalds]

On Wed, Oct 26, 2016 at 8:51 AM, Andy Lutomirski  wrote:
>>
>> I get the following BUG with 4.9-rc2, CONFIG_VMAP_STACK and
>> CONFIG_DEBUG_VIRTUAL turned on:
>>
>>   kernel BUG at arch/x86/mm/physaddr.c:26!
>
> const struct zone *zone = page_zone(virt_to_page(word));
>
> If the stack is vmalloced, then you can't find the page's zone like
> that.  We could look it up the slow way (ick!), but maybe another
> solution would be to do:

Christ. It's that damn bit-wait craziness again with the idiotic zone lookup.

I complained about it a couple of weeks ago for entirely unrelated
reasons: it absolutely sucks donkey ass through a straw from a cache
standpoint too. It makes the page_waitqueue() thing very expensive, to
the point where it shows up as taking up 3% of CPU time on a real
load.,

PeterZ had a patch that fixed most of the performance trouble because
the page_waitqueue is actually never realistically contested, and by
making the bit-waiting use *two* bits you can avoid the slow-path cost
entirely.

But here we have a totally different issue, namely that we want to
wait on a virtual address.

Quite frankly, I think the solution is to just rip out all the insane
zone crap. The most important use (by far) for the bit-waitqueue is
for the page locking, and with the "use a second bit to show
contention", there is absolutely no reason to try to do some crazy
per-zone thing. It's a slow-path that never matters, and rather than
make things scale well, the only thing it does is to pretty much
guarantee at least one extra cache miss.

Adding MelG and the mm list to the cc (PeterZ was already there) here
just for the heads up.

   Linus

Re: [RFC PATCH 1/5] of: introduce the overlay manager

[Mathieu Poirier]

Hi Antoine,

Please find my comments below.

On 26 October 2016 at 08:57, Antoine Tenart
 wrote:
> The overlay manager is an in-kernel library helping to handle dt overlay
> loading when using capes.
>
> Signed-off-by: Antoine Tenart 
> ---
>  drivers/of/Kconfig   |   2 +
>  drivers/of/Makefile  |   1 +
>  drivers/of/overlay-manager/Kconfig   |   6 +
>  drivers/of/overlay-manager/Makefile  |   1 +
>  drivers/of/overlay-manager/overlay-manager.c | 199 
> +++
>  include/linux/overlay-manager.h  |  38 +
>  6 files changed, 247 insertions(+)
>  create mode 100644 drivers/of/overlay-manager/Kconfig
>  create mode 100644 drivers/of/overlay-manager/Makefile
>  create mode 100644 drivers/of/overlay-manager/overlay-manager.c
>  create mode 100644 include/linux/overlay-manager.h
>
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index bc07ad30c9bf..e57aeaf0bf4f 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -116,4 +116,6 @@ config OF_OVERLAY
>  config OF_NUMA
> bool
>
> +source "drivers/of/overlay-manager/Kconfig"
> +
>  endif # OF
> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
> index d7efd9d458aa..d738fd41271f 100644
> --- a/drivers/of/Makefile
> +++ b/drivers/of/Makefile
> @@ -16,3 +16,4 @@ obj-$(CONFIG_OF_OVERLAY) += overlay.o
>  obj-$(CONFIG_OF_NUMA) += of_numa.o
>
>  obj-$(CONFIG_OF_UNITTEST) += unittest-data/
> +obj-y += overlay-manager/
> diff --git a/drivers/of/overlay-manager/Kconfig 
> b/drivers/of/overlay-manager/Kconfig
> new file mode 100644
> index ..eeb76054dcb8
> --- /dev/null
> +++ b/drivers/of/overlay-manager/Kconfig
> @@ -0,0 +1,6 @@
> +config OF_OVERLAY_MGR
> +   bool "Device Tree Overlay Manager"
> +   depends on OF_OVERLAY
> +   help
> + Enable the overlay manager to handle automatic overlay loading when
> + devices are detected.
> diff --git a/drivers/of/overlay-manager/Makefile 
> b/drivers/of/overlay-manager/Makefile
> new file mode 100644
> index ..86d2b53950e7
> --- /dev/null
> +++ b/drivers/of/overlay-manager/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_OF_OVERLAY_MGR)   += overlay-manager.o
> diff --git a/drivers/of/overlay-manager/overlay-manager.c 
> b/drivers/of/overlay-manager/overlay-manager.c
> new file mode 100644
> index ..a725d7e24d38
> --- /dev/null
> +++ b/drivers/of/overlay-manager/overlay-manager.c
> @@ -0,0 +1,199 @@
> +/*
> + * Copyright (C) 2016 - Antoine Tenart 
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct overlay_mgr_overlay {
> +   struct list_head list;
> +   char *name;
> +};

Please use the proper documentation format for structures.

> +
> +LIST_HEAD(overlay_mgr_overlays);
> +LIST_HEAD(overlay_mgr_formats);
> +DEFINE_SPINLOCK(overlay_mgr_lock);
> +DEFINE_SPINLOCK(overlay_mgr_format_lock);
> +
> +/*
> + * overlay_mgr_register_format()
> + *
> + * Adds a new format candidate to the list of supported formats. The 
> registered
> + * formats are used to parse the headers stored on the dips.
> + */
> +int overlay_mgr_register_format(struct overlay_mgr_format *candidate)
> +{
> +   struct overlay_mgr_format *format;
> +   int err = 0;
> +
> +   spin_lock(_mgr_format_lock);
> +
> +   /* Check if the format is already registered */
> +   list_for_each_entry(format, _mgr_formats, list) {
> +   if (!strcpy(format->name, candidate->name)) {

This function is public to the rest of the kernel - limiting the
lenght of ->name and using strncpy() is probably a good idea.

> +   err = -EEXIST;
> +   goto err;
> +   }
> +   }
> +
> +   list_add_tail(>list, _mgr_formats);
> +
> +err:
> +   spin_unlock(_mgr_format_lock);
> +   return err;
> +}
> +EXPORT_SYMBOL_GPL(overlay_mgr_register_format);
> +
> +/*
> + * overlay_mgr_parse()
> + *
> + * Parse raw data with registered format parsers. Fills the candidate string 
> if
> + * one parser understood the raw data format.
> + */
> +int overlay_mgr_parse(struct device *dev, void *data, char ***candidates,

I'm pretty sure there is another way to proceed than using 3 levels of
references.  It makes the code hard to read and a prime candidate for
errors.

> + unsigned *n)
> +{
> +   struct list_head *pos, *tmp;
> +   struct overlay_mgr_format *format;
> +
> +   list_for_each_safe(pos, tmp, _mgr_formats) {
> +   format = list_entry(pos, struct overlay_mgr_format, list);

Can you use 

[PATCH v2 04/12] staging: fsl-mc: whitespace cleanup: align function args

[Stuart Yoder]

From: Ioana Ciornei 

align function arguments that were not aligned to the starting parenthesis

Signed-off-by: Ioana Ciornei 
Signed-off-by: Stuart Yoder 
---
-v2
   -patch is result of split of original patch, updated
commit messasge to reflect the change

 drivers/staging/fsl-mc/bus/dpmcp.h| 32 
 drivers/staging/fsl-mc/include/dprc.h |  8 
 2 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/fsl-mc/bus/dpmcp.h 
b/drivers/staging/fsl-mc/bus/dpmcp.h
index c40253a..0a24c37 100644
--- a/drivers/staging/fsl-mc/bus/dpmcp.h
+++ b/drivers/staging/fsl-mc/bus/dpmcp.h
@@ -61,7 +61,7 @@ struct dpmcp_cfg {
 int dpmcp_create(struct fsl_mc_io  *mc_io,
 u32cmd_flags,
 const struct dpmcp_cfg *cfg,
-   u16 *token);
+u16*token);
 
 int dpmcp_destroy(struct fsl_mc_io *mc_io,
  u32 cmd_flags,
@@ -92,45 +92,45 @@ struct dpmcp_irq_cfg {
 int dpmcp_set_irq(struct fsl_mc_io *mc_io,
  u32   cmd_flags,
  u16   token,
-u8 irq_index,
+ u8irq_index,
  struct dpmcp_irq_cfg  *irq_cfg);
 
 int dpmcp_get_irq(struct fsl_mc_io *mc_io,
  u32   cmd_flags,
  u16   token,
-u8 irq_index,
-int*type,
-struct dpmcp_irq_cfg   *irq_cfg);
+ u8irq_index,
+ int   *type,
+ struct dpmcp_irq_cfg  *irq_cfg);
 
 int dpmcp_set_irq_enable(struct fsl_mc_io  *mc_io,
 u32cmd_flags,
 u16token,
-   u8  irq_index,
-   u8  en);
+u8 irq_index,
+u8 en);
 
 int dpmcp_get_irq_enable(struct fsl_mc_io  *mc_io,
 u32cmd_flags,
 u16token,
-   u8  irq_index,
-   u8  *en);
+u8 irq_index,
+u8 *en);
 
 int dpmcp_set_irq_mask(struct fsl_mc_io*mc_io,
   u32  cmd_flags,
   u16  token,
- u8irq_index,
- u32   mask);
+  u8   irq_index,
+  u32  mask);
 
 int dpmcp_get_irq_mask(struct fsl_mc_io*mc_io,
   u32  cmd_flags,
   u16  token,
- u8irq_index,
- u32   *mask);
+  u8   irq_index,
+  u32  *mask);
 
 int dpmcp_get_irq_status(struct fsl_mc_io  *mc_io,
 u32cmd_flags,
 u16token,
-   u8  irq_index,
-   u32 *status);
+u8 irq_index,
+u32*status);
 
 /**
  * struct dpmcp_attr - Structure representing DPMCP attributes
@@ -153,6 +153,6 @@ struct dpmcp_attr {
 int dpmcp_get_attributes(struct fsl_mc_io  *mc_io,
 u32cmd_flags,
 u16token,
-   struct dpmcp_attr   *attr);
+struct dpmcp_attr  *attr);
 
 #endif /* __FSL_DPMCP_H */
diff --git a/drivers/staging/fsl-mc/include/dprc.h 
b/drivers/staging/fsl-mc/include/dprc.h
index 07a11b3..c40abcd 100644
--- a/drivers/staging/fsl-mc/include/dprc.h
+++ b/drivers/staging/fsl-mc/include/dprc.h
@@ -389,10 +389,10 @@ int dprc_get_obj(struct fsl_mc_io *mc_io,
 
 int dprc_get_obj_desc(struct fsl_mc_io *mc_io,
  u32   cmd_flags,
-   u16 token,
-   char*obj_type,
-   int obj_id,
-   struct dprc_obj_desc*obj_desc);
+ u16   token,
+ char  *obj_type,
+ int   obj_id,
+ struct dprc_obj_desc  *obj_desc);
 
 int dprc_set_obj_irq(struct fsl_mc_io  *mc_io,
 u32cmd_flags,
-- 
1.9.0