Re: [PATCH 01/10] Documentation: dt-bindings: mailbox: tegra: Add binding for HSP mailbox

[Joseph Lo]

On 06/29/2016 03:08 AM, Stephen Warren wrote:

On 06/28/2016 03:15 AM, Joseph Lo wrote:

On 06/27/2016 11:55 PM, Stephen Warren wrote:

On 06/27/2016 03:02 AM, Joseph Lo wrote:

snip.


Currently the usage of HSP HW in the downstream kernel is something like
the model below.

remote_processor_A-\
remote_processor_B--->hsp@1000 (doorbell func) <-> host CPU
remote_processor_C-/

remote_processor_D -> hsp@2000 (shared mailbox) <-> CPU

remote_processor_E -> hsp@3000 (shared mailbox) <-> CPU

I am thinking if we can just add the appropriate compatible strings for
it to replace "nvidia,tegra186-hsp". e.g. "nvidia,tegra186-hsp-doorbell"
and "nvidia,tegra186-hsp-sharedmailbox". So the driver can probe and
initialize correctly depend on the compatible property. How do you think
about it? Is this the same as the (b) you mentioned above?


Yes, that would be (b) above.

However, please do note (a): I expect that splitting things up will turn
out to be a mistake, as it has for other HW modules in the past. I would
far rather see a single hsp node in DT, since there is a single HSP
block in HW. Sure that block has multiple sub-functions. However, there
is common logic that affects all of those sub-functions and binds
everything into a single HW module. If you represent the HW module using
multiple different DT nodes, it will be hard to correctly represent that
common logic. Conversely, I see no real advantage to splitting up the DT
node. I strongly believe we should have a single "hsp" node in DT.


We have 6 HSP block in HW. FYI.



Internally, the SW driver for that node can be structured however you
want; it could register with multiple subsystems (mailbox, ...) with
just one struct device, or the HSP driver could be an MFD device with
sub-drivers for each separate piece of functionality the HW implements.
All this can easily be done even while using a single DT node. And
furthermore, we can add this SW structure later if/when we actually need
it; in other words, there's no need to change your current patches right
now, except to remove the nvidia,hsp-function DT property.


Thanks,
-Joseph

Re: [PATCH 01/10] Documentation: dt-bindings: mailbox: tegra: Add binding for HSP mailbox

[Joseph Lo]

On 06/29/2016 03:08 AM, Stephen Warren wrote:

On 06/28/2016 03:15 AM, Joseph Lo wrote:

On 06/27/2016 11:55 PM, Stephen Warren wrote:

On 06/27/2016 03:02 AM, Joseph Lo wrote:

snip.


Currently the usage of HSP HW in the downstream kernel is something like
the model below.

remote_processor_A-\
remote_processor_B--->hsp@1000 (doorbell func) <-> host CPU
remote_processor_C-/

remote_processor_D -> hsp@2000 (shared mailbox) <-> CPU

remote_processor_E -> hsp@3000 (shared mailbox) <-> CPU

I am thinking if we can just add the appropriate compatible strings for
it to replace "nvidia,tegra186-hsp". e.g. "nvidia,tegra186-hsp-doorbell"
and "nvidia,tegra186-hsp-sharedmailbox". So the driver can probe and
initialize correctly depend on the compatible property. How do you think
about it? Is this the same as the (b) you mentioned above?


Yes, that would be (b) above.

However, please do note (a): I expect that splitting things up will turn
out to be a mistake, as it has for other HW modules in the past. I would
far rather see a single hsp node in DT, since there is a single HSP
block in HW. Sure that block has multiple sub-functions. However, there
is common logic that affects all of those sub-functions and binds
everything into a single HW module. If you represent the HW module using
multiple different DT nodes, it will be hard to correctly represent that
common logic. Conversely, I see no real advantage to splitting up the DT
node. I strongly believe we should have a single "hsp" node in DT.


We have 6 HSP block in HW. FYI.



Internally, the SW driver for that node can be structured however you
want; it could register with multiple subsystems (mailbox, ...) with
just one struct device, or the HSP driver could be an MFD device with
sub-drivers for each separate piece of functionality the HW implements.
All this can easily be done even while using a single DT node. And
furthermore, we can add this SW structure later if/when we actually need
it; in other words, there's no need to change your current patches right
now, except to remove the nvidia,hsp-function DT property.


Thanks,
-Joseph

[PATCH v5 0/5] regulator: add Ricoh RN5T567 PMIC support

[Stefan Agner]

This patchset adds RN5T567 PMIC support which is used on the 
Toradex Colibri iMX7S/iMX7D modules. The existing RN5T618 is from
the same family, hence this patchset uses the same driver and adds
variant support.

The Colibris currently do not use the PMIC's power off capabilities,
as do the current users of that PMIC driver. Therefore this patchset
also makes the use of the system-power-controller property mandatory
if the power off capabilties are required.

Changes since v4:
- Spell check in patch 5 and added Acks

Changes since v3:
- Use RN5T618_REPCNT_REPWRON macro when writing RN5T618_REPCNT register

Changes since v2:
- Elevate restart priority to 192 to make sure PMIC takes presedence
  over SoC level restart capabilities (e.g. watchdog)
- Print a warning if poweroff callback is already assigned
- Reorder of_id and variant assignment
- Lower delay to 1ms and justify why it is required
- Fix DCDC count and a typos in device tree bindings

Changes since v1:
- Removed obsolete include 

Stefan Agner (5):
  ARM: dts: meson: minix-neo-x8: define PMIC as power controller
  mfd: add Ricoh RN5T567 PMIC support
  regulator: rn5t618: add RN5T567 PMIC support
  mfd: rn5t618: register power off callback optionally
  mfd: rn5t618: register restart handler

 Documentation/devicetree/bindings/mfd/rn5t618.txt | 19 +++---
 arch/arm/boot/dts/meson8-minix-neo-x8.dts |  1 +
 drivers/mfd/Kconfig   |  7 ++-
 drivers/mfd/rn5t618.c | 70 +++
 drivers/regulator/Kconfig |  5 +-
 drivers/regulator/rn5t618-regulator.c | 40 +++--
 include/linux/mfd/rn5t618.h   | 13 +
 7 files changed, 126 insertions(+), 29 deletions(-)

-- 
2.9.0

[PATCH v5 4/5] mfd: rn5t618: register power off callback optionally

[Stefan Agner]

Only register power off if the PMIC is defined as system power
controller (see Documentation/devicetree/bindings/power/
power-controller.txt).

Signed-off-by: Stefan Agner 
Reviewed-by: Marcel Ziswiler 
Acked-by: Lee Jones 
---
 drivers/mfd/rn5t618.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/mfd/rn5t618.c b/drivers/mfd/rn5t618.c
index c86160d..1831740 100644
--- a/drivers/mfd/rn5t618.c
+++ b/drivers/mfd/rn5t618.c
@@ -102,9 +102,13 @@ static int rn5t618_i2c_probe(struct i2c_client *i2c,
return ret;
}
 
-   if (!pm_power_off) {
-   rn5t618_pm_power_off = priv;
-   pm_power_off = rn5t618_power_off;
+   if (of_device_is_system_power_controller(i2c->dev.of_node)) {
+   if (!pm_power_off) {
+   rn5t618_pm_power_off = priv;
+   pm_power_off = rn5t618_power_off;
+   } else {
+   dev_warn(>dev, "Poweroff callback already 
assigned\n");
+   }
}
 
return 0;
-- 
2.9.0

[PATCH v5 4/5] mfd: rn5t618: register power off callback optionally

[Stefan Agner]

Only register power off if the PMIC is defined as system power
controller (see Documentation/devicetree/bindings/power/
power-controller.txt).

Signed-off-by: Stefan Agner 
Reviewed-by: Marcel Ziswiler 
Acked-by: Lee Jones 
---
 drivers/mfd/rn5t618.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/mfd/rn5t618.c b/drivers/mfd/rn5t618.c
index c86160d..1831740 100644
--- a/drivers/mfd/rn5t618.c
+++ b/drivers/mfd/rn5t618.c
@@ -102,9 +102,13 @@ static int rn5t618_i2c_probe(struct i2c_client *i2c,
return ret;
}
 
-   if (!pm_power_off) {
-   rn5t618_pm_power_off = priv;
-   pm_power_off = rn5t618_power_off;
+   if (of_device_is_system_power_controller(i2c->dev.of_node)) {
+   if (!pm_power_off) {
+   rn5t618_pm_power_off = priv;
+   pm_power_off = rn5t618_power_off;
+   } else {
+   dev_warn(>dev, "Poweroff callback already 
assigned\n");
+   }
}
 
return 0;
-- 
2.9.0

[PATCH v5 0/5] regulator: add Ricoh RN5T567 PMIC support

[Stefan Agner]

This patchset adds RN5T567 PMIC support which is used on the 
Toradex Colibri iMX7S/iMX7D modules. The existing RN5T618 is from
the same family, hence this patchset uses the same driver and adds
variant support.

The Colibris currently do not use the PMIC's power off capabilities,
as do the current users of that PMIC driver. Therefore this patchset
also makes the use of the system-power-controller property mandatory
if the power off capabilties are required.

Changes since v4:
- Spell check in patch 5 and added Acks

Changes since v3:
- Use RN5T618_REPCNT_REPWRON macro when writing RN5T618_REPCNT register

Changes since v2:
- Elevate restart priority to 192 to make sure PMIC takes presedence
  over SoC level restart capabilities (e.g. watchdog)
- Print a warning if poweroff callback is already assigned
- Reorder of_id and variant assignment
- Lower delay to 1ms and justify why it is required
- Fix DCDC count and a typos in device tree bindings

Changes since v1:
- Removed obsolete include 

Stefan Agner (5):
  ARM: dts: meson: minix-neo-x8: define PMIC as power controller
  mfd: add Ricoh RN5T567 PMIC support
  regulator: rn5t618: add RN5T567 PMIC support
  mfd: rn5t618: register power off callback optionally
  mfd: rn5t618: register restart handler

 Documentation/devicetree/bindings/mfd/rn5t618.txt | 19 +++---
 arch/arm/boot/dts/meson8-minix-neo-x8.dts |  1 +
 drivers/mfd/Kconfig   |  7 ++-
 drivers/mfd/rn5t618.c | 70 +++
 drivers/regulator/Kconfig |  5 +-
 drivers/regulator/rn5t618-regulator.c | 40 +++--
 include/linux/mfd/rn5t618.h   | 13 +
 7 files changed, 126 insertions(+), 29 deletions(-)

-- 
2.9.0

[PATCH v5 5/5] mfd: rn5t618: register restart handler

[Stefan Agner]

Use the PMIC's repower capability for reboots. Register a restart
handler and use a slightly elevated priority of 192 since the PMIC
has suprior reset capability (causing a system wide reset).

Signed-off-by: Stefan Agner 
Reviewed-by: Marcel Ziswiler 
Acked-by: Lee Jones 
---
 drivers/mfd/rn5t618.c | 43 +--
 1 file changed, 37 insertions(+), 6 deletions(-)

diff --git a/drivers/mfd/rn5t618.c b/drivers/mfd/rn5t618.c
index 1831740..ee94080 100644
--- a/drivers/mfd/rn5t618.c
+++ b/drivers/mfd/rn5t618.c
@@ -12,11 +12,13 @@
  * along with this program. If not, see .
  */
 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static const struct mfd_cell rn5t618_cells[] = {
@@ -50,17 +52,38 @@ static const struct regmap_config rn5t618_regmap_config = {
 };
 
 static struct rn5t618 *rn5t618_pm_power_off;
+static struct notifier_block rn5t618_restart_handler;
 
-static void rn5t618_power_off(void)
+static void rn5t618_trigger_poweroff_sequence(bool repower)
 {
/* disable automatic repower-on */
regmap_update_bits(rn5t618_pm_power_off->regmap, RN5T618_REPCNT,
-  RN5T618_REPCNT_REPWRON, 0);
+  RN5T618_REPCNT_REPWRON,
+  repower ? RN5T618_REPCNT_REPWRON : 0);
/* start power-off sequence */
regmap_update_bits(rn5t618_pm_power_off->regmap, RN5T618_SLPCNT,
   RN5T618_SLPCNT_SWPWROFF, RN5T618_SLPCNT_SWPWROFF);
 }
 
+static void rn5t618_power_off(void)
+{
+   rn5t618_trigger_poweroff_sequence(false);
+}
+
+static int rn5t618_restart(struct notifier_block *this,
+   unsigned long mode, void *cmd)
+{
+   rn5t618_trigger_poweroff_sequence(true);
+
+   /*
+* Re-power factor detection on PMIC side is not instant. 1ms
+* proved to be enough time until reset takes effect.
+*/
+   mdelay(1);
+
+   return NOTIFY_DONE;
+}
+
 static const struct of_device_id rn5t618_of_match[] = {
{ .compatible = "ricoh,rn5t567", .data = (void *)RN5T567 },
{ .compatible = "ricoh,rn5t618", .data = (void *)RN5T618 },
@@ -102,13 +125,21 @@ static int rn5t618_i2c_probe(struct i2c_client *i2c,
return ret;
}
 
+   rn5t618_pm_power_off = priv;
if (of_device_is_system_power_controller(i2c->dev.of_node)) {
-   if (!pm_power_off) {
-   rn5t618_pm_power_off = priv;
+   if (!pm_power_off)
pm_power_off = rn5t618_power_off;
-   } else {
+   else
dev_warn(>dev, "Poweroff callback already 
assigned\n");
-   }
+   }
+
+   rn5t618_restart_handler.notifier_call = rn5t618_restart;
+   rn5t618_restart_handler.priority = 192;
+
+   ret = register_restart_handler(_restart_handler);
+   if (ret) {
+   dev_err(>dev, "cannot register restart handler, %d\n", 
ret);
+   return ret;
}
 
return 0;
-- 
2.9.0

[PATCH v5 5/5] mfd: rn5t618: register restart handler

[Stefan Agner]

Use the PMIC's repower capability for reboots. Register a restart
handler and use a slightly elevated priority of 192 since the PMIC
has suprior reset capability (causing a system wide reset).

Signed-off-by: Stefan Agner 
Reviewed-by: Marcel Ziswiler 
Acked-by: Lee Jones 
---
 drivers/mfd/rn5t618.c | 43 +--
 1 file changed, 37 insertions(+), 6 deletions(-)

diff --git a/drivers/mfd/rn5t618.c b/drivers/mfd/rn5t618.c
index 1831740..ee94080 100644
--- a/drivers/mfd/rn5t618.c
+++ b/drivers/mfd/rn5t618.c
@@ -12,11 +12,13 @@
  * along with this program. If not, see .
  */
 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static const struct mfd_cell rn5t618_cells[] = {
@@ -50,17 +52,38 @@ static const struct regmap_config rn5t618_regmap_config = {
 };
 
 static struct rn5t618 *rn5t618_pm_power_off;
+static struct notifier_block rn5t618_restart_handler;
 
-static void rn5t618_power_off(void)
+static void rn5t618_trigger_poweroff_sequence(bool repower)
 {
/* disable automatic repower-on */
regmap_update_bits(rn5t618_pm_power_off->regmap, RN5T618_REPCNT,
-  RN5T618_REPCNT_REPWRON, 0);
+  RN5T618_REPCNT_REPWRON,
+  repower ? RN5T618_REPCNT_REPWRON : 0);
/* start power-off sequence */
regmap_update_bits(rn5t618_pm_power_off->regmap, RN5T618_SLPCNT,
   RN5T618_SLPCNT_SWPWROFF, RN5T618_SLPCNT_SWPWROFF);
 }
 
+static void rn5t618_power_off(void)
+{
+   rn5t618_trigger_poweroff_sequence(false);
+}
+
+static int rn5t618_restart(struct notifier_block *this,
+   unsigned long mode, void *cmd)
+{
+   rn5t618_trigger_poweroff_sequence(true);
+
+   /*
+* Re-power factor detection on PMIC side is not instant. 1ms
+* proved to be enough time until reset takes effect.
+*/
+   mdelay(1);
+
+   return NOTIFY_DONE;
+}
+
 static const struct of_device_id rn5t618_of_match[] = {
{ .compatible = "ricoh,rn5t567", .data = (void *)RN5T567 },
{ .compatible = "ricoh,rn5t618", .data = (void *)RN5T618 },
@@ -102,13 +125,21 @@ static int rn5t618_i2c_probe(struct i2c_client *i2c,
return ret;
}
 
+   rn5t618_pm_power_off = priv;
if (of_device_is_system_power_controller(i2c->dev.of_node)) {
-   if (!pm_power_off) {
-   rn5t618_pm_power_off = priv;
+   if (!pm_power_off)
pm_power_off = rn5t618_power_off;
-   } else {
+   else
dev_warn(>dev, "Poweroff callback already 
assigned\n");
-   }
+   }
+
+   rn5t618_restart_handler.notifier_call = rn5t618_restart;
+   rn5t618_restart_handler.priority = 192;
+
+   ret = register_restart_handler(_restart_handler);
+   if (ret) {
+   dev_err(>dev, "cannot register restart handler, %d\n", 
ret);
+   return ret;
}
 
return 0;
-- 
2.9.0

Re: [PATCH 74/92] clocksource/drivers/bcm_kona: Remove useless header

[Ray Jui]

Hi Daniel,

On 6/28/2016 3:31 AM, Daniel Lezcano wrote:

The driver includes the  header but it is pointless.

Remove it.

Signed-off-by: Daniel Lezcano 
---
 drivers/clocksource/bcm_kona_timer.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/clocksource/bcm_kona_timer.c 
b/drivers/clocksource/bcm_kona_timer.c
index 86f87be3d..7e3fd37 100644
--- a/drivers/clocksource/bcm_kona_timer.c
+++ b/drivers/clocksource/bcm_kona_timer.c
@@ -20,7 +20,6 @@
 #include 

 #include 
-#include 

 #include 
 #include 



Acked-by: Ray Jui 

Thanks!

[PATCH v5 2/5] mfd: add Ricoh RN5T567 PMIC support

[Stefan Agner]

The Ricoh RN5T567 is from the same family as the Ricoh RN5T618 is,
the differences are:

+ DCDC4
+ Slightly different output voltage/currents
+ 32kHz Output
- ADC/Charger capabilities

Signed-off-by: Stefan Agner 
Reviewed-by: Marcel Ziswiler 
Acked-by: Rob Herring 
Acked-by: Lee Jones 
---
 Documentation/devicetree/bindings/mfd/rn5t618.txt | 19 +
 drivers/mfd/Kconfig   |  7 ---
 drivers/mfd/rn5t618.c | 25 ---
 include/linux/mfd/rn5t618.h   | 12 +++
 4 files changed, 45 insertions(+), 18 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/rn5t618.txt 
b/Documentation/devicetree/bindings/mfd/rn5t618.txt
index 937785a..9e6770b 100644
--- a/Documentation/devicetree/bindings/mfd/rn5t618.txt
+++ b/Documentation/devicetree/bindings/mfd/rn5t618.txt
@@ -1,18 +1,21 @@
-* Ricoh RN5T618 PMIC
+* Ricoh RN5T567/RN5T618 PMIC
 
-Ricoh RN5T618 is a power management IC which integrates 3 step-down
-DCDC converters, 7 low-dropout regulators, a Li-ion battery charger,
-fuel gauge, ADC, GPIOs and a watchdog timer. It can be controlled
-through a I2C interface.
+Ricoh RN5T567/RN5T618 is a power management IC family which integrates
+3 to 4 step-down DCDC converters, 7 low-dropout regulators, GPIOs and
+a watchdog timer. The RN5T618 provides additionally a Li-ion battery
+charger, fuel gauge and an ADC. It can be controlled through an I2C
+interface.
 
 Required properties:
- - compatible: should be "ricoh,rn5t618"
+ - compatible: must be one of
+   "ricoh,rn5t567"
+   "ricoh,rn5t618"
  - reg: the I2C slave address of the device
 
 Sub-nodes:
  - regulators: the node is required if the regulator functionality is
-   needed. The valid regulator names are: DCDC1, DCDC2, DCDC3, LDO1,
-   LDO2, LDO3, LDO4, LDO5, LDORTC1 and LDORTC2.
+   needed. The valid regulator names are: DCDC1, DCDC2, DCDC3, DCDC4
+   (RN5T567), LDO1, LDO2, LDO3, LDO4, LDO5, LDORTC1 and LDORTC2.
The common bindings for each individual regulator can be found in:
Documentation/devicetree/bindings/regulator/regulator.txt
 
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 1bcf601..ff031a7 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -852,13 +852,14 @@ config MFD_RK808
  including interrupts, RTC, LDO & DCDC regulators, and onkey.
 
 config MFD_RN5T618
-   tristate "Ricoh RN5T5618 PMIC"
+   tristate "Ricoh RN5T567/618 PMIC"
depends on I2C
+   depends on OF
select MFD_CORE
select REGMAP_I2C
help
- Say yes here to add support for the Ricoh RN5T618 PMIC. This
- driver provides common support for accessing the device,
+ Say yes here to add support for the Ricoh RN5T567 or R5T618 PMIC.
+ This driver provides common support for accessing the device,
  additional drivers must be enabled in order to use the
  functionality of the device.
 
diff --git a/drivers/mfd/rn5t618.c b/drivers/mfd/rn5t618.c
index 0ad51d7..c86160d 100644
--- a/drivers/mfd/rn5t618.c
+++ b/drivers/mfd/rn5t618.c
@@ -2,6 +2,7 @@
  * MFD core driver for Ricoh RN5T618 PMIC
  *
  * Copyright (C) 2014 Beniamino Galvani 
+ * Copyright (C) 2016 Toradex AG
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -15,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static const struct mfd_cell rn5t618_cells[] = {
@@ -59,17 +61,32 @@ static void rn5t618_power_off(void)
   RN5T618_SLPCNT_SWPWROFF, RN5T618_SLPCNT_SWPWROFF);
 }
 
+static const struct of_device_id rn5t618_of_match[] = {
+   { .compatible = "ricoh,rn5t567", .data = (void *)RN5T567 },
+   { .compatible = "ricoh,rn5t618", .data = (void *)RN5T618 },
+   { }
+};
+MODULE_DEVICE_TABLE(of, rn5t618_of_match);
+
 static int rn5t618_i2c_probe(struct i2c_client *i2c,
 const struct i2c_device_id *id)
 {
+   const struct of_device_id *of_id;
struct rn5t618 *priv;
int ret;
 
+   of_id = of_match_device(rn5t618_of_match, >dev);
+   if (!of_id) {
+   dev_err(>dev, "Failed to find matching DT ID\n");
+   return -EINVAL;
+   }
+
priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
return -ENOMEM;
 
i2c_set_clientdata(i2c, priv);
+   priv->variant = (long)of_id->data;
 
priv->regmap = devm_regmap_init_i2c(i2c, _regmap_config);
if (IS_ERR(priv->regmap)) {
@@ -105,12 +122,6 @@ static int rn5t618_i2c_remove(struct i2c_client *i2c)
return 0;
 }
 
-static const struct of_device_id rn5t618_of_match[] = {
-   { .compatible = "ricoh,rn5t618" },
-   { }
-};
-MODULE_DEVICE_TABLE(of, 

[PATCH v5 3/5] regulator: rn5t618: add RN5T567 PMIC support

[Stefan Agner]

Extend the driver to support Ricoh RN5T567. Support the additional
DCDC and slightly different voltage range of LDORTC1.

Signed-off-by: Stefan Agner 
Reviewed-by: Marcel Ziswiler 
Acked-by: Mark Brown 
Acked-by: Lee Jones 
---
 drivers/regulator/Kconfig |  5 +++--
 drivers/regulator/rn5t618-regulator.c | 40 +++
 include/linux/mfd/rn5t618.h   |  1 +
 3 files changed, 40 insertions(+), 6 deletions(-)

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 144cbf5..5472694 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -636,10 +636,11 @@ config REGULATOR_RK808
  outputs which can be controlled by i2c communication.
 
 config REGULATOR_RN5T618
-   tristate "Ricoh RN5T618 voltage regulators"
+   tristate "Ricoh RN5T567/618 voltage regulators"
depends on MFD_RN5T618
help
- Say y here to support the regulators found on Ricoh RN5T618 PMIC.
+ Say y here to support the regulators found on Ricoh RN5T567 or
+ RN5T618 PMIC.
 
 config REGULATOR_RT5033
tristate "Richtek RT5033 Regulators"
diff --git a/drivers/regulator/rn5t618-regulator.c 
b/drivers/regulator/rn5t618-regulator.c
index b85ceb8..9c930eb 100644
--- a/drivers/regulator/rn5t618-regulator.c
+++ b/drivers/regulator/rn5t618-regulator.c
@@ -46,6 +46,23 @@ static struct regulator_ops rn5t618_reg_ops = {
.vsel_mask  = (vmask),  \
}
 
+static struct regulator_desc rn5t567_regulators[] = {
+   /* DCDC */
+   REG(DCDC1, DC1CTL, BIT(0), DC1DAC, 0xff, 60, 350, 12500),
+   REG(DCDC2, DC2CTL, BIT(0), DC2DAC, 0xff, 60, 350, 12500),
+   REG(DCDC3, DC3CTL, BIT(0), DC3DAC, 0xff, 60, 350, 12500),
+   REG(DCDC4, DC4CTL, BIT(0), DC4DAC, 0xff, 60, 350, 12500),
+   /* LDO */
+   REG(LDO1, LDOEN1, BIT(0), LDO1DAC, 0x7f, 90, 350, 25000),
+   REG(LDO2, LDOEN1, BIT(1), LDO2DAC, 0x7f, 90, 350, 25000),
+   REG(LDO3, LDOEN1, BIT(2), LDO3DAC, 0x7f, 60, 350, 25000),
+   REG(LDO4, LDOEN1, BIT(3), LDO4DAC, 0x7f, 90, 350, 25000),
+   REG(LDO5, LDOEN1, BIT(4), LDO5DAC, 0x7f, 90, 350, 25000),
+   /* LDO RTC */
+   REG(LDORTC1, LDOEN2, BIT(4), LDORTCDAC, 0x7f, 120, 350, 25000),
+   REG(LDORTC2, LDOEN2, BIT(5), LDORTC2DAC, 0x7f, 90, 350, 25000),
+};
+
 static struct regulator_desc rn5t618_regulators[] = {
/* DCDC */
REG(DCDC1, DC1CTL, BIT(0), DC1DAC, 0xff, 60, 350, 12500),
@@ -67,18 +84,33 @@ static int rn5t618_regulator_probe(struct platform_device 
*pdev)
struct rn5t618 *rn5t618 = dev_get_drvdata(pdev->dev.parent);
struct regulator_config config = { };
struct regulator_dev *rdev;
+   struct regulator_desc *regulators;
int i;
 
+   switch (rn5t618->variant) {
+   case RN5T567:
+   regulators = rn5t567_regulators;
+   break;
+   case RN5T618:
+   regulators = rn5t618_regulators;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   config.dev = pdev->dev.parent;
+   config.regmap = rn5t618->regmap;
+
for (i = 0; i < RN5T618_REG_NUM; i++) {
-   config.dev = pdev->dev.parent;
-   config.regmap = rn5t618->regmap;
+   if (!regulators[i].name)
+   continue;
 
rdev = devm_regulator_register(>dev,
-  _regulators[i],
+  [i],
   );
if (IS_ERR(rdev)) {
dev_err(>dev, "failed to register %s regulator\n",
-   rn5t618_regulators[i].name);
+   regulators[i].name);
return PTR_ERR(rdev);
}
}
diff --git a/include/linux/mfd/rn5t618.h b/include/linux/mfd/rn5t618.h
index 54179c2..cadc654 100644
--- a/include/linux/mfd/rn5t618.h
+++ b/include/linux/mfd/rn5t618.h
@@ -217,6 +217,7 @@ enum {
RN5T618_DCDC1,
RN5T618_DCDC2,
RN5T618_DCDC3,
+   RN5T618_DCDC4,
RN5T618_LDO1,
RN5T618_LDO2,
RN5T618_LDO3,
-- 
2.9.0

[PATCH v5 1/5] ARM: dts: meson: minix-neo-x8: define PMIC as power controller

[Stefan Agner]

The PMIC driver used to register itself as poweroff controller by
default, hence assuming that this device is using the PMIC as
system power controller.

Signed-off-by: Stefan Agner 
Reviewed-by: Marcel Ziswiler 
Acked-by: Carlo Caione 
---
 arch/arm/boot/dts/meson8-minix-neo-x8.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/meson8-minix-neo-x8.dts 
b/arch/arm/boot/dts/meson8-minix-neo-x8.dts
index 4f536bb..8bceb8d 100644
--- a/arch/arm/boot/dts/meson8-minix-neo-x8.dts
+++ b/arch/arm/boot/dts/meson8-minix-neo-x8.dts
@@ -80,6 +80,7 @@
pmic@32 {
compatible = "ricoh,rn5t618";
reg = <0x32>;
+   system-power-controller;
 
regulators {
};
-- 
2.9.0

Re: [PATCH 74/92] clocksource/drivers/bcm_kona: Remove useless header

[Ray Jui]

Hi Daniel,

On 6/28/2016 3:31 AM, Daniel Lezcano wrote:

The driver includes the  header but it is pointless.

Remove it.

Signed-off-by: Daniel Lezcano 
---
 drivers/clocksource/bcm_kona_timer.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/clocksource/bcm_kona_timer.c 
b/drivers/clocksource/bcm_kona_timer.c
index 86f87be3d..7e3fd37 100644
--- a/drivers/clocksource/bcm_kona_timer.c
+++ b/drivers/clocksource/bcm_kona_timer.c
@@ -20,7 +20,6 @@
 #include 

 #include 
-#include 

 #include 
 #include 



Acked-by: Ray Jui 

Thanks!

[PATCH v5 2/5] mfd: add Ricoh RN5T567 PMIC support

[Stefan Agner]

The Ricoh RN5T567 is from the same family as the Ricoh RN5T618 is,
the differences are:

+ DCDC4
+ Slightly different output voltage/currents
+ 32kHz Output
- ADC/Charger capabilities

Signed-off-by: Stefan Agner 
Reviewed-by: Marcel Ziswiler 
Acked-by: Rob Herring 
Acked-by: Lee Jones 
---
 Documentation/devicetree/bindings/mfd/rn5t618.txt | 19 +
 drivers/mfd/Kconfig   |  7 ---
 drivers/mfd/rn5t618.c | 25 ---
 include/linux/mfd/rn5t618.h   | 12 +++
 4 files changed, 45 insertions(+), 18 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/rn5t618.txt 
b/Documentation/devicetree/bindings/mfd/rn5t618.txt
index 937785a..9e6770b 100644
--- a/Documentation/devicetree/bindings/mfd/rn5t618.txt
+++ b/Documentation/devicetree/bindings/mfd/rn5t618.txt
@@ -1,18 +1,21 @@
-* Ricoh RN5T618 PMIC
+* Ricoh RN5T567/RN5T618 PMIC
 
-Ricoh RN5T618 is a power management IC which integrates 3 step-down
-DCDC converters, 7 low-dropout regulators, a Li-ion battery charger,
-fuel gauge, ADC, GPIOs and a watchdog timer. It can be controlled
-through a I2C interface.
+Ricoh RN5T567/RN5T618 is a power management IC family which integrates
+3 to 4 step-down DCDC converters, 7 low-dropout regulators, GPIOs and
+a watchdog timer. The RN5T618 provides additionally a Li-ion battery
+charger, fuel gauge and an ADC. It can be controlled through an I2C
+interface.
 
 Required properties:
- - compatible: should be "ricoh,rn5t618"
+ - compatible: must be one of
+   "ricoh,rn5t567"
+   "ricoh,rn5t618"
  - reg: the I2C slave address of the device
 
 Sub-nodes:
  - regulators: the node is required if the regulator functionality is
-   needed. The valid regulator names are: DCDC1, DCDC2, DCDC3, LDO1,
-   LDO2, LDO3, LDO4, LDO5, LDORTC1 and LDORTC2.
+   needed. The valid regulator names are: DCDC1, DCDC2, DCDC3, DCDC4
+   (RN5T567), LDO1, LDO2, LDO3, LDO4, LDO5, LDORTC1 and LDORTC2.
The common bindings for each individual regulator can be found in:
Documentation/devicetree/bindings/regulator/regulator.txt
 
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 1bcf601..ff031a7 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -852,13 +852,14 @@ config MFD_RK808
  including interrupts, RTC, LDO & DCDC regulators, and onkey.
 
 config MFD_RN5T618
-   tristate "Ricoh RN5T5618 PMIC"
+   tristate "Ricoh RN5T567/618 PMIC"
depends on I2C
+   depends on OF
select MFD_CORE
select REGMAP_I2C
help
- Say yes here to add support for the Ricoh RN5T618 PMIC. This
- driver provides common support for accessing the device,
+ Say yes here to add support for the Ricoh RN5T567 or R5T618 PMIC.
+ This driver provides common support for accessing the device,
  additional drivers must be enabled in order to use the
  functionality of the device.
 
diff --git a/drivers/mfd/rn5t618.c b/drivers/mfd/rn5t618.c
index 0ad51d7..c86160d 100644
--- a/drivers/mfd/rn5t618.c
+++ b/drivers/mfd/rn5t618.c
@@ -2,6 +2,7 @@
  * MFD core driver for Ricoh RN5T618 PMIC
  *
  * Copyright (C) 2014 Beniamino Galvani 
+ * Copyright (C) 2016 Toradex AG
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -15,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static const struct mfd_cell rn5t618_cells[] = {
@@ -59,17 +61,32 @@ static void rn5t618_power_off(void)
   RN5T618_SLPCNT_SWPWROFF, RN5T618_SLPCNT_SWPWROFF);
 }
 
+static const struct of_device_id rn5t618_of_match[] = {
+   { .compatible = "ricoh,rn5t567", .data = (void *)RN5T567 },
+   { .compatible = "ricoh,rn5t618", .data = (void *)RN5T618 },
+   { }
+};
+MODULE_DEVICE_TABLE(of, rn5t618_of_match);
+
 static int rn5t618_i2c_probe(struct i2c_client *i2c,
 const struct i2c_device_id *id)
 {
+   const struct of_device_id *of_id;
struct rn5t618 *priv;
int ret;
 
+   of_id = of_match_device(rn5t618_of_match, >dev);
+   if (!of_id) {
+   dev_err(>dev, "Failed to find matching DT ID\n");
+   return -EINVAL;
+   }
+
priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
return -ENOMEM;
 
i2c_set_clientdata(i2c, priv);
+   priv->variant = (long)of_id->data;
 
priv->regmap = devm_regmap_init_i2c(i2c, _regmap_config);
if (IS_ERR(priv->regmap)) {
@@ -105,12 +122,6 @@ static int rn5t618_i2c_remove(struct i2c_client *i2c)
return 0;
 }
 
-static const struct of_device_id rn5t618_of_match[] = {
-   { .compatible = "ricoh,rn5t618" },
-   { }
-};
-MODULE_DEVICE_TABLE(of, rn5t618_of_match);
-
 static const struct i2c_device_id rn5t618_i2c_id[] = {
{ }
 };
@@ -129,5 

[PATCH v5 3/5] regulator: rn5t618: add RN5T567 PMIC support

[Stefan Agner]

Extend the driver to support Ricoh RN5T567. Support the additional
DCDC and slightly different voltage range of LDORTC1.

Signed-off-by: Stefan Agner 
Reviewed-by: Marcel Ziswiler 
Acked-by: Mark Brown 
Acked-by: Lee Jones 
---
 drivers/regulator/Kconfig |  5 +++--
 drivers/regulator/rn5t618-regulator.c | 40 +++
 include/linux/mfd/rn5t618.h   |  1 +
 3 files changed, 40 insertions(+), 6 deletions(-)

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 144cbf5..5472694 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -636,10 +636,11 @@ config REGULATOR_RK808
  outputs which can be controlled by i2c communication.
 
 config REGULATOR_RN5T618
-   tristate "Ricoh RN5T618 voltage regulators"
+   tristate "Ricoh RN5T567/618 voltage regulators"
depends on MFD_RN5T618
help
- Say y here to support the regulators found on Ricoh RN5T618 PMIC.
+ Say y here to support the regulators found on Ricoh RN5T567 or
+ RN5T618 PMIC.
 
 config REGULATOR_RT5033
tristate "Richtek RT5033 Regulators"
diff --git a/drivers/regulator/rn5t618-regulator.c 
b/drivers/regulator/rn5t618-regulator.c
index b85ceb8..9c930eb 100644
--- a/drivers/regulator/rn5t618-regulator.c
+++ b/drivers/regulator/rn5t618-regulator.c
@@ -46,6 +46,23 @@ static struct regulator_ops rn5t618_reg_ops = {
.vsel_mask  = (vmask),  \
}
 
+static struct regulator_desc rn5t567_regulators[] = {
+   /* DCDC */
+   REG(DCDC1, DC1CTL, BIT(0), DC1DAC, 0xff, 60, 350, 12500),
+   REG(DCDC2, DC2CTL, BIT(0), DC2DAC, 0xff, 60, 350, 12500),
+   REG(DCDC3, DC3CTL, BIT(0), DC3DAC, 0xff, 60, 350, 12500),
+   REG(DCDC4, DC4CTL, BIT(0), DC4DAC, 0xff, 60, 350, 12500),
+   /* LDO */
+   REG(LDO1, LDOEN1, BIT(0), LDO1DAC, 0x7f, 90, 350, 25000),
+   REG(LDO2, LDOEN1, BIT(1), LDO2DAC, 0x7f, 90, 350, 25000),
+   REG(LDO3, LDOEN1, BIT(2), LDO3DAC, 0x7f, 60, 350, 25000),
+   REG(LDO4, LDOEN1, BIT(3), LDO4DAC, 0x7f, 90, 350, 25000),
+   REG(LDO5, LDOEN1, BIT(4), LDO5DAC, 0x7f, 90, 350, 25000),
+   /* LDO RTC */
+   REG(LDORTC1, LDOEN2, BIT(4), LDORTCDAC, 0x7f, 120, 350, 25000),
+   REG(LDORTC2, LDOEN2, BIT(5), LDORTC2DAC, 0x7f, 90, 350, 25000),
+};
+
 static struct regulator_desc rn5t618_regulators[] = {
/* DCDC */
REG(DCDC1, DC1CTL, BIT(0), DC1DAC, 0xff, 60, 350, 12500),
@@ -67,18 +84,33 @@ static int rn5t618_regulator_probe(struct platform_device 
*pdev)
struct rn5t618 *rn5t618 = dev_get_drvdata(pdev->dev.parent);
struct regulator_config config = { };
struct regulator_dev *rdev;
+   struct regulator_desc *regulators;
int i;
 
+   switch (rn5t618->variant) {
+   case RN5T567:
+   regulators = rn5t567_regulators;
+   break;
+   case RN5T618:
+   regulators = rn5t618_regulators;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   config.dev = pdev->dev.parent;
+   config.regmap = rn5t618->regmap;
+
for (i = 0; i < RN5T618_REG_NUM; i++) {
-   config.dev = pdev->dev.parent;
-   config.regmap = rn5t618->regmap;
+   if (!regulators[i].name)
+   continue;
 
rdev = devm_regulator_register(>dev,
-  _regulators[i],
+  [i],
   );
if (IS_ERR(rdev)) {
dev_err(>dev, "failed to register %s regulator\n",
-   rn5t618_regulators[i].name);
+   regulators[i].name);
return PTR_ERR(rdev);
}
}
diff --git a/include/linux/mfd/rn5t618.h b/include/linux/mfd/rn5t618.h
index 54179c2..cadc654 100644
--- a/include/linux/mfd/rn5t618.h
+++ b/include/linux/mfd/rn5t618.h
@@ -217,6 +217,7 @@ enum {
RN5T618_DCDC1,
RN5T618_DCDC2,
RN5T618_DCDC3,
+   RN5T618_DCDC4,
RN5T618_LDO1,
RN5T618_LDO2,
RN5T618_LDO3,
-- 
2.9.0

[PATCH v5 1/5] ARM: dts: meson: minix-neo-x8: define PMIC as power controller

[Stefan Agner]

The PMIC driver used to register itself as poweroff controller by
default, hence assuming that this device is using the PMIC as
system power controller.

Signed-off-by: Stefan Agner 
Reviewed-by: Marcel Ziswiler 
Acked-by: Carlo Caione 
---
 arch/arm/boot/dts/meson8-minix-neo-x8.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/meson8-minix-neo-x8.dts 
b/arch/arm/boot/dts/meson8-minix-neo-x8.dts
index 4f536bb..8bceb8d 100644
--- a/arch/arm/boot/dts/meson8-minix-neo-x8.dts
+++ b/arch/arm/boot/dts/meson8-minix-neo-x8.dts
@@ -80,6 +80,7 @@
pmic@32 {
compatible = "ricoh,rn5t618";
reg = <0x32>;
+   system-power-controller;
 
regulators {
};
-- 
2.9.0

DONATION OF $ 1.5 MILLION DOLLARS!!!

[Colin & Chris Weir]

My wife and I have awarded you with a donation of $ 1.5 million Dollars from 
part of our Jackpot Lottery of 161,653,000 Million Pounds,Send your 
name,Address, Phone for claims Now.

To verify the genuineness of this email, check this web page;
http://www.bbc.com/news/uk-scotland-glasgow-west-18801698

We await your earliest response and God Bless you.

Best of luck.
Colin & Chris Weir

DONATION OF $ 1.5 MILLION DOLLARS!!!

[Colin & Chris Weir]

My wife and I have awarded you with a donation of $ 1.5 million Dollars from 
part of our Jackpot Lottery of 161,653,000 Million Pounds,Send your 
name,Address, Phone for claims Now.

To verify the genuineness of this email, check this web page;
http://www.bbc.com/news/uk-scotland-glasgow-west-18801698

We await your earliest response and God Bless you.

Best of luck.
Colin & Chris Weir

DONATION OF $ 1.5 MILLION DOLLARS!!!

[Colin & Chris Weir]

My wife and I have awarded you with a donation of $ 1.5 million Dollars from 
part of our Jackpot Lottery of 161,653,000 Million Pounds,Send your 
name,Address, Phone for claims Now.

To verify the genuineness of this email, check this web page;
http://www.bbc.com/news/uk-scotland-glasgow-west-18801698

We await your earliest response and God Bless you.

Best of luck.
Colin & Chris Weir

DONATION OF $ 1.5 MILLION DOLLARS!!!

[Colin & Chris Weir]

My wife and I have awarded you with a donation of $ 1.5 million Dollars from 
part of our Jackpot Lottery of 161,653,000 Million Pounds,Send your 
name,Address, Phone for claims Now.

To verify the genuineness of this email, check this web page;
http://www.bbc.com/news/uk-scotland-glasgow-west-18801698

We await your earliest response and God Bless you.

Best of luck.
Colin & Chris Weir

[PATCH] mm, vmscan: Give up balancing node for high order allocations earlier

[Hillf Danton]

To avoid excessive reclaim, we give up rebalancing for high order 
allocations right after reclaiming enough pages.

Signed-off-by: Hillf Danton 
---

 mm/vmscan.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index ee7e531..d080fb2 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -3159,8 +3159,7 @@ static int balance_pgdat(pg_data_t *pgdat, int order, int 
classzone_idx)
 
do {
bool raise_priority = true;
-
-   sc.nr_reclaimed = 0;
+   unsigned long reclaimed_pages = sc.nr_reclaimed;
 
/*
 * If the number of buffer_heads in the machine exceeds the
@@ -3254,7 +3253,7 @@ static int balance_pgdat(pg_data_t *pgdat, int order, int 
classzone_idx)
 * Raise priority if scanning rate is too low or there was no
 * progress in reclaiming pages
 */
-   if (raise_priority || !sc.nr_reclaimed)
+   if (raise_priority || sc.nr_reclaimed == reclaimed_pages)
sc.priority--;
} while (sc.priority >= 1);
 
--

[PATCH] mm, vmscan: Give up balancing node for high order allocations earlier

[Hillf Danton]

To avoid excessive reclaim, we give up rebalancing for high order 
allocations right after reclaiming enough pages.

Signed-off-by: Hillf Danton 
---

 mm/vmscan.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index ee7e531..d080fb2 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -3159,8 +3159,7 @@ static int balance_pgdat(pg_data_t *pgdat, int order, int 
classzone_idx)
 
do {
bool raise_priority = true;
-
-   sc.nr_reclaimed = 0;
+   unsigned long reclaimed_pages = sc.nr_reclaimed;
 
/*
 * If the number of buffer_heads in the machine exceeds the
@@ -3254,7 +3253,7 @@ static int balance_pgdat(pg_data_t *pgdat, int order, int 
classzone_idx)
 * Raise priority if scanning rate is too low or there was no
 * progress in reclaiming pages
 */
-   if (raise_priority || !sc.nr_reclaimed)
+   if (raise_priority || sc.nr_reclaimed == reclaimed_pages)
sc.priority--;
} while (sc.priority >= 1);
 
--

Re: linux-next: manual merge of the kvm tree with the s390 tree

[Heiko Carstens]

On Wed, Jun 29, 2016 at 02:36:58PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the kvm tree got a conflict in:
> 
>   arch/s390/hypfs/hypfs_diag.c
> 
> between commit:
> 
>   e030c1125eab ("s390/hypfs: use basic block for diag inline assembly")
> 
> from the s390 tree and commit:
> 
>   e65f30e0cb29 ("s390: hypfs: Move diag implementation and data definitions")
> 
> from the kvm tree.
> 
> I fixed it up (my fixup patch now looks like below) and can carry the
> fix as necessary. This is now fixed as far as linux-next is concerned,
> but any non trivial conflicts should be mentioned to your upstream
> maintainer when your tree is submitted for merging.  You may also want
> to consider cooperating with the maintainer of the conflicting tree to
> minimise any particularly complex conflicts.
> 
> From: Stephen Rothwell 
> Date: Tue, 14 Jun 2016 14:47:33 +1000
> Subject: [PATCH] s390: merge fix up for __diag204 move
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  arch/s390/kernel/diag.c | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)

The fix looks good. Thanks!

Re: linux-next: manual merge of the kvm tree with the s390 tree

[Heiko Carstens]

On Wed, Jun 29, 2016 at 02:36:58PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the kvm tree got a conflict in:
> 
>   arch/s390/hypfs/hypfs_diag.c
> 
> between commit:
> 
>   e030c1125eab ("s390/hypfs: use basic block for diag inline assembly")
> 
> from the s390 tree and commit:
> 
>   e65f30e0cb29 ("s390: hypfs: Move diag implementation and data definitions")
> 
> from the kvm tree.
> 
> I fixed it up (my fixup patch now looks like below) and can carry the
> fix as necessary. This is now fixed as far as linux-next is concerned,
> but any non trivial conflicts should be mentioned to your upstream
> maintainer when your tree is submitted for merging.  You may also want
> to consider cooperating with the maintainer of the conflicting tree to
> minimise any particularly complex conflicts.
> 
> From: Stephen Rothwell 
> Date: Tue, 14 Jun 2016 14:47:33 +1000
> Subject: [PATCH] s390: merge fix up for __diag204 move
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  arch/s390/kernel/diag.c | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)

The fix looks good. Thanks!

Re: [PATCH v12 0/3] printk: Make printk() completely async

[Sergey Senozhatsky]

On (06/28/16 22:16), Joe Perches wrote:
> On Wed, 2016-06-29 at 14:08 +0900, Sergey Senozhatsky wrote:
> > the patch to fix the async KERN_CONT printk regression I mentioned
> > several days ago in another thread.
> 
> KERN_CONT is effectively a no-op.
> This is any printk without a KERN_

if the message has no LOG_NEWLINE in flags then it's stored as LOG_CONT
in log buffer, but before getting there it sits in cont buffer. and those
are usually KERN_CONT messages that don't have LOG_NEWLINE in flags. may
be the wording is not exactly correct in the original message.

-ss

Re: [PATCH v12 0/3] printk: Make printk() completely async

[Sergey Senozhatsky]

On (06/28/16 22:16), Joe Perches wrote:
> On Wed, 2016-06-29 at 14:08 +0900, Sergey Senozhatsky wrote:
> > the patch to fix the async KERN_CONT printk regression I mentioned
> > several days ago in another thread.
> 
> KERN_CONT is effectively a no-op.
> This is any printk without a KERN_

if the message has no LOG_NEWLINE in flags then it's stored as LOG_CONT
in log buffer, but before getting there it sits in cont buffer. and those
are usually KERN_CONT messages that don't have LOG_NEWLINE in flags. may
be the wording is not exactly correct in the original message.

-ss

Re: linux-next: manual merge of the powerpc tree with Linus' tree

[Naveen N. Rao]

On 2016/06/29 10:35AM, Stephen Rothwell wrote:
> Hi all,

Hi Stephen,

> 
> Today's linux-next merge of the powerpc tree got a conflict in:
> 
>   arch/powerpc/Kconfig
> 
> between commit:
> 
>   844e3be47693 ("powerpc/bpf/jit: Disable classic BPF JIT on ppc64le")

Ah, I see that the above commit is not part of powerpc next tree, which 
explains the conflict.

> 
> from Linus' tree and commit:
> 
>   156d0e290e96 ("powerpc/ebpf/jit: Implement JIT compiler for extended BPF")
> 
> from the powerpc tree.
> 
> I fixed it up (see below - I am not sure this entirely correct) and can
> carry the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging.  You may
> also want to consider cooperating with the maintainer of the
> conflicting tree to minimise any particularly complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc arch/powerpc/Kconfig
> index 0a9d439bcda6,ee82f9a09a85..
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@@ -128,7 -128,8 +128,8 @@@ config PP
>   select IRQ_FORCED_THREADING
>   select HAVE_RCU_TABLE_FREE if SMP
>   select HAVE_SYSCALL_TRACEPOINTS
> - select HAVE_CBPF_JIT if CPU_BIG_ENDIAN
>  -select HAVE_CBPF_JIT if !PPC64
> ++select HAVE_CBPF_JIT if !PPC64 && CPU_BIG_ENDIAN

'if !PPC64' condition is sufficient, though having the BIG_ENDIAN check 
should be ok too.

Thanks,
Naveen

> + select HAVE_EBPF_JIT if PPC64
>   select HAVE_ARCH_JUMP_LABEL
>   select ARCH_HAVE_NMI_SAFE_CMPXCHG
>   select ARCH_HAS_GCOV_PROFILE_ALL
> 

Re: linux-next: manual merge of the powerpc tree with Linus' tree

[Naveen N. Rao]

On 2016/06/29 10:35AM, Stephen Rothwell wrote:
> Hi all,

Hi Stephen,

> 
> Today's linux-next merge of the powerpc tree got a conflict in:
> 
>   arch/powerpc/Kconfig
> 
> between commit:
> 
>   844e3be47693 ("powerpc/bpf/jit: Disable classic BPF JIT on ppc64le")

Ah, I see that the above commit is not part of powerpc next tree, which 
explains the conflict.

> 
> from Linus' tree and commit:
> 
>   156d0e290e96 ("powerpc/ebpf/jit: Implement JIT compiler for extended BPF")
> 
> from the powerpc tree.
> 
> I fixed it up (see below - I am not sure this entirely correct) and can
> carry the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging.  You may
> also want to consider cooperating with the maintainer of the
> conflicting tree to minimise any particularly complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc arch/powerpc/Kconfig
> index 0a9d439bcda6,ee82f9a09a85..
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@@ -128,7 -128,8 +128,8 @@@ config PP
>   select IRQ_FORCED_THREADING
>   select HAVE_RCU_TABLE_FREE if SMP
>   select HAVE_SYSCALL_TRACEPOINTS
> - select HAVE_CBPF_JIT if CPU_BIG_ENDIAN
>  -select HAVE_CBPF_JIT if !PPC64
> ++select HAVE_CBPF_JIT if !PPC64 && CPU_BIG_ENDIAN

'if !PPC64' condition is sufficient, though having the BIG_ENDIAN check 
should be ok too.

Thanks,
Naveen

> + select HAVE_EBPF_JIT if PPC64
>   select HAVE_ARCH_JUMP_LABEL
>   select ARCH_HAVE_NMI_SAFE_CMPXCHG
>   select ARCH_HAS_GCOV_PROFILE_ALL
> 

Re: [PATCH] platform:x86 Remove Monitor MWAIT feature dependency

[Darren Hart]

On Thu, Jun 23, 2016 at 02:59:58PM +0800, ong.hock...@intel.com wrote:
> From: "Yu, Ong Hock" 
> 
> Telemetry capability does not depend on Monitor MWAIT feature.

Thank you Ong Hock, queued to testing for 4.8.
> 
> Signed-off-by: Yu, Ong Hock 
> ---
>  drivers/platform/x86/intel_telemetry_debugfs.c | 2 +-
>  drivers/platform/x86/intel_telemetry_pltdrv.c  | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/platform/x86/intel_telemetry_debugfs.c 
> b/drivers/platform/x86/intel_telemetry_debugfs.c
> index f5134ac..d76ee59 100644
> --- a/drivers/platform/x86/intel_telemetry_debugfs.c
> +++ b/drivers/platform/x86/intel_telemetry_debugfs.c
> @@ -78,7 +78,7 @@
>  #define TELEM_EVT_LEN(x) (sizeof(x)/sizeof((x)[0]))
>  
>  #define TELEM_DEBUGFS_CPU(model, data) \
> - { X86_VENDOR_INTEL, 6, model, X86_FEATURE_MWAIT, (unsigned long)}
> + { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (unsigned long)}
>  
>  #define TELEM_CHECK_AND_PARSE_EVTS(EVTID, EVTNUM, BUF, EVTLOG, EVTDAT, MASK) 
> { \
>   if (evtlog[index].telem_evtid == (EVTID)) { \
> diff --git a/drivers/platform/x86/intel_telemetry_pltdrv.c 
> b/drivers/platform/x86/intel_telemetry_pltdrv.c
> index 09c84a2..e62cee9 100644
> --- a/drivers/platform/x86/intel_telemetry_pltdrv.c
> +++ b/drivers/platform/x86/intel_telemetry_pltdrv.c
> @@ -82,7 +82,7 @@
>  #define TELEM_SET_VERBOSITY_BITS(x, y)   ((x) |= ((y) << 27))
>  
>  #define TELEM_CPU(model, data) \
> - { X86_VENDOR_INTEL, 6, model, X86_FEATURE_MWAIT, (unsigned long) }
> + { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (unsigned long) }
>  
>  enum telemetry_action {
>   TELEM_UPDATE = 0,
> -- 
> 1.9.1
> 
> 

-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH] platform:x86 Remove Monitor MWAIT feature dependency

[Darren Hart]

On Thu, Jun 23, 2016 at 02:59:58PM +0800, ong.hock...@intel.com wrote:
> From: "Yu, Ong Hock" 
> 
> Telemetry capability does not depend on Monitor MWAIT feature.

Thank you Ong Hock, queued to testing for 4.8.
> 
> Signed-off-by: Yu, Ong Hock 
> ---
>  drivers/platform/x86/intel_telemetry_debugfs.c | 2 +-
>  drivers/platform/x86/intel_telemetry_pltdrv.c  | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/platform/x86/intel_telemetry_debugfs.c 
> b/drivers/platform/x86/intel_telemetry_debugfs.c
> index f5134ac..d76ee59 100644
> --- a/drivers/platform/x86/intel_telemetry_debugfs.c
> +++ b/drivers/platform/x86/intel_telemetry_debugfs.c
> @@ -78,7 +78,7 @@
>  #define TELEM_EVT_LEN(x) (sizeof(x)/sizeof((x)[0]))
>  
>  #define TELEM_DEBUGFS_CPU(model, data) \
> - { X86_VENDOR_INTEL, 6, model, X86_FEATURE_MWAIT, (unsigned long)}
> + { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (unsigned long)}
>  
>  #define TELEM_CHECK_AND_PARSE_EVTS(EVTID, EVTNUM, BUF, EVTLOG, EVTDAT, MASK) 
> { \
>   if (evtlog[index].telem_evtid == (EVTID)) { \
> diff --git a/drivers/platform/x86/intel_telemetry_pltdrv.c 
> b/drivers/platform/x86/intel_telemetry_pltdrv.c
> index 09c84a2..e62cee9 100644
> --- a/drivers/platform/x86/intel_telemetry_pltdrv.c
> +++ b/drivers/platform/x86/intel_telemetry_pltdrv.c
> @@ -82,7 +82,7 @@
>  #define TELEM_SET_VERBOSITY_BITS(x, y)   ((x) |= ((y) << 27))
>  
>  #define TELEM_CPU(model, data) \
> - { X86_VENDOR_INTEL, 6, model, X86_FEATURE_MWAIT, (unsigned long) }
> + { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (unsigned long) }
>  
>  enum telemetry_action {
>   TELEM_UPDATE = 0,
> -- 
> 1.9.1
> 
> 

-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH] [linux-next] rtlwifi: Fix typo in printk

[Larry Finger]

On 06/28/2016 10:37 PM, Masanari Iida wrote:

This patch fix spelling typos found in drivers/net/wireless/realtek.

Signed-off-by: Masanari Iida 


Acked--by: Larry Finger 

Thanks,

Larry


---
  drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c   | 2 +-
  drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c | 2 +-
  drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c| 2 +-
  drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c   | 2 +-
  drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c   | 2 +-
  drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c| 2 +-
  drivers/net/wireless/realtek/rtlwifi/rtl8723be/phy.c   | 2 +-
  7 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c
index 416a9ba6382e..422c7813f5ee 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c
@@ -1239,7 +1239,7 @@ u8 rtl88e_phy_sw_chnl(struct ieee80211_hw *hw)
if (!(is_hal_stop(rtlhal)) && !(RT_CANNOT_IO(hw))) {
rtl88e_phy_sw_chnl_callback(hw);
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
-"sw_chnl_inprogress false schdule workitem current channel 
%d\n",
+"sw_chnl_inprogress false schedule workitem current channel 
%d\n",
 rtlphy->current_channel);
rtlphy->sw_chnl_inprogress = false;
} else {
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
index 77e61b19bf36..9301583ce768 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
@@ -757,7 +757,7 @@ u8 rtl92c_phy_sw_chnl(struct ieee80211_hw *hw)
if (!(is_hal_stop(rtlhal)) && !(RT_CANNOT_IO(hw))) {
rtl92c_phy_sw_chnl_callback(hw);
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
-"sw_chnl_inprogress false schdule workitem\n");
+"sw_chnl_inprogress false schedule workitem\n");
rtlphy->sw_chnl_inprogress = false;
} else {
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c
index 459f3d0efa2f..0a5c9fcfe73b 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c
@@ -496,7 +496,7 @@ static void rtl92ee_dm_find_minimum_rssi(struct 
ieee80211_hw *hw)
rtl_dm_dig->min_undec_pwdb_for_dm =
rtlpriv->dm.entry_min_undec_sm_pwdb;
RT_TRACE(rtlpriv, COMP_BB_POWERSAVING, DBG_LOUD,
-"AP Ext Port or disconnet PWDB = 0x%x\n",
+"AP Ext Port or disconnect PWDB = 0x%x\n",
 rtl_dm_dig->min_undec_pwdb_for_dm);
}
RT_TRACE(rtlpriv, COMP_DIG, DBG_LOUD,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c
index c2bf8d1a7af3..97d9a8e209f1 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c
@@ -1819,7 +1819,7 @@ u8 rtl92ee_phy_sw_chnl(struct ieee80211_hw *hw)
if (!(is_hal_stop(rtlhal)) && !(RT_CANNOT_IO(hw))) {
rtl92ee_phy_sw_chnl_callback(hw);
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
-"sw_chnl_inprogress false schdule workitem current channel 
%d\n",
+"sw_chnl_inprogress false schedule workitem current channel 
%d\n",
 rtlphy->current_channel);
rtlphy->sw_chnl_inprogress = false;
} else {
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c
index d367097f490b..e9a9bbf44966 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c
@@ -893,7 +893,7 @@ u8 rtl8723e_phy_sw_chnl(struct ieee80211_hw *hw)
if (!(is_hal_stop(rtlhal)) && !(RT_CANNOT_IO(hw))) {
rtl8723e_phy_sw_chnl_callback(hw);
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
-"sw_chnl_inprogress false schdule workitem\n");
+"sw_chnl_inprogress false schedule workitem\n");
rtlphy->sw_chnl_inprogress = false;
} else {
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
index 08288ac9020a..97ae14d48840 100644
--- 

Re: [PATCH] [linux-next] rtlwifi: Fix typo in printk

[Larry Finger]

On 06/28/2016 10:37 PM, Masanari Iida wrote:

This patch fix spelling typos found in drivers/net/wireless/realtek.

Signed-off-by: Masanari Iida 


Acked--by: Larry Finger 

Thanks,

Larry


---
  drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c   | 2 +-
  drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c | 2 +-
  drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c| 2 +-
  drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c   | 2 +-
  drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c   | 2 +-
  drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c| 2 +-
  drivers/net/wireless/realtek/rtlwifi/rtl8723be/phy.c   | 2 +-
  7 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c
index 416a9ba6382e..422c7813f5ee 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c
@@ -1239,7 +1239,7 @@ u8 rtl88e_phy_sw_chnl(struct ieee80211_hw *hw)
if (!(is_hal_stop(rtlhal)) && !(RT_CANNOT_IO(hw))) {
rtl88e_phy_sw_chnl_callback(hw);
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
-"sw_chnl_inprogress false schdule workitem current channel 
%d\n",
+"sw_chnl_inprogress false schedule workitem current channel 
%d\n",
 rtlphy->current_channel);
rtlphy->sw_chnl_inprogress = false;
} else {
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
index 77e61b19bf36..9301583ce768 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
@@ -757,7 +757,7 @@ u8 rtl92c_phy_sw_chnl(struct ieee80211_hw *hw)
if (!(is_hal_stop(rtlhal)) && !(RT_CANNOT_IO(hw))) {
rtl92c_phy_sw_chnl_callback(hw);
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
-"sw_chnl_inprogress false schdule workitem\n");
+"sw_chnl_inprogress false schedule workitem\n");
rtlphy->sw_chnl_inprogress = false;
} else {
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c
index 459f3d0efa2f..0a5c9fcfe73b 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c
@@ -496,7 +496,7 @@ static void rtl92ee_dm_find_minimum_rssi(struct 
ieee80211_hw *hw)
rtl_dm_dig->min_undec_pwdb_for_dm =
rtlpriv->dm.entry_min_undec_sm_pwdb;
RT_TRACE(rtlpriv, COMP_BB_POWERSAVING, DBG_LOUD,
-"AP Ext Port or disconnet PWDB = 0x%x\n",
+"AP Ext Port or disconnect PWDB = 0x%x\n",
 rtl_dm_dig->min_undec_pwdb_for_dm);
}
RT_TRACE(rtlpriv, COMP_DIG, DBG_LOUD,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c
index c2bf8d1a7af3..97d9a8e209f1 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c
@@ -1819,7 +1819,7 @@ u8 rtl92ee_phy_sw_chnl(struct ieee80211_hw *hw)
if (!(is_hal_stop(rtlhal)) && !(RT_CANNOT_IO(hw))) {
rtl92ee_phy_sw_chnl_callback(hw);
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
-"sw_chnl_inprogress false schdule workitem current channel 
%d\n",
+"sw_chnl_inprogress false schedule workitem current channel 
%d\n",
 rtlphy->current_channel);
rtlphy->sw_chnl_inprogress = false;
} else {
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c
index d367097f490b..e9a9bbf44966 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c
@@ -893,7 +893,7 @@ u8 rtl8723e_phy_sw_chnl(struct ieee80211_hw *hw)
if (!(is_hal_stop(rtlhal)) && !(RT_CANNOT_IO(hw))) {
rtl8723e_phy_sw_chnl_callback(hw);
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
-"sw_chnl_inprogress false schdule workitem\n");
+"sw_chnl_inprogress false schedule workitem\n");
rtlphy->sw_chnl_inprogress = false;
} else {
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
index 08288ac9020a..97ae14d48840 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
+++ 

Re: [PATCH] platform/x86: Add IIO dependency to ACPI_TOSHIBA

[Azael Avalos]

2016-06-28 23:16 GMT-06:00 Darren Hart :
> On Tue, Jun 28, 2016 at 01:58:55PM -0600, Azael Avalos wrote:
>> The toshiba_acpi driver added support to the accelerometer axis
>> via the IIO subsystem, but failed to add the dependency to the
>> Kconfig file, making the driver fail to compile if the IIO
>> subsystem is not selected.
>>
>> This patch adds a depedency to the IIO subsystem to the
>> ACPI_TOSHIBA entry in Kconfig to avoid such build failure.
>>
>> Signed-off-by: Azael Avalos 
>> ---
>> Darren, Jonathan:
>>  I just received a few mails from the kbuild test robot informing
>>  the build failure, as a fix for this I just added a hard dependency
>>  to IIO, but maybe Jonathan can weigh in and provide me with a better
>>  alternative (perhaps some ifdefs) as to the hard IIO dependency.
>
> Don't you just love the giant kernel builder in the sky?

I certainly do, the ever watching eye XD

>
> Rather than add this separately and leave a potential build failure in the
> kernel, I'll add this line to:
>
> toshiba_acpi: Add IIO interface for accelerometer axis data

Great :-)

>
>>
>>  drivers/platform/x86/Kconfig | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
>> index c06bb85..633fc5c 100644
>> --- a/drivers/platform/x86/Kconfig
>> +++ b/drivers/platform/x86/Kconfig
>> @@ -669,6 +669,7 @@ config ACPI_TOSHIBA
>>   depends on SERIO_I8042 || SERIO_I8042 = n
>>   depends on ACPI_VIDEO || ACPI_VIDEO = n
>>   depends on RFKILL || RFKILL = n
>> + depends on IIO
>>   select INPUT_POLLDEV
>>   select INPUT_SPARSEKMAP
>>   ---help---
>> --
>> 2.8.4
>>
>>
>
> --
> Darren Hart
> Intel Open Source Technology Center



-- 
-- El mundo apesta y vosotros apestais tambien --

Re: [PATCH] platform/x86: Add IIO dependency to ACPI_TOSHIBA

[Azael Avalos]

2016-06-28 23:16 GMT-06:00 Darren Hart :
> On Tue, Jun 28, 2016 at 01:58:55PM -0600, Azael Avalos wrote:
>> The toshiba_acpi driver added support to the accelerometer axis
>> via the IIO subsystem, but failed to add the dependency to the
>> Kconfig file, making the driver fail to compile if the IIO
>> subsystem is not selected.
>>
>> This patch adds a depedency to the IIO subsystem to the
>> ACPI_TOSHIBA entry in Kconfig to avoid such build failure.
>>
>> Signed-off-by: Azael Avalos 
>> ---
>> Darren, Jonathan:
>>  I just received a few mails from the kbuild test robot informing
>>  the build failure, as a fix for this I just added a hard dependency
>>  to IIO, but maybe Jonathan can weigh in and provide me with a better
>>  alternative (perhaps some ifdefs) as to the hard IIO dependency.
>
> Don't you just love the giant kernel builder in the sky?

I certainly do, the ever watching eye XD

>
> Rather than add this separately and leave a potential build failure in the
> kernel, I'll add this line to:
>
> toshiba_acpi: Add IIO interface for accelerometer axis data

Great :-)

>
>>
>>  drivers/platform/x86/Kconfig | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
>> index c06bb85..633fc5c 100644
>> --- a/drivers/platform/x86/Kconfig
>> +++ b/drivers/platform/x86/Kconfig
>> @@ -669,6 +669,7 @@ config ACPI_TOSHIBA
>>   depends on SERIO_I8042 || SERIO_I8042 = n
>>   depends on ACPI_VIDEO || ACPI_VIDEO = n
>>   depends on RFKILL || RFKILL = n
>> + depends on IIO
>>   select INPUT_POLLDEV
>>   select INPUT_SPARSEKMAP
>>   ---help---
>> --
>> 2.8.4
>>
>>
>
> --
> Darren Hart
> Intel Open Source Technology Center



-- 
-- El mundo apesta y vosotros apestais tambien --

Re: [PATCH v12 0/3] printk: Make printk() completely async

[Joe Perches]

On Wed, 2016-06-29 at 14:08 +0900, Sergey Senozhatsky wrote:
> the patch to fix the async KERN_CONT printk regression I mentioned
> several days ago in another thread.

KERN_CONT is effectively a no-op.
This is any printk without a KERN_

Re: [PATCH] platform/x86: Add IIO dependency to ACPI_TOSHIBA

[Darren Hart]

On Tue, Jun 28, 2016 at 01:58:55PM -0600, Azael Avalos wrote:
> The toshiba_acpi driver added support to the accelerometer axis
> via the IIO subsystem, but failed to add the dependency to the
> Kconfig file, making the driver fail to compile if the IIO
> subsystem is not selected.
> 
> This patch adds a depedency to the IIO subsystem to the
> ACPI_TOSHIBA entry in Kconfig to avoid such build failure.
> 
> Signed-off-by: Azael Avalos 
> ---
> Darren, Jonathan:
>  I just received a few mails from the kbuild test robot informing
>  the build failure, as a fix for this I just added a hard dependency
>  to IIO, but maybe Jonathan can weigh in and provide me with a better
>  alternative (perhaps some ifdefs) as to the hard IIO dependency.

Don't you just love the giant kernel builder in the sky?

Rather than add this separately and leave a potential build failure in the
kernel, I'll add this line to:

toshiba_acpi: Add IIO interface for accelerometer axis data

> 
>  drivers/platform/x86/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> index c06bb85..633fc5c 100644
> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -669,6 +669,7 @@ config ACPI_TOSHIBA
>   depends on SERIO_I8042 || SERIO_I8042 = n
>   depends on ACPI_VIDEO || ACPI_VIDEO = n
>   depends on RFKILL || RFKILL = n
> + depends on IIO
>   select INPUT_POLLDEV
>   select INPUT_SPARSEKMAP
>   ---help---
> -- 
> 2.8.4
> 
> 

-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH v12 0/3] printk: Make printk() completely async

[Joe Perches]

On Wed, 2016-06-29 at 14:08 +0900, Sergey Senozhatsky wrote:
> the patch to fix the async KERN_CONT printk regression I mentioned
> several days ago in another thread.

KERN_CONT is effectively a no-op.
This is any printk without a KERN_

Re: [PATCH] platform/x86: Add IIO dependency to ACPI_TOSHIBA

[Darren Hart]

On Tue, Jun 28, 2016 at 01:58:55PM -0600, Azael Avalos wrote:
> The toshiba_acpi driver added support to the accelerometer axis
> via the IIO subsystem, but failed to add the dependency to the
> Kconfig file, making the driver fail to compile if the IIO
> subsystem is not selected.
> 
> This patch adds a depedency to the IIO subsystem to the
> ACPI_TOSHIBA entry in Kconfig to avoid such build failure.
> 
> Signed-off-by: Azael Avalos 
> ---
> Darren, Jonathan:
>  I just received a few mails from the kbuild test robot informing
>  the build failure, as a fix for this I just added a hard dependency
>  to IIO, but maybe Jonathan can weigh in and provide me with a better
>  alternative (perhaps some ifdefs) as to the hard IIO dependency.

Don't you just love the giant kernel builder in the sky?

Rather than add this separately and leave a potential build failure in the
kernel, I'll add this line to:

toshiba_acpi: Add IIO interface for accelerometer axis data

> 
>  drivers/platform/x86/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> index c06bb85..633fc5c 100644
> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -669,6 +669,7 @@ config ACPI_TOSHIBA
>   depends on SERIO_I8042 || SERIO_I8042 = n
>   depends on ACPI_VIDEO || ACPI_VIDEO = n
>   depends on RFKILL || RFKILL = n
> + depends on IIO
>   select INPUT_POLLDEV
>   select INPUT_SPARSEKMAP
>   ---help---
> -- 
> 2.8.4
> 
> 

-- 
Darren Hart
Intel Open Source Technology Center

[PATCH 1/2] x86/apic: shutdown local APIC before I/O APIC during crash

[Wei Jiangang]

commit <522e66464467> disables I/O APIC before shutdown of
the local APIC for both reboot and crash path.
and commit <2885432aaf15> declares that 'it still makes sense to
quiet IO APIC before disabling Local APIC'.

However, the former introduced a bug for crashdown.
If specify 'notsc' for capture-kernel, and then trigger crashdown.
The capture-kernel will be blocked at calibrate_delay_converge().

/* wait for "start of" clock tick */
ticks = jiffies;
while (ticks == jiffies)
; /* nothing */

serial console log as following,

[0.00] Linux version 4.7.0-rc2+ (root@localhost.localdomain)
(gcc version 4.8.2 20140120 (Red Hat 4.8.2-16) (GCC) ) #2 SMP Wed Jun
156
[0.00] Kernel command line: BOOT_IMAGE=/vmlinuz-4.7.0-rc2+
root=/dev/mapper/centos-root ro rd.lvm.lv=centos/swap
vconsole.font=latarcyrheb-sun16 rd.lvm.lv=centos/root crashkernel=256M
vconsole.keymap=us console=tty0 console=ttyS0,115200n8 LANG=en_US.UTF-8
irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off
panic=10 rootflags=nofail acpi_no_memhotplug notsc

[0.00] tsc: Kernel compiled with CONFIG_X86_TSC, cannot disable
TSC completely

[0.00] clocksource: hpet: mask: 0x max_cycles:
0x, max_idle_ns: 133484882848 ns
[0.00] tsc: Fast TSC calibration using PIT
[0.00] tsc: Detected 3192.714 MHz processor
[0.00] Calibrating delay loop...

The bug remains and unsolved for a long time, since 2013.
I find the arch-criminal by bisect.

The commit <522e66464467> used to fix erratum AVR31 for "Intel Atom
Processor C2000 Product Family Specification Update".
You can find the doc at http://www.intel.com/content/dam/www/public/us
/en/documents/specification-updates/atom-c2000-family-spec-update.pdf.

IMO,
It doesn't make sense that change the order of disabling between
I/O APIC and local APIC just for a certain model C2000.
And I couldn't find any related descriptions for Intel 64 and IA-32 Arch.

so, I want to revert the crash part of commit <522e66464467>.

Signed-off-by: Wei Jiangang 
---
 arch/x86/kernel/crash.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 9ef978d69c22..9aa0235c1f7d 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -179,12 +179,13 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
 */
cpu_emergency_stop_pt();
 
+   lapic_shutdown();
 #ifdef CONFIG_X86_IO_APIC
/* Prevent crash_kexec() from deadlocking on ioapic_lock. */
ioapic_zap_locks();
disable_IO_APIC();
 #endif
-   lapic_shutdown();
+
 #ifdef CONFIG_HPET_TIMER
hpet_disable();
 #endif
-- 
1.9.3

[PATCH 1/2] x86/apic: shutdown local APIC before I/O APIC during crash

[Wei Jiangang]

commit <522e66464467> disables I/O APIC before shutdown of
the local APIC for both reboot and crash path.
and commit <2885432aaf15> declares that 'it still makes sense to
quiet IO APIC before disabling Local APIC'.

However, the former introduced a bug for crashdown.
If specify 'notsc' for capture-kernel, and then trigger crashdown.
The capture-kernel will be blocked at calibrate_delay_converge().

/* wait for "start of" clock tick */
ticks = jiffies;
while (ticks == jiffies)
; /* nothing */

serial console log as following,

[0.00] Linux version 4.7.0-rc2+ (root@localhost.localdomain)
(gcc version 4.8.2 20140120 (Red Hat 4.8.2-16) (GCC) ) #2 SMP Wed Jun
156
[0.00] Kernel command line: BOOT_IMAGE=/vmlinuz-4.7.0-rc2+
root=/dev/mapper/centos-root ro rd.lvm.lv=centos/swap
vconsole.font=latarcyrheb-sun16 rd.lvm.lv=centos/root crashkernel=256M
vconsole.keymap=us console=tty0 console=ttyS0,115200n8 LANG=en_US.UTF-8
irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off
panic=10 rootflags=nofail acpi_no_memhotplug notsc

[0.00] tsc: Kernel compiled with CONFIG_X86_TSC, cannot disable
TSC completely

[0.00] clocksource: hpet: mask: 0x max_cycles:
0x, max_idle_ns: 133484882848 ns
[0.00] tsc: Fast TSC calibration using PIT
[0.00] tsc: Detected 3192.714 MHz processor
[0.00] Calibrating delay loop...

The bug remains and unsolved for a long time, since 2013.
I find the arch-criminal by bisect.

The commit <522e66464467> used to fix erratum AVR31 for "Intel Atom
Processor C2000 Product Family Specification Update".
You can find the doc at http://www.intel.com/content/dam/www/public/us
/en/documents/specification-updates/atom-c2000-family-spec-update.pdf.

IMO,
It doesn't make sense that change the order of disabling between
I/O APIC and local APIC just for a certain model C2000.
And I couldn't find any related descriptions for Intel 64 and IA-32 Arch.

so, I want to revert the crash part of commit <522e66464467>.

Signed-off-by: Wei Jiangang 
---
 arch/x86/kernel/crash.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 9ef978d69c22..9aa0235c1f7d 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -179,12 +179,13 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
 */
cpu_emergency_stop_pt();
 
+   lapic_shutdown();
 #ifdef CONFIG_X86_IO_APIC
/* Prevent crash_kexec() from deadlocking on ioapic_lock. */
ioapic_zap_locks();
disable_IO_APIC();
 #endif
-   lapic_shutdown();
+
 #ifdef CONFIG_HPET_TIMER
hpet_disable();
 #endif
-- 
1.9.3

Re: [RESEND PATCH] x86/mm: only allow memmap=XX!YY over existing RAM

[Yigal Korman]

On Wed, Jun 29, 2016 at 4:09 AM, Dan Williams  wrote:
>
> On Tue, Jun 28, 2016 at 10:58 AM, H. Peter Anvin  wrote:
> > On 06/28/16 09:33, Dan Williams wrote:
> >> On Tue, Jun 28, 2016 at 1:31 AM, Yigal Korman  wrote:
> >>> Before this patch, passing a range that is beyond the physical memory
> >>> range will succeed, the user will see a /dev/pmem0 and will be able to
> >>> access it. Reads will always return 0 and writes will be silently
> >>> ignored.
> >>>
> >>> I've gotten more than one bug report about mkfs.{xfs,ext4} or nvml
> >>> failing that were eventually tracked down to be wrong values passed to
> >>> memmap.
> >>>
> >>> This patch prevents the above issue by instead of adding a new memory
> >>> range, only update a RAM memory range with the PRAM type. This way,
> >>> passing the wrong memmap will either not give you a pmem at all or give
> >>> you a smaller one that actually has RAM behind it.
> >>>
> >>> And if someone still needs to fake a pmem that doesn't have RAM behind
> >>> it, they can simply do memmap=XX@YY,XX!YY.
> >>>
> >>> Signed-off-by: Yigal Korman 
> >>> Acked-by: Dan Williams 
> >>> Acked-by: Johannes Thumshirn 
> >>> Tested-by: Boaz Harrosh 
> >>> ---
> >>
> >> I have some other libnvdimm fixes heading upstream shortly if x86
> >> folks just want to ack this one...
> >>
> >
> > I'm concerned about this.  This would mean that memory not marked as RAM
> > because it is persistent and you don't want the OS to accidentally
> > clobber persistent RAM can't be added.
>
> Ah true.  Specifically you are worried about the case where a
> platform-firmware has mis-marked pmem as reserved memory (or some
> other type) and would like to correct it to be pram.


As I mentioned in the patch, this is still possible by doing memmap=X@Y,X!Y
Also, with fixes in grub and the kernel regarding mis-marking NVDIMMs
this is much less common today.
My purpose was simply to prevent a repeating user error for the common use case.

>
>
> > So it seems like The Wrong
> > Thing.  If all you want is simulated pram then it shouldn't care about
> > addresses in the first place and instead we should just specify it by
> > quantity.
>
> Yes, agree we need an explicit "simulate pram" option independent of
> memmap=, or just continue to educate users that if they try to
> simulate pmem and specify an invalid range they get to keep all the
> broken pieces.

I'd love to have a simpler way to specify simulated pram, but quantity
is not good enough.
For my use case, for example, I need the quantity to be spread evenly
over all NUMA nodes, so just getting a range "somewhere" is not good.
And I can imagine other users that want to pin pram to same socket
where their high speed NIC sits.
So I not sure we can find a better general api than memmap and I not
sure it's worth it.

Thanks,
Yigal

Re: [RESEND PATCH] x86/mm: only allow memmap=XX!YY over existing RAM

[Yigal Korman]

On Wed, Jun 29, 2016 at 4:09 AM, Dan Williams  wrote:
>
> On Tue, Jun 28, 2016 at 10:58 AM, H. Peter Anvin  wrote:
> > On 06/28/16 09:33, Dan Williams wrote:
> >> On Tue, Jun 28, 2016 at 1:31 AM, Yigal Korman  wrote:
> >>> Before this patch, passing a range that is beyond the physical memory
> >>> range will succeed, the user will see a /dev/pmem0 and will be able to
> >>> access it. Reads will always return 0 and writes will be silently
> >>> ignored.
> >>>
> >>> I've gotten more than one bug report about mkfs.{xfs,ext4} or nvml
> >>> failing that were eventually tracked down to be wrong values passed to
> >>> memmap.
> >>>
> >>> This patch prevents the above issue by instead of adding a new memory
> >>> range, only update a RAM memory range with the PRAM type. This way,
> >>> passing the wrong memmap will either not give you a pmem at all or give
> >>> you a smaller one that actually has RAM behind it.
> >>>
> >>> And if someone still needs to fake a pmem that doesn't have RAM behind
> >>> it, they can simply do memmap=XX@YY,XX!YY.
> >>>
> >>> Signed-off-by: Yigal Korman 
> >>> Acked-by: Dan Williams 
> >>> Acked-by: Johannes Thumshirn 
> >>> Tested-by: Boaz Harrosh 
> >>> ---
> >>
> >> I have some other libnvdimm fixes heading upstream shortly if x86
> >> folks just want to ack this one...
> >>
> >
> > I'm concerned about this.  This would mean that memory not marked as RAM
> > because it is persistent and you don't want the OS to accidentally
> > clobber persistent RAM can't be added.
>
> Ah true.  Specifically you are worried about the case where a
> platform-firmware has mis-marked pmem as reserved memory (or some
> other type) and would like to correct it to be pram.


As I mentioned in the patch, this is still possible by doing memmap=X@Y,X!Y
Also, with fixes in grub and the kernel regarding mis-marking NVDIMMs
this is much less common today.
My purpose was simply to prevent a repeating user error for the common use case.

>
>
> > So it seems like The Wrong
> > Thing.  If all you want is simulated pram then it shouldn't care about
> > addresses in the first place and instead we should just specify it by
> > quantity.
>
> Yes, agree we need an explicit "simulate pram" option independent of
> memmap=, or just continue to educate users that if they try to
> simulate pmem and specify an invalid range they get to keep all the
> broken pieces.

I'd love to have a simpler way to specify simulated pram, but quantity
is not good enough.
For my use case, for example, I need the quantity to be spread evenly
over all NUMA nodes, so just getting a range "somewhere" is not good.
And I can imagine other users that want to pin pram to same socket
where their high speed NIC sits.
So I not sure we can find a better general api than memmap and I not
sure it's worth it.

Thanks,
Yigal

Re: [PATCH 1/1] gpio: max77620: get gpio value based on direction

[Alexandre Courbot]

On Mon, Jun 27, 2016 at 7:56 PM, Venkat Reddy Talla
 wrote:
> Gpio direction is determined by DIRx bit of GPIO
> configuration register, return max77620 gpio value
> based on direction in or out.
>
> Signed-off-by: Venkat Reddy Talla 
> ---
>  drivers/gpio/gpio-max77620.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-max77620.c b/drivers/gpio/gpio-max77620.c
> index 8658c32..b46b436 100644
> --- a/drivers/gpio/gpio-max77620.c
> +++ b/drivers/gpio/gpio-max77620.c
> @@ -123,7 +123,10 @@ static int max77620_gpio_get(struct gpio_chip *gc, 
> unsigned int offset)
> return ret;
> }
>
> -   return !!(val & MAX77620_CNFG_GPIO_INPUT_VAL_MASK);
> +   if  (val & MAX77620_CNFG_GPIO_DIR_MASK)
> +   return !!(val & MAX77620_CNFG_GPIO_INPUT_VAL_MASK);
> +   else
> +   return !!(val & MAX77620_CNFG_GPIO_OUTPUT_VAL_MASK);

Looks sensible!

Reviewed-by: Alexandre Courbot 

Re: [PATCH 1/1] gpio: max77620: get gpio value based on direction

[Alexandre Courbot]

On Mon, Jun 27, 2016 at 7:56 PM, Venkat Reddy Talla
 wrote:
> Gpio direction is determined by DIRx bit of GPIO
> configuration register, return max77620 gpio value
> based on direction in or out.
>
> Signed-off-by: Venkat Reddy Talla 
> ---
>  drivers/gpio/gpio-max77620.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-max77620.c b/drivers/gpio/gpio-max77620.c
> index 8658c32..b46b436 100644
> --- a/drivers/gpio/gpio-max77620.c
> +++ b/drivers/gpio/gpio-max77620.c
> @@ -123,7 +123,10 @@ static int max77620_gpio_get(struct gpio_chip *gc, 
> unsigned int offset)
> return ret;
> }
>
> -   return !!(val & MAX77620_CNFG_GPIO_INPUT_VAL_MASK);
> +   if  (val & MAX77620_CNFG_GPIO_DIR_MASK)
> +   return !!(val & MAX77620_CNFG_GPIO_INPUT_VAL_MASK);
> +   else
> +   return !!(val & MAX77620_CNFG_GPIO_OUTPUT_VAL_MASK);

Looks sensible!

Reviewed-by: Alexandre Courbot 

Re: [PATCH v12 0/3] printk: Make printk() completely async

[Sergey Senozhatsky]

Hello,

the patch to fix the async KERN_CONT printk regression I mentioned
several days ago in another thread.

as a separate patch for now, to ease the review. will squash with 0001.

== 8< ==

>From 70f65ed55eb82a1b8b74fdbd1a7afc9e77e9b380 Mon Sep 17 00:00:00 2001
From: Sergey Senozhatsky 
Subject: [PATCH] printk: print KERN_CONT buffer in sync printk mode

One of my boxen has revealed that there is a race condition now between
pr_cot() output and printk_kthread wake_up() time. Schematically, the CPU
that triggered the race conditions was doing
something like this:

for (...) {
for () {
...
pr_cont(...);
...
}
pr_cont("\n");
}

the resulting output was:

$ dmesg

0001 0002 0003 0004 0005 0006 0007
0008
0009 000a 000b 000c 000d 000e
000f 0010 0011 0012 0013 0014 0015
002b 002c 002d 002e 002f 0030 0031



KERN_CONT output is heavily relying on the fact there will be no other
CPU(-s)/process(-es) doing any sort (KERN_CONT etc.) of printk-s simultaneously.
This basically means that pr_cont() CPU is expected to be the one that actually
does the printing and log_store() of the entire cont buffer:

pr_cont()
console_unlock()
console_cont_flush()
log_store() /* cont buffer */
pr_cont()
console_unlock()
console_cont_flush()
log_store() /* cont buffer */


Async printk breaks this contract, because console_cont_flush() is now deferred.
Thus pr_cont() will see a not fully flushed cont buffer, which will force it to
append a new KERN_CONT not to cont buffer, but to buffer log as a separate log
entry via log_store(). Due to the deferred nature of console_cont_flush() the
very next pr_cont() may see cont buffer being flushed, so it will keep the
message in the cont buffer and log_store() it later. So the cont line will split
across several log entries -- printk_kthread can take some time to wkeup,
during which pr_cont() will keep splitting cont line:

$ dmesg

0001 0002 0003 0004 0005 0006 0007
0008
0009
000a
000b
000c
000d
000e


To fix the issue we need to switch to sync printk mode for KERN_CONT messages
and when we cont_flush() the cont buffer.


CPU0CPU1

vprintk_emit(KERN_CONT "0001")
if (!(lflags & LOG_NEWLINE))
cont_add()
if (!cont.len)
starts a new cont line
wake_up() printk_kthread
...

vprintk_emit(KERN_CONT "004")   entering 
console_unlock()
if (!(lflags & LOG_NEWLINE))
cont_add()
wake_up() printk_kthread

vprintk_emit(KERN_CONT "005")
if (!(lflags & LOG_NEWLINE))
cont_add()
wake_up() printk_kthreadconsole_cont_flush()

cont_print_text()

vprintk_emit(KERN_CONT "006")
if (!(lflags & LOG_NEWLINE))
cont_add()
wake_up() printk_kthread
leaving console_unlock()

vprintk_emit(KERN_CONT "007")
if (!(lflags & LOG_NEWLINE))entering 
console_unlock()
cont_add()
wake_up() printk_kthreadconsole_cont_flush()

cont_print_text()
leaving console_unlock()
vprintk_emit(KERN_CONT "\n")
if (lflags & LOG_NEWLINE)
if (cont.len) {
cont_add()
cont_flush()
if (cont.cons) {
cont.flags = flags;
cont.flushed = true;

}
log_store() /* "001 .. 007" */
^^
}
wake_up() process   leaving console_unlock()

vprintk_emit(KERN_CONT "008")
if (!(lflags & LOG_NEWLINE))entering 
console_unlock()
cont_add()
{
if (cont.len && cont.flushed)
^^^  not flushed yet!
return false;
...
}

log_store() /* 

Re: [PATCH v12 0/3] printk: Make printk() completely async

[Sergey Senozhatsky]

Hello,

the patch to fix the async KERN_CONT printk regression I mentioned
several days ago in another thread.

as a separate patch for now, to ease the review. will squash with 0001.

== 8< ==

>From 70f65ed55eb82a1b8b74fdbd1a7afc9e77e9b380 Mon Sep 17 00:00:00 2001
From: Sergey Senozhatsky 
Subject: [PATCH] printk: print KERN_CONT buffer in sync printk mode

One of my boxen has revealed that there is a race condition now between
pr_cot() output and printk_kthread wake_up() time. Schematically, the CPU
that triggered the race conditions was doing
something like this:

for (...) {
for () {
...
pr_cont(...);
...
}
pr_cont("\n");
}

the resulting output was:

$ dmesg

0001 0002 0003 0004 0005 0006 0007
0008
0009 000a 000b 000c 000d 000e
000f 0010 0011 0012 0013 0014 0015
002b 002c 002d 002e 002f 0030 0031



KERN_CONT output is heavily relying on the fact there will be no other
CPU(-s)/process(-es) doing any sort (KERN_CONT etc.) of printk-s simultaneously.
This basically means that pr_cont() CPU is expected to be the one that actually
does the printing and log_store() of the entire cont buffer:

pr_cont()
console_unlock()
console_cont_flush()
log_store() /* cont buffer */
pr_cont()
console_unlock()
console_cont_flush()
log_store() /* cont buffer */


Async printk breaks this contract, because console_cont_flush() is now deferred.
Thus pr_cont() will see a not fully flushed cont buffer, which will force it to
append a new KERN_CONT not to cont buffer, but to buffer log as a separate log
entry via log_store(). Due to the deferred nature of console_cont_flush() the
very next pr_cont() may see cont buffer being flushed, so it will keep the
message in the cont buffer and log_store() it later. So the cont line will split
across several log entries -- printk_kthread can take some time to wkeup,
during which pr_cont() will keep splitting cont line:

$ dmesg

0001 0002 0003 0004 0005 0006 0007
0008
0009
000a
000b
000c
000d
000e


To fix the issue we need to switch to sync printk mode for KERN_CONT messages
and when we cont_flush() the cont buffer.


CPU0CPU1

vprintk_emit(KERN_CONT "0001")
if (!(lflags & LOG_NEWLINE))
cont_add()
if (!cont.len)
starts a new cont line
wake_up() printk_kthread
...

vprintk_emit(KERN_CONT "004")   entering 
console_unlock()
if (!(lflags & LOG_NEWLINE))
cont_add()
wake_up() printk_kthread

vprintk_emit(KERN_CONT "005")
if (!(lflags & LOG_NEWLINE))
cont_add()
wake_up() printk_kthreadconsole_cont_flush()

cont_print_text()

vprintk_emit(KERN_CONT "006")
if (!(lflags & LOG_NEWLINE))
cont_add()
wake_up() printk_kthread
leaving console_unlock()

vprintk_emit(KERN_CONT "007")
if (!(lflags & LOG_NEWLINE))entering 
console_unlock()
cont_add()
wake_up() printk_kthreadconsole_cont_flush()

cont_print_text()
leaving console_unlock()
vprintk_emit(KERN_CONT "\n")
if (lflags & LOG_NEWLINE)
if (cont.len) {
cont_add()
cont_flush()
if (cont.cons) {
cont.flags = flags;
cont.flushed = true;

}
log_store() /* "001 .. 007" */
^^
}
wake_up() process   leaving console_unlock()

vprintk_emit(KERN_CONT "008")
if (!(lflags & LOG_NEWLINE))entering 
console_unlock()
cont_add()
{
if (cont.len && cont.flushed)
^^^  not flushed yet!
return false;
...
}

log_store() /* "008" */

Re: [PATCH 1/2] cgroup: pids: show number of failed forks since limit reset

[Aleksa Sarai]

On Sun, Jun 26, 2016 at 09:34:41PM +1000, Aleksa Sarai wrote:

If a user has a setup where they wait for notifications on changes to
pids.event, and then auto-adjust the cgroup limits based on the number of
failures you have a race condition between reading the pids.event file and
then setting the new limit. Then, upon getting notified again there may have
been many failed forks with the old limit set, so you might decide to bump
up the limit again.

It's not a huge deal, I just though it could be useful to alleviate problems
like the above.


This is something which can easily be avoided from userland.  I don't
think we need to add extra facilities for this.


Maybe I'm misunderstanding what the purpose of pids.events is meant to 
be. If it's just meant to be a "hint" to the administrator, then that 
seems like an awfully odd way of giving hints (the kernel logging should 
be enough for that). If it's meant so that the administrator can make 
policy decisions, then she won't know if the change in failures happened 
before or after she adjusted the limit.


I also don't see what you mean by "it can be avoided from userland". 
There's a race between changing pids.max and a process forking that 
causes pids.events to be updated.


--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/

Re: Review of ptrace Yama ptrace_scope description

[Michael Kerrisk (man-pages)]

Hi Kees,

On 06/28/2016 10:55 PM, Kees Cook wrote:

On Mon, Jun 27, 2016 at 11:11 PM, Michael Kerrisk (man-pages)
 wrote:

Hi Jann,


On 06/25/2016 04:30 PM, Jann Horn wrote:


On Sat, Jun 25, 2016 at 09:30:43AM +0200, Michael Kerrisk (man-pages)
wrote:


Hi Kees,

So, last year, I added some documentation to ptrace(2) to describe
the Yama ptrace_scope file. I don't think I asked you for review
at the time, but in the light of other changes to the ptrace(2)
page, it occurred to me that it might be a good idea to ask you
to check the text below to see if anything is missing or could be
improved. Might you have a moment for that?

   /proc/sys/kernel/yama/ptrace_scope
   On systems with the Yama Linux Security Module (LSM)  installed
   (i.e.,  the  kernel  was configured with CONFIG_SECURITY_YAMA),
   the /proc/sys/kernel/yama/ptrace_scope  file  (available  since
   Linux  3.4)  can  be  used  to  restrict the ability to trace a
   process with ptrace(2) (and thus also the ability to use  tools
   such  as  strace(1) and gdb(1)).  The goal of such restrictions
   is to prevent attack escalation whereby a  compromised  process
   can  ptrace-attach  to  other  sensitive processes (e.g., a GPG
   agent or an SSH session) owned by the user  in  order  to  gain
   additional credentials and thus expand the scope of the attack.


Maybe clarify "additional credentials that may exist in memory only and thus..."


Done.



   More precisely, the Yama LSM limits two types of operations:

   *  Any   operation   that   performs   a   ptrace  access  mode
  PTRACE_MODE_ATTACH check—for  example,  ptrace()
  PTRACE_ATTACH.   (See the "Ptrace access mode checking" dis‐
  cussion above.)

   *  ptrace() PTRACE_TRACEME.

   A process that has the CAP_SYS_PTRACE capability can update the
   /proc/sys/kernel/yama/ptrace_scope file with one of the follow‐
   ing values:

   0 ("classic ptrace permissions")
  No additional restrictions on  operations  that  perform
  PTRACE_MODE_ATTACH  checks  (beyond those imposed by the
  commoncap and other LSMs).

  The use of PTRACE_TRACEME is unchanged.

   1 ("restricted ptrace") [default value]
  When   performing   an   operation   that   requires   a
  PTRACE_MODE_ATTACH  check, the calling process must have
  a predefined relationship with the target  process.   By
  default,  the predefined relationship is that the target
  process must be a child of the caller.

  A target process can employ the prctl(2)  PR_SET_PTRACER
  operation  to declare a different PID that is allowed to
  perform PTRACE_MODE_ATTACH  operations  on  the  target.
  See   the   kernel   source   file   Documentation/secu‐
  rity/Yama.txt for further details.

  The use of PTRACE_TRACEME is unchanged.



(namespaced) CAP_SYS_PTRACE is also sufficient here.


Both here and in the "admin-only attach" case, it is IMO important to
note that creating a user namespace effectively removes the Yama
protection because the owner of a namespace, when accessing its
contents from outside, is relatively capable.

This means that when a process tries to use namespaces to sandbox
itself, it inadvertently makes itself more accessible.

(This could probably be worked around in the kernel, but such a
workaround would likely not be default, but rather opt-in via a new
flag for clone() and unshare() or so.)



Tanks for catching this!

So I've made that section of text:

   A  process  that  has the CAP_SYS_PTRACE capability can update the
   /proc/sys/kernel/yama/ptrace_scope file with one of the  following
   values:

   0 ("classic ptrace permissions")
  No  additional  restrictions  on  operations  that  perform
  PTRACE_MODE_ATTACH checks (beyond those imposed by the com‐
  moncap and other LSMs).

  The use of PTRACE_TRACEME is unchanged.

   1 ("restricted ptrace") [default value]
  Whenperforminganoperation   that   requires   a
  PTRACE_MODE_ATTACH check, the calling process  must  either
  have the CAP_SYS_PTRACE capability in the user namespace of
  the target process or it  have  a  predefined  relationship
  with  the target process.  By default, the predefined rela‐
  tionship is that the target process must be a child of  the
  caller.


More accurately, must be a descendant of the caller (grand child is fine, etc).


Thanks, Fixed.





  A  target  process  can  employ the prctl(2) PR_SET_PTRACER
  operation to declare a different PID  that  is  allowed  to
  perform  PTRACE_MODE_ATTACH  operations on the 

Re: [PATCH 1/2] cgroup: pids: show number of failed forks since limit reset

[Aleksa Sarai]

On Sun, Jun 26, 2016 at 09:34:41PM +1000, Aleksa Sarai wrote:

If a user has a setup where they wait for notifications on changes to
pids.event, and then auto-adjust the cgroup limits based on the number of
failures you have a race condition between reading the pids.event file and
then setting the new limit. Then, upon getting notified again there may have
been many failed forks with the old limit set, so you might decide to bump
up the limit again.

It's not a huge deal, I just though it could be useful to alleviate problems
like the above.


This is something which can easily be avoided from userland.  I don't
think we need to add extra facilities for this.


Maybe I'm misunderstanding what the purpose of pids.events is meant to 
be. If it's just meant to be a "hint" to the administrator, then that 
seems like an awfully odd way of giving hints (the kernel logging should 
be enough for that). If it's meant so that the administrator can make 
policy decisions, then she won't know if the change in failures happened 
before or after she adjusted the limit.


I also don't see what you mean by "it can be avoided from userland". 
There's a race between changing pids.max and a process forking that 
causes pids.events to be updated.


--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/

Re: Review of ptrace Yama ptrace_scope description

[Michael Kerrisk (man-pages)]

Hi Kees,

On 06/28/2016 10:55 PM, Kees Cook wrote:

On Mon, Jun 27, 2016 at 11:11 PM, Michael Kerrisk (man-pages)
 wrote:

Hi Jann,


On 06/25/2016 04:30 PM, Jann Horn wrote:


On Sat, Jun 25, 2016 at 09:30:43AM +0200, Michael Kerrisk (man-pages)
wrote:


Hi Kees,

So, last year, I added some documentation to ptrace(2) to describe
the Yama ptrace_scope file. I don't think I asked you for review
at the time, but in the light of other changes to the ptrace(2)
page, it occurred to me that it might be a good idea to ask you
to check the text below to see if anything is missing or could be
improved. Might you have a moment for that?

   /proc/sys/kernel/yama/ptrace_scope
   On systems with the Yama Linux Security Module (LSM)  installed
   (i.e.,  the  kernel  was configured with CONFIG_SECURITY_YAMA),
   the /proc/sys/kernel/yama/ptrace_scope  file  (available  since
   Linux  3.4)  can  be  used  to  restrict the ability to trace a
   process with ptrace(2) (and thus also the ability to use  tools
   such  as  strace(1) and gdb(1)).  The goal of such restrictions
   is to prevent attack escalation whereby a  compromised  process
   can  ptrace-attach  to  other  sensitive processes (e.g., a GPG
   agent or an SSH session) owned by the user  in  order  to  gain
   additional credentials and thus expand the scope of the attack.


Maybe clarify "additional credentials that may exist in memory only and thus..."


Done.



   More precisely, the Yama LSM limits two types of operations:

   *  Any   operation   that   performs   a   ptrace  access  mode
  PTRACE_MODE_ATTACH check—for  example,  ptrace()
  PTRACE_ATTACH.   (See the "Ptrace access mode checking" dis‐
  cussion above.)

   *  ptrace() PTRACE_TRACEME.

   A process that has the CAP_SYS_PTRACE capability can update the
   /proc/sys/kernel/yama/ptrace_scope file with one of the follow‐
   ing values:

   0 ("classic ptrace permissions")
  No additional restrictions on  operations  that  perform
  PTRACE_MODE_ATTACH  checks  (beyond those imposed by the
  commoncap and other LSMs).

  The use of PTRACE_TRACEME is unchanged.

   1 ("restricted ptrace") [default value]
  When   performing   an   operation   that   requires   a
  PTRACE_MODE_ATTACH  check, the calling process must have
  a predefined relationship with the target  process.   By
  default,  the predefined relationship is that the target
  process must be a child of the caller.

  A target process can employ the prctl(2)  PR_SET_PTRACER
  operation  to declare a different PID that is allowed to
  perform PTRACE_MODE_ATTACH  operations  on  the  target.
  See   the   kernel   source   file   Documentation/secu‐
  rity/Yama.txt for further details.

  The use of PTRACE_TRACEME is unchanged.



(namespaced) CAP_SYS_PTRACE is also sufficient here.


Both here and in the "admin-only attach" case, it is IMO important to
note that creating a user namespace effectively removes the Yama
protection because the owner of a namespace, when accessing its
contents from outside, is relatively capable.

This means that when a process tries to use namespaces to sandbox
itself, it inadvertently makes itself more accessible.

(This could probably be worked around in the kernel, but such a
workaround would likely not be default, but rather opt-in via a new
flag for clone() and unshare() or so.)



Tanks for catching this!

So I've made that section of text:

   A  process  that  has the CAP_SYS_PTRACE capability can update the
   /proc/sys/kernel/yama/ptrace_scope file with one of the  following
   values:

   0 ("classic ptrace permissions")
  No  additional  restrictions  on  operations  that  perform
  PTRACE_MODE_ATTACH checks (beyond those imposed by the com‐
  moncap and other LSMs).

  The use of PTRACE_TRACEME is unchanged.

   1 ("restricted ptrace") [default value]
  Whenperforminganoperation   that   requires   a
  PTRACE_MODE_ATTACH check, the calling process  must  either
  have the CAP_SYS_PTRACE capability in the user namespace of
  the target process or it  have  a  predefined  relationship
  with  the target process.  By default, the predefined rela‐
  tionship is that the target process must be a child of  the
  caller.


More accurately, must be a descendant of the caller (grand child is fine, etc).


Thanks, Fixed.





  A  target  process  can  employ the prctl(2) PR_SET_PTRACER
  operation to declare a different PID  that  is  allowed  to
  perform  PTRACE_MODE_ATTACH  operations on the target.  See
 

Re: [PATCH v2] clk: fixed-factor: add optional dt-binding clock-flags

[Jongsung Kim]

On 2016년 06월 29일 05:55, Rob Herring wrote:
> On Fri, Jun 24, 2016 at 01:12:52PM +0900, Jongsung Kim wrote:
>> There is no way to set additional flags for a DT-initialized fixed-
>> factor-clock, and it can be problematic i.e., when the clock rate
>> needs to be changed. [1][2]
>>
>> This patch introduces an optional dt-binding named "clock-flags" to
>> be used for passing any needed flags from dts.
> I don't think we want this in DT. If we did, the flags would need some 
> documentation about what the flags mean.
Thanks for your comment. It looks not that big deal to provide a little 
documentation..? Some of the flags looks safe to be removed. Thinking of only 
fixed-factor-clock, most of them can be removed.

Re: [PATCH v2] clk: fixed-factor: add optional dt-binding clock-flags

[Jongsung Kim]

On 2016년 06월 29일 05:55, Rob Herring wrote:
> On Fri, Jun 24, 2016 at 01:12:52PM +0900, Jongsung Kim wrote:
>> There is no way to set additional flags for a DT-initialized fixed-
>> factor-clock, and it can be problematic i.e., when the clock rate
>> needs to be changed. [1][2]
>>
>> This patch introduces an optional dt-binding named "clock-flags" to
>> be used for passing any needed flags from dts.
> I don't think we want this in DT. If we did, the flags would need some 
> documentation about what the flags mean.
Thanks for your comment. It looks not that big deal to provide a little 
documentation..? Some of the flags looks safe to be removed. Thinking of only 
fixed-factor-clock, most of them can be removed.

Re: [PATCH 0/6] scripts/gdb: Fixes for 4.7

[Jan Kiszka]

On 2016-06-28 17:22, Kieran Bingham wrote:
> Hi Andrew,
> 
> Please consider this series for integration into the current rc series.
> I had hoped to get this to you, with a fixed radix-tree, rather than a
> reverted one. Alas, time has gone against me, and we are nearing the end
> of the window - so having discussed with Jan, we felt it best to simply
> revert the feature for this release.
> 
> Aside from the revert, we have four fairly minor fixups.
> 
> Kieran Bingham (4):
>   scripts/gdb: silence 'nothing to do' message
>   scripts/gdb: rebuild constants.py on dependancy change
>   Revert "scripts/gdb: add a Radix Tree Parser"
>   Revert "scripts/gdb: add documentation example for radix tree"
> 
> Nikolay Borisov (1):
>   scripts/gdb: Perform path expansion to lx-symbol's arguments
> 
> Omar Sandoval (1):
>   scripts/gdb: add constants.py to .gitignore
> 
>  Documentation/gdb-kernel-debugging.txt | 21 
>  scripts/gdb/linux/.gitignore   |  1 +
>  scripts/gdb/linux/Makefile |  6 ++-
>  scripts/gdb/linux/constants.py.in  |  7 ---
>  scripts/gdb/linux/radixtree.py | 97 
> --
>  scripts/gdb/linux/symbols.py   |  2 +-
>  scripts/gdb/vmlinux-gdb.py |  1 -
>  7 files changed, 6 insertions(+), 129 deletions(-)
>  delete mode 100644 scripts/gdb/linux/radixtree.py
> 

For all:
Acked-by: Jan Kiszka 

Thanks!
Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH 0/6] scripts/gdb: Fixes for 4.7

[Jan Kiszka]

On 2016-06-28 17:22, Kieran Bingham wrote:
> Hi Andrew,
> 
> Please consider this series for integration into the current rc series.
> I had hoped to get this to you, with a fixed radix-tree, rather than a
> reverted one. Alas, time has gone against me, and we are nearing the end
> of the window - so having discussed with Jan, we felt it best to simply
> revert the feature for this release.
> 
> Aside from the revert, we have four fairly minor fixups.
> 
> Kieran Bingham (4):
>   scripts/gdb: silence 'nothing to do' message
>   scripts/gdb: rebuild constants.py on dependancy change
>   Revert "scripts/gdb: add a Radix Tree Parser"
>   Revert "scripts/gdb: add documentation example for radix tree"
> 
> Nikolay Borisov (1):
>   scripts/gdb: Perform path expansion to lx-symbol's arguments
> 
> Omar Sandoval (1):
>   scripts/gdb: add constants.py to .gitignore
> 
>  Documentation/gdb-kernel-debugging.txt | 21 
>  scripts/gdb/linux/.gitignore   |  1 +
>  scripts/gdb/linux/Makefile |  6 ++-
>  scripts/gdb/linux/constants.py.in  |  7 ---
>  scripts/gdb/linux/radixtree.py | 97 
> --
>  scripts/gdb/linux/symbols.py   |  2 +-
>  scripts/gdb/vmlinux-gdb.py |  1 -
>  7 files changed, 6 insertions(+), 129 deletions(-)
>  delete mode 100644 scripts/gdb/linux/radixtree.py
> 

For all:
Acked-by: Jan Kiszka 

Thanks!
Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH v2] thermal: add Intel BXT WhiskeyCove PMIC thermal driver

[Manish Badarkhe]

Hi


> +static int pmic_thermal_remove(struct platform_device *pdev)
> +{
> +   return 0;
> +}
> +

Why this remove function still requires?

Regards
Manish Badarkhe

Re: [PATCH v2] thermal: add Intel BXT WhiskeyCove PMIC thermal driver

[Manish Badarkhe]

Hi


> +static int pmic_thermal_remove(struct platform_device *pdev)
> +{
> +   return 0;
> +}
> +

Why this remove function still requires?

Regards
Manish Badarkhe

[PATCH 2/2] time/tick-schede: fix typos

[Wei Jiangang]

When investigating kdump's failure with 'notsc' and
jiffies not incrementing, I found several spelling mistakes

Signed-off-by: Wei Jiangang 
---
 kernel/time/tick-sched.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 536ada80f6dd..6d83e9c4a302 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -61,7 +61,7 @@ static void tick_do_update_jiffies64(ktime_t now)
if (delta.tv64 < tick_period.tv64)
return;
 
-   /* Reevalute with jiffies_lock held */
+   /* Reevaluate with jiffies_lock held */
write_seqlock(_lock);
 
delta = ktime_sub(now, last_jiffies_update);
@@ -117,7 +117,7 @@ static void tick_sched_do_timer(ktime_t now)
/*
 * Check if the do_timer duty was dropped. We don't care about
 * concurrency: This happens only when the cpu in charge went
-* into a long sleep. If two cpus happen to assign themself to
+* into a long sleep. If two cpus happen to assign themselves to
 * this duty, then the jiffies update is still serialized by
 * jiffies_lock.
 */
@@ -571,7 +571,7 @@ static ktime_t tick_nohz_start_idle(struct tick_sched *ts)
  * @last_update_time: variable to store update time in. Do not update
  * counters if NULL.
  *
- * Return the cummulative idle time (since boot) for a given
+ * Return the cumulative idle time (since boot) for a given
  * CPU, in microseconds.
  *
  * This time is measured via accounting rather than sampling,
@@ -612,7 +612,7 @@ EXPORT_SYMBOL_GPL(get_cpu_idle_time_us);
  * @last_update_time: variable to store update time in. Do not update
  * counters if NULL.
  *
- * Return the cummulative iowait time (since boot) for a given
+ * Return the cumulative iowait time (since boot) for a given
  * CPU, in microseconds.
  *
  * This time is measured via accounting rather than sampling,
@@ -733,7 +733,7 @@ static ktime_t tick_nohz_stop_sched_tick(struct tick_sched 
*ts,
 * do_timer() never invoked. Keep track of the fact that it
 * was the one which had the do_timer() duty last. If this cpu
 * is the one which had the do_timer() duty last, we limit the
-* sleep time to the timekeeping max_deferement value.
+* sleep time to the timekeeping max_deferment value.
 * Otherwise we can sleep as long as we want.
 */
delta = timekeeping_max_deferment();
-- 
1.9.3

[PATCH 2/2] time/tick-schede: fix typos

[Wei Jiangang]

When investigating kdump's failure with 'notsc' and
jiffies not incrementing, I found several spelling mistakes

Signed-off-by: Wei Jiangang 
---
 kernel/time/tick-sched.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 536ada80f6dd..6d83e9c4a302 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -61,7 +61,7 @@ static void tick_do_update_jiffies64(ktime_t now)
if (delta.tv64 < tick_period.tv64)
return;
 
-   /* Reevalute with jiffies_lock held */
+   /* Reevaluate with jiffies_lock held */
write_seqlock(_lock);
 
delta = ktime_sub(now, last_jiffies_update);
@@ -117,7 +117,7 @@ static void tick_sched_do_timer(ktime_t now)
/*
 * Check if the do_timer duty was dropped. We don't care about
 * concurrency: This happens only when the cpu in charge went
-* into a long sleep. If two cpus happen to assign themself to
+* into a long sleep. If two cpus happen to assign themselves to
 * this duty, then the jiffies update is still serialized by
 * jiffies_lock.
 */
@@ -571,7 +571,7 @@ static ktime_t tick_nohz_start_idle(struct tick_sched *ts)
  * @last_update_time: variable to store update time in. Do not update
  * counters if NULL.
  *
- * Return the cummulative idle time (since boot) for a given
+ * Return the cumulative idle time (since boot) for a given
  * CPU, in microseconds.
  *
  * This time is measured via accounting rather than sampling,
@@ -612,7 +612,7 @@ EXPORT_SYMBOL_GPL(get_cpu_idle_time_us);
  * @last_update_time: variable to store update time in. Do not update
  * counters if NULL.
  *
- * Return the cummulative iowait time (since boot) for a given
+ * Return the cumulative iowait time (since boot) for a given
  * CPU, in microseconds.
  *
  * This time is measured via accounting rather than sampling,
@@ -733,7 +733,7 @@ static ktime_t tick_nohz_stop_sched_tick(struct tick_sched 
*ts,
 * do_timer() never invoked. Keep track of the fact that it
 * was the one which had the do_timer() duty last. If this cpu
 * is the one which had the do_timer() duty last, we limit the
-* sleep time to the timekeeping max_deferement value.
+* sleep time to the timekeeping max_deferment value.
 * Otherwise we can sleep as long as we want.
 */
delta = timekeeping_max_deferment();
-- 
1.9.3

Re: [PATCHv3 2/2] xenfs: replace xenbus and privcmd with symlinks

[Juergen Gross]

On 28/06/16 20:06, David Vrabel wrote:
> /proc/xen/xenbus does not work correctly.  A read blocked waiting for
> a xenstore message holds the mutex needed for atomic file position
> updates.  This blocks any writes on the same file handle, which can
> deadlock if the write is needed to unblock the read.
> 
> /proc/xen/xenbus is supposed to be identical to the character device
> /dev/xen/xenbus so replace the file with a symlink.
> 
> Similarly, replace /proc/xen/privcmd with a symlink since it should be
> the same as /dev/xen/privcmd.
> 
> Signed-off-by: David Vrabel 
> ---
> v2:
> - remove unneeded includes
> ---

I think you should make xen_xenbus_fops and xen_privcmd_fops static
now that they are no longer referenced by super.c


Juergen

>  drivers/xen/xenfs/super.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
> index 8559a71..0f2e2cd 100644
> --- a/drivers/xen/xenfs/super.c
> +++ b/drivers/xen/xenfs/super.c
> @@ -18,8 +18,6 @@
>  #include 
>  
>  #include "xenfs.h"
> -#include "../privcmd.h"
> -#include "../xenbus/xenbus_comms.h"
>  
>  #include 
>  
> @@ -45,16 +43,16 @@ static const struct file_operations capabilities_file_ops 
> = {
>  static int xenfs_fill_super(struct super_block *sb, void *data, int silent)
>  {
>   static struct tree_descr xenfs_files[] = {
> - [2] = { "xenbus", _xenbus_fops, S_IRUSR|S_IWUSR },
> + [2] = { "xenbus", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/xenbus" 
> },
>   { "capabilities", _file_ops, S_IRUGO },
> - { "privcmd", _privcmd_fops, S_IRUSR|S_IWUSR },
> + { "privcmd", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/privcmd" },
>   {""},
>   };
>  
>   static struct tree_descr xenfs_init_files[] = {
> - [2] = { "xenbus", _xenbus_fops, S_IRUSR|S_IWUSR },
> + [2] = { "xenbus", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/xenbus" 
> },
>   { "capabilities", _file_ops, S_IRUGO },
> - { "privcmd", _privcmd_fops, S_IRUSR|S_IWUSR },
> + { "privcmd", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/privcmd" },
>   { "xsd_kva", _kva_file_ops, S_IRUSR|S_IWUSR},
>   { "xsd_port", _port_file_ops, S_IRUSR|S_IWUSR},
>  #ifdef CONFIG_XEN_SYMS
> 

Re: [PATCHv3 2/2] xenfs: replace xenbus and privcmd with symlinks

[Juergen Gross]

On 28/06/16 20:06, David Vrabel wrote:
> /proc/xen/xenbus does not work correctly.  A read blocked waiting for
> a xenstore message holds the mutex needed for atomic file position
> updates.  This blocks any writes on the same file handle, which can
> deadlock if the write is needed to unblock the read.
> 
> /proc/xen/xenbus is supposed to be identical to the character device
> /dev/xen/xenbus so replace the file with a symlink.
> 
> Similarly, replace /proc/xen/privcmd with a symlink since it should be
> the same as /dev/xen/privcmd.
> 
> Signed-off-by: David Vrabel 
> ---
> v2:
> - remove unneeded includes
> ---

I think you should make xen_xenbus_fops and xen_privcmd_fops static
now that they are no longer referenced by super.c


Juergen

>  drivers/xen/xenfs/super.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
> index 8559a71..0f2e2cd 100644
> --- a/drivers/xen/xenfs/super.c
> +++ b/drivers/xen/xenfs/super.c
> @@ -18,8 +18,6 @@
>  #include 
>  
>  #include "xenfs.h"
> -#include "../privcmd.h"
> -#include "../xenbus/xenbus_comms.h"
>  
>  #include 
>  
> @@ -45,16 +43,16 @@ static const struct file_operations capabilities_file_ops 
> = {
>  static int xenfs_fill_super(struct super_block *sb, void *data, int silent)
>  {
>   static struct tree_descr xenfs_files[] = {
> - [2] = { "xenbus", _xenbus_fops, S_IRUSR|S_IWUSR },
> + [2] = { "xenbus", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/xenbus" 
> },
>   { "capabilities", _file_ops, S_IRUGO },
> - { "privcmd", _privcmd_fops, S_IRUSR|S_IWUSR },
> + { "privcmd", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/privcmd" },
>   {""},
>   };
>  
>   static struct tree_descr xenfs_init_files[] = {
> - [2] = { "xenbus", _xenbus_fops, S_IRUSR|S_IWUSR },
> + [2] = { "xenbus", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/xenbus" 
> },
>   { "capabilities", _file_ops, S_IRUGO },
> - { "privcmd", _privcmd_fops, S_IRUSR|S_IWUSR },
> + { "privcmd", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/privcmd" },
>   { "xsd_kva", _kva_file_ops, S_IRUSR|S_IWUSR},
>   { "xsd_port", _port_file_ops, S_IRUSR|S_IWUSR},
>  #ifdef CONFIG_XEN_SYMS
> 

Re: Review of ptrace Yama ptrace_scope description

[Michael Kerrisk (man-pages)]

Hi Jann,
...


So I've made that section of text:

   A  process  that  has the CAP_SYS_PTRACE capability can update the
   /proc/sys/kernel/yama/ptrace_scope file with one of the  following
   values:

   0 ("classic ptrace permissions")
  No  additional  restrictions  on  operations  that  perform
  PTRACE_MODE_ATTACH checks (beyond those imposed by the com‐
  moncap and other LSMs).

  The use of PTRACE_TRACEME is unchanged.

   1 ("restricted ptrace") [default value]
  Whenperforminganoperation   that   requires   a
  PTRACE_MODE_ATTACH check, the calling process  must  either
  have the CAP_SYS_PTRACE capability in the user namespace of
  the target process or it  have  a  predefined  relationship
  with  the target process.


Nit: The grammar in this sentence seems wrong to me.
s/or it have/or it must have/?


Yep, thanks for catching that. Fixed now.

Cheers,

Michael


--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: Review of ptrace Yama ptrace_scope description

[Michael Kerrisk (man-pages)]

Hi Jann,
...


So I've made that section of text:

   A  process  that  has the CAP_SYS_PTRACE capability can update the
   /proc/sys/kernel/yama/ptrace_scope file with one of the  following
   values:

   0 ("classic ptrace permissions")
  No  additional  restrictions  on  operations  that  perform
  PTRACE_MODE_ATTACH checks (beyond those imposed by the com‐
  moncap and other LSMs).

  The use of PTRACE_TRACEME is unchanged.

   1 ("restricted ptrace") [default value]
  Whenperforminganoperation   that   requires   a
  PTRACE_MODE_ATTACH check, the calling process  must  either
  have the CAP_SYS_PTRACE capability in the user namespace of
  the target process or it  have  a  predefined  relationship
  with  the target process.


Nit: The grammar in this sentence seems wrong to me.
s/or it have/or it must have/?


Yep, thanks for catching that. Fixed now.

Cheers,

Michael


--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

[PATCH V5 1/3] devicetree/bindings: Add binding for operator panel on FSP machines

[Suraj Jitindar Singh]

Add a binding to Documentation/devicetree/bindings/powerpc/opal
(oppanel-opal.txt) for the operator panel which is present on IBM
Power Systems machines with FSPs.

Signed-off-by: Suraj Jitindar Singh 
Acked-by: Rob Herring 
Acked-by: Stewart Smith 

---

Change Log:

V1 -> V2:
- Nothing
V2 -> V3:
- Change "IBM pseries machines" to "IBM Power Systems machines"
in the commit message for improved clarity.
V3 -> V5:
- Nothing
---
 .../devicetree/bindings/powerpc/opal/oppanel-opal.txt  | 14 ++
 1 file changed, 14 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/powerpc/opal/oppanel-opal.txt

diff --git a/Documentation/devicetree/bindings/powerpc/opal/oppanel-opal.txt 
b/Documentation/devicetree/bindings/powerpc/opal/oppanel-opal.txt
new file mode 100644
index 000..dffb791
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/opal/oppanel-opal.txt
@@ -0,0 +1,14 @@
+IBM OPAL Operator Panel Binding
+---
+
+Required properties:
+- compatible : Should be "ibm,opal-oppanel".
+- #lines : Number of lines on the operator panel e.g. <0x2>.
+- #length: Number of characters per line of the operator panel e.g. <0x10>.
+
+Example:
+   oppanel {
+   compatible = "ibm,opal-oppanel";
+   #lines = <0x2>;
+   #length = <0x10>;
+   };
-- 
2.5.5

[PATCH V5 1/3] devicetree/bindings: Add binding for operator panel on FSP machines

[Suraj Jitindar Singh]

Add a binding to Documentation/devicetree/bindings/powerpc/opal
(oppanel-opal.txt) for the operator panel which is present on IBM
Power Systems machines with FSPs.

Signed-off-by: Suraj Jitindar Singh 
Acked-by: Rob Herring 
Acked-by: Stewart Smith 

---

Change Log:

V1 -> V2:
- Nothing
V2 -> V3:
- Change "IBM pseries machines" to "IBM Power Systems machines"
in the commit message for improved clarity.
V3 -> V5:
- Nothing
---
 .../devicetree/bindings/powerpc/opal/oppanel-opal.txt  | 14 ++
 1 file changed, 14 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/powerpc/opal/oppanel-opal.txt

diff --git a/Documentation/devicetree/bindings/powerpc/opal/oppanel-opal.txt 
b/Documentation/devicetree/bindings/powerpc/opal/oppanel-opal.txt
new file mode 100644
index 000..dffb791
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/opal/oppanel-opal.txt
@@ -0,0 +1,14 @@
+IBM OPAL Operator Panel Binding
+---
+
+Required properties:
+- compatible : Should be "ibm,opal-oppanel".
+- #lines : Number of lines on the operator panel e.g. <0x2>.
+- #length: Number of characters per line of the operator panel e.g. <0x10>.
+
+Example:
+   oppanel {
+   compatible = "ibm,opal-oppanel";
+   #lines = <0x2>;
+   #length = <0x10>;
+   };
-- 
2.5.5

linux-next: manual merge of the kvm tree with the s390 tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/s390/hypfs/hypfs_diag.c

between commit:

  e030c1125eab ("s390/hypfs: use basic block for diag inline assembly")

from the s390 tree and commit:

  e65f30e0cb29 ("s390: hypfs: Move diag implementation and data definitions")

from the kvm tree.

I fixed it up (my fixup patch now looks like below) and can carry the
fix as necessary. This is now fixed as far as linux-next is concerned,
but any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging.  You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.

From: Stephen Rothwell 
Date: Tue, 14 Jun 2016 14:47:33 +1000
Subject: [PATCH] s390: merge fix up for __diag204 move

Signed-off-by: Stephen Rothwell 
---
 arch/s390/kernel/diag.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/arch/s390/kernel/diag.c b/arch/s390/kernel/diag.c
index a44faf4a0454..a97354c8c667 100644
--- a/arch/s390/kernel/diag.c
+++ b/arch/s390/kernel/diag.c
@@ -162,25 +162,27 @@ int diag14(unsigned long rx, unsigned long ry1, unsigned 
long subcode)
 }
 EXPORT_SYMBOL(diag14);
 
-static inline int __diag204(unsigned long subcode, unsigned long size, void 
*addr)
+static inline int __diag204(unsigned long *subcode, unsigned long size, void 
*addr)
 {
-   register unsigned long _subcode asm("0") = subcode;
+   register unsigned long _subcode asm("0") = *subcode;
register unsigned long _size asm("1") = size;
 
asm volatile(
"   diag%2,%0,0x204\n"
-   "0:\n"
+   "0: nopr%%r7\n"
EX_TABLE(0b,0b)
: "+d" (_subcode), "+d" (_size) : "d" (addr) : "memory");
-   if (_subcode)
-   return -1;
+   *subcode = _subcode;
return _size;
 }
 
 int diag204(unsigned long subcode, unsigned long size, void *addr)
 {
diag_stat_inc(DIAG_STAT_X204);
-   return __diag204(subcode, size, addr);
+   size = __diag204(, size, addr);
+   if (subcode)
+   return -1;
+   return size;
 }
 EXPORT_SYMBOL(diag204);
 
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell

linux-next: manual merge of the kvm tree with the s390 tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/s390/hypfs/hypfs_diag.c

between commit:

  e030c1125eab ("s390/hypfs: use basic block for diag inline assembly")

from the s390 tree and commit:

  e65f30e0cb29 ("s390: hypfs: Move diag implementation and data definitions")

from the kvm tree.

I fixed it up (my fixup patch now looks like below) and can carry the
fix as necessary. This is now fixed as far as linux-next is concerned,
but any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging.  You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.

From: Stephen Rothwell 
Date: Tue, 14 Jun 2016 14:47:33 +1000
Subject: [PATCH] s390: merge fix up for __diag204 move

Signed-off-by: Stephen Rothwell 
---
 arch/s390/kernel/diag.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/arch/s390/kernel/diag.c b/arch/s390/kernel/diag.c
index a44faf4a0454..a97354c8c667 100644
--- a/arch/s390/kernel/diag.c
+++ b/arch/s390/kernel/diag.c
@@ -162,25 +162,27 @@ int diag14(unsigned long rx, unsigned long ry1, unsigned 
long subcode)
 }
 EXPORT_SYMBOL(diag14);
 
-static inline int __diag204(unsigned long subcode, unsigned long size, void 
*addr)
+static inline int __diag204(unsigned long *subcode, unsigned long size, void 
*addr)
 {
-   register unsigned long _subcode asm("0") = subcode;
+   register unsigned long _subcode asm("0") = *subcode;
register unsigned long _size asm("1") = size;
 
asm volatile(
"   diag%2,%0,0x204\n"
-   "0:\n"
+   "0: nopr%%r7\n"
EX_TABLE(0b,0b)
: "+d" (_subcode), "+d" (_size) : "d" (addr) : "memory");
-   if (_subcode)
-   return -1;
+   *subcode = _subcode;
return _size;
 }
 
 int diag204(unsigned long subcode, unsigned long size, void *addr)
 {
diag_stat_inc(DIAG_STAT_X204);
-   return __diag204(subcode, size, addr);
+   size = __diag204(, size, addr);
+   if (subcode)
+   return -1;
+   return size;
 }
 EXPORT_SYMBOL(diag204);
 
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell

Re: [PATCH 0/4] Mesh mpm fixes and enhancements

[Julian Calaby]

Hi Yaniv,

On Tue, Jun 28, 2016 at 9:13 PM, Yaniv Machani  wrote:
> This patch set is addressing some issues found in the current 802.11s 
> implementation,
> specifically when using hostap mpm.
> It's aligning the beacon format and handling some corner cases.
>
> Maital Hahn (2):
>   mac80211: mesh: flush stations before beacons are stopped
>   mac80211/cfg: mesh: fix healing time when a mesh peer is disconnecting
>
> Meirav Kama (2):
>   mac80211: mesh: fixed HT ies in beacon template
>   mac80211: sta_info: max_peers reached falsely

Patches that you send must be signed off by you, not ack'd by you.

I.e.

From: Random Developer 

.

Signed-off-by: Random Developer 
Signed-off-by: Patch Sender 

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [PATCH 0/4] Mesh mpm fixes and enhancements

[Julian Calaby]

Hi Yaniv,

On Tue, Jun 28, 2016 at 9:13 PM, Yaniv Machani  wrote:
> This patch set is addressing some issues found in the current 802.11s 
> implementation,
> specifically when using hostap mpm.
> It's aligning the beacon format and handling some corner cases.
>
> Maital Hahn (2):
>   mac80211: mesh: flush stations before beacons are stopped
>   mac80211/cfg: mesh: fix healing time when a mesh peer is disconnecting
>
> Meirav Kama (2):
>   mac80211: mesh: fixed HT ies in beacon template
>   mac80211: sta_info: max_peers reached falsely

Patches that you send must be signed off by you, not ack'd by you.

I.e.

From: Random Developer 

.

Signed-off-by: Random Developer 
Signed-off-by: Patch Sender 

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [PATCH 2/2 v16] drm/bridge: Add I2C based driver for ps8640 bridge

[Daniel Kurtz]

Hi Emil,

One answer inline below.  The rest I leave to Jitao...

[snip...]

On Fri, Jun 17, 2016 at 3:14 AM, Emil Velikov  wrote:

>> +static ssize_t ps8640_update_fw_store(struct device *dev,
>> + struct device_attribute *attr,
>> + const char *buf, size_t count)
>> +{
>> +   struct i2c_client *client = to_i2c_client(dev);
>> +   struct ps8640 *ps_bridge = i2c_get_clientdata(client);
>> +   const struct firmware *fw;
>> +   int error;
>> +
>> +   error = request_firmware(, PS_FW_NAME, dev);
> Can the device operate without a firmware ? If not, why is the
> firmware loaded so later/after user interaction (via sysfs) ? I don't
> recall any other driver in DRM to use such an approach.

The PS8640 has internal flash, so it should always already have a
working firmware.
This sysfs interface is useful for user space initiated field firmware updates.

Regards,
-Daniel

> Regards,
> Emil
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2 v16] drm/bridge: Add I2C based driver for ps8640 bridge

[Daniel Kurtz]

Hi Emil,

One answer inline below.  The rest I leave to Jitao...

[snip...]

On Fri, Jun 17, 2016 at 3:14 AM, Emil Velikov  wrote:

>> +static ssize_t ps8640_update_fw_store(struct device *dev,
>> + struct device_attribute *attr,
>> + const char *buf, size_t count)
>> +{
>> +   struct i2c_client *client = to_i2c_client(dev);
>> +   struct ps8640 *ps_bridge = i2c_get_clientdata(client);
>> +   const struct firmware *fw;
>> +   int error;
>> +
>> +   error = request_firmware(, PS_FW_NAME, dev);
> Can the device operate without a firmware ? If not, why is the
> firmware loaded so later/after user interaction (via sysfs) ? I don't
> recall any other driver in DRM to use such an approach.

The PS8640 has internal flash, so it should always already have a
working firmware.
This sysfs interface is useful for user space initiated field firmware updates.

Regards,
-Daniel

> Regards,
> Emil
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] thermal: add Intel BXT WhiskeyCove PMIC thermal driver

[Bin Gao]

This change add support for pmic thermal driver which is intended to
handle the alert interrupts triggered upon thermal trip point cross
and notify the thermal framework appropriately with the zone, temp,
crossed trip and event details.

Signed-off-by: Yegnesh S Iyer 
Signed-off-by: Bin Gao 
---
Changes in v2:
 - Removed unnecessary request_threaded_irq() - we should be only
   using devm_request_threaded_irq() with virq
 drivers/thermal/Kconfig  |  10 +++
 drivers/thermal/Makefile |   1 +
 drivers/thermal/intel_pmic_thermal.c | 155 +++
 include/linux/mfd/intel_soc_pmic.h   |  21 +
 4 files changed, 187 insertions(+)
 create mode 100644 drivers/thermal/intel_pmic_thermal.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 2d702ca..9065ba7 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -332,6 +332,16 @@ menu "ACPI INT340X thermal drivers"
 source drivers/thermal/int340x_thermal/Kconfig
 endmenu
 
+config INTEL_PMIC_THERMAL
+   tristate "Intel PMIC thermal driver"
+   depends on X86 && INTEL_SOC_PMIC && REGMAP
+   help
+ Select this driver for Intel PMIC with ADC channels monitoring system
+ temperature measurements and alerts.
+ This driver is used for monitoring the ADC channels of PMIC and 
handles
+ the alert trip point interrupts and notifies the thermal framework 
with
+ the trip point and temperature details of the zone.
+
 config INTEL_PCH_THERMAL
tristate "Intel PCH Thermal Reporting Driver"
depends on X86 && PCI
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 10b07c1..159efcc 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_INTEL_SOC_DTS_THERMAL)   += 
intel_soc_dts_thermal.o
 obj-$(CONFIG_INTEL_QUARK_DTS_THERMAL)  += intel_quark_dts_thermal.o
 obj-$(CONFIG_TI_SOC_THERMAL)   += ti-soc-thermal/
 obj-$(CONFIG_INT340X_THERMAL)  += int340x_thermal/
+obj-$(CONFIG_INTEL_PMIC_THERMAL) += intel_pmic_thermal.o
 obj-$(CONFIG_INTEL_PCH_THERMAL)+= intel_pch_thermal.o
 obj-$(CONFIG_ST_THERMAL)   += st/
 obj-$(CONFIG_TEGRA_SOCTHERM)   += tegra/
diff --git a/drivers/thermal/intel_pmic_thermal.c 
b/drivers/thermal/intel_pmic_thermal.c
new file mode 100644
index 000..8c40a0a
--- /dev/null
+++ b/drivers/thermal/intel_pmic_thermal.c
@@ -0,0 +1,155 @@
+/*
+ * pmic_thermal.c - PMIC thermal driver
+ *
+ * Copyright (C) 2015 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed 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 
+
+static irqreturn_t pmic_thermal_irq_handler(int irq, void *data)
+{
+   struct platform_device *pdev = data;
+   struct pmic_thermal_data *td =
+   (struct pmic_thermal_data *)pdev->dev.platform_data;
+   struct intel_soc_pmic *pmic = dev_get_drvdata(pdev->dev.parent);
+   struct regmap *regmap = pmic->regmap;
+   struct thermal_zone_device *tzd;
+   int i, j, ret;
+   u16 reg, evt_stat_reg;
+   u8 reg_val, mask, irq_stat, trip;
+
+   /* Resolve thermal irqs */
+   for (i = 0; i < td->num_maps; i++) {
+   for (j = 0; j < td->maps[i].num_trips; j++) {
+   reg = td->maps[i].trip_config[j].irq_reg;
+   mask = td->maps[i].trip_config[j].irq_mask;
+   /*
+* Read the irq register to resolve whether the
+* interrupt was triggered for this sensor
+*/
+   if (regmap_read(regmap, reg, ))
+   return IRQ_HANDLED;
+
+   reg_val = (u8)ret;
+
+   irq_stat = ((u8)ret & mask);
+   if (irq_stat) {
+   /*
+* Read the status register to find out what
+* event occurred i.e a high or a low
+*/
+   evt_stat_reg =
+   td->maps[i].trip_config[j].evt_stat;
+   if (regmap_read(regmap, evt_stat_reg, ))
+   return IRQ_HANDLED;
+
+   trip = td->maps[i].trip_config[j].trip_num;
+   tzd = thermal_zone_get_zone_by_name(
+   

[PATCH v2] thermal: add Intel BXT WhiskeyCove PMIC thermal driver

[Bin Gao]

This change add support for pmic thermal driver which is intended to
handle the alert interrupts triggered upon thermal trip point cross
and notify the thermal framework appropriately with the zone, temp,
crossed trip and event details.

Signed-off-by: Yegnesh S Iyer 
Signed-off-by: Bin Gao 
---
Changes in v2:
 - Removed unnecessary request_threaded_irq() - we should be only
   using devm_request_threaded_irq() with virq
 drivers/thermal/Kconfig  |  10 +++
 drivers/thermal/Makefile |   1 +
 drivers/thermal/intel_pmic_thermal.c | 155 +++
 include/linux/mfd/intel_soc_pmic.h   |  21 +
 4 files changed, 187 insertions(+)
 create mode 100644 drivers/thermal/intel_pmic_thermal.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 2d702ca..9065ba7 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -332,6 +332,16 @@ menu "ACPI INT340X thermal drivers"
 source drivers/thermal/int340x_thermal/Kconfig
 endmenu
 
+config INTEL_PMIC_THERMAL
+   tristate "Intel PMIC thermal driver"
+   depends on X86 && INTEL_SOC_PMIC && REGMAP
+   help
+ Select this driver for Intel PMIC with ADC channels monitoring system
+ temperature measurements and alerts.
+ This driver is used for monitoring the ADC channels of PMIC and 
handles
+ the alert trip point interrupts and notifies the thermal framework 
with
+ the trip point and temperature details of the zone.
+
 config INTEL_PCH_THERMAL
tristate "Intel PCH Thermal Reporting Driver"
depends on X86 && PCI
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 10b07c1..159efcc 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_INTEL_SOC_DTS_THERMAL)   += 
intel_soc_dts_thermal.o
 obj-$(CONFIG_INTEL_QUARK_DTS_THERMAL)  += intel_quark_dts_thermal.o
 obj-$(CONFIG_TI_SOC_THERMAL)   += ti-soc-thermal/
 obj-$(CONFIG_INT340X_THERMAL)  += int340x_thermal/
+obj-$(CONFIG_INTEL_PMIC_THERMAL) += intel_pmic_thermal.o
 obj-$(CONFIG_INTEL_PCH_THERMAL)+= intel_pch_thermal.o
 obj-$(CONFIG_ST_THERMAL)   += st/
 obj-$(CONFIG_TEGRA_SOCTHERM)   += tegra/
diff --git a/drivers/thermal/intel_pmic_thermal.c 
b/drivers/thermal/intel_pmic_thermal.c
new file mode 100644
index 000..8c40a0a
--- /dev/null
+++ b/drivers/thermal/intel_pmic_thermal.c
@@ -0,0 +1,155 @@
+/*
+ * pmic_thermal.c - PMIC thermal driver
+ *
+ * Copyright (C) 2015 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed 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 
+
+static irqreturn_t pmic_thermal_irq_handler(int irq, void *data)
+{
+   struct platform_device *pdev = data;
+   struct pmic_thermal_data *td =
+   (struct pmic_thermal_data *)pdev->dev.platform_data;
+   struct intel_soc_pmic *pmic = dev_get_drvdata(pdev->dev.parent);
+   struct regmap *regmap = pmic->regmap;
+   struct thermal_zone_device *tzd;
+   int i, j, ret;
+   u16 reg, evt_stat_reg;
+   u8 reg_val, mask, irq_stat, trip;
+
+   /* Resolve thermal irqs */
+   for (i = 0; i < td->num_maps; i++) {
+   for (j = 0; j < td->maps[i].num_trips; j++) {
+   reg = td->maps[i].trip_config[j].irq_reg;
+   mask = td->maps[i].trip_config[j].irq_mask;
+   /*
+* Read the irq register to resolve whether the
+* interrupt was triggered for this sensor
+*/
+   if (regmap_read(regmap, reg, ))
+   return IRQ_HANDLED;
+
+   reg_val = (u8)ret;
+
+   irq_stat = ((u8)ret & mask);
+   if (irq_stat) {
+   /*
+* Read the status register to find out what
+* event occurred i.e a high or a low
+*/
+   evt_stat_reg =
+   td->maps[i].trip_config[j].evt_stat;
+   if (regmap_read(regmap, evt_stat_reg, ))
+   return IRQ_HANDLED;
+
+   trip = td->maps[i].trip_config[j].trip_num;
+   tzd = thermal_zone_get_zone_by_name(
+   

RE: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver support

[Punnaiah Choudary Kalluri]

> -Original Message-
> From: Vinod Koul [mailto:vinod.k...@intel.com]
> Sent: Tuesday, June 28, 2016 9:45 AM
> To: Punnaiah Choudary Kalluri 
> Cc: Appana Durga Kedareswara Rao ;
> robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com;
> ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; Michal Simek
> ; Soren Brinkmann ;
> dan.j.willi...@intel.com; moritz.fisc...@ettus.com;
> laurent.pinch...@ideasonboard.com; l...@debethencourt.com; Srikanth
> Vemula ; Anirudha Sarangi ;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; dmaeng...@vger.kernel.org
> Subject: Re: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine
> driver support
> 
> On Tue, Jun 21, 2016 at 05:29:42PM +, Punnaiah Choudary Kalluri wrote:
> >
> > Ok agree with you for the scenario that I have mentioned above.
> >
> > Other simple dma mode feature that I missed to explain is configuring the
> > Dma descriptors. It provides a register interface for configuring the dma
> transaction.
> > So, no need to maintain the descriptors in memory and it will be useful for
> the system
> > that are in crunch of memory.
> 
> And why are these not coming out in the first place, which makes me think it
> is fishy!
> 
> Do you mean programming DMA descriptors to hardware and you can use
> registers instead of memory?
> 

Yes.

> >
> > How do you want us to handle this case?
> >
> 
> > > Okay I am convince now this is not right approach. Please remove this
> > > custom interface and then implement slave for required slave scenarios!
> > >
> >
> > Assume controller is having 8 channels and four of them are used for slave
> > Dma and others are for memcpy.
> > Controller didn't have the per channel priority control but providing the
> rate control
> > Mechanism.
> 
> How does the use of few for memcpy and few for slave change things? IMO
> it
> doesn't, you program the channel accordingly
> 
> >
> > So, I need some interface for configuring the rate control per channel at
> run time irrespective
> > Of whether the channel is allocated for slave dma or memcpy dma.
> 
> why?
> 

This is to prioritize the channel over other channels at runtime.
Also, if the slave device doesn't have a flow control implemented,
Then rate control is one mechanism for controlling the transactions 
Between the source and destination.

> > Is it wrong having the configurable dma parameters for dma memcpy
> operation? We are exposing the
> > Hw capabilities to the user for better dma transaction management.
> 
> For memcpy yes. Memcpy is a generic case where people do not do driver
> specific stuff. So I tend ot push back on that..
> 

Ok. Then we will consider using slave dma if the memcpy requires custom
Settings (the settings might be for debug purpose or there is real hw design
that mandates changes in default optimized settings).

> For slave, existing APIs allow you to program the additional parameters..
> FWIW, rate control is a generic parameter which if you justify enough can be
> added to dma_slave_config
> 

As said above, rate control will be helpful for the controller that doesn't 
have 
Per channel priority option and also cases where slave device/controller that
Doesn't have Flow control implemented.

Thanks,
Punnaiah

> Thanks
> --
> ~Vinod

RE: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver support

[Punnaiah Choudary Kalluri]

> -Original Message-
> From: Vinod Koul [mailto:vinod.k...@intel.com]
> Sent: Tuesday, June 28, 2016 9:45 AM
> To: Punnaiah Choudary Kalluri 
> Cc: Appana Durga Kedareswara Rao ;
> robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com;
> ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; Michal Simek
> ; Soren Brinkmann ;
> dan.j.willi...@intel.com; moritz.fisc...@ettus.com;
> laurent.pinch...@ideasonboard.com; l...@debethencourt.com; Srikanth
> Vemula ; Anirudha Sarangi ;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; dmaeng...@vger.kernel.org
> Subject: Re: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine
> driver support
> 
> On Tue, Jun 21, 2016 at 05:29:42PM +, Punnaiah Choudary Kalluri wrote:
> >
> > Ok agree with you for the scenario that I have mentioned above.
> >
> > Other simple dma mode feature that I missed to explain is configuring the
> > Dma descriptors. It provides a register interface for configuring the dma
> transaction.
> > So, no need to maintain the descriptors in memory and it will be useful for
> the system
> > that are in crunch of memory.
> 
> And why are these not coming out in the first place, which makes me think it
> is fishy!
> 
> Do you mean programming DMA descriptors to hardware and you can use
> registers instead of memory?
> 

Yes.

> >
> > How do you want us to handle this case?
> >
> 
> > > Okay I am convince now this is not right approach. Please remove this
> > > custom interface and then implement slave for required slave scenarios!
> > >
> >
> > Assume controller is having 8 channels and four of them are used for slave
> > Dma and others are for memcpy.
> > Controller didn't have the per channel priority control but providing the
> rate control
> > Mechanism.
> 
> How does the use of few for memcpy and few for slave change things? IMO
> it
> doesn't, you program the channel accordingly
> 
> >
> > So, I need some interface for configuring the rate control per channel at
> run time irrespective
> > Of whether the channel is allocated for slave dma or memcpy dma.
> 
> why?
> 

This is to prioritize the channel over other channels at runtime.
Also, if the slave device doesn't have a flow control implemented,
Then rate control is one mechanism for controlling the transactions 
Between the source and destination.

> > Is it wrong having the configurable dma parameters for dma memcpy
> operation? We are exposing the
> > Hw capabilities to the user for better dma transaction management.
> 
> For memcpy yes. Memcpy is a generic case where people do not do driver
> specific stuff. So I tend ot push back on that..
> 

Ok. Then we will consider using slave dma if the memcpy requires custom
Settings (the settings might be for debug purpose or there is real hw design
that mandates changes in default optimized settings).

> For slave, existing APIs allow you to program the additional parameters..
> FWIW, rate control is a generic parameter which if you justify enough can be
> added to dma_slave_config
> 

As said above, rate control will be helpful for the controller that doesn't 
have 
Per channel priority option and also cases where slave device/controller that
Doesn't have Flow control implemented.

Thanks,
Punnaiah

> Thanks
> --
> ~Vinod

Re: [PATCH] PM / suspend: show workqueues busy name in suspend flow

[Roger Lu]

Dear Tejun,

On Tue, 2016-06-28 at 12:56 -0400, Tejun Heo wrote:
> Hello, Roger.
> 
> On Mon, Jun 27, 2016 at 05:44:05PM +0800, Roger Lu wrote:
> > show_workqueue_state() is a better choice to me. However, only freezable
> > workqueue is able to affect suspend flow. So, is there other mailing
> > list discussing about showing freezable workqueue state only?? Maybe we
> > can use that API in this case. Thanks very much.
> > 
> > freezable workqueue means workqueue is created with flag WQ_FREEZABLE.
> 
> It's for debugging anyway and workqueue dumps usually are pretty
> short.  I don't think it's fine to use the same function.  We can add
> flags in the printouts but I'm not even sure that'd be necessary.
> 
> Thanks.
> 

Please allow me to elaborate my previous concern about printing
freezable workqueue info only in this case.

The benefit of it is that debugger can quickly understand which
freezable workqueues block suspend flow and assign this issue to
corresponding owner instead of extracting freezable workqueue info from
show_workqueue_state() first and, then, assigning the issue.

Adding a flag to printout the info we need is great. Perhaps we can do
that. Thanks for the advice.

Sincerely,
Roger Lu.

Re: [PATCH] PM / suspend: show workqueues busy name in suspend flow

[Roger Lu]

Dear Tejun,

On Tue, 2016-06-28 at 12:56 -0400, Tejun Heo wrote:
> Hello, Roger.
> 
> On Mon, Jun 27, 2016 at 05:44:05PM +0800, Roger Lu wrote:
> > show_workqueue_state() is a better choice to me. However, only freezable
> > workqueue is able to affect suspend flow. So, is there other mailing
> > list discussing about showing freezable workqueue state only?? Maybe we
> > can use that API in this case. Thanks very much.
> > 
> > freezable workqueue means workqueue is created with flag WQ_FREEZABLE.
> 
> It's for debugging anyway and workqueue dumps usually are pretty
> short.  I don't think it's fine to use the same function.  We can add
> flags in the printouts but I'm not even sure that'd be necessary.
> 
> Thanks.
> 

Please allow me to elaborate my previous concern about printing
freezable workqueue info only in this case.

The benefit of it is that debugger can quickly understand which
freezable workqueues block suspend flow and assign this issue to
corresponding owner instead of extracting freezable workqueue info from
show_workqueue_state() first and, then, assigning the issue.

Adding a flag to printout the info we need is great. Perhaps we can do
that. Thanks for the advice.

Sincerely,
Roger Lu.

[PATCH V5 3/3] powerpc/drivers: Add driver for operator panel on FSP machines

[Suraj Jitindar Singh]

Implement new character device driver to allow access from user space
to the operator panel display present on IBM Power Systems machines
with FSPs.

This will allow status information to be presented on the display which
is visible to a user.

The driver implements a character buffer which a user can read/write
by accessing the device (/dev/op_panel). This buffer is then displayed on
the operator panel display. Any attempt to write past the last character
position will have no effect and attempts to write more characters than
the size of the display will be truncated. The device may only be accessed
by a single process at a time.

Signed-off-by: Suraj Jitindar Singh 
Reviewed-by: Andrew Donnellan 

---

Change Log:

V1 -> V2:
- Replace "IBM pSeries machines" with "IBM Power Systems machines
with FSPs" for improved clarity
- Basic wording/grammar fixes
V2 -> V3:
- Nothing
V3 -> V4:
- Various style changes and non-functional code updates
V4 -> V5:
- Nothing
---
 MAINTAINERS|   6 +
 arch/powerpc/configs/powernv_defconfig |   1 +
 arch/powerpc/include/asm/opal.h|   2 +
 arch/powerpc/platforms/powernv/opal-wrappers.S |   1 +
 arch/powerpc/platforms/powernv/opal.c  |   5 +
 drivers/char/Kconfig   |  14 ++
 drivers/char/Makefile  |   1 +
 drivers/char/powernv-op-panel.c| 223 +
 8 files changed, 253 insertions(+)
 create mode 100644 drivers/char/powernv-op-panel.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 952fd2a..42ace38 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9094,6 +9094,12 @@ F:   drivers/firmware/psci.c
 F: include/linux/psci.h
 F: include/uapi/linux/psci.h
 
+POWERNV OPERATOR PANEL LCD DISPLAY DRIVER
+M: Suraj Jitindar Singh 
+L: linuxppc-...@lists.ozlabs.org
+S: Maintained
+F: drivers/char/powernv-op-panel.c
+
 PNP SUPPORT
 M: "Rafael J. Wysocki" 
 S: Maintained
diff --git a/arch/powerpc/configs/powernv_defconfig 
b/arch/powerpc/configs/powernv_defconfig
index 0450310..959d32b 100644
--- a/arch/powerpc/configs/powernv_defconfig
+++ b/arch/powerpc/configs/powernv_defconfig
@@ -181,6 +181,7 @@ CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_JSM=m
 CONFIG_VIRTIO_CONSOLE=m
+CONFIG_POWERNV_OP_PANEL=m
 CONFIG_IPMI_HANDLER=y
 CONFIG_IPMI_DEVICE_INTERFACE=y
 CONFIG_IPMI_POWERNV=y
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 0d4e690..ea9e7f4 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -178,6 +178,8 @@ int64_t opal_dump_ack(uint32_t dump_id);
 int64_t opal_dump_resend_notification(void);
 
 int64_t opal_get_msg(uint64_t buffer, uint64_t size);
+int64_t opal_write_oppanel_async(uint64_t token, oppanel_line_t *lines,
+   uint64_t num_lines);
 int64_t opal_check_completion(uint64_t buffer, uint64_t size, uint64_t token);
 int64_t opal_sync_host_reboot(void);
 int64_t opal_get_param(uint64_t token, uint32_t param_id, uint64_t buffer,
diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S 
b/arch/powerpc/platforms/powernv/opal-wrappers.S
index e45b88a..ddba8bf 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -278,6 +278,7 @@ OPAL_CALL(opal_dump_info2,  
OPAL_DUMP_INFO2);
 OPAL_CALL(opal_dump_read,  OPAL_DUMP_READ);
 OPAL_CALL(opal_dump_ack,   OPAL_DUMP_ACK);
 OPAL_CALL(opal_get_msg,OPAL_GET_MSG);
+OPAL_CALL(opal_write_oppanel_async,OPAL_WRITE_OPPANEL_ASYNC);
 OPAL_CALL(opal_check_completion,   OPAL_CHECK_ASYNC_COMPLETION);
 OPAL_CALL(opal_dump_resend_notification,   OPAL_DUMP_RESEND);
 OPAL_CALL(opal_sync_host_reboot,   OPAL_SYNC_HOST_REBOOT);
diff --git a/arch/powerpc/platforms/powernv/opal.c 
b/arch/powerpc/platforms/powernv/opal.c
index 0256d07..228751a 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -751,6 +751,9 @@ static int __init opal_init(void)
opal_pdev_init(opal_node, "ibm,opal-flash");
opal_pdev_init(opal_node, "ibm,opal-prd");
 
+   /* Initialise platform device: oppanel interface */
+   opal_pdev_init(opal_node, "ibm,opal-oppanel");
+
/* Initialise OPAL kmsg dumper for flushing console on panic */
opal_kmsg_init();
 
@@ -885,3 +888,5 @@ EXPORT_SYMBOL_GPL(opal_i2c_request);
 /* Export these symbols for PowerNV LED class driver */
 EXPORT_SYMBOL_GPL(opal_leds_get_ind);
 EXPORT_SYMBOL_GPL(opal_leds_set_ind);
+/* Export this symbol for PowerNV Operator Panel class driver */
+EXPORT_SYMBOL_GPL(opal_write_oppanel_async);
diff --git 

[PATCH V5 3/3] powerpc/drivers: Add driver for operator panel on FSP machines

[Suraj Jitindar Singh]

Implement new character device driver to allow access from user space
to the operator panel display present on IBM Power Systems machines
with FSPs.

This will allow status information to be presented on the display which
is visible to a user.

The driver implements a character buffer which a user can read/write
by accessing the device (/dev/op_panel). This buffer is then displayed on
the operator panel display. Any attempt to write past the last character
position will have no effect and attempts to write more characters than
the size of the display will be truncated. The device may only be accessed
by a single process at a time.

Signed-off-by: Suraj Jitindar Singh 
Reviewed-by: Andrew Donnellan 

---

Change Log:

V1 -> V2:
- Replace "IBM pSeries machines" with "IBM Power Systems machines
with FSPs" for improved clarity
- Basic wording/grammar fixes
V2 -> V3:
- Nothing
V3 -> V4:
- Various style changes and non-functional code updates
V4 -> V5:
- Nothing
---
 MAINTAINERS|   6 +
 arch/powerpc/configs/powernv_defconfig |   1 +
 arch/powerpc/include/asm/opal.h|   2 +
 arch/powerpc/platforms/powernv/opal-wrappers.S |   1 +
 arch/powerpc/platforms/powernv/opal.c  |   5 +
 drivers/char/Kconfig   |  14 ++
 drivers/char/Makefile  |   1 +
 drivers/char/powernv-op-panel.c| 223 +
 8 files changed, 253 insertions(+)
 create mode 100644 drivers/char/powernv-op-panel.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 952fd2a..42ace38 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9094,6 +9094,12 @@ F:   drivers/firmware/psci.c
 F: include/linux/psci.h
 F: include/uapi/linux/psci.h
 
+POWERNV OPERATOR PANEL LCD DISPLAY DRIVER
+M: Suraj Jitindar Singh 
+L: linuxppc-...@lists.ozlabs.org
+S: Maintained
+F: drivers/char/powernv-op-panel.c
+
 PNP SUPPORT
 M: "Rafael J. Wysocki" 
 S: Maintained
diff --git a/arch/powerpc/configs/powernv_defconfig 
b/arch/powerpc/configs/powernv_defconfig
index 0450310..959d32b 100644
--- a/arch/powerpc/configs/powernv_defconfig
+++ b/arch/powerpc/configs/powernv_defconfig
@@ -181,6 +181,7 @@ CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_JSM=m
 CONFIG_VIRTIO_CONSOLE=m
+CONFIG_POWERNV_OP_PANEL=m
 CONFIG_IPMI_HANDLER=y
 CONFIG_IPMI_DEVICE_INTERFACE=y
 CONFIG_IPMI_POWERNV=y
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 0d4e690..ea9e7f4 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -178,6 +178,8 @@ int64_t opal_dump_ack(uint32_t dump_id);
 int64_t opal_dump_resend_notification(void);
 
 int64_t opal_get_msg(uint64_t buffer, uint64_t size);
+int64_t opal_write_oppanel_async(uint64_t token, oppanel_line_t *lines,
+   uint64_t num_lines);
 int64_t opal_check_completion(uint64_t buffer, uint64_t size, uint64_t token);
 int64_t opal_sync_host_reboot(void);
 int64_t opal_get_param(uint64_t token, uint32_t param_id, uint64_t buffer,
diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S 
b/arch/powerpc/platforms/powernv/opal-wrappers.S
index e45b88a..ddba8bf 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -278,6 +278,7 @@ OPAL_CALL(opal_dump_info2,  
OPAL_DUMP_INFO2);
 OPAL_CALL(opal_dump_read,  OPAL_DUMP_READ);
 OPAL_CALL(opal_dump_ack,   OPAL_DUMP_ACK);
 OPAL_CALL(opal_get_msg,OPAL_GET_MSG);
+OPAL_CALL(opal_write_oppanel_async,OPAL_WRITE_OPPANEL_ASYNC);
 OPAL_CALL(opal_check_completion,   OPAL_CHECK_ASYNC_COMPLETION);
 OPAL_CALL(opal_dump_resend_notification,   OPAL_DUMP_RESEND);
 OPAL_CALL(opal_sync_host_reboot,   OPAL_SYNC_HOST_REBOOT);
diff --git a/arch/powerpc/platforms/powernv/opal.c 
b/arch/powerpc/platforms/powernv/opal.c
index 0256d07..228751a 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -751,6 +751,9 @@ static int __init opal_init(void)
opal_pdev_init(opal_node, "ibm,opal-flash");
opal_pdev_init(opal_node, "ibm,opal-prd");
 
+   /* Initialise platform device: oppanel interface */
+   opal_pdev_init(opal_node, "ibm,opal-oppanel");
+
/* Initialise OPAL kmsg dumper for flushing console on panic */
opal_kmsg_init();
 
@@ -885,3 +888,5 @@ EXPORT_SYMBOL_GPL(opal_i2c_request);
 /* Export these symbols for PowerNV LED class driver */
 EXPORT_SYMBOL_GPL(opal_leds_get_ind);
 EXPORT_SYMBOL_GPL(opal_leds_set_ind);
+/* Export this symbol for PowerNV Operator Panel class driver */
+EXPORT_SYMBOL_GPL(opal_write_oppanel_async);
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 601f64f..fdb8f3e 100644
--- a/drivers/char/Kconfig
+++ 

[PATCH V5 2/3] powerpc/opal: Add inline function to get rc from an ASYNC_COMP opal_msg

[Suraj Jitindar Singh]

An opal_msg of type OPAL_MSG_ASYNC_COMP contains the return code in the
params[1] struct member. However this isn't intuitive or obvious when
reading the code and requires that a user look at the skiboot
documentation or opal-api.h to verify this.

Add an inline function to get the return code from an opal_msg and update
call sites accordingly.

Signed-off-by: Suraj Jitindar Singh 

---

Change Log:

-> V4:
- Added Patch to Series
V4 -> V5:
- Changed from #define in opal-api.h to inline in opal.h
---
 arch/powerpc/include/asm/opal.h| 8 
 arch/powerpc/platforms/powernv/opal-sensor.c   | 2 +-
 arch/powerpc/platforms/powernv/opal-sysparam.c | 4 ++--
 drivers/i2c/busses/i2c-opal.c  | 2 +-
 drivers/leds/leds-powernv.c| 2 +-
 drivers/mtd/devices/powernv_flash.c| 2 +-
 drivers/rtc/rtc-opal.c | 4 ++--
 7 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 9d86c66..0d4e690 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -276,6 +276,14 @@ extern int opal_error_code(int rc);
 
 ssize_t opal_msglog_copy(char *to, loff_t pos, size_t count);
 
+static inline int opal_get_async_rc(struct opal_msg msg)
+{
+   if (msg.msg_type != OPAL_MSG_ASYNC_COMP)
+   return OPAL_PARAMETER;
+   else
+   return be64_to_cpu(msg.params[1]);
+}
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* _ASM_POWERPC_OPAL_H */
diff --git a/arch/powerpc/platforms/powernv/opal-sensor.c 
b/arch/powerpc/platforms/powernv/opal-sensor.c
index a06059d..308efd1 100644
--- a/arch/powerpc/platforms/powernv/opal-sensor.c
+++ b/arch/powerpc/platforms/powernv/opal-sensor.c
@@ -55,7 +55,7 @@ int opal_get_sensor_data(u32 sensor_hndl, u32 *sensor_data)
goto out_token;
}
 
-   ret = opal_error_code(be64_to_cpu(msg.params[1]));
+   ret = opal_error_code(opal_get_async_rc(msg));
*sensor_data = be32_to_cpu(data);
break;
 
diff --git a/arch/powerpc/platforms/powernv/opal-sysparam.c 
b/arch/powerpc/platforms/powernv/opal-sysparam.c
index afe66c5..23fb664 100644
--- a/arch/powerpc/platforms/powernv/opal-sysparam.c
+++ b/arch/powerpc/platforms/powernv/opal-sysparam.c
@@ -67,7 +67,7 @@ static ssize_t opal_get_sys_param(u32 param_id, u32 length, 
void *buffer)
goto out_token;
}
 
-   ret = opal_error_code(be64_to_cpu(msg.params[1]));
+   ret = opal_error_code(opal_get_async_rc(msg));
 
 out_token:
opal_async_release_token(token);
@@ -103,7 +103,7 @@ static int opal_set_sys_param(u32 param_id, u32 length, 
void *buffer)
goto out_token;
}
 
-   ret = opal_error_code(be64_to_cpu(msg.params[1]));
+   ret = opal_error_code(opal_get_async_rc(msg));
 
 out_token:
opal_async_release_token(token);
diff --git a/drivers/i2c/busses/i2c-opal.c b/drivers/i2c/busses/i2c-opal.c
index 75dd6d0..11e2a1f 100644
--- a/drivers/i2c/busses/i2c-opal.c
+++ b/drivers/i2c/busses/i2c-opal.c
@@ -71,7 +71,7 @@ static int i2c_opal_send_request(u32 bus_id, struct 
opal_i2c_request *req)
if (rc)
goto exit;
 
-   rc = be64_to_cpu(msg.params[1]);
+   rc = opal_get_async_rc(msg);
if (rc != OPAL_SUCCESS) {
rc = i2c_opal_translate_error(rc);
goto exit;
diff --git a/drivers/leds/leds-powernv.c b/drivers/leds/leds-powernv.c
index dfb8bd3..b2a98c7 100644
--- a/drivers/leds/leds-powernv.c
+++ b/drivers/leds/leds-powernv.c
@@ -118,7 +118,7 @@ static int powernv_led_set(struct powernv_led_data 
*powernv_led,
goto out_token;
}
 
-   rc = be64_to_cpu(msg.params[1]);
+   rc = opal_get_async_rc(msg);
if (rc != OPAL_SUCCESS)
dev_err(dev, "%s : OAPL async call returned failed [rc=%d]\n",
__func__, rc);
diff --git a/drivers/mtd/devices/powernv_flash.c 
b/drivers/mtd/devices/powernv_flash.c
index d5b870b..f5396f2 100644
--- a/drivers/mtd/devices/powernv_flash.c
+++ b/drivers/mtd/devices/powernv_flash.c
@@ -95,7 +95,7 @@ static int powernv_flash_async_op(struct mtd_info *mtd, enum 
flash_op op,
return -EIO;
}
 
-   rc = be64_to_cpu(msg.params[1]);
+   rc = opal_get_async_rc(msg);
if (rc == OPAL_SUCCESS) {
rc = 0;
if (retlen)
diff --git a/drivers/rtc/rtc-opal.c b/drivers/rtc/rtc-opal.c
index 9c18d6f..ea20f62 100644
--- a/drivers/rtc/rtc-opal.c
+++ b/drivers/rtc/rtc-opal.c
@@ -134,7 +134,7 @@ static int opal_get_tpo_time(struct device *dev, struct 
rtc_wkalrm *alarm)
goto exit;
}
 
-   rc = be64_to_cpu(msg.params[1]);
+   rc = opal_get_async_rc(msg);
if (rc != OPAL_SUCCESS) {
rc = -EIO;
goto 

[PATCH V5 2/3] powerpc/opal: Add inline function to get rc from an ASYNC_COMP opal_msg

[Suraj Jitindar Singh]

An opal_msg of type OPAL_MSG_ASYNC_COMP contains the return code in the
params[1] struct member. However this isn't intuitive or obvious when
reading the code and requires that a user look at the skiboot
documentation or opal-api.h to verify this.

Add an inline function to get the return code from an opal_msg and update
call sites accordingly.

Signed-off-by: Suraj Jitindar Singh 

---

Change Log:

-> V4:
- Added Patch to Series
V4 -> V5:
- Changed from #define in opal-api.h to inline in opal.h
---
 arch/powerpc/include/asm/opal.h| 8 
 arch/powerpc/platforms/powernv/opal-sensor.c   | 2 +-
 arch/powerpc/platforms/powernv/opal-sysparam.c | 4 ++--
 drivers/i2c/busses/i2c-opal.c  | 2 +-
 drivers/leds/leds-powernv.c| 2 +-
 drivers/mtd/devices/powernv_flash.c| 2 +-
 drivers/rtc/rtc-opal.c | 4 ++--
 7 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 9d86c66..0d4e690 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -276,6 +276,14 @@ extern int opal_error_code(int rc);
 
 ssize_t opal_msglog_copy(char *to, loff_t pos, size_t count);
 
+static inline int opal_get_async_rc(struct opal_msg msg)
+{
+   if (msg.msg_type != OPAL_MSG_ASYNC_COMP)
+   return OPAL_PARAMETER;
+   else
+   return be64_to_cpu(msg.params[1]);
+}
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* _ASM_POWERPC_OPAL_H */
diff --git a/arch/powerpc/platforms/powernv/opal-sensor.c 
b/arch/powerpc/platforms/powernv/opal-sensor.c
index a06059d..308efd1 100644
--- a/arch/powerpc/platforms/powernv/opal-sensor.c
+++ b/arch/powerpc/platforms/powernv/opal-sensor.c
@@ -55,7 +55,7 @@ int opal_get_sensor_data(u32 sensor_hndl, u32 *sensor_data)
goto out_token;
}
 
-   ret = opal_error_code(be64_to_cpu(msg.params[1]));
+   ret = opal_error_code(opal_get_async_rc(msg));
*sensor_data = be32_to_cpu(data);
break;
 
diff --git a/arch/powerpc/platforms/powernv/opal-sysparam.c 
b/arch/powerpc/platforms/powernv/opal-sysparam.c
index afe66c5..23fb664 100644
--- a/arch/powerpc/platforms/powernv/opal-sysparam.c
+++ b/arch/powerpc/platforms/powernv/opal-sysparam.c
@@ -67,7 +67,7 @@ static ssize_t opal_get_sys_param(u32 param_id, u32 length, 
void *buffer)
goto out_token;
}
 
-   ret = opal_error_code(be64_to_cpu(msg.params[1]));
+   ret = opal_error_code(opal_get_async_rc(msg));
 
 out_token:
opal_async_release_token(token);
@@ -103,7 +103,7 @@ static int opal_set_sys_param(u32 param_id, u32 length, 
void *buffer)
goto out_token;
}
 
-   ret = opal_error_code(be64_to_cpu(msg.params[1]));
+   ret = opal_error_code(opal_get_async_rc(msg));
 
 out_token:
opal_async_release_token(token);
diff --git a/drivers/i2c/busses/i2c-opal.c b/drivers/i2c/busses/i2c-opal.c
index 75dd6d0..11e2a1f 100644
--- a/drivers/i2c/busses/i2c-opal.c
+++ b/drivers/i2c/busses/i2c-opal.c
@@ -71,7 +71,7 @@ static int i2c_opal_send_request(u32 bus_id, struct 
opal_i2c_request *req)
if (rc)
goto exit;
 
-   rc = be64_to_cpu(msg.params[1]);
+   rc = opal_get_async_rc(msg);
if (rc != OPAL_SUCCESS) {
rc = i2c_opal_translate_error(rc);
goto exit;
diff --git a/drivers/leds/leds-powernv.c b/drivers/leds/leds-powernv.c
index dfb8bd3..b2a98c7 100644
--- a/drivers/leds/leds-powernv.c
+++ b/drivers/leds/leds-powernv.c
@@ -118,7 +118,7 @@ static int powernv_led_set(struct powernv_led_data 
*powernv_led,
goto out_token;
}
 
-   rc = be64_to_cpu(msg.params[1]);
+   rc = opal_get_async_rc(msg);
if (rc != OPAL_SUCCESS)
dev_err(dev, "%s : OAPL async call returned failed [rc=%d]\n",
__func__, rc);
diff --git a/drivers/mtd/devices/powernv_flash.c 
b/drivers/mtd/devices/powernv_flash.c
index d5b870b..f5396f2 100644
--- a/drivers/mtd/devices/powernv_flash.c
+++ b/drivers/mtd/devices/powernv_flash.c
@@ -95,7 +95,7 @@ static int powernv_flash_async_op(struct mtd_info *mtd, enum 
flash_op op,
return -EIO;
}
 
-   rc = be64_to_cpu(msg.params[1]);
+   rc = opal_get_async_rc(msg);
if (rc == OPAL_SUCCESS) {
rc = 0;
if (retlen)
diff --git a/drivers/rtc/rtc-opal.c b/drivers/rtc/rtc-opal.c
index 9c18d6f..ea20f62 100644
--- a/drivers/rtc/rtc-opal.c
+++ b/drivers/rtc/rtc-opal.c
@@ -134,7 +134,7 @@ static int opal_get_tpo_time(struct device *dev, struct 
rtc_wkalrm *alarm)
goto exit;
}
 
-   rc = be64_to_cpu(msg.params[1]);
+   rc = opal_get_async_rc(msg);
if (rc != OPAL_SUCCESS) {
rc = -EIO;
goto exit;
@@ -181,7 +181,7 @@ 

linux-next: manual merge of the devicetree tree with the imx-mxs tree

[Stephen Rothwell]

Hi Rob,

Today's linux-next merge of the devicetree tree got a conflict in:

  arch/arm/mach-imx/mach-imx51.c

between commit:

  463f90fa8a12 ("ARM: i.MX: Disable supervisor protect for i.MX51")

from the imx-mxs tree and commit:

  850bea2335e4 ("arm: Remove unnecessary of_platform_populate with default 
match table")

from the devicetree tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm/mach-imx/mach-imx51.c
index 0d9049825f0e,ec64de611d90..
--- a/arch/arm/mach-imx/mach-imx51.c
+++ b/arch/arm/mach-imx/mach-imx51.c
@@@ -52,10 -52,6 +52,8 @@@ static void __init imx51_dt_init(void
  {
imx51_ipu_mipi_setup();
imx_src_init();
 +
-   of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
- 
 +  imx_aips_allow_unprivileged_access("fsl,imx51-aipstz");
  }
  
  static void __init imx51_init_late(void)

linux-next: manual merge of the devicetree tree with the imx-mxs tree

[Stephen Rothwell]

Hi Rob,

Today's linux-next merge of the devicetree tree got a conflict in:

  arch/arm/mach-imx/mach-imx51.c

between commit:

  463f90fa8a12 ("ARM: i.MX: Disable supervisor protect for i.MX51")

from the imx-mxs tree and commit:

  850bea2335e4 ("arm: Remove unnecessary of_platform_populate with default 
match table")

from the devicetree tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm/mach-imx/mach-imx51.c
index 0d9049825f0e,ec64de611d90..
--- a/arch/arm/mach-imx/mach-imx51.c
+++ b/arch/arm/mach-imx/mach-imx51.c
@@@ -52,10 -52,6 +52,8 @@@ static void __init imx51_dt_init(void
  {
imx51_ipu_mipi_setup();
imx_src_init();
 +
-   of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
- 
 +  imx_aips_allow_unprivileged_access("fsl,imx51-aipstz");
  }
  
  static void __init imx51_init_late(void)

Re: [PATCH] [linux-next] rtlwifi: Fix typo in printk

[Julian Calaby]

Hi All,

On Wed, Jun 29, 2016 at 1:37 PM, Masanari Iida  wrote:
> This patch fix spelling typos found in drivers/net/wireless/realtek.
>
> Signed-off-by: Masanari Iida 

Looks right to me.

Reviewed-by: Julian Calaby 

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [PATCH] [linux-next] rtlwifi: Fix typo in printk

[Julian Calaby]

Hi All,

On Wed, Jun 29, 2016 at 1:37 PM, Masanari Iida  wrote:
> This patch fix spelling typos found in drivers/net/wireless/realtek.
>
> Signed-off-by: Masanari Iida 

Looks right to me.

Reviewed-by: Julian Calaby 

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

[PATCH] [linux-next] rtlwifi: Fix typo in printk

[Masanari Iida]

This patch fix spelling typos found in drivers/net/wireless/realtek.

Signed-off-by: Masanari Iida 
---
 drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c   | 2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c | 2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c| 2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c   | 2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c   | 2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c| 2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/phy.c   | 2 +-
 7 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c
index 416a9ba6382e..422c7813f5ee 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c
@@ -1239,7 +1239,7 @@ u8 rtl88e_phy_sw_chnl(struct ieee80211_hw *hw)
if (!(is_hal_stop(rtlhal)) && !(RT_CANNOT_IO(hw))) {
rtl88e_phy_sw_chnl_callback(hw);
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
-"sw_chnl_inprogress false schdule workitem current 
channel %d\n",
+"sw_chnl_inprogress false schedule workitem current 
channel %d\n",
 rtlphy->current_channel);
rtlphy->sw_chnl_inprogress = false;
} else {
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
index 77e61b19bf36..9301583ce768 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
@@ -757,7 +757,7 @@ u8 rtl92c_phy_sw_chnl(struct ieee80211_hw *hw)
if (!(is_hal_stop(rtlhal)) && !(RT_CANNOT_IO(hw))) {
rtl92c_phy_sw_chnl_callback(hw);
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
-"sw_chnl_inprogress false schdule workitem\n");
+"sw_chnl_inprogress false schedule workitem\n");
rtlphy->sw_chnl_inprogress = false;
} else {
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c
index 459f3d0efa2f..0a5c9fcfe73b 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c
@@ -496,7 +496,7 @@ static void rtl92ee_dm_find_minimum_rssi(struct 
ieee80211_hw *hw)
rtl_dm_dig->min_undec_pwdb_for_dm =
rtlpriv->dm.entry_min_undec_sm_pwdb;
RT_TRACE(rtlpriv, COMP_BB_POWERSAVING, DBG_LOUD,
-"AP Ext Port or disconnet PWDB = 0x%x\n",
+"AP Ext Port or disconnect PWDB = 0x%x\n",
 rtl_dm_dig->min_undec_pwdb_for_dm);
}
RT_TRACE(rtlpriv, COMP_DIG, DBG_LOUD,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c
index c2bf8d1a7af3..97d9a8e209f1 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c
@@ -1819,7 +1819,7 @@ u8 rtl92ee_phy_sw_chnl(struct ieee80211_hw *hw)
if (!(is_hal_stop(rtlhal)) && !(RT_CANNOT_IO(hw))) {
rtl92ee_phy_sw_chnl_callback(hw);
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
-"sw_chnl_inprogress false schdule workitem current 
channel %d\n",
+"sw_chnl_inprogress false schedule workitem current 
channel %d\n",
 rtlphy->current_channel);
rtlphy->sw_chnl_inprogress = false;
} else {
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c
index d367097f490b..e9a9bbf44966 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c
@@ -893,7 +893,7 @@ u8 rtl8723e_phy_sw_chnl(struct ieee80211_hw *hw)
if (!(is_hal_stop(rtlhal)) && !(RT_CANNOT_IO(hw))) {
rtl8723e_phy_sw_chnl_callback(hw);
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
-"sw_chnl_inprogress false schdule workitem\n");
+"sw_chnl_inprogress false schedule workitem\n");
rtlphy->sw_chnl_inprogress = false;
} else {
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
index 08288ac9020a..97ae14d48840 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
@@ -1474,7 +1474,7 @@ static enum version_8723e 

[PATCH] [linux-next] rtlwifi: Fix typo in printk

[Masanari Iida]

This patch fix spelling typos found in drivers/net/wireless/realtek.

Signed-off-by: Masanari Iida 
---
 drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c   | 2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c | 2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c| 2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c   | 2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c   | 2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c| 2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/phy.c   | 2 +-
 7 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c
index 416a9ba6382e..422c7813f5ee 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c
@@ -1239,7 +1239,7 @@ u8 rtl88e_phy_sw_chnl(struct ieee80211_hw *hw)
if (!(is_hal_stop(rtlhal)) && !(RT_CANNOT_IO(hw))) {
rtl88e_phy_sw_chnl_callback(hw);
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
-"sw_chnl_inprogress false schdule workitem current 
channel %d\n",
+"sw_chnl_inprogress false schedule workitem current 
channel %d\n",
 rtlphy->current_channel);
rtlphy->sw_chnl_inprogress = false;
} else {
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
index 77e61b19bf36..9301583ce768 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
@@ -757,7 +757,7 @@ u8 rtl92c_phy_sw_chnl(struct ieee80211_hw *hw)
if (!(is_hal_stop(rtlhal)) && !(RT_CANNOT_IO(hw))) {
rtl92c_phy_sw_chnl_callback(hw);
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
-"sw_chnl_inprogress false schdule workitem\n");
+"sw_chnl_inprogress false schedule workitem\n");
rtlphy->sw_chnl_inprogress = false;
} else {
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c
index 459f3d0efa2f..0a5c9fcfe73b 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c
@@ -496,7 +496,7 @@ static void rtl92ee_dm_find_minimum_rssi(struct 
ieee80211_hw *hw)
rtl_dm_dig->min_undec_pwdb_for_dm =
rtlpriv->dm.entry_min_undec_sm_pwdb;
RT_TRACE(rtlpriv, COMP_BB_POWERSAVING, DBG_LOUD,
-"AP Ext Port or disconnet PWDB = 0x%x\n",
+"AP Ext Port or disconnect PWDB = 0x%x\n",
 rtl_dm_dig->min_undec_pwdb_for_dm);
}
RT_TRACE(rtlpriv, COMP_DIG, DBG_LOUD,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c
index c2bf8d1a7af3..97d9a8e209f1 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c
@@ -1819,7 +1819,7 @@ u8 rtl92ee_phy_sw_chnl(struct ieee80211_hw *hw)
if (!(is_hal_stop(rtlhal)) && !(RT_CANNOT_IO(hw))) {
rtl92ee_phy_sw_chnl_callback(hw);
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
-"sw_chnl_inprogress false schdule workitem current 
channel %d\n",
+"sw_chnl_inprogress false schedule workitem current 
channel %d\n",
 rtlphy->current_channel);
rtlphy->sw_chnl_inprogress = false;
} else {
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c
index d367097f490b..e9a9bbf44966 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c
@@ -893,7 +893,7 @@ u8 rtl8723e_phy_sw_chnl(struct ieee80211_hw *hw)
if (!(is_hal_stop(rtlhal)) && !(RT_CANNOT_IO(hw))) {
rtl8723e_phy_sw_chnl_callback(hw);
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
-"sw_chnl_inprogress false schdule workitem\n");
+"sw_chnl_inprogress false schedule workitem\n");
rtlphy->sw_chnl_inprogress = false;
} else {
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
index 08288ac9020a..97ae14d48840 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
@@ -1474,7 +1474,7 @@ static enum version_8723e 

Re: [PATCH v3 10/10] drm/bridge: analogix_dp: fix no drm hpd event when panel plug in

[Yakir Yang]

Sean,

On 06/23/2016 10:24 PM, Sean Paul wrote:

On Tue, Jun 14, 2016 at 7:46 AM, Yakir Yang  wrote:

The enum value of DP_IRQ_TYPE_HP_CABLE_IN is zero, but driver only
send drm hp event when the irq_type and the enum value is true.

if (irq_type & DP_IRQ_TYPE_HP_CABLE_IN || ...)
 drm_helper_hpd_irq_event(dp->drm_dev);

So there would no drm hpd event when cable plug in, to fix that
just need to assign all hotplug enum with no-zero values.

Reported-by: Dan Carpenter 
Signed-off-by: Yakir Yang 
Reviewed-by: Stéphane Marchesin 
Tested-by: Javier Martinez Canillas 

Reviewed-by: Sean Paul 



Thanks  ;)


---
Changes in v3:
- Add reviewed flag from Stéphane.
 [https://chromium-review.googlesource.com/#/c/346319/15]
- Add tested flag from Javier

Changes in v2: None

  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index f09275d..b456380 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -127,10 +127,10 @@ enum analog_power_block {
  };

  enum dp_irq_type {
-   DP_IRQ_TYPE_HP_CABLE_IN,
-   DP_IRQ_TYPE_HP_CABLE_OUT,
-   DP_IRQ_TYPE_HP_CHANGE,
-   DP_IRQ_TYPE_UNKNOWN,
+   DP_IRQ_TYPE_HP_CABLE_IN  = BIT(0),
+   DP_IRQ_TYPE_HP_CABLE_OUT = BIT(1),
+   DP_IRQ_TYPE_HP_CHANGE= BIT(2),
+   DP_IRQ_TYPE_UNKNOWN  = BIT(3),
  };

  struct video_info {
--
1.9.1


___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 10/10] drm/bridge: analogix_dp: fix no drm hpd event when panel plug in

[Yakir Yang]

Sean,

On 06/23/2016 10:24 PM, Sean Paul wrote:

On Tue, Jun 14, 2016 at 7:46 AM, Yakir Yang  wrote:

The enum value of DP_IRQ_TYPE_HP_CABLE_IN is zero, but driver only
send drm hp event when the irq_type and the enum value is true.

if (irq_type & DP_IRQ_TYPE_HP_CABLE_IN || ...)
 drm_helper_hpd_irq_event(dp->drm_dev);

So there would no drm hpd event when cable plug in, to fix that
just need to assign all hotplug enum with no-zero values.

Reported-by: Dan Carpenter 
Signed-off-by: Yakir Yang 
Reviewed-by: Stéphane Marchesin 
Tested-by: Javier Martinez Canillas 

Reviewed-by: Sean Paul 



Thanks  ;)


---
Changes in v3:
- Add reviewed flag from Stéphane.
 [https://chromium-review.googlesource.com/#/c/346319/15]
- Add tested flag from Javier

Changes in v2: None

  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index f09275d..b456380 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -127,10 +127,10 @@ enum analog_power_block {
  };

  enum dp_irq_type {
-   DP_IRQ_TYPE_HP_CABLE_IN,
-   DP_IRQ_TYPE_HP_CABLE_OUT,
-   DP_IRQ_TYPE_HP_CHANGE,
-   DP_IRQ_TYPE_UNKNOWN,
+   DP_IRQ_TYPE_HP_CABLE_IN  = BIT(0),
+   DP_IRQ_TYPE_HP_CABLE_OUT = BIT(1),
+   DP_IRQ_TYPE_HP_CHANGE= BIT(2),
+   DP_IRQ_TYPE_UNKNOWN  = BIT(3),
  };

  struct video_info {
--
1.9.1


___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4.1 1/2] drm/rockchip: analogix_dp: introduce the pclk for grf

[Yakir Yang]

Doug,

On 06/23/2016 01:16 PM, Doug Anderson wrote:

Yakir,

On Wed, Jun 22, 2016 at 6:58 PM, Yakir Yang  wrote:

For RK3399's GRF module, if we want to operate the graphic related grf
registers, we need to enable the pclk_vio_grf which supply power for VIO
GRF IOs, so it's better to introduce an optional grf clock in driver.

Signed-off-by: Yakir Yang 
---
Hi all,

This is an external patch for analogix_dp misc cleanup thread [0]
[0]: https://patchwork.kernel.org/patch/9175613/

BR,
- Yakir

Changes in v4.1:
- Fix compiled error, sorry.
   "dp->cgfclk"  -->  'dp->grfclk'

Changes in v4:
- Check the the error code properly, 'EPROBE_DEFER' should be returned,
   'ENOENT' should assign a NULL point to grfclk, other errors should be
   regarded as failed. (Tomasz, Doug, reviewed at Google Gerrit)
 
[https://chromium-review.googlesource.com/#/c/351821/20/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c@249]
- Add the document about optional 'grf' clock (Tomasz, Doug, reviewed at Google 
Gerrit)
 [https://chromium-review.googlesource.com/#/c/351821/]

Changes in v3:
- Add this patch in v3

  .../display/rockchip/analogix_dp-rockchip.txt  |  6 ++
  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 23 +++---
  2 files changed, 26 insertions(+), 3 deletions(-)

I probably would have split into two patches so the bindings was its
own patch, but I don't think it's strictly required.

In any case, this seems good to me.

Reviewed-by: Douglas Anderson 

This is not big change, so collect them into one patch should be more 
cleaner, thanks for your reviewed ;)

Re: [PATCH v4.1 1/2] drm/rockchip: analogix_dp: introduce the pclk for grf

[Yakir Yang]

Doug,

On 06/23/2016 01:16 PM, Doug Anderson wrote:

Yakir,

On Wed, Jun 22, 2016 at 6:58 PM, Yakir Yang  wrote:

For RK3399's GRF module, if we want to operate the graphic related grf
registers, we need to enable the pclk_vio_grf which supply power for VIO
GRF IOs, so it's better to introduce an optional grf clock in driver.

Signed-off-by: Yakir Yang 
---
Hi all,

This is an external patch for analogix_dp misc cleanup thread [0]
[0]: https://patchwork.kernel.org/patch/9175613/

BR,
- Yakir

Changes in v4.1:
- Fix compiled error, sorry.
   "dp->cgfclk"  -->  'dp->grfclk'

Changes in v4:
- Check the the error code properly, 'EPROBE_DEFER' should be returned,
   'ENOENT' should assign a NULL point to grfclk, other errors should be
   regarded as failed. (Tomasz, Doug, reviewed at Google Gerrit)
 
[https://chromium-review.googlesource.com/#/c/351821/20/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c@249]
- Add the document about optional 'grf' clock (Tomasz, Doug, reviewed at Google 
Gerrit)
 [https://chromium-review.googlesource.com/#/c/351821/]

Changes in v3:
- Add this patch in v3

  .../display/rockchip/analogix_dp-rockchip.txt  |  6 ++
  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 23 +++---
  2 files changed, 26 insertions(+), 3 deletions(-)

I probably would have split into two patches so the bindings was its
own patch, but I don't think it's strictly required.

In any case, this seems good to me.

Reviewed-by: Douglas Anderson 

This is not big change, so collect them into one patch should be more 
cleaner, thanks for your reviewed ;)

RE: [PATCH net-next v3 0/7] r8152: support new chips

[Hayes Wang]

> From: Hayes Wang
> Sent: Tuesday, June 28, 2016 8:29 PM
> To: net...@vger.kernel.org
> Cc: nic_swsd; linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; Hayes
> Wang
> Subject: [PATCH net-next v3 0/7] r8152: support new chips

Excuse me. Please ignore these patches.
We want to do more tests for the chips. I would submit the patches after the
settings are stable.

Best Regards,
Hayes

RE: [PATCH net-next v3 0/7] r8152: support new chips

[Hayes Wang]

> From: Hayes Wang
> Sent: Tuesday, June 28, 2016 8:29 PM
> To: net...@vger.kernel.org
> Cc: nic_swsd; linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; Hayes
> Wang
> Subject: [PATCH net-next v3 0/7] r8152: support new chips

Excuse me. Please ignore these patches.
We want to do more tests for the chips. I would submit the patches after the
settings are stable.

Best Regards,
Hayes

Re: [PATCH v2 3/3] drivers core: allow id match override when manually binding driver

[Michal Suchanek]

On 28 June 2016 at 22:57, Mark Brown  wrote:
> On Tue, Jun 28, 2016 at 10:02:59PM +0200, Michal Suchanek wrote:
>
>> Of course I could add "my-shiny-new-board" compatible to the device
>> tree and spidev. Then when I build my-shiny-new-board2 and it happens
>> to also use userspace driver I will not bother to update the
>> compatible nor will anyone else doing this. So it's equivalent to
>> having "foobar123" in there from the start. Your proposed solution is
>> so complex that it will never be used as intended even if changing the
>> compatible on the node and driver could be both accomplished by an
>> echo to sysfs.
>
> If you are describing the connected SPI device as the board rather than
> the actual device you're doing things wrong, and if you have the same
> thing on two boards then /of course/ they should list the same
> compatible string so the existing software stack should work.  If people
> just use some random board description that happens to work right now
> even if it doesn't match their actual hardware then they're no worse off
> than with your hacks but we've been pushing people to do something long
> term supportable so a bunch of other people who paid attention will be
> better off.

ok, so my-shiny-new-spi-expansion-board and my-dhiny-new-expansion-board-2

It's unsupportable to pretend people will change the hardware
descriptio, either. It won't happen.

>
>> >  If the tooling around this is too hard to use then that
>> > seems like a useful thing to work on, having simple ways for people to
>> > describe modules they build for maker type systems (ideally integrated
>> > with schematic capture software) would be great for example.
>
>> Again, what simple to use tooling do you use to describe the modem you
>> connect to a serial port in the kernel (ideally integrated with
>> schematic capture software)? I use none. I just connect the modem. I
>> want to do that with all SPI devices that I do not intend to use with
>> an in-kernel driver above the spi master driver that provides the
>> communication channel as is the case with the serial modem.
>
> This has been gone through repeatedly.  There's obvious differences here
> - quite apart from anything else dedicated SPI connectors that are
> completely fixed function and also not part of a bigger expansion
> connector are rather rare and are a clear subset of the more general
> plugin module case.

The thing is that there are two common use cases. One is to get an
expansion board designed to connect to your big expansion connector.

The other is to get a generic expansion board and jumper wires. Of
course, you will not use all pins of your expansion connector this
way. On the other hand using the remaining pins becomes challenging
because of the jumper wires you just added. You can use some of the
remaining pins as GPIO or add more jumper wires and use some of the
remaining functions of the connector for another expansion board.

> The way we handle serial ports is currently not
> ideal anyway, and the general software stacks sitting on top of serial
> ports are very different to those for SPI.

Of course they are different. It's different communication channel
with different set of supported devices on the other end.

>
>> It is not my very specific use case. It's common use case for
>> devboards which have spi connectors.
>
> That's really not that common - it *is* common to have expansion
> connectors, but single function ones not so much and certainly not in
> sufficient numbers that it's worth doing something that only works for
> them alone (and then only in cases where spidev happens to be the best
> way to control the device which is a further subset).

It's not about single function connector. It's about using the
particular bus available on the connector. Devices using multiple
buses are very rare so even if you have specially designed expansion
board it rarely uses more than one function of the connector.

> There's also the
> fact that the limited connectors are more commonly found on the more
> expensive eval boards which of course tend to have users who are more
> technically experienced than the maker boards and should really not
> struggle with basic tasks.

On the other hand, expansion boards that designed for a particular
multi-function connector are much more expensive than generic boards
that just have a device on them and make the signals required to use
the device available on pin header which can be wired to any board.
Also the range of devices available on generic expansion board is much
larger than that available for a particular connector - be it Arduino
compatible, Pi compatible, Beagleboard compatible or anything else.

So it's very common to get a shiny new generic expansion board, look
at the pin signal description, wire these, look at the chip printing
and

1) it reads something like ds1301 and I see kernel driver for this -
mod the DT or write an overlay
2) it reads something like rc522 

Re: [PATCH v2 3/3] drivers core: allow id match override when manually binding driver

[Michal Suchanek]

On 28 June 2016 at 22:57, Mark Brown  wrote:
> On Tue, Jun 28, 2016 at 10:02:59PM +0200, Michal Suchanek wrote:
>
>> Of course I could add "my-shiny-new-board" compatible to the device
>> tree and spidev. Then when I build my-shiny-new-board2 and it happens
>> to also use userspace driver I will not bother to update the
>> compatible nor will anyone else doing this. So it's equivalent to
>> having "foobar123" in there from the start. Your proposed solution is
>> so complex that it will never be used as intended even if changing the
>> compatible on the node and driver could be both accomplished by an
>> echo to sysfs.
>
> If you are describing the connected SPI device as the board rather than
> the actual device you're doing things wrong, and if you have the same
> thing on two boards then /of course/ they should list the same
> compatible string so the existing software stack should work.  If people
> just use some random board description that happens to work right now
> even if it doesn't match their actual hardware then they're no worse off
> than with your hacks but we've been pushing people to do something long
> term supportable so a bunch of other people who paid attention will be
> better off.

ok, so my-shiny-new-spi-expansion-board and my-dhiny-new-expansion-board-2

It's unsupportable to pretend people will change the hardware
descriptio, either. It won't happen.

>
>> >  If the tooling around this is too hard to use then that
>> > seems like a useful thing to work on, having simple ways for people to
>> > describe modules they build for maker type systems (ideally integrated
>> > with schematic capture software) would be great for example.
>
>> Again, what simple to use tooling do you use to describe the modem you
>> connect to a serial port in the kernel (ideally integrated with
>> schematic capture software)? I use none. I just connect the modem. I
>> want to do that with all SPI devices that I do not intend to use with
>> an in-kernel driver above the spi master driver that provides the
>> communication channel as is the case with the serial modem.
>
> This has been gone through repeatedly.  There's obvious differences here
> - quite apart from anything else dedicated SPI connectors that are
> completely fixed function and also not part of a bigger expansion
> connector are rather rare and are a clear subset of the more general
> plugin module case.

The thing is that there are two common use cases. One is to get an
expansion board designed to connect to your big expansion connector.

The other is to get a generic expansion board and jumper wires. Of
course, you will not use all pins of your expansion connector this
way. On the other hand using the remaining pins becomes challenging
because of the jumper wires you just added. You can use some of the
remaining pins as GPIO or add more jumper wires and use some of the
remaining functions of the connector for another expansion board.

> The way we handle serial ports is currently not
> ideal anyway, and the general software stacks sitting on top of serial
> ports are very different to those for SPI.

Of course they are different. It's different communication channel
with different set of supported devices on the other end.

>
>> It is not my very specific use case. It's common use case for
>> devboards which have spi connectors.
>
> That's really not that common - it *is* common to have expansion
> connectors, but single function ones not so much and certainly not in
> sufficient numbers that it's worth doing something that only works for
> them alone (and then only in cases where spidev happens to be the best
> way to control the device which is a further subset).

It's not about single function connector. It's about using the
particular bus available on the connector. Devices using multiple
buses are very rare so even if you have specially designed expansion
board it rarely uses more than one function of the connector.

> There's also the
> fact that the limited connectors are more commonly found on the more
> expensive eval boards which of course tend to have users who are more
> technically experienced than the maker boards and should really not
> struggle with basic tasks.

On the other hand, expansion boards that designed for a particular
multi-function connector are much more expensive than generic boards
that just have a device on them and make the signals required to use
the device available on pin header which can be wired to any board.
Also the range of devices available on generic expansion board is much
larger than that available for a particular connector - be it Arduino
compatible, Pi compatible, Beagleboard compatible or anything else.

So it's very common to get a shiny new generic expansion board, look
at the pin signal description, wire these, look at the chip printing
and

1) it reads something like ds1301 and I see kernel driver for this -
mod the DT or write an overlay
2) it reads something like rc522 or pn533 and there 

Re: [PATCH v4 2/2] dt-bindings: analogix_dp: rockchip: correct the wrong compatible name

[Yakir Yang]

Doug,

On 06/23/2016 01:17 PM, Doug Anderson wrote:

Hi,

On Wed, Jun 22, 2016 at 6:47 PM, Yakir Yang  wrote:

The document about rockchip platform make a mistaken in available
compatible name of "rk3288-edp", we should correct it to "rk3288-dp"
which correspond to the compatible name in driver.

This mistaken was introduced in commit be91c36247089 ("dt-bindings:
add document for rockchip variant of analogix_dp").

Reported-by: Tomasz Figa 
Signed-off-by: Yakir Yang 
---
Hi all,

This is an external patch for analogix_dp misc cleanup thread [0]
[0]: https://patchwork.kernel.org/patch/9175613/

BR,
- Yakir

Changes in v4: None
Changes in v3:
- Add this patch in v3

  .../devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt   | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Douglas Anderson 

Thanks ;)

Re: [PATCH v4 2/2] dt-bindings: analogix_dp: rockchip: correct the wrong compatible name

[Yakir Yang]

Doug,

On 06/23/2016 01:17 PM, Doug Anderson wrote:

Hi,

On Wed, Jun 22, 2016 at 6:47 PM, Yakir Yang  wrote:

The document about rockchip platform make a mistaken in available
compatible name of "rk3288-edp", we should correct it to "rk3288-dp"
which correspond to the compatible name in driver.

This mistaken was introduced in commit be91c36247089 ("dt-bindings:
add document for rockchip variant of analogix_dp").

Reported-by: Tomasz Figa 
Signed-off-by: Yakir Yang 
---
Hi all,

This is an external patch for analogix_dp misc cleanup thread [0]
[0]: https://patchwork.kernel.org/patch/9175613/

BR,
- Yakir

Changes in v4: None
Changes in v3:
- Add this patch in v3

  .../devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt   | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Douglas Anderson 

Thanks ;)

Re: [PATCH v1 1/5] dt-bindings: Add support for LG LP079QX1-SP0V 1536x2048 panel

[Yakir Yang]

Rob,

On 06/29/2016 04:59 AM, Rob Herring wrote:

On Tue, Jun 28, 2016 at 12:51:12PM +0800, Yakir Yang wrote:

The LG LP079QX1-SP0V is an 7.9" QXGA TFT with LED Backlight unit and
32 pins eDP interface. This module supports 1536x2048 mode.

Signed-off-by: Yakir Yang 
---
  .../devicetree/bindings/display/panel/lg,lp079qx1-sp0v.txt | 7 +++
  1 file changed, 7 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/display/panel/lg,lp079qx1-sp0v.txt

Acked-by: Rob Herring 


Thanks for your fast respond ;)

Re: [PATCH v1 1/5] dt-bindings: Add support for LG LP079QX1-SP0V 1536x2048 panel

[Yakir Yang]

Rob,

On 06/29/2016 04:59 AM, Rob Herring wrote:

On Tue, Jun 28, 2016 at 12:51:12PM +0800, Yakir Yang wrote:

The LG LP079QX1-SP0V is an 7.9" QXGA TFT with LED Backlight unit and
32 pins eDP interface. This module supports 1536x2048 mode.

Signed-off-by: Yakir Yang 
---
  .../devicetree/bindings/display/panel/lg,lp079qx1-sp0v.txt | 7 +++
  1 file changed, 7 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/display/panel/lg,lp079qx1-sp0v.txt

Acked-by: Rob Herring 


Thanks for your fast respond ;)

Re: [PATCH 0/3] add support for Allwinner SoCs ADC

[Chen-Yu Tsai]

Hi,

On Tue, Jun 28, 2016 at 4:45 PM, Quentin Schulz
 wrote:
> The Allwinner SoCs all have an ADC that can also act as a touchscreen 
> controller
> and a thermal sensor. The first four channels can be used either for the ADC 
> or
> the touchscreen and the fifth channel is used for the thermal sensor. We
> currently have a driver for the two latter functions in
> drivers/input/touchscreen/sun4i-ts.c but we don't have access to the ADC 
> feature
> at all.
>
> This adds initial support for Allwinner SoCs ADC with all features. Yet, the
> touchscreen is not implemented but will be added later. To switch between
> touchscreen and ADC modes, you need to poke few bits in registers and
> (de)activate an interrupt (pen-up).
> A MFD is provided to let the input driver activate the pen-up interrupt 
> through
> virtual interrupt, poke few bits via regmap and read data from the ADC driver
> while both (and iio_hwmon) are probed by the MFD.

I take it that we are going to replace the original sun4i-ts driver
with this new mfd one, and various sub device drivers?

> There exists slight modifications between the different SoCs ADC like the
> address of some registers and the scale and offset to apply to thermal sensor
> raw values. These modifications are done by drivers on different
> platform_device_id passed by the MFD when probing subdrivers.
>
> This also modifies iio-hwmon to allow probe deferring when no iio channel is
> found. Currently when no iio channel is found, the probing of iio-hwmon fails.
> This is problematic when iio-hwmon probes before the iio driver could register
> iio channels to share.

One thing about iio-hwmon is that it doesn't support hwmon labels.
Any chance you could improve this, so we see the same names in userspace?

Thanks
ChenYu

>
> Quentin Schulz (3):
>   mfd: add support for Allwinner SoCs ADC
>   iio: adc: add support for Allwinner SoCs ADC
>   hwmon: iio_hwmon: defer probe when no channel is found
>
>  drivers/hwmon/iio_hwmon.c   |   5 +-
>  drivers/iio/adc/Kconfig |  12 ++
>  drivers/iio/adc/Makefile|   1 +
>  drivers/iio/adc/sunxi-gpadc-iio.c   | 371 
> 
>  drivers/mfd/Kconfig |  14 ++
>  drivers/mfd/Makefile|   2 +
>  drivers/mfd/sunxi-gpadc-mfd.c   | 188 ++
>  include/linux/mfd/sunxi-gpadc-mfd.h |  14 ++
>  8 files changed, 606 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/iio/adc/sunxi-gpadc-iio.c
>  create mode 100644 drivers/mfd/sunxi-gpadc-mfd.c
>  create mode 100644 include/linux/mfd/sunxi-gpadc-mfd.h
>
> --
> 2.5.0
>

Re: [PATCH 0/3] add support for Allwinner SoCs ADC

[Chen-Yu Tsai]

Hi,

On Tue, Jun 28, 2016 at 4:45 PM, Quentin Schulz
 wrote:
> The Allwinner SoCs all have an ADC that can also act as a touchscreen 
> controller
> and a thermal sensor. The first four channels can be used either for the ADC 
> or
> the touchscreen and the fifth channel is used for the thermal sensor. We
> currently have a driver for the two latter functions in
> drivers/input/touchscreen/sun4i-ts.c but we don't have access to the ADC 
> feature
> at all.
>
> This adds initial support for Allwinner SoCs ADC with all features. Yet, the
> touchscreen is not implemented but will be added later. To switch between
> touchscreen and ADC modes, you need to poke few bits in registers and
> (de)activate an interrupt (pen-up).
> A MFD is provided to let the input driver activate the pen-up interrupt 
> through
> virtual interrupt, poke few bits via regmap and read data from the ADC driver
> while both (and iio_hwmon) are probed by the MFD.

I take it that we are going to replace the original sun4i-ts driver
with this new mfd one, and various sub device drivers?

> There exists slight modifications between the different SoCs ADC like the
> address of some registers and the scale and offset to apply to thermal sensor
> raw values. These modifications are done by drivers on different
> platform_device_id passed by the MFD when probing subdrivers.
>
> This also modifies iio-hwmon to allow probe deferring when no iio channel is
> found. Currently when no iio channel is found, the probing of iio-hwmon fails.
> This is problematic when iio-hwmon probes before the iio driver could register
> iio channels to share.

One thing about iio-hwmon is that it doesn't support hwmon labels.
Any chance you could improve this, so we see the same names in userspace?

Thanks
ChenYu

>
> Quentin Schulz (3):
>   mfd: add support for Allwinner SoCs ADC
>   iio: adc: add support for Allwinner SoCs ADC
>   hwmon: iio_hwmon: defer probe when no channel is found
>
>  drivers/hwmon/iio_hwmon.c   |   5 +-
>  drivers/iio/adc/Kconfig |  12 ++
>  drivers/iio/adc/Makefile|   1 +
>  drivers/iio/adc/sunxi-gpadc-iio.c   | 371 
> 
>  drivers/mfd/Kconfig |  14 ++
>  drivers/mfd/Makefile|   2 +
>  drivers/mfd/sunxi-gpadc-mfd.c   | 188 ++
>  include/linux/mfd/sunxi-gpadc-mfd.h |  14 ++
>  8 files changed, 606 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/iio/adc/sunxi-gpadc-iio.c
>  create mode 100644 drivers/mfd/sunxi-gpadc-mfd.c
>  create mode 100644 include/linux/mfd/sunxi-gpadc-mfd.h
>
> --
> 2.5.0
>