from:"Bartlomiej Zolnierkiewicz"

Re: [PATCH] ata: add Buddha PATA controller driver

2018-10-18 Thread Bartlomiej Zolnierkiewicz

On 10/18/2018 02:41 PM, Christoph Hellwig wrote:
>> +static int __init pata_buddha_init_one(void)
>> +{
>> +struct zorro_dev *z = NULL;
>> +
>> +while ((z = zorro_find_device(ZORRO_WILDCARD, z))) {
> 
> I'm not really an m68k expert, but shouldn't this implement a
> struct zorro_driver instead?  (or maybe two of them as xsurf
> seems sufficiently different).

I didn't want to introduce too many changes over old IDE's
driver in the initial version of the libata driver as
I can't test them myself. Once the new driver is verified
to work I plan to convert it into proper Zorro_driver.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

Re: [PATCH] ata: add Buddha PATA controller driver

2018-10-18 Thread Bartlomiej Zolnierkiewicz

On 10/18/2018 02:41 PM, Christoph Hellwig wrote:
>> +static int __init pata_buddha_init_one(void)
>> +{
>> +struct zorro_dev *z = NULL;
>> +
>> +while ((z = zorro_find_device(ZORRO_WILDCARD, z))) {
> 
> I'm not really an m68k expert, but shouldn't this implement a
> struct zorro_driver instead?  (or maybe two of them as xsurf
> seems sufficiently different).

I didn't want to introduce too many changes over old IDE's
driver in the initial version of the libata driver as
I can't test them myself. Once the new driver is verified
to work I plan to convert it into proper Zorro_driver.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

[PATCH] ata: add Buddha PATA controller driver

2018-10-18 Thread Bartlomiej Zolnierkiewicz

Add Buddha PATA controller driver. It enables libata support for
the Buddha, Catweasel and X-Surf expansion boards on the Zorro
expansion bus.

Cc: John Paul Adrian Glaubitz 
Cc: Michael Schmitz 
Cc: Geert Uytterhoeven 
Signed-off-by: Bartlomiej Zolnierkiewicz 
---
John, please test if possible..

 drivers/ata/Kconfig   |   12 ++
 drivers/ata/Makefile  |1 
 drivers/ata/pata_buddha.c |  257 ++
 3 files changed, 270 insertions(+)

Index: b/drivers/ata/Kconfig
===
--- a/drivers/ata/Kconfig   2018-10-18 14:18:02.766452406 +0200
+++ b/drivers/ata/Kconfig   2018-10-18 14:18:02.766452406 +0200
@@ -965,6 +965,18 @@ config PATA_GAYLE
 
  If unsure, say N.
 
+config PATA_BUDDHA
+   tristate "Buddha/Catweasel/X-Surf PATA support"
+   depends on ZORRO
+   help
+ This option enables support for the IDE interfaces
+ on the Buddha, Catweasel and X-Surf expansion boards
+ on the Zorro expansion bus. It supports up to two
+ interfaces on the Buddha, three on the Catweasel and
+ two on the X-Surf.
+
+ If unsure, say N.
+
 config PATA_ISAPNP
tristate "ISA Plug and Play PATA support"
depends on ISAPNP
Index: b/drivers/ata/Makefile
===
--- a/drivers/ata/Makefile  2018-10-18 14:18:02.766452406 +0200
+++ b/drivers/ata/Makefile  2018-10-18 14:18:02.766452406 +0200
@@ -98,6 +98,7 @@ obj-$(CONFIG_PATA_WINBOND)+= pata_sl82c
 obj-$(CONFIG_PATA_CMD640_PCI)  += pata_cmd640.o
 obj-$(CONFIG_PATA_FALCON)  += pata_falcon.o
 obj-$(CONFIG_PATA_GAYLE)   += pata_gayle.o
+obj-$(CONFIG_PATA_BUDDHA)  += pata_buddha.o
 obj-$(CONFIG_PATA_ISAPNP)  += pata_isapnp.o
 obj-$(CONFIG_PATA_IXP4XX_CF)   += pata_ixp4xx_cf.o
 obj-$(CONFIG_PATA_MPIIX)   += pata_mpiix.o
Index: b/drivers/ata/pata_buddha.c
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ b/drivers/ata/pata_buddha.c 2018-10-18 14:23:41.054460925 +0200
@@ -0,0 +1,257 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * Buddha, Catweasel and X-Surf PATA controller driver
+ *
+ * Copyright (c) 2018 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Based on buddha.c:
+ *
+ * Copyright (C) 1997, 2001 by Geert Uytterhoeven and others
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define DRV_NAME "pata_buddha"
+#define DRV_VERSION "0.1.0"
+
+#define BUDDHA_BASE1   0x800
+#define BUDDHA_BASE2   0xa00
+#define BUDDHA_BASE3   0xc00
+#define XSURF_BASE10xb000 /* 2.5" interface */
+#define XSURF_BASE20xd000 /* 3.5" interface */
+#define BUDDHA_CONTROL 0x11a
+#define BUDDHA_IRQ 0xf00
+#define XSURF_IRQ  0x7e
+#define BUDDHA_IRQ_MR  0xfc0   /* master interrupt enable */
+
+enum {
+   BOARD_BUDDHA = 0,
+   BOARD_CATWEASEL,
+   BOARD_XSURF
+};
+
+static unsigned int buddha_bases[3] __initdata = {
+   BUDDHA_BASE1, BUDDHA_BASE2, BUDDHA_BASE3
+};
+
+static unsigned int xsurf_bases[2] __initdata = {
+   XSURF_BASE1, XSURF_BASE2
+};
+
+static struct scsi_host_template pata_buddha_sht = {
+   ATA_PIO_SHT(DRV_NAME),
+};
+
+/* FIXME: is this needed? */
+static unsigned int pata_buddha_data_xfer(struct ata_queued_cmd *qc,
+unsigned char *buf,
+unsigned int buflen, int rw)
+{
+   struct ata_device *dev = qc->dev;
+   struct ata_port *ap = dev->link->ap;
+   void __iomem *data_addr = ap->ioaddr.data_addr;
+   unsigned int words = buflen >> 1;
+
+   /* Transfer multiple of 2 bytes */
+   if (rw == READ)
+   raw_insw((u16 *)data_addr, (u16 *)buf, words);
+   else
+   raw_outsw((u16 *)data_addr, (u16 *)buf, words);
+
+   /* Transfer trailing byte, if any. */
+   if (unlikely(buflen & 0x01)) {
+   unsigned char pad[2] = { };
+
+   /* Point buf to the tail of buffer */
+   buf += buflen - 1;
+
+   if (rw == READ) {
+   raw_insw((u16 *)data_addr, (u16 *)pad, 1);
+   *buf = pad[0];
+   } else {
+   pad[0] = *buf;
+   raw_outsw((u16 *)data_addr, (u16 *)pad, 1);
+   }
+   words++;
+   }
+
+   return words << 1;
+}
+
+/*
+ * Provide our own set_mode() as we don't want to change anything that has
+ * already been configured..
+ */
+static int pata_buddha_set_mode(struct ata_link *link,
+   struct ata_device **unused)
+{
+   struct ata_device *dev

[PATCH] ata: add Buddha PATA controller driver

2018-10-18 Thread Bartlomiej Zolnierkiewicz

Add Buddha PATA controller driver. It enables libata support for
the Buddha, Catweasel and X-Surf expansion boards on the Zorro
expansion bus.

Cc: John Paul Adrian Glaubitz 
Cc: Michael Schmitz 
Cc: Geert Uytterhoeven 
Signed-off-by: Bartlomiej Zolnierkiewicz 
---
John, please test if possible..

 drivers/ata/Kconfig   |   12 ++
 drivers/ata/Makefile  |1 
 drivers/ata/pata_buddha.c |  257 ++
 3 files changed, 270 insertions(+)

Index: b/drivers/ata/Kconfig
===
--- a/drivers/ata/Kconfig   2018-10-18 14:18:02.766452406 +0200
+++ b/drivers/ata/Kconfig   2018-10-18 14:18:02.766452406 +0200
@@ -965,6 +965,18 @@ config PATA_GAYLE
 
  If unsure, say N.
 
+config PATA_BUDDHA
+   tristate "Buddha/Catweasel/X-Surf PATA support"
+   depends on ZORRO
+   help
+ This option enables support for the IDE interfaces
+ on the Buddha, Catweasel and X-Surf expansion boards
+ on the Zorro expansion bus. It supports up to two
+ interfaces on the Buddha, three on the Catweasel and
+ two on the X-Surf.
+
+ If unsure, say N.
+
 config PATA_ISAPNP
tristate "ISA Plug and Play PATA support"
depends on ISAPNP
Index: b/drivers/ata/Makefile
===
--- a/drivers/ata/Makefile  2018-10-18 14:18:02.766452406 +0200
+++ b/drivers/ata/Makefile  2018-10-18 14:18:02.766452406 +0200
@@ -98,6 +98,7 @@ obj-$(CONFIG_PATA_WINBOND)+= pata_sl82c
 obj-$(CONFIG_PATA_CMD640_PCI)  += pata_cmd640.o
 obj-$(CONFIG_PATA_FALCON)  += pata_falcon.o
 obj-$(CONFIG_PATA_GAYLE)   += pata_gayle.o
+obj-$(CONFIG_PATA_BUDDHA)  += pata_buddha.o
 obj-$(CONFIG_PATA_ISAPNP)  += pata_isapnp.o
 obj-$(CONFIG_PATA_IXP4XX_CF)   += pata_ixp4xx_cf.o
 obj-$(CONFIG_PATA_MPIIX)   += pata_mpiix.o
Index: b/drivers/ata/pata_buddha.c
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ b/drivers/ata/pata_buddha.c 2018-10-18 14:23:41.054460925 +0200
@@ -0,0 +1,257 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * Buddha, Catweasel and X-Surf PATA controller driver
+ *
+ * Copyright (c) 2018 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Based on buddha.c:
+ *
+ * Copyright (C) 1997, 2001 by Geert Uytterhoeven and others
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define DRV_NAME "pata_buddha"
+#define DRV_VERSION "0.1.0"
+
+#define BUDDHA_BASE1   0x800
+#define BUDDHA_BASE2   0xa00
+#define BUDDHA_BASE3   0xc00
+#define XSURF_BASE10xb000 /* 2.5" interface */
+#define XSURF_BASE20xd000 /* 3.5" interface */
+#define BUDDHA_CONTROL 0x11a
+#define BUDDHA_IRQ 0xf00
+#define XSURF_IRQ  0x7e
+#define BUDDHA_IRQ_MR  0xfc0   /* master interrupt enable */
+
+enum {
+   BOARD_BUDDHA = 0,
+   BOARD_CATWEASEL,
+   BOARD_XSURF
+};
+
+static unsigned int buddha_bases[3] __initdata = {
+   BUDDHA_BASE1, BUDDHA_BASE2, BUDDHA_BASE3
+};
+
+static unsigned int xsurf_bases[2] __initdata = {
+   XSURF_BASE1, XSURF_BASE2
+};
+
+static struct scsi_host_template pata_buddha_sht = {
+   ATA_PIO_SHT(DRV_NAME),
+};
+
+/* FIXME: is this needed? */
+static unsigned int pata_buddha_data_xfer(struct ata_queued_cmd *qc,
+unsigned char *buf,
+unsigned int buflen, int rw)
+{
+   struct ata_device *dev = qc->dev;
+   struct ata_port *ap = dev->link->ap;
+   void __iomem *data_addr = ap->ioaddr.data_addr;
+   unsigned int words = buflen >> 1;
+
+   /* Transfer multiple of 2 bytes */
+   if (rw == READ)
+   raw_insw((u16 *)data_addr, (u16 *)buf, words);
+   else
+   raw_outsw((u16 *)data_addr, (u16 *)buf, words);
+
+   /* Transfer trailing byte, if any. */
+   if (unlikely(buflen & 0x01)) {
+   unsigned char pad[2] = { };
+
+   /* Point buf to the tail of buffer */
+   buf += buflen - 1;
+
+   if (rw == READ) {
+   raw_insw((u16 *)data_addr, (u16 *)pad, 1);
+   *buf = pad[0];
+   } else {
+   pad[0] = *buf;
+   raw_outsw((u16 *)data_addr, (u16 *)pad, 1);
+   }
+   words++;
+   }
+
+   return words << 1;
+}
+
+/*
+ * Provide our own set_mode() as we don't want to change anything that has
+ * already been configured..
+ */
+static int pata_buddha_set_mode(struct ata_link *link,
+   struct ata_device **unused)
+{
+   struct ata_device *dev

[PATCH v2 13/17] thermal: tegra: enable+check sensor after its setup is finished

2018-10-17 Thread Bartlomiej Zolnierkiewicz

Enable+check sensor after setting zone->tz and programming hwtrips.

Cc: Thierry Reding 
Cc: Jonathan Hunter 
Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/thermal/tegra/soctherm.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/thermal/tegra/soctherm.c b/drivers/thermal/tegra/soctherm.c
index 2ac9f81..394b34e 100644
--- a/drivers/thermal/tegra/soctherm.c
+++ b/drivers/thermal/tegra/soctherm.c
@@ -1375,9 +1375,6 @@ static int tegra_soctherm_probe(struct platform_device 
*pdev)
goto disable_clocks;
}
 
-   thermal_zone_set_mode(z, THERMAL_DEVICE_ENABLED);
-   thermal_zone_device_check(z);
-
zone->tz = z;
tegra->thermctl_tzs[soc->ttgs[i]->id] = z;
 
@@ -1385,6 +1382,9 @@ static int tegra_soctherm_probe(struct platform_device 
*pdev)
err = tegra_soctherm_set_hwtrips(>dev, soc->ttgs[i], z);
if (err)
goto disable_clocks;
+
+   thermal_zone_set_mode(z, THERMAL_DEVICE_ENABLED);
+   thermal_zone_device_check(z);
}
 
soctherm_debug_init(pdev);
-- 
1.9.1

[PATCH v2 13/17] thermal: tegra: enable+check sensor after its setup is finished

2018-10-17 Thread Bartlomiej Zolnierkiewicz

Enable+check sensor after setting zone->tz and programming hwtrips.

Cc: Thierry Reding 
Cc: Jonathan Hunter 
Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/thermal/tegra/soctherm.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/thermal/tegra/soctherm.c b/drivers/thermal/tegra/soctherm.c
index 2ac9f81..394b34e 100644
--- a/drivers/thermal/tegra/soctherm.c
+++ b/drivers/thermal/tegra/soctherm.c
@@ -1375,9 +1375,6 @@ static int tegra_soctherm_probe(struct platform_device 
*pdev)
goto disable_clocks;
}
 
-   thermal_zone_set_mode(z, THERMAL_DEVICE_ENABLED);
-   thermal_zone_device_check(z);
-
zone->tz = z;
tegra->thermctl_tzs[soc->ttgs[i]->id] = z;
 
@@ -1385,6 +1382,9 @@ static int tegra_soctherm_probe(struct platform_device 
*pdev)
err = tegra_soctherm_set_hwtrips(>dev, soc->ttgs[i], z);
if (err)
goto disable_clocks;
+
+   thermal_zone_set_mode(z, THERMAL_DEVICE_ENABLED);
+   thermal_zone_device_check(z);
}
 
soctherm_debug_init(pdev);
-- 
1.9.1

[PATCH v2 04/17] thermal: separate sensor registration and enable+check operations

2018-10-17 Thread Bartlomiej Zolnierkiewicz

[devm]_thermal_zone_of_sensor_register() is used to register
thermal sensor by thermal drivers using DeviceTree. Besides
registering sensor this function also immediately:

- enables it:

  tzd->ops->set_mode(tzd, THERMAL_DEVICE_ENABLED)
  (->set_mode is set to of_thermal_set_mode() in of-thermal.c)

- checks it (indirectly by using of_thermal_set_mode()):

  thermal_zone_device_update(tz, THERMAL_EVENT_UNSPECIFIED);
  (which in turn ends up using ->get_temp method).

For many DT thermal drivers this causes a problem because:

- [devm]_thermal_zone_of_sensor_register() need to be called in
  order to obtain data about thermal trips which are then used to
  finish hardware sensor setup (only after which ->get_temp can
  be used)

There is also related issue for DT thermal drivers that support
IRQ (i.e. exynos and rockchip ones):

- sensor hardware should be enabled only after IRQ handler is
  requested (because otherwise we might get IRQs that we can't
  handle)

- IRQ handler needs tzd structure which is obtained from
  [devm_]thermal_zone_of_sensor_register()

- after [devm_]thermal_zone_of_sensor_register() call core
  thermal code assumes that sensor is enabled and ready to use
  (i.e. that IRQ handler has been requested and sensor hardware
  has been enabled)

In order to prepare for fixing all abovementioned issues separate
sensor registration and enable+check operations in the core DT
thermal code and update DT thermal drivers accordingly:

* Move thermal_zone_[set_mode,device_check]() calls to the users of
  [devm]_thermal_zone_of_sensor_register().

There should be no functional changes caused by this patch.

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/ata/ahci_imx.c | 10 --
 drivers/hwmon/hwmon.c  |  5 +
 drivers/hwmon/ntc_thermistor.c |  4 
 drivers/hwmon/scpi-hwmon.c |  4 
 drivers/iio/adc/sun4i-gpadc-iio.c  |  5 +
 drivers/input/touchscreen/sun4i-ts.c   |  8 +++-
 drivers/regulator/max8973-regulator.c  |  3 +++
 drivers/thermal/armada_thermal.c   |  3 +++
 drivers/thermal/broadcom/bcm2835_thermal.c |  3 +++
 drivers/thermal/broadcom/brcmstb_thermal.c |  3 +++
 drivers/thermal/broadcom/ns-thermal.c  |  3 +++
 drivers/thermal/hisi_thermal.c |  3 +++
 drivers/thermal/max77620_thermal.c |  3 +++
 drivers/thermal/mtk_thermal.c  |  3 +++
 drivers/thermal/of-thermal.c   |  6 --
 drivers/thermal/qcom-spmi-temp-alarm.c |  3 +++
 drivers/thermal/qcom/tsens.c   |  6 ++
 drivers/thermal/qoriq_thermal.c|  3 +++
 drivers/thermal/rcar_gen3_thermal.c|  4 
 drivers/thermal/rcar_thermal.c |  4 
 drivers/thermal/rockchip_thermal.c |  3 +++
 drivers/thermal/samsung/exynos_tmu.c   |  3 +++
 drivers/thermal/tango_thermal.c|  5 +
 drivers/thermal/tegra/soctherm.c   |  3 +++
 drivers/thermal/tegra/tegra-bpmp-thermal.c |  3 +++
 drivers/thermal/thermal-generic-adc.c  |  3 +++
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c |  3 +++
 drivers/thermal/uniphier_thermal.c |  3 +++
 drivers/thermal/zx2967_thermal.c   |  3 +++
 29 files changed, 106 insertions(+), 9 deletions(-)

diff --git a/drivers/ata/ahci_imx.c b/drivers/ata/ahci_imx.c
index b00799d..f1dcc3d 100644
--- a/drivers/ata/ahci_imx.c
+++ b/drivers/ata/ahci_imx.c
@@ -1141,6 +1141,7 @@ static int imx_ahci_probe(struct platform_device *pdev)
IS_ENABLED(CONFIG_HWMON)) {
/* Add the temperature monitor */
struct device *hwmon_dev;
+   struct thermal_zone_device *tzd;
 
hwmon_dev =
devm_hwmon_device_register_with_groups(dev,
@@ -1151,8 +1152,13 @@ static int imx_ahci_probe(struct platform_device *pdev)
ret = PTR_ERR(hwmon_dev);
goto disable_clk;
}
-   devm_thermal_zone_of_sensor_register(hwmon_dev, 0, hwmon_dev,
-_sata_ahci_of_thermal_ops);
+   tzd = devm_thermal_zone_of_sensor_register(hwmon_dev, 0,
+   hwmon_dev,
+   _sata_ahci_of_thermal_ops);
+   if (!IS_ERR(tzd)) {
+   thermal_zone_set_mode(tzd, THERMAL_DEVICE_ENABLED);
+   thermal_zone_device_check(tzd);
+   }
dev_info(dev, "%s: sensor 'sata_ahci'\n", dev_name(hwmon_dev));
}
 
diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c
index ac1cdf8..486d7a0 100644
--- a/dr

[PATCH v2 04/17] thermal: separate sensor registration and enable+check operations

2018-10-17 Thread Bartlomiej Zolnierkiewicz

[devm]_thermal_zone_of_sensor_register() is used to register
thermal sensor by thermal drivers using DeviceTree. Besides
registering sensor this function also immediately:

- enables it:

  tzd->ops->set_mode(tzd, THERMAL_DEVICE_ENABLED)
  (->set_mode is set to of_thermal_set_mode() in of-thermal.c)

- checks it (indirectly by using of_thermal_set_mode()):

  thermal_zone_device_update(tz, THERMAL_EVENT_UNSPECIFIED);
  (which in turn ends up using ->get_temp method).

For many DT thermal drivers this causes a problem because:

- [devm]_thermal_zone_of_sensor_register() need to be called in
  order to obtain data about thermal trips which are then used to
  finish hardware sensor setup (only after which ->get_temp can
  be used)

There is also related issue for DT thermal drivers that support
IRQ (i.e. exynos and rockchip ones):

- sensor hardware should be enabled only after IRQ handler is
  requested (because otherwise we might get IRQs that we can't
  handle)

- IRQ handler needs tzd structure which is obtained from
  [devm_]thermal_zone_of_sensor_register()

- after [devm_]thermal_zone_of_sensor_register() call core
  thermal code assumes that sensor is enabled and ready to use
  (i.e. that IRQ handler has been requested and sensor hardware
  has been enabled)

In order to prepare for fixing all abovementioned issues separate
sensor registration and enable+check operations in the core DT
thermal code and update DT thermal drivers accordingly:

* Move thermal_zone_[set_mode,device_check]() calls to the users of
  [devm]_thermal_zone_of_sensor_register().

There should be no functional changes caused by this patch.

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/ata/ahci_imx.c | 10 --
 drivers/hwmon/hwmon.c  |  5 +
 drivers/hwmon/ntc_thermistor.c |  4 
 drivers/hwmon/scpi-hwmon.c |  4 
 drivers/iio/adc/sun4i-gpadc-iio.c  |  5 +
 drivers/input/touchscreen/sun4i-ts.c   |  8 +++-
 drivers/regulator/max8973-regulator.c  |  3 +++
 drivers/thermal/armada_thermal.c   |  3 +++
 drivers/thermal/broadcom/bcm2835_thermal.c |  3 +++
 drivers/thermal/broadcom/brcmstb_thermal.c |  3 +++
 drivers/thermal/broadcom/ns-thermal.c  |  3 +++
 drivers/thermal/hisi_thermal.c |  3 +++
 drivers/thermal/max77620_thermal.c |  3 +++
 drivers/thermal/mtk_thermal.c  |  3 +++
 drivers/thermal/of-thermal.c   |  6 --
 drivers/thermal/qcom-spmi-temp-alarm.c |  3 +++
 drivers/thermal/qcom/tsens.c   |  6 ++
 drivers/thermal/qoriq_thermal.c|  3 +++
 drivers/thermal/rcar_gen3_thermal.c|  4 
 drivers/thermal/rcar_thermal.c |  4 
 drivers/thermal/rockchip_thermal.c |  3 +++
 drivers/thermal/samsung/exynos_tmu.c   |  3 +++
 drivers/thermal/tango_thermal.c|  5 +
 drivers/thermal/tegra/soctherm.c   |  3 +++
 drivers/thermal/tegra/tegra-bpmp-thermal.c |  3 +++
 drivers/thermal/thermal-generic-adc.c  |  3 +++
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c |  3 +++
 drivers/thermal/uniphier_thermal.c |  3 +++
 drivers/thermal/zx2967_thermal.c   |  3 +++
 29 files changed, 106 insertions(+), 9 deletions(-)

diff --git a/drivers/ata/ahci_imx.c b/drivers/ata/ahci_imx.c
index b00799d..f1dcc3d 100644
--- a/drivers/ata/ahci_imx.c
+++ b/drivers/ata/ahci_imx.c
@@ -1141,6 +1141,7 @@ static int imx_ahci_probe(struct platform_device *pdev)
IS_ENABLED(CONFIG_HWMON)) {
/* Add the temperature monitor */
struct device *hwmon_dev;
+   struct thermal_zone_device *tzd;
 
hwmon_dev =
devm_hwmon_device_register_with_groups(dev,
@@ -1151,8 +1152,13 @@ static int imx_ahci_probe(struct platform_device *pdev)
ret = PTR_ERR(hwmon_dev);
goto disable_clk;
}
-   devm_thermal_zone_of_sensor_register(hwmon_dev, 0, hwmon_dev,
-_sata_ahci_of_thermal_ops);
+   tzd = devm_thermal_zone_of_sensor_register(hwmon_dev, 0,
+   hwmon_dev,
+   _sata_ahci_of_thermal_ops);
+   if (!IS_ERR(tzd)) {
+   thermal_zone_set_mode(tzd, THERMAL_DEVICE_ENABLED);
+   thermal_zone_device_check(tzd);
+   }
dev_info(dev, "%s: sensor 'sata_ahci'\n", dev_name(hwmon_dev));
}
 
diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c
index ac1cdf8..486d7a0 100644
--- a/dr

[PATCH v2 11/17] thermal: rockchip_thermal: enable+check sensor after its setup is finished

2018-10-17 Thread Bartlomiej Zolnierkiewicz

* Enable+check sensor explicitly in rockchip_thermal_probe() (also
  check sensor after doing chipset specific control operation).

* Remove superfluous second sensor enable+check attempt.

Cc: Heiko Stuebner 
Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/thermal/rockchip_thermal.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/thermal/rockchip_thermal.c 
b/drivers/thermal/rockchip_thermal.c
index 90d8175..ef9e2aa 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -1161,9 +1161,6 @@ static int rockchip_configure_from_dt(struct device *dev,
return error;
}
 
-   thermal_zone_set_mode(sensor->tzd, THERMAL_DEVICE_ENABLED);
-   thermal_zone_device_check(sensor->tzd);
-
return 0;
 }
 
@@ -1272,6 +1269,10 @@ static int rockchip_thermal_probe(struct platform_device 
*pdev)
}
}
 
+   for (i = 0; i < thermal->chip->chn_num; i++)
+   thermal_zone_set_mode((>sensors[i])->tzd,
+ THERMAL_DEVICE_ENABLED);
+
error = devm_request_threaded_irq(>dev, irq, NULL,
  _thermal_alarm_irq_thread,
  IRQF_ONESHOT,
@@ -1284,11 +1285,8 @@ static int rockchip_thermal_probe(struct platform_device 
*pdev)
 
thermal->chip->control(thermal->regs, true);
 
-   for (i = 0; i < thermal->chip->chn_num; i++) {
-   thermal_zone_set_mode((>sensors[i])->tzd,
- THERMAL_DEVICE_ENABLED);
+   for (i = 0; i < thermal->chip->chn_num; i++)
thermal_zone_device_check((>sensors[i])->tzd);
-   }
 
platform_set_drvdata(pdev, thermal);
 
-- 
1.9.1

[PATCH v2 11/17] thermal: rockchip_thermal: enable+check sensor after its setup is finished

2018-10-17 Thread Bartlomiej Zolnierkiewicz

* Enable+check sensor explicitly in rockchip_thermal_probe() (also
  check sensor after doing chipset specific control operation).

* Remove superfluous second sensor enable+check attempt.

Cc: Heiko Stuebner 
Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/thermal/rockchip_thermal.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/thermal/rockchip_thermal.c 
b/drivers/thermal/rockchip_thermal.c
index 90d8175..ef9e2aa 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -1161,9 +1161,6 @@ static int rockchip_configure_from_dt(struct device *dev,
return error;
}
 
-   thermal_zone_set_mode(sensor->tzd, THERMAL_DEVICE_ENABLED);
-   thermal_zone_device_check(sensor->tzd);
-
return 0;
 }
 
@@ -1272,6 +1269,10 @@ static int rockchip_thermal_probe(struct platform_device 
*pdev)
}
}
 
+   for (i = 0; i < thermal->chip->chn_num; i++)
+   thermal_zone_set_mode((>sensors[i])->tzd,
+ THERMAL_DEVICE_ENABLED);
+
error = devm_request_threaded_irq(>dev, irq, NULL,
  _thermal_alarm_irq_thread,
  IRQF_ONESHOT,
@@ -1284,11 +1285,8 @@ static int rockchip_thermal_probe(struct platform_device 
*pdev)
 
thermal->chip->control(thermal->regs, true);
 
-   for (i = 0; i < thermal->chip->chn_num; i++) {
-   thermal_zone_set_mode((>sensors[i])->tzd,
- THERMAL_DEVICE_ENABLED);
+   for (i = 0; i < thermal->chip->chn_num; i++)
thermal_zone_device_check((>sensors[i])->tzd);
-   }
 
platform_set_drvdata(pdev, thermal);
 
-- 
1.9.1

[PATCH v2 14/17] thermal: ti-soc-thermal: enable+check sensor after its setup is finished

2018-10-17 Thread Bartlomiej Zolnierkiewicz

Enable sensor after setting sensor data and check sensor after
writing update interval.

Cc: Eduardo Valentin 
Cc: Keerthy 
Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c 
b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
index aa15719..4675d96 100644
--- a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
+++ b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
@@ -197,13 +197,15 @@ int ti_thermal_expose_sensor(struct ti_bandgap *bgp, int 
id,
return PTR_ERR(data->ti_thermal);
}
 
+   ti_bandgap_set_sensor_data(bgp, id, data);
+
thermal_zone_set_mode(data->ti_thermal, THERMAL_DEVICE_ENABLED);
-   thermal_zone_device_check(data->ti_thermal);
 
-   ti_bandgap_set_sensor_data(bgp, id, data);
ti_bandgap_write_update_interval(bgp, data->sensor_id,
data->ti_thermal->polling_delay);
 
+   thermal_zone_device_check(data->ti_thermal);
+
return 0;
 }
 
-- 
1.9.1

[PATCH v2 17/17] thermal: warn on attempts to read temperature on disabled sensors

2018-10-17 Thread Bartlomiej Zolnierkiewicz

* Add ops_of_thermal flag to struct thermal_zone_device_ops and
  set it in of-thermal.c.

* Add checking sensor mode for drivers using of-thermal.c to
  thermal_zone_get_temp() (print a warning if sensor is disabled).

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/thermal/of-thermal.c  |  2 ++
 drivers/thermal/thermal_helpers.c | 12 
 include/linux/thermal.h   |  1 +
 3 files changed, 15 insertions(+)

diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index 523ac5c..912bd85 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -378,6 +378,8 @@ static int of_thermal_get_crit_temp(struct 
thermal_zone_device *tz,
 
.bind = of_thermal_bind,
.unbind = of_thermal_unbind,
+
+   .ops_of_thermal = true,
 };
 
 /***   sensor API   ***/
diff --git a/drivers/thermal/thermal_helpers.c 
b/drivers/thermal/thermal_helpers.c
index 14b7a7e..12d1f53 100644
--- a/drivers/thermal/thermal_helpers.c
+++ b/drivers/thermal/thermal_helpers.c
@@ -84,6 +84,18 @@ int thermal_zone_get_temp(struct thermal_zone_device *tz, 
int *temp)
if (!tz || IS_ERR(tz) || !tz->ops->get_temp)
goto exit;
 
+   if (tz->ops->ops_of_thermal) {
+   enum thermal_device_mode mode;
+
+   ret = tz->ops->get_mode(tz, );
+   if (ret)
+   goto exit;
+
+   if (mode == THERMAL_DEVICE_DISABLED)
+   dev_warn_once(>device,
+"trying to read out disabled thermal zone\n");
+   }
+
mutex_lock(>lock);
 
ret = tz->ops->get_temp(tz, temp);
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 92c460e..2215e11 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -115,6 +115,7 @@ struct thermal_zone_device_ops {
   enum thermal_trip_type);
 
bool set_mode_skip_check;
+   bool ops_of_thermal;
 };
 
 struct thermal_cooling_device_ops {
-- 
1.9.1

[PATCH v2 16/17] thermal: zx2967: enable+check sensor after its setup is finished

2018-10-17 Thread Bartlomiej Zolnierkiewicz

Enable+check sensor after checking sensor coefficients.

Cc: Jun Nie 
Cc: Baoyou Xie 
Cc: Shawn Guo 
Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/thermal/zx2967_thermal.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/thermal/zx2967_thermal.c b/drivers/thermal/zx2967_thermal.c
index 3c08e1d..4e30b1f 100644
--- a/drivers/thermal/zx2967_thermal.c
+++ b/drivers/thermal/zx2967_thermal.c
@@ -168,9 +168,6 @@ static int zx2967_thermal_probe(struct platform_device 
*pdev)
goto disable_clk_all;
}
 
-   thermal_zone_set_mode(priv->tzd, THERMAL_DEVICE_ENABLED);
-   thermal_zone_device_check(priv->tzd);
-
if (priv->tzd->tzp->slope == 0) {
thermal_zone_of_sensor_unregister(>dev, priv->tzd);
dev_err(>dev, "coefficients of sensor is invalid\n");
@@ -178,6 +175,9 @@ static int zx2967_thermal_probe(struct platform_device 
*pdev)
goto disable_clk_all;
}
 
+   thermal_zone_set_mode(priv->tzd, THERMAL_DEVICE_ENABLED);
+   thermal_zone_device_check(priv->tzd);
+
priv->dev = >dev;
platform_set_drvdata(pdev, priv);
 
-- 
1.9.1

[PATCH v2 15/17] thermal: uniphier: enable+check sensor after its setup is finished

2018-10-17 Thread Bartlomiej Zolnierkiewicz

Enable sensor after checking trip points (unipher_tm_enable_sensor()
enables IRQ so we need to toggle sensor before calling it) and check
sensor after doing chipset specific enable sensor operation.

Cc: Masahiro Yamada 
Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/thermal/uniphier_thermal.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/thermal/uniphier_thermal.c 
b/drivers/thermal/uniphier_thermal.c
index ed3a920..9ccc1fc 100644
--- a/drivers/thermal/uniphier_thermal.c
+++ b/drivers/thermal/uniphier_thermal.c
@@ -307,9 +307,6 @@ static int uniphier_tm_probe(struct platform_device *pdev)
return PTR_ERR(tdev->tz_dev);
}
 
-   thermal_zone_set_mode(tdev->tz_dev, THERMAL_DEVICE_ENABLED);
-   thermal_zone_device_check(tdev->tz_dev);
-
/* get trip points */
trips = of_thermal_get_trip_points(tdev->tz_dev);
ntrips = of_thermal_get_ntrips(tdev->tz_dev);
@@ -332,8 +329,12 @@ static int uniphier_tm_probe(struct platform_device *pdev)
return -EINVAL;
}
 
+   thermal_zone_set_mode(tdev->tz_dev, THERMAL_DEVICE_ENABLED);
+
uniphier_tm_enable_sensor(tdev);
 
+   thermal_zone_device_check(tdev->tz_dev);
+
return 0;
 }
 
-- 
1.9.1

[PATCH v2 16/17] thermal: zx2967: enable+check sensor after its setup is finished

2018-10-17 Thread Bartlomiej Zolnierkiewicz

Enable+check sensor after checking sensor coefficients.

Cc: Jun Nie 
Cc: Baoyou Xie 
Cc: Shawn Guo 
Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/thermal/zx2967_thermal.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/thermal/zx2967_thermal.c b/drivers/thermal/zx2967_thermal.c
index 3c08e1d..4e30b1f 100644
--- a/drivers/thermal/zx2967_thermal.c
+++ b/drivers/thermal/zx2967_thermal.c
@@ -168,9 +168,6 @@ static int zx2967_thermal_probe(struct platform_device 
*pdev)
goto disable_clk_all;
}
 
-   thermal_zone_set_mode(priv->tzd, THERMAL_DEVICE_ENABLED);
-   thermal_zone_device_check(priv->tzd);
-
if (priv->tzd->tzp->slope == 0) {
thermal_zone_of_sensor_unregister(>dev, priv->tzd);
dev_err(>dev, "coefficients of sensor is invalid\n");
@@ -178,6 +175,9 @@ static int zx2967_thermal_probe(struct platform_device 
*pdev)
goto disable_clk_all;
}
 
+   thermal_zone_set_mode(priv->tzd, THERMAL_DEVICE_ENABLED);
+   thermal_zone_device_check(priv->tzd);
+
priv->dev = >dev;
platform_set_drvdata(pdev, priv);
 
-- 
1.9.1

[PATCH v2 15/17] thermal: uniphier: enable+check sensor after its setup is finished

2018-10-17 Thread Bartlomiej Zolnierkiewicz

Enable sensor after checking trip points (unipher_tm_enable_sensor()
enables IRQ so we need to toggle sensor before calling it) and check
sensor after doing chipset specific enable sensor operation.

Cc: Masahiro Yamada 
Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/thermal/uniphier_thermal.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/thermal/uniphier_thermal.c 
b/drivers/thermal/uniphier_thermal.c
index ed3a920..9ccc1fc 100644
--- a/drivers/thermal/uniphier_thermal.c
+++ b/drivers/thermal/uniphier_thermal.c
@@ -307,9 +307,6 @@ static int uniphier_tm_probe(struct platform_device *pdev)
return PTR_ERR(tdev->tz_dev);
}
 
-   thermal_zone_set_mode(tdev->tz_dev, THERMAL_DEVICE_ENABLED);
-   thermal_zone_device_check(tdev->tz_dev);
-
/* get trip points */
trips = of_thermal_get_trip_points(tdev->tz_dev);
ntrips = of_thermal_get_ntrips(tdev->tz_dev);
@@ -332,8 +329,12 @@ static int uniphier_tm_probe(struct platform_device *pdev)
return -EINVAL;
}
 
+   thermal_zone_set_mode(tdev->tz_dev, THERMAL_DEVICE_ENABLED);
+
uniphier_tm_enable_sensor(tdev);
 
+   thermal_zone_device_check(tdev->tz_dev);
+
return 0;
 }
 
-- 
1.9.1

[PATCH v2 14/17] thermal: ti-soc-thermal: enable+check sensor after its setup is finished

2018-10-17 Thread Bartlomiej Zolnierkiewicz

Enable sensor after setting sensor data and check sensor after
writing update interval.

Cc: Eduardo Valentin 
Cc: Keerthy 
Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c 
b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
index aa15719..4675d96 100644
--- a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
+++ b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
@@ -197,13 +197,15 @@ int ti_thermal_expose_sensor(struct ti_bandgap *bgp, int 
id,
return PTR_ERR(data->ti_thermal);
}
 
+   ti_bandgap_set_sensor_data(bgp, id, data);
+
thermal_zone_set_mode(data->ti_thermal, THERMAL_DEVICE_ENABLED);
-   thermal_zone_device_check(data->ti_thermal);
 
-   ti_bandgap_set_sensor_data(bgp, id, data);
ti_bandgap_write_update_interval(bgp, data->sensor_id,
data->ti_thermal->polling_delay);
 
+   thermal_zone_device_check(data->ti_thermal);
+
return 0;
 }
 
-- 
1.9.1

[PATCH v2 17/17] thermal: warn on attempts to read temperature on disabled sensors

2018-10-17 Thread Bartlomiej Zolnierkiewicz

* Add ops_of_thermal flag to struct thermal_zone_device_ops and
  set it in of-thermal.c.

* Add checking sensor mode for drivers using of-thermal.c to
  thermal_zone_get_temp() (print a warning if sensor is disabled).

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/thermal/of-thermal.c  |  2 ++
 drivers/thermal/thermal_helpers.c | 12 
 include/linux/thermal.h   |  1 +
 3 files changed, 15 insertions(+)

diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index 523ac5c..912bd85 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -378,6 +378,8 @@ static int of_thermal_get_crit_temp(struct 
thermal_zone_device *tz,
 
.bind = of_thermal_bind,
.unbind = of_thermal_unbind,
+
+   .ops_of_thermal = true,
 };
 
 /***   sensor API   ***/
diff --git a/drivers/thermal/thermal_helpers.c 
b/drivers/thermal/thermal_helpers.c
index 14b7a7e..12d1f53 100644
--- a/drivers/thermal/thermal_helpers.c
+++ b/drivers/thermal/thermal_helpers.c
@@ -84,6 +84,18 @@ int thermal_zone_get_temp(struct thermal_zone_device *tz, 
int *temp)
if (!tz || IS_ERR(tz) || !tz->ops->get_temp)
goto exit;
 
+   if (tz->ops->ops_of_thermal) {
+   enum thermal_device_mode mode;
+
+   ret = tz->ops->get_mode(tz, );
+   if (ret)
+   goto exit;
+
+   if (mode == THERMAL_DEVICE_DISABLED)
+   dev_warn_once(>device,
+"trying to read out disabled thermal zone\n");
+   }
+
mutex_lock(>lock);
 
ret = tz->ops->get_temp(tz, temp);
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 92c460e..2215e11 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -115,6 +115,7 @@ struct thermal_zone_device_ops {
   enum thermal_trip_type);
 
bool set_mode_skip_check;
+   bool ops_of_thermal;
 };
 
 struct thermal_cooling_device_ops {
-- 
1.9.1

[PATCH v2 12/17] thermal: exynos: enable+check sensor after its setup is finished

2018-10-17 Thread Bartlomiej Zolnierkiewicz

Enable sensor after doing chipset specific initialization operation and
check sensor after doing chipset specific control operation.

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/thermal/samsung/exynos_tmu.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index 8ec74a62..796a868 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -1109,15 +1109,14 @@ static int exynos_tmu_probe(struct platform_device 
*pdev)
goto err_sclk;
}
 
-   thermal_zone_set_mode(data->tzd, THERMAL_DEVICE_ENABLED);
-   thermal_zone_device_check(data->tzd);
-
ret = exynos_tmu_initialize(pdev);
if (ret) {
dev_err(>dev, "Failed to initialize TMU\n");
goto err_thermal;
}
 
+   thermal_zone_set_mode(data->tzd, THERMAL_DEVICE_ENABLED);
+
ret = devm_request_irq(>dev, data->irq, exynos_tmu_irq,
IRQF_TRIGGER_RISING | IRQF_SHARED, dev_name(>dev), data);
if (ret) {
@@ -1126,6 +1125,9 @@ static int exynos_tmu_probe(struct platform_device *pdev)
}
 
exynos_tmu_control(pdev, true);
+
+   thermal_zone_device_check(data->tzd);
+
return 0;
 
 err_thermal:
-- 
1.9.1

[PATCH v2 12/17] thermal: exynos: enable+check sensor after its setup is finished

2018-10-17 Thread Bartlomiej Zolnierkiewicz

Enable sensor after doing chipset specific initialization operation and
check sensor after doing chipset specific control operation.

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/thermal/samsung/exynos_tmu.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index 8ec74a62..796a868 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -1109,15 +1109,14 @@ static int exynos_tmu_probe(struct platform_device 
*pdev)
goto err_sclk;
}
 
-   thermal_zone_set_mode(data->tzd, THERMAL_DEVICE_ENABLED);
-   thermal_zone_device_check(data->tzd);
-
ret = exynos_tmu_initialize(pdev);
if (ret) {
dev_err(>dev, "Failed to initialize TMU\n");
goto err_thermal;
}
 
+   thermal_zone_set_mode(data->tzd, THERMAL_DEVICE_ENABLED);
+
ret = devm_request_irq(>dev, data->irq, exynos_tmu_irq,
IRQF_TRIGGER_RISING | IRQF_SHARED, dev_name(>dev), data);
if (ret) {
@@ -1126,6 +1125,9 @@ static int exynos_tmu_probe(struct platform_device *pdev)
}
 
exynos_tmu_control(pdev, true);
+
+   thermal_zone_device_check(data->tzd);
+
return 0;
 
 err_thermal:
-- 
1.9.1

[PATCH v2 09/17] thermal: qoriq: enable+check sensor after its setup is finished

2018-10-17 Thread Bartlomiej Zolnierkiewicz

Enable+check sensor after enabling monitoring.

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/thermal/qoriq_thermal.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/thermal/qoriq_thermal.c b/drivers/thermal/qoriq_thermal.c
index d8a80448..fb1750f 100644
--- a/drivers/thermal/qoriq_thermal.c
+++ b/drivers/thermal/qoriq_thermal.c
@@ -233,13 +233,13 @@ static int qoriq_tmu_probe(struct platform_device *pdev)
goto err_tmu;
}
 
-   thermal_zone_set_mode(data->tz, THERMAL_DEVICE_ENABLED);
-   thermal_zone_device_check(data->tz);
-
/* Enable monitoring */
site = 0x1 << (15 - data->sensor_id);
tmu_write(data, site | TMR_ME | TMR_ALPF, >regs->tmr);
 
+   thermal_zone_set_mode(data->tz, THERMAL_DEVICE_ENABLED);
+   thermal_zone_device_check(data->tz);
+
return 0;
 
 err_tmu:
-- 
1.9.1

[PATCH v2 10/17] thermal: rcar_gen3_thermal: enable+check sensor after its setup is finished

2018-10-17 Thread Bartlomiej Zolnierkiewicz

Enable+check sensor after setting tsc->zone and checking ntrips.

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/thermal/rcar_gen3_thermal.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/thermal/rcar_gen3_thermal.c 
b/drivers/thermal/rcar_gen3_thermal.c
index c72453e..eb50f33 100644
--- a/drivers/thermal/rcar_gen3_thermal.c
+++ b/drivers/thermal/rcar_gen3_thermal.c
@@ -421,9 +421,6 @@ static int rcar_gen3_thermal_probe(struct platform_device 
*pdev)
goto error_unregister;
}
 
-   thermal_zone_set_mode(zone, THERMAL_DEVICE_ENABLED);
-   thermal_zone_device_check(zone);
-
tsc->zone = zone;
 
ret = of_thermal_get_ntrips(tsc->zone);
@@ -431,6 +428,9 @@ static int rcar_gen3_thermal_probe(struct platform_device 
*pdev)
goto error_unregister;
 
dev_info(dev, "TSC%d: Loaded %d trip points\n", i, ret);
+
+   thermal_zone_set_mode(zone, THERMAL_DEVICE_ENABLED);
+   thermal_zone_device_check(zone);
}
 
priv->num_tscs = i;
-- 
1.9.1

[PATCH v2 09/17] thermal: qoriq: enable+check sensor after its setup is finished

2018-10-17 Thread Bartlomiej Zolnierkiewicz

Enable+check sensor after enabling monitoring.

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/thermal/qoriq_thermal.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/thermal/qoriq_thermal.c b/drivers/thermal/qoriq_thermal.c
index d8a80448..fb1750f 100644
--- a/drivers/thermal/qoriq_thermal.c
+++ b/drivers/thermal/qoriq_thermal.c
@@ -233,13 +233,13 @@ static int qoriq_tmu_probe(struct platform_device *pdev)
goto err_tmu;
}
 
-   thermal_zone_set_mode(data->tz, THERMAL_DEVICE_ENABLED);
-   thermal_zone_device_check(data->tz);
-
/* Enable monitoring */
site = 0x1 << (15 - data->sensor_id);
tmu_write(data, site | TMR_ME | TMR_ALPF, >regs->tmr);
 
+   thermal_zone_set_mode(data->tz, THERMAL_DEVICE_ENABLED);
+   thermal_zone_device_check(data->tz);
+
return 0;
 
 err_tmu:
-- 
1.9.1

[PATCH v2 10/17] thermal: rcar_gen3_thermal: enable+check sensor after its setup is finished

2018-10-17 Thread Bartlomiej Zolnierkiewicz

Enable+check sensor after setting tsc->zone and checking ntrips.

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/thermal/rcar_gen3_thermal.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/thermal/rcar_gen3_thermal.c 
b/drivers/thermal/rcar_gen3_thermal.c
index c72453e..eb50f33 100644
--- a/drivers/thermal/rcar_gen3_thermal.c
+++ b/drivers/thermal/rcar_gen3_thermal.c
@@ -421,9 +421,6 @@ static int rcar_gen3_thermal_probe(struct platform_device 
*pdev)
goto error_unregister;
}
 
-   thermal_zone_set_mode(zone, THERMAL_DEVICE_ENABLED);
-   thermal_zone_device_check(zone);
-
tsc->zone = zone;
 
ret = of_thermal_get_ntrips(tsc->zone);
@@ -431,6 +428,9 @@ static int rcar_gen3_thermal_probe(struct platform_device 
*pdev)
goto error_unregister;
 
dev_info(dev, "TSC%d: Loaded %d trip points\n", i, ret);
+
+   thermal_zone_set_mode(zone, THERMAL_DEVICE_ENABLED);
+   thermal_zone_device_check(zone);
}
 
priv->num_tscs = i;
-- 
1.9.1

[PATCH v2 06/17] thermal: brcmstb: enable+check sensor after its setup is finished

2018-10-17 Thread Bartlomiej Zolnierkiewicz

Enable+check sensor after setting priv->thermal.

Cc: Markus Mayer 
Cc: bcm-kernel-feedback-l...@broadcom.com
Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/thermal/broadcom/brcmstb_thermal.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/broadcom/brcmstb_thermal.c 
b/drivers/thermal/broadcom/brcmstb_thermal.c
index 3511ce6..5650a6a 100644
--- a/drivers/thermal/broadcom/brcmstb_thermal.c
+++ b/drivers/thermal/broadcom/brcmstb_thermal.c
@@ -336,11 +336,11 @@ static int brcmstb_thermal_probe(struct platform_device 
*pdev)
return ret;
}
 
+   priv->thermal = thermal;
+
thermal_zone_set_mode(thermal, THERMAL_DEVICE_ENABLED);
thermal_zone_device_check(thermal);
 
-   priv->thermal = thermal;
-
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
dev_err(>dev, "could not get IRQ\n");
-- 
1.9.1

[PATCH v2 08/17] thermal: qcom: tsens: enable+check sensor after its setup is finished

2018-10-17 Thread Bartlomiej Zolnierkiewicz

Enable+check sensor after setting tmdev->sensor[i].tzd and calling
chipset specific enable operation.

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/thermal/qcom/tsens.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/thermal/qcom/tsens.c b/drivers/thermal/qcom/tsens.c
index dbd2556..01bff96 100644
--- a/drivers/thermal/qcom/tsens.c
+++ b/drivers/thermal/qcom/tsens.c
@@ -105,13 +105,13 @@ static int tsens_register(struct tsens_device *tmdev)
if (IS_ERR(tzd))
continue;
 
-   thermal_zone_set_mode(tzd, THERMAL_DEVICE_ENABLED);
-   thermal_zone_device_check(tzd);
-
tmdev->sensor[i].tzd = tzd;
 
if (tmdev->ops->enable)
tmdev->ops->enable(tmdev, i);
+
+   thermal_zone_set_mode(tzd, THERMAL_DEVICE_ENABLED);
+   thermal_zone_device_check(tzd);
}
return 0;
 }
-- 
1.9.1

[PATCH v2 08/17] thermal: qcom: tsens: enable+check sensor after its setup is finished

2018-10-17 Thread Bartlomiej Zolnierkiewicz

Enable+check sensor after setting tmdev->sensor[i].tzd and calling
chipset specific enable operation.

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/thermal/qcom/tsens.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/thermal/qcom/tsens.c b/drivers/thermal/qcom/tsens.c
index dbd2556..01bff96 100644
--- a/drivers/thermal/qcom/tsens.c
+++ b/drivers/thermal/qcom/tsens.c
@@ -105,13 +105,13 @@ static int tsens_register(struct tsens_device *tmdev)
if (IS_ERR(tzd))
continue;
 
-   thermal_zone_set_mode(tzd, THERMAL_DEVICE_ENABLED);
-   thermal_zone_device_check(tzd);
-
tmdev->sensor[i].tzd = tzd;
 
if (tmdev->ops->enable)
tmdev->ops->enable(tmdev, i);
+
+   thermal_zone_set_mode(tzd, THERMAL_DEVICE_ENABLED);
+   thermal_zone_device_check(tzd);
}
return 0;
 }
-- 
1.9.1

[PATCH v2 06/17] thermal: brcmstb: enable+check sensor after its setup is finished

2018-10-17 Thread Bartlomiej Zolnierkiewicz

Enable+check sensor after setting priv->thermal.

Cc: Markus Mayer 
Cc: bcm-kernel-feedback-l...@broadcom.com
Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/thermal/broadcom/brcmstb_thermal.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/broadcom/brcmstb_thermal.c 
b/drivers/thermal/broadcom/brcmstb_thermal.c
index 3511ce6..5650a6a 100644
--- a/drivers/thermal/broadcom/brcmstb_thermal.c
+++ b/drivers/thermal/broadcom/brcmstb_thermal.c
@@ -336,11 +336,11 @@ static int brcmstb_thermal_probe(struct platform_device 
*pdev)
return ret;
}
 
+   priv->thermal = thermal;
+
thermal_zone_set_mode(thermal, THERMAL_DEVICE_ENABLED);
thermal_zone_device_check(thermal);
 
-   priv->thermal = thermal;
-
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
dev_err(>dev, "could not get IRQ\n");
-- 
1.9.1

[PATCH v2 07/17] thermal: hisi_thermal: enable+check sensor after its setup is finished

2018-10-17 Thread Bartlomiej Zolnierkiewicz

* Enable+check sensor after checking ntrips and doing chipset specific
  enable operation.

* Remove superfluous second sensor enable+check attempt.

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/thermal/hisi_thermal.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
index cc4e2ca..370696c 100644
--- a/drivers/thermal/hisi_thermal.c
+++ b/drivers/thermal/hisi_thermal.c
@@ -488,9 +488,6 @@ static int hisi_thermal_register_sensor(struct 
platform_device *pdev,
return ret;
}
 
-   thermal_zone_set_mode(sensor->tzd, THERMAL_DEVICE_ENABLED);
-   thermal_zone_device_check(sensor->tzd);
-
trip = of_thermal_get_trip_points(sensor->tzd);
 
for (i = 0; i < of_thermal_get_ntrips(sensor->tzd); i++) {
@@ -553,6 +550,9 @@ static int hisi_thermal_probe(struct platform_device *pdev)
return ret;
}
 
+   thermal_zone_set_mode((>sensor)->tzd, THERMAL_DEVICE_ENABLED);
+   thermal_zone_device_check((>sensor)->tzd);
+
if (data->irq) {
ret = devm_request_threaded_irq(dev, data->irq, NULL,
hisi_thermal_alarm_irq_thread,
@@ -563,9 +563,6 @@ static int hisi_thermal_probe(struct platform_device *pdev)
}
}
 
-   thermal_zone_set_mode((>sensor)->tzd, THERMAL_DEVICE_ENABLED);
-   thermal_zone_device_check((>sensor)->tzd);
-
return 0;
 }
 
-- 
1.9.1

[PATCH v2 07/17] thermal: hisi_thermal: enable+check sensor after its setup is finished

2018-10-17 Thread Bartlomiej Zolnierkiewicz

* Enable+check sensor after checking ntrips and doing chipset specific
  enable operation.

* Remove superfluous second sensor enable+check attempt.

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/thermal/hisi_thermal.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
index cc4e2ca..370696c 100644
--- a/drivers/thermal/hisi_thermal.c
+++ b/drivers/thermal/hisi_thermal.c
@@ -488,9 +488,6 @@ static int hisi_thermal_register_sensor(struct 
platform_device *pdev,
return ret;
}
 
-   thermal_zone_set_mode(sensor->tzd, THERMAL_DEVICE_ENABLED);
-   thermal_zone_device_check(sensor->tzd);
-
trip = of_thermal_get_trip_points(sensor->tzd);
 
for (i = 0; i < of_thermal_get_ntrips(sensor->tzd); i++) {
@@ -553,6 +550,9 @@ static int hisi_thermal_probe(struct platform_device *pdev)
return ret;
}
 
+   thermal_zone_set_mode((>sensor)->tzd, THERMAL_DEVICE_ENABLED);
+   thermal_zone_device_check((>sensor)->tzd);
+
if (data->irq) {
ret = devm_request_threaded_irq(dev, data->irq, NULL,
hisi_thermal_alarm_irq_thread,
@@ -563,9 +563,6 @@ static int hisi_thermal_probe(struct platform_device *pdev)
}
}
 
-   thermal_zone_set_mode((>sensor)->tzd, THERMAL_DEVICE_ENABLED);
-   thermal_zone_device_check((>sensor)->tzd);
-
return 0;
 }
 
-- 
1.9.1

[PATCH v2 05/17] thermal: bcm2835: enable+check sensor after its setup is finished

2018-10-17 Thread Bartlomiej Zolnierkiewicz

Enable+check sensor after HW-block setup (if necessary) and setting
data->tz.

Cc: Eric Anholt 
Cc: Stefan Wahren 
Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/thermal/broadcom/bcm2835_thermal.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/thermal/broadcom/bcm2835_thermal.c 
b/drivers/thermal/broadcom/bcm2835_thermal.c
index 687a00c..ec82fef 100644
--- a/drivers/thermal/broadcom/bcm2835_thermal.c
+++ b/drivers/thermal/broadcom/bcm2835_thermal.c
@@ -227,9 +227,6 @@ static int bcm2835_thermal_probe(struct platform_device 
*pdev)
goto err_clk;
}
 
-   thermal_zone_set_mode(tz, THERMAL_DEVICE_ENABLED);
-   thermal_zone_device_check(tz);
-
/*
 * right now the FW does set up the HW-block, so we are not
 * touching the configuration registers.
@@ -276,6 +273,9 @@ static int bcm2835_thermal_probe(struct platform_device 
*pdev)
 
data->tz = tz;
 
+   thermal_zone_set_mode(tz, THERMAL_DEVICE_ENABLED);
+   thermal_zone_device_check(tz);
+
platform_set_drvdata(pdev, tz);
 
bcm2835_thermal_debugfs(pdev);
-- 
1.9.1

[PATCH v2 05/17] thermal: bcm2835: enable+check sensor after its setup is finished

2018-10-17 Thread Bartlomiej Zolnierkiewicz

Enable+check sensor after HW-block setup (if necessary) and setting
data->tz.

Cc: Eric Anholt 
Cc: Stefan Wahren 
Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/thermal/broadcom/bcm2835_thermal.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/thermal/broadcom/bcm2835_thermal.c 
b/drivers/thermal/broadcom/bcm2835_thermal.c
index 687a00c..ec82fef 100644
--- a/drivers/thermal/broadcom/bcm2835_thermal.c
+++ b/drivers/thermal/broadcom/bcm2835_thermal.c
@@ -227,9 +227,6 @@ static int bcm2835_thermal_probe(struct platform_device 
*pdev)
goto err_clk;
}
 
-   thermal_zone_set_mode(tz, THERMAL_DEVICE_ENABLED);
-   thermal_zone_device_check(tz);
-
/*
 * right now the FW does set up the HW-block, so we are not
 * touching the configuration registers.
@@ -276,6 +273,9 @@ static int bcm2835_thermal_probe(struct platform_device 
*pdev)
 
data->tz = tz;
 
+   thermal_zone_set_mode(tz, THERMAL_DEVICE_ENABLED);
+   thermal_zone_device_check(tz);
+
platform_set_drvdata(pdev, tz);
 
bcm2835_thermal_debugfs(pdev);
-- 
1.9.1

[PATCH v2 03/17] thermal: separate sensor enable and check operations

2018-10-17 Thread Bartlomiej Zolnierkiewicz

[devm]_thermal_zone_of_sensor_register() is used to register
thermal sensor by thermal drivers using DeviceTree. Besides
registering sensor this function also immediately:

- enables it:

  tzd->ops->set_mode(tzd, THERMAL_DEVICE_ENABLED)
  (->set_mode is set to of_thermal_set_mode() in of-thermal.c)

- checks it (indirectly by using of_thermal_set_mode()):

  thermal_zone_device_update(tz, THERMAL_EVENT_UNSPECIFIED);
  (which in turn ends up using ->get_temp method).

For many DT thermal drivers this causes a problem because:

- [devm]_thermal_zone_of_sensor_register() need to be called in
  order to obtain data about thermal trips which are then used to
  finish hardware sensor setup (only after which ->get_temp can
  be used)

There is also related issue for DT thermal drivers that support
IRQ (i.e. exynos and rockchip ones):

- sensor hardware should be enabled only after IRQ handler is
  requested (because otherwise we might get IRQs that we can't
  handle)

- IRQ handler needs tzd structure which is obtained from
  [devm_]thermal_zone_of_sensor_register()

- after [devm_]thermal_zone_of_sensor_register() call core
  thermal code assumes that sensor is enabled and ready to use
  (i.e. that IRQ handler has been requested and sensor hardware
  has been enabled)

In order to prepare for fixing all abovementioned issues separate
sensor enable and check operations in the core thermal code and
update thermal drivers accordingly:

* Add set_mode_skip_check flag to struct thermal_zone_device_ops and
  set it in drivers that don't check the thermal zone device in their
  ->set_mode method implementations.

* Move thermal_zone_device_check() from ->set_mode implementations to
  the users of thermal_zone_set_mode() (only place which calls
  ->set_mode). Modify mode_store() in thermal_sysfs.c accordingly.

There should be no functional changes caused by this patch.

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/acpi/thermal.c |  2 ++
 drivers/net/ethernet/mellanox/mlxsw/core_thermal.c |  2 --
 drivers/platform/x86/acerhdf.c |  2 ++
 drivers/thermal/db8500_thermal.c   |  2 ++
 drivers/thermal/hisi_thermal.c |  2 ++
 drivers/thermal/imx_thermal.c  |  2 --
 drivers/thermal/int340x_thermal/int3400_thermal.c  |  1 +
 drivers/thermal/of-thermal.c   |  6 +++---
 drivers/thermal/rockchip_thermal.c | 16 
 drivers/thermal/thermal_sysfs.c|  3 +++
 include/linux/thermal.h|  2 ++
 11 files changed, 29 insertions(+), 11 deletions(-)

diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
index b8b275e1..a7e3d9e 100644
--- a/drivers/acpi/thermal.c
+++ b/drivers/acpi/thermal.c
@@ -879,6 +879,8 @@ static int acpi_thermal_cooling_device_cb(struct 
thermal_zone_device *thermal,
.get_crit_temp = thermal_get_crit_temp,
.get_trend = thermal_get_trend,
.notify = thermal_notify,
+
+   .set_mode_skip_check = true,
 };
 
 static int acpi_thermal_register_thermal_zone(struct acpi_thermal *tz)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c 
b/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
index b0afd36..5f4b3bd 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
@@ -170,8 +170,6 @@ static int mlxsw_thermal_set_mode(struct 
thermal_zone_device *tzdev,
 
thermal->mode = mode;
 
-   thermal_zone_device_check(tzdev);
-
return 0;
 }
 
diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index 5a2b93a..884fd83 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -507,6 +507,8 @@ static int acerhdf_get_crit_temp(struct thermal_zone_device 
*thermal,
.get_trip_hyst = acerhdf_get_trip_hyst,
.get_trip_temp = acerhdf_get_trip_temp,
.get_crit_temp = acerhdf_get_crit_temp,
+
+   .set_mode_skip_check = true,
 };
 
 
diff --git a/drivers/thermal/db8500_thermal.c b/drivers/thermal/db8500_thermal.c
index ab66b2d7..c4d0fb1 100644
--- a/drivers/thermal/db8500_thermal.c
+++ b/drivers/thermal/db8500_thermal.c
@@ -220,6 +220,8 @@ static int db8500_sys_get_crit_temp(struct 
thermal_zone_device *thermal,
.get_trip_type = db8500_sys_get_trip_type,
.get_trip_temp = db8500_sys_get_trip_temp,
.get_crit_temp = db8500_sys_get_crit_temp,
+
+   .set_mode_skip_check = true,
 };
 
 static void db8500_thermal_update_config(struct db8500_thermal_zone *pzone,
diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
index 63d4fc3..6151e55 100644
--- a/drivers/thermal/hisi_thermal.c
+++ b/drivers/thermal/hisi_thermal.c
@@ -561,6 +561,7 @@ static int hisi_thermal_probe(struct platform_device *pdev)
}
 
thermal_zone_set_mode((>sensor

[PATCH v2 03/17] thermal: separate sensor enable and check operations

2018-10-17 Thread Bartlomiej Zolnierkiewicz

[devm]_thermal_zone_of_sensor_register() is used to register
thermal sensor by thermal drivers using DeviceTree. Besides
registering sensor this function also immediately:

- enables it:

  tzd->ops->set_mode(tzd, THERMAL_DEVICE_ENABLED)
  (->set_mode is set to of_thermal_set_mode() in of-thermal.c)

- checks it (indirectly by using of_thermal_set_mode()):

  thermal_zone_device_update(tz, THERMAL_EVENT_UNSPECIFIED);
  (which in turn ends up using ->get_temp method).

For many DT thermal drivers this causes a problem because:

- [devm]_thermal_zone_of_sensor_register() need to be called in
  order to obtain data about thermal trips which are then used to
  finish hardware sensor setup (only after which ->get_temp can
  be used)

There is also related issue for DT thermal drivers that support
IRQ (i.e. exynos and rockchip ones):

- sensor hardware should be enabled only after IRQ handler is
  requested (because otherwise we might get IRQs that we can't
  handle)

- IRQ handler needs tzd structure which is obtained from
  [devm_]thermal_zone_of_sensor_register()

- after [devm_]thermal_zone_of_sensor_register() call core
  thermal code assumes that sensor is enabled and ready to use
  (i.e. that IRQ handler has been requested and sensor hardware
  has been enabled)

In order to prepare for fixing all abovementioned issues separate
sensor enable and check operations in the core thermal code and
update thermal drivers accordingly:

* Add set_mode_skip_check flag to struct thermal_zone_device_ops and
  set it in drivers that don't check the thermal zone device in their
  ->set_mode method implementations.

* Move thermal_zone_device_check() from ->set_mode implementations to
  the users of thermal_zone_set_mode() (only place which calls
  ->set_mode). Modify mode_store() in thermal_sysfs.c accordingly.

There should be no functional changes caused by this patch.

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/acpi/thermal.c |  2 ++
 drivers/net/ethernet/mellanox/mlxsw/core_thermal.c |  2 --
 drivers/platform/x86/acerhdf.c |  2 ++
 drivers/thermal/db8500_thermal.c   |  2 ++
 drivers/thermal/hisi_thermal.c |  2 ++
 drivers/thermal/imx_thermal.c  |  2 --
 drivers/thermal/int340x_thermal/int3400_thermal.c  |  1 +
 drivers/thermal/of-thermal.c   |  6 +++---
 drivers/thermal/rockchip_thermal.c | 16 
 drivers/thermal/thermal_sysfs.c|  3 +++
 include/linux/thermal.h|  2 ++
 11 files changed, 29 insertions(+), 11 deletions(-)

diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
index b8b275e1..a7e3d9e 100644
--- a/drivers/acpi/thermal.c
+++ b/drivers/acpi/thermal.c
@@ -879,6 +879,8 @@ static int acpi_thermal_cooling_device_cb(struct 
thermal_zone_device *thermal,
.get_crit_temp = thermal_get_crit_temp,
.get_trend = thermal_get_trend,
.notify = thermal_notify,
+
+   .set_mode_skip_check = true,
 };
 
 static int acpi_thermal_register_thermal_zone(struct acpi_thermal *tz)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c 
b/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
index b0afd36..5f4b3bd 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
@@ -170,8 +170,6 @@ static int mlxsw_thermal_set_mode(struct 
thermal_zone_device *tzdev,
 
thermal->mode = mode;
 
-   thermal_zone_device_check(tzdev);
-
return 0;
 }
 
diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index 5a2b93a..884fd83 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -507,6 +507,8 @@ static int acerhdf_get_crit_temp(struct thermal_zone_device 
*thermal,
.get_trip_hyst = acerhdf_get_trip_hyst,
.get_trip_temp = acerhdf_get_trip_temp,
.get_crit_temp = acerhdf_get_crit_temp,
+
+   .set_mode_skip_check = true,
 };
 
 
diff --git a/drivers/thermal/db8500_thermal.c b/drivers/thermal/db8500_thermal.c
index ab66b2d7..c4d0fb1 100644
--- a/drivers/thermal/db8500_thermal.c
+++ b/drivers/thermal/db8500_thermal.c
@@ -220,6 +220,8 @@ static int db8500_sys_get_crit_temp(struct 
thermal_zone_device *thermal,
.get_trip_type = db8500_sys_get_trip_type,
.get_trip_temp = db8500_sys_get_trip_temp,
.get_crit_temp = db8500_sys_get_crit_temp,
+
+   .set_mode_skip_check = true,
 };
 
 static void db8500_thermal_update_config(struct db8500_thermal_zone *pzone,
diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
index 63d4fc3..6151e55 100644
--- a/drivers/thermal/hisi_thermal.c
+++ b/drivers/thermal/hisi_thermal.c
@@ -561,6 +561,7 @@ static int hisi_thermal_probe(struct platform_device *pdev)
}
 
thermal_zone_set_mode((>sensor

[PATCH v2 02/17] thermal: add thermal_zone_device_check() helper

2018-10-17 Thread Bartlomiej Zolnierkiewicz

In order to remove the code duplication and prepare for further
changes:

* Rename static thermal_zone_device_check() helper in thermal_core.c
  to thermal_zone_device_work_check().

* Add thermal_zone_device_check() helper. Then update core code and
  drivers to use it.

There should be no functional changes caused by this patch.

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/acpi/thermal.c |  3 +--
 drivers/net/ethernet/mellanox/mlxsw/core_thermal.c |  3 ++-
 drivers/platform/x86/acerhdf.c |  4 +++-
 drivers/regulator/max8973-regulator.c  |  3 +--
 drivers/thermal/da9062-thermal.c   |  7 ++-
 drivers/thermal/db8500_thermal.c   |  3 ++-
 drivers/thermal/hisi_thermal.c |  4 +---
 drivers/thermal/imx_thermal.c  |  5 +++--
 drivers/thermal/intel_bxt_pmic_thermal.c   |  3 +--
 drivers/thermal/intel_soc_dts_iosf.c   |  3 +--
 drivers/thermal/max77620_thermal.c |  3 +--
 drivers/thermal/of-thermal.c   |  3 ++-
 drivers/thermal/qcom-spmi-temp-alarm.c |  2 +-
 drivers/thermal/rcar_gen3_thermal.c|  3 +--
 drivers/thermal/rcar_thermal.c |  3 +--
 drivers/thermal/rockchip_thermal.c |  3 +--
 drivers/thermal/samsung/exynos_tmu.c   |  2 +-
 drivers/thermal/st/st_thermal_memmap.c |  3 +--
 drivers/thermal/thermal_core.c | 14 ++
 drivers/thermal/thermal_helpers.c  |  6 ++
 drivers/thermal/thermal_sysfs.c|  6 +++---
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c |  2 +-
 drivers/thermal/uniphier_thermal.c |  2 +-
 drivers/thermal/x86_pkg_temp_thermal.c |  2 +-
 include/linux/thermal.h|  3 +++
 25 files changed, 47 insertions(+), 48 deletions(-)

diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
index 551b71a..b8b275e1 100644
--- a/drivers/acpi/thermal.c
+++ b/drivers/acpi/thermal.c
@@ -520,8 +520,7 @@ static void acpi_thermal_check(void *data)
if (!tz->tz_enabled)
return;
 
-   thermal_zone_device_update(tz->thermal_zone,
-  THERMAL_EVENT_UNSPECIFIED);
+   thermal_zone_device_check(tz->thermal_zone);
 }
 
 /* sys I/F for generic thermal sysfs support */
diff --git a/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c 
b/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
index 6d29dc4..b0afd36 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
@@ -169,7 +169,8 @@ static int mlxsw_thermal_set_mode(struct 
thermal_zone_device *tzdev,
mutex_unlock(>lock);
 
thermal->mode = mode;
-   thermal_zone_device_update(tzdev, THERMAL_EVENT_UNSPECIFIED);
+
+   thermal_zone_device_check(tzdev);
 
return 0;
 }
diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index 5052242..5a2b93a 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -417,7 +417,9 @@ static inline void acerhdf_enable_kernelmode(void)
kernelmode = 1;
 
thz_dev->polling_delay = interval*1000;
-   thermal_zone_device_update(thz_dev, THERMAL_EVENT_UNSPECIFIED);
+
+   thermal_zone_device_check(thz_dev);
+
pr_notice("kernel mode fan control ON\n");
 }
 
diff --git a/drivers/regulator/max8973-regulator.c 
b/drivers/regulator/max8973-regulator.c
index 7cd493e..9a522ed 100644
--- a/drivers/regulator/max8973-regulator.c
+++ b/drivers/regulator/max8973-regulator.c
@@ -495,8 +495,7 @@ static irqreturn_t max8973_thermal_irq(int irq, void *data)
 {
struct max8973_chip *mchip = data;
 
-   thermal_zone_device_update(mchip->tz_device,
-  THERMAL_EVENT_UNSPECIFIED);
+   thermal_zone_device_check(mchip->tz_device);
 
return IRQ_HANDLED;
 }
diff --git a/drivers/thermal/da9062-thermal.c b/drivers/thermal/da9062-thermal.c
index dd8dd94..8c6721b 100644
--- a/drivers/thermal/da9062-thermal.c
+++ b/drivers/thermal/da9062-thermal.c
@@ -102,9 +102,7 @@ static void da9062_thermal_poll_on(struct work_struct *work)
mutex_lock(>lock);
thermal->temperature = DA9062_MILLI_CELSIUS(125);
mutex_unlock(>lock);
-   thermal_zone_device_update(thermal->zone,
-  THERMAL_EVENT_UNSPECIFIED);
-
+   thermal_zone_device_check(thermal->zone);
delay = msecs_to_jiffies(thermal->zone->passive_delay);
schedule_delayed_work(>work, delay);
return;
@@ -113,8 +111,7 @@ static void da9062_thermal_poll_on(struct work_struct *work)
mutex_lock(>lock);
thermal->t

[PATCH v2 00/17] thermal: enable+check sensor after its setup is finished

2018-10-17 Thread Bartlomiej Zolnierkiewicz

Hi,

[devm]_thermal_zone_of_sensor_register() is used to register
thermal sensor by thermal drivers using DeviceTree. Besides
registering sensor this function also immediately:

- enables it:

  tzd->ops->set_mode(tzd, THERMAL_DEVICE_ENABLED)
  (->set_mode is set to of_thermal_set_mode() in of-thermal.c)

- checks it (indirectly by using of_thermal_set_mode()):

  thermal_zone_device_update(tz, THERMAL_EVENT_UNSPECIFIED);
  (which in turn ends up using ->get_temp method).

For many DT thermal drivers this causes a problem because:

- [devm]_thermal_zone_of_sensor_register() need to be called in
  order to obtain data about thermal trips which are then used to
  finish hardware sensor setup (only after which ->get_temp can
  be used)

There is also related issue for DT thermal drivers that support
IRQ (i.e. exynos and rockchip ones):

- sensor hardware should be enabled only after IRQ handler is
  requested (because otherwise we might get IRQs that we can't
  handle)

- IRQ handler needs tzd structure which is obtained from
  [devm_]thermal_zone_of_sensor_register()

- after [devm_]thermal_zone_of_sensor_register() call core
  thermal code assumes that sensor is enabled and ready to use
  (i.e. that IRQ handler has been requested and sensor hardware
  has been enabled)

In order to fix all abovementioned issues sensor registration,
enable and check operations are separated in the core DT thermal
code and corresponding DT thermal drivers are modified to do sensor
setup correctly.

Changes since v1:
- rebased on the current -next kernel (next-20181015)
- enhanced patch descriptions and cover letter
- renamed thermal_zone_device_toggler() to thermal_zone_set_mode()
- converted thermal_zone_set_mode() to use enum thermal_device_mode
- added CONFIG_THERMAL=n stubs for thermal_zone_set_mode() and
  thermal_zone_device_check()
- fixed uses of [devm]_thermal_zone_of_sensor_register() outside of
  drivers/thermal/
- changed ordering between patch #2 and #3 in order to add all
  needed core helpers first before fixing sensor setup code
- changed ordering between patch #3 and #4 in order to simplify them
- renamed patch #3 to "thermal: separate sensor enable and check
  operations"
- renamed patch #4 to "thermal: separate sensor registration and
  enable+check operations"

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics


Bartlomiej Zolnierkiewicz (17):
  thermal: add thermal_zone_set_mode() helper
  thermal: add thermal_zone_device_check() helper
  thermal: separate sensor enable and check operations
  thermal: separate sensor registration and enable+check operations
  thermal: bcm2835: enable+check sensor after its setup is finished
  thermal: brcmstb: enable+check sensor after its setup is finished
  thermal: hisi_thermal: enable+check sensor after its setup is finished
  thermal: qcom: tsens: enable+check sensor after its setup is finished
  thermal: qoriq: enable+check sensor after its setup is finished
  thermal: rcar_gen3_thermal: enable+check sensor after its setup is
finished
  thermal: rockchip_thermal: enable+check sensor after its setup is
finished
  thermal: exynos: enable+check sensor after its setup is finished
  thermal: tegra: enable+check sensor after its setup is finished
  thermal: ti-soc-thermal: enable+check sensor after its setup is
finished
  thermal: uniphier: enable+check sensor after its setup is finished
  thermal: zx2967: enable+check sensor after its setup is finished
  thermal: warn on attempts to read temperature on disabled sensors

 drivers/acpi/thermal.c |  5 +--
 drivers/ata/ahci_imx.c | 10 --
 drivers/hwmon/hwmon.c  |  5 +++
 drivers/hwmon/ntc_thermistor.c |  4 +++
 drivers/hwmon/scpi-hwmon.c |  4 +++
 drivers/iio/adc/sun4i-gpadc-iio.c  |  5 +++
 drivers/input/touchscreen/sun4i-ts.c   |  8 -
 drivers/net/ethernet/mellanox/mlxsw/core_thermal.c |  1 -
 drivers/platform/x86/acerhdf.c |  6 +++-
 drivers/regulator/max8973-regulator.c  |  6 ++--
 drivers/thermal/armada_thermal.c   |  3 ++
 drivers/thermal/broadcom/bcm2835_thermal.c |  3 ++
 drivers/thermal/broadcom/brcmstb_thermal.c |  3 ++
 drivers/thermal/broadcom/ns-thermal.c  |  3 ++
 drivers/thermal/da9062-thermal.c   |  7 ++--
 drivers/thermal/db8500_thermal.c   |  5 ++-
 drivers/thermal/hisi_thermal.c | 22 -
 drivers/thermal/imx_thermal.c  |  3 +-
 drivers/thermal/int340x_thermal/int3400_thermal.c  |  1 +
 drivers/thermal/intel_bxt_pmic_thermal.c   |  3 +-
 drivers/thermal/intel_soc_dts_iosf.c   |  3 +-
 drivers/thermal/max77620_thermal.c |  6 ++--
 drivers/thermal/mtk_thermal.c

[PATCH v2 01/17] thermal: add thermal_zone_set_mode() helper

2018-10-17 Thread Bartlomiej Zolnierkiewicz

In order to remove the code duplication and prepare for further
changes:

* Add thermal_zone_set_mode() helper. Then update core code and
  drivers to use it.

There should be no functional changes caused by this patch.

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/thermal/hisi_thermal.c | 14 ++
 drivers/thermal/of-thermal.c   |  3 ++-
 drivers/thermal/rockchip_thermal.c | 26 +-
 drivers/thermal/thermal_helpers.c  | 14 ++
 drivers/thermal/thermal_sysfs.c|  8 +---
 include/linux/thermal.h|  5 +
 6 files changed, 37 insertions(+), 33 deletions(-)

diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
index 761d055..b3f8d9f 100644
--- a/drivers/thermal/hisi_thermal.c
+++ b/drivers/thermal/hisi_thermal.c
@@ -515,15 +515,6 @@ static int hisi_thermal_register_sensor(struct 
platform_device *pdev,
 };
 MODULE_DEVICE_TABLE(of, of_hisi_thermal_match);
 
-static void hisi_thermal_toggle_sensor(struct hisi_thermal_sensor *sensor,
-  bool on)
-{
-   struct thermal_zone_device *tzd = sensor->tzd;
-
-   tzd->ops->set_mode(tzd,
-   on ? THERMAL_DEVICE_ENABLED : THERMAL_DEVICE_DISABLED);
-}
-
 static int hisi_thermal_probe(struct platform_device *pdev)
 {
struct hisi_thermal_data *data;
@@ -571,7 +562,7 @@ static int hisi_thermal_probe(struct platform_device *pdev)
}
}
 
-   hisi_thermal_toggle_sensor(>sensor, true);
+   thermal_zone_set_mode((>sensor)->tzd, THERMAL_DEVICE_ENABLED);
 
return 0;
 }
@@ -579,9 +570,8 @@ static int hisi_thermal_probe(struct platform_device *pdev)
 static int hisi_thermal_remove(struct platform_device *pdev)
 {
struct hisi_thermal_data *data = platform_get_drvdata(pdev);
-   struct hisi_thermal_sensor *sensor = >sensor;
 
-   hisi_thermal_toggle_sensor(sensor, false);
+   thermal_zone_set_mode((>sensor)->tzd, THERMAL_DEVICE_DISABLED);
 
data->disable_sensor(data);
 
diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index 4f28165..118910c 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -496,7 +496,8 @@ struct thermal_zone_device *
tzd = thermal_zone_of_add_sensor(child, sensor_np,
 data, ops);
if (!IS_ERR(tzd))
-   tzd->ops->set_mode(tzd, THERMAL_DEVICE_ENABLED);
+   thermal_zone_set_mode(tzd,
+ THERMAL_DEVICE_ENABLED);
 
of_node_put(sensor_specs.np);
of_node_put(child);
diff --git a/drivers/thermal/rockchip_thermal.c 
b/drivers/thermal/rockchip_thermal.c
index f36375d..2edd44c 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -1022,15 +1022,6 @@ static void rk_tsadcv2_tshut_mode(int chn, void __iomem 
*regs,
 };
 MODULE_DEVICE_TABLE(of, of_rockchip_thermal_match);
 
-static void
-rockchip_thermal_toggle_sensor(struct rockchip_thermal_sensor *sensor, bool on)
-{
-   struct thermal_zone_device *tzd = sensor->tzd;
-
-   tzd->ops->set_mode(tzd,
-   on ? THERMAL_DEVICE_ENABLED : THERMAL_DEVICE_DISABLED);
-}
-
 static irqreturn_t rockchip_thermal_alarm_irq_thread(int irq, void *dev)
 {
struct rockchip_thermal_data *thermal = dev;
@@ -1292,7 +1283,8 @@ static int rockchip_thermal_probe(struct platform_device 
*pdev)
thermal->chip->control(thermal->regs, true);
 
for (i = 0; i < thermal->chip->chn_num; i++)
-   rockchip_thermal_toggle_sensor(>sensors[i], true);
+   thermal_zone_set_mode((>sensors[i])->tzd,
+ THERMAL_DEVICE_ENABLED);
 
platform_set_drvdata(pdev, thermal);
 
@@ -1311,11 +1303,9 @@ static int rockchip_thermal_remove(struct 
platform_device *pdev)
struct rockchip_thermal_data *thermal = platform_get_drvdata(pdev);
int i;
 
-   for (i = 0; i < thermal->chip->chn_num; i++) {
-   struct rockchip_thermal_sensor *sensor = >sensors[i];
-
-   rockchip_thermal_toggle_sensor(sensor, false);
-   }
+   for (i = 0; i < thermal->chip->chn_num; i++)
+   thermal_zone_set_mode((>sensors[i])->tzd,
+ THERMAL_DEVICE_DISABLED);
 
thermal->chip->control(thermal->regs, false);
 
@@ -1332,7 +1322,8 @@ static int __maybe_unused rockchip_thermal_suspend(struct 
device *dev)
int i;
 
for (i = 0; i < thermal->chip->chn_num; i++)
-   rockchip_thermal_toggle_sensor(>sensors[i], false);
+   thermal_zone_set_mode((>sensors[i])->tzd,
+

[PATCH v2 02/17] thermal: add thermal_zone_device_check() helper

2018-10-17 Thread Bartlomiej Zolnierkiewicz

In order to remove the code duplication and prepare for further
changes:

* Rename static thermal_zone_device_check() helper in thermal_core.c
  to thermal_zone_device_work_check().

* Add thermal_zone_device_check() helper. Then update core code and
  drivers to use it.

There should be no functional changes caused by this patch.

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/acpi/thermal.c |  3 +--
 drivers/net/ethernet/mellanox/mlxsw/core_thermal.c |  3 ++-
 drivers/platform/x86/acerhdf.c |  4 +++-
 drivers/regulator/max8973-regulator.c  |  3 +--
 drivers/thermal/da9062-thermal.c   |  7 ++-
 drivers/thermal/db8500_thermal.c   |  3 ++-
 drivers/thermal/hisi_thermal.c |  4 +---
 drivers/thermal/imx_thermal.c  |  5 +++--
 drivers/thermal/intel_bxt_pmic_thermal.c   |  3 +--
 drivers/thermal/intel_soc_dts_iosf.c   |  3 +--
 drivers/thermal/max77620_thermal.c |  3 +--
 drivers/thermal/of-thermal.c   |  3 ++-
 drivers/thermal/qcom-spmi-temp-alarm.c |  2 +-
 drivers/thermal/rcar_gen3_thermal.c|  3 +--
 drivers/thermal/rcar_thermal.c |  3 +--
 drivers/thermal/rockchip_thermal.c |  3 +--
 drivers/thermal/samsung/exynos_tmu.c   |  2 +-
 drivers/thermal/st/st_thermal_memmap.c |  3 +--
 drivers/thermal/thermal_core.c | 14 ++
 drivers/thermal/thermal_helpers.c  |  6 ++
 drivers/thermal/thermal_sysfs.c|  6 +++---
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c |  2 +-
 drivers/thermal/uniphier_thermal.c |  2 +-
 drivers/thermal/x86_pkg_temp_thermal.c |  2 +-
 include/linux/thermal.h|  3 +++
 25 files changed, 47 insertions(+), 48 deletions(-)

diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
index 551b71a..b8b275e1 100644
--- a/drivers/acpi/thermal.c
+++ b/drivers/acpi/thermal.c
@@ -520,8 +520,7 @@ static void acpi_thermal_check(void *data)
if (!tz->tz_enabled)
return;
 
-   thermal_zone_device_update(tz->thermal_zone,
-  THERMAL_EVENT_UNSPECIFIED);
+   thermal_zone_device_check(tz->thermal_zone);
 }
 
 /* sys I/F for generic thermal sysfs support */
diff --git a/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c 
b/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
index 6d29dc4..b0afd36 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
@@ -169,7 +169,8 @@ static int mlxsw_thermal_set_mode(struct 
thermal_zone_device *tzdev,
mutex_unlock(>lock);
 
thermal->mode = mode;
-   thermal_zone_device_update(tzdev, THERMAL_EVENT_UNSPECIFIED);
+
+   thermal_zone_device_check(tzdev);
 
return 0;
 }
diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index 5052242..5a2b93a 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -417,7 +417,9 @@ static inline void acerhdf_enable_kernelmode(void)
kernelmode = 1;
 
thz_dev->polling_delay = interval*1000;
-   thermal_zone_device_update(thz_dev, THERMAL_EVENT_UNSPECIFIED);
+
+   thermal_zone_device_check(thz_dev);
+
pr_notice("kernel mode fan control ON\n");
 }
 
diff --git a/drivers/regulator/max8973-regulator.c 
b/drivers/regulator/max8973-regulator.c
index 7cd493e..9a522ed 100644
--- a/drivers/regulator/max8973-regulator.c
+++ b/drivers/regulator/max8973-regulator.c
@@ -495,8 +495,7 @@ static irqreturn_t max8973_thermal_irq(int irq, void *data)
 {
struct max8973_chip *mchip = data;
 
-   thermal_zone_device_update(mchip->tz_device,
-  THERMAL_EVENT_UNSPECIFIED);
+   thermal_zone_device_check(mchip->tz_device);
 
return IRQ_HANDLED;
 }
diff --git a/drivers/thermal/da9062-thermal.c b/drivers/thermal/da9062-thermal.c
index dd8dd94..8c6721b 100644
--- a/drivers/thermal/da9062-thermal.c
+++ b/drivers/thermal/da9062-thermal.c
@@ -102,9 +102,7 @@ static void da9062_thermal_poll_on(struct work_struct *work)
mutex_lock(>lock);
thermal->temperature = DA9062_MILLI_CELSIUS(125);
mutex_unlock(>lock);
-   thermal_zone_device_update(thermal->zone,
-  THERMAL_EVENT_UNSPECIFIED);
-
+   thermal_zone_device_check(thermal->zone);
delay = msecs_to_jiffies(thermal->zone->passive_delay);
schedule_delayed_work(>work, delay);
return;
@@ -113,8 +111,7 @@ static void da9062_thermal_poll_on(struct work_struct *work)
mutex_lock(>lock);
thermal->t

[PATCH v2 00/17] thermal: enable+check sensor after its setup is finished

2018-10-17 Thread Bartlomiej Zolnierkiewicz

Hi,

[devm]_thermal_zone_of_sensor_register() is used to register
thermal sensor by thermal drivers using DeviceTree. Besides
registering sensor this function also immediately:

- enables it:

  tzd->ops->set_mode(tzd, THERMAL_DEVICE_ENABLED)
  (->set_mode is set to of_thermal_set_mode() in of-thermal.c)

- checks it (indirectly by using of_thermal_set_mode()):

  thermal_zone_device_update(tz, THERMAL_EVENT_UNSPECIFIED);
  (which in turn ends up using ->get_temp method).

For many DT thermal drivers this causes a problem because:

- [devm]_thermal_zone_of_sensor_register() need to be called in
  order to obtain data about thermal trips which are then used to
  finish hardware sensor setup (only after which ->get_temp can
  be used)

There is also related issue for DT thermal drivers that support
IRQ (i.e. exynos and rockchip ones):

- sensor hardware should be enabled only after IRQ handler is
  requested (because otherwise we might get IRQs that we can't
  handle)

- IRQ handler needs tzd structure which is obtained from
  [devm_]thermal_zone_of_sensor_register()

- after [devm_]thermal_zone_of_sensor_register() call core
  thermal code assumes that sensor is enabled and ready to use
  (i.e. that IRQ handler has been requested and sensor hardware
  has been enabled)

In order to fix all abovementioned issues sensor registration,
enable and check operations are separated in the core DT thermal
code and corresponding DT thermal drivers are modified to do sensor
setup correctly.

Changes since v1:
- rebased on the current -next kernel (next-20181015)
- enhanced patch descriptions and cover letter
- renamed thermal_zone_device_toggler() to thermal_zone_set_mode()
- converted thermal_zone_set_mode() to use enum thermal_device_mode
- added CONFIG_THERMAL=n stubs for thermal_zone_set_mode() and
  thermal_zone_device_check()
- fixed uses of [devm]_thermal_zone_of_sensor_register() outside of
  drivers/thermal/
- changed ordering between patch #2 and #3 in order to add all
  needed core helpers first before fixing sensor setup code
- changed ordering between patch #3 and #4 in order to simplify them
- renamed patch #3 to "thermal: separate sensor enable and check
  operations"
- renamed patch #4 to "thermal: separate sensor registration and
  enable+check operations"

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics


Bartlomiej Zolnierkiewicz (17):
  thermal: add thermal_zone_set_mode() helper
  thermal: add thermal_zone_device_check() helper
  thermal: separate sensor enable and check operations
  thermal: separate sensor registration and enable+check operations
  thermal: bcm2835: enable+check sensor after its setup is finished
  thermal: brcmstb: enable+check sensor after its setup is finished
  thermal: hisi_thermal: enable+check sensor after its setup is finished
  thermal: qcom: tsens: enable+check sensor after its setup is finished
  thermal: qoriq: enable+check sensor after its setup is finished
  thermal: rcar_gen3_thermal: enable+check sensor after its setup is
finished
  thermal: rockchip_thermal: enable+check sensor after its setup is
finished
  thermal: exynos: enable+check sensor after its setup is finished
  thermal: tegra: enable+check sensor after its setup is finished
  thermal: ti-soc-thermal: enable+check sensor after its setup is
finished
  thermal: uniphier: enable+check sensor after its setup is finished
  thermal: zx2967: enable+check sensor after its setup is finished
  thermal: warn on attempts to read temperature on disabled sensors

 drivers/acpi/thermal.c |  5 +--
 drivers/ata/ahci_imx.c | 10 --
 drivers/hwmon/hwmon.c  |  5 +++
 drivers/hwmon/ntc_thermistor.c |  4 +++
 drivers/hwmon/scpi-hwmon.c |  4 +++
 drivers/iio/adc/sun4i-gpadc-iio.c  |  5 +++
 drivers/input/touchscreen/sun4i-ts.c   |  8 -
 drivers/net/ethernet/mellanox/mlxsw/core_thermal.c |  1 -
 drivers/platform/x86/acerhdf.c |  6 +++-
 drivers/regulator/max8973-regulator.c  |  6 ++--
 drivers/thermal/armada_thermal.c   |  3 ++
 drivers/thermal/broadcom/bcm2835_thermal.c |  3 ++
 drivers/thermal/broadcom/brcmstb_thermal.c |  3 ++
 drivers/thermal/broadcom/ns-thermal.c  |  3 ++
 drivers/thermal/da9062-thermal.c   |  7 ++--
 drivers/thermal/db8500_thermal.c   |  5 ++-
 drivers/thermal/hisi_thermal.c | 22 -
 drivers/thermal/imx_thermal.c  |  3 +-
 drivers/thermal/int340x_thermal/int3400_thermal.c  |  1 +
 drivers/thermal/intel_bxt_pmic_thermal.c   |  3 +-
 drivers/thermal/intel_soc_dts_iosf.c   |  3 +-
 drivers/thermal/max77620_thermal.c |  6 ++--
 drivers/thermal/mtk_thermal.c

[PATCH v2 01/17] thermal: add thermal_zone_set_mode() helper

2018-10-17 Thread Bartlomiej Zolnierkiewicz

In order to remove the code duplication and prepare for further
changes:

* Add thermal_zone_set_mode() helper. Then update core code and
  drivers to use it.

There should be no functional changes caused by this patch.

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/thermal/hisi_thermal.c | 14 ++
 drivers/thermal/of-thermal.c   |  3 ++-
 drivers/thermal/rockchip_thermal.c | 26 +-
 drivers/thermal/thermal_helpers.c  | 14 ++
 drivers/thermal/thermal_sysfs.c|  8 +---
 include/linux/thermal.h|  5 +
 6 files changed, 37 insertions(+), 33 deletions(-)

diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
index 761d055..b3f8d9f 100644
--- a/drivers/thermal/hisi_thermal.c
+++ b/drivers/thermal/hisi_thermal.c
@@ -515,15 +515,6 @@ static int hisi_thermal_register_sensor(struct 
platform_device *pdev,
 };
 MODULE_DEVICE_TABLE(of, of_hisi_thermal_match);
 
-static void hisi_thermal_toggle_sensor(struct hisi_thermal_sensor *sensor,
-  bool on)
-{
-   struct thermal_zone_device *tzd = sensor->tzd;
-
-   tzd->ops->set_mode(tzd,
-   on ? THERMAL_DEVICE_ENABLED : THERMAL_DEVICE_DISABLED);
-}
-
 static int hisi_thermal_probe(struct platform_device *pdev)
 {
struct hisi_thermal_data *data;
@@ -571,7 +562,7 @@ static int hisi_thermal_probe(struct platform_device *pdev)
}
}
 
-   hisi_thermal_toggle_sensor(>sensor, true);
+   thermal_zone_set_mode((>sensor)->tzd, THERMAL_DEVICE_ENABLED);
 
return 0;
 }
@@ -579,9 +570,8 @@ static int hisi_thermal_probe(struct platform_device *pdev)
 static int hisi_thermal_remove(struct platform_device *pdev)
 {
struct hisi_thermal_data *data = platform_get_drvdata(pdev);
-   struct hisi_thermal_sensor *sensor = >sensor;
 
-   hisi_thermal_toggle_sensor(sensor, false);
+   thermal_zone_set_mode((>sensor)->tzd, THERMAL_DEVICE_DISABLED);
 
data->disable_sensor(data);
 
diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index 4f28165..118910c 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -496,7 +496,8 @@ struct thermal_zone_device *
tzd = thermal_zone_of_add_sensor(child, sensor_np,
 data, ops);
if (!IS_ERR(tzd))
-   tzd->ops->set_mode(tzd, THERMAL_DEVICE_ENABLED);
+   thermal_zone_set_mode(tzd,
+ THERMAL_DEVICE_ENABLED);
 
of_node_put(sensor_specs.np);
of_node_put(child);
diff --git a/drivers/thermal/rockchip_thermal.c 
b/drivers/thermal/rockchip_thermal.c
index f36375d..2edd44c 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -1022,15 +1022,6 @@ static void rk_tsadcv2_tshut_mode(int chn, void __iomem 
*regs,
 };
 MODULE_DEVICE_TABLE(of, of_rockchip_thermal_match);
 
-static void
-rockchip_thermal_toggle_sensor(struct rockchip_thermal_sensor *sensor, bool on)
-{
-   struct thermal_zone_device *tzd = sensor->tzd;
-
-   tzd->ops->set_mode(tzd,
-   on ? THERMAL_DEVICE_ENABLED : THERMAL_DEVICE_DISABLED);
-}
-
 static irqreturn_t rockchip_thermal_alarm_irq_thread(int irq, void *dev)
 {
struct rockchip_thermal_data *thermal = dev;
@@ -1292,7 +1283,8 @@ static int rockchip_thermal_probe(struct platform_device 
*pdev)
thermal->chip->control(thermal->regs, true);
 
for (i = 0; i < thermal->chip->chn_num; i++)
-   rockchip_thermal_toggle_sensor(>sensors[i], true);
+   thermal_zone_set_mode((>sensors[i])->tzd,
+ THERMAL_DEVICE_ENABLED);
 
platform_set_drvdata(pdev, thermal);
 
@@ -1311,11 +1303,9 @@ static int rockchip_thermal_remove(struct 
platform_device *pdev)
struct rockchip_thermal_data *thermal = platform_get_drvdata(pdev);
int i;
 
-   for (i = 0; i < thermal->chip->chn_num; i++) {
-   struct rockchip_thermal_sensor *sensor = >sensors[i];
-
-   rockchip_thermal_toggle_sensor(sensor, false);
-   }
+   for (i = 0; i < thermal->chip->chn_num; i++)
+   thermal_zone_set_mode((>sensors[i])->tzd,
+ THERMAL_DEVICE_DISABLED);
 
thermal->chip->control(thermal->regs, false);
 
@@ -1332,7 +1322,8 @@ static int __maybe_unused rockchip_thermal_suspend(struct 
device *dev)
int i;
 
for (i = 0; i < thermal->chip->chn_num; i++)
-   rockchip_thermal_toggle_sensor(>sensors[i], false);
+   thermal_zone_set_mode((>sensors[i])->tzd,
+

[PATCH] PCI: pcie: remove redundant 'default n' from Kconfig

2018-10-16 Thread Bartlomiej Zolnierkiewicz

'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.

Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or not:

...
One side effect of (and the main motivation for) this change is making
the following two definitions behave exactly the same:

config FOO
bool

config FOO
bool
default n

With this change, neither of these will generate a
'# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
That might make it clearer to people that a bare 'default n' is
redundant.
...

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/pci/pcie/Kconfig |4 
 1 file changed, 4 deletions(-)

Index: b/drivers/pci/pcie/Kconfig
===
--- a/drivers/pci/pcie/Kconfig  2018-10-09 15:58:49.831123212 +0200
+++ b/drivers/pci/pcie/Kconfig  2018-10-16 16:36:32.419732670 +0200
@@ -36,7 +36,6 @@ config PCIEAER
 config PCIEAER_INJECT
tristate "PCI Express error injection support"
depends on PCIEAER && DYNAMIC_FTRACE_WITH_REGS
-   default n
help
  This enables PCI Express Root Port Advanced Error Reporting
  (AER) software error injector.
@@ -84,7 +83,6 @@ config PCIEASPM
 config PCIEASPM_DEBUG
bool "Debug PCI Express ASPM"
depends on PCIEASPM
-   default n
help
  This enables PCI Express ASPM debug support. It will add per-device
  interface to control ASPM.
@@ -129,7 +127,6 @@ config PCIE_PME
 config PCIE_DPC
bool "PCI Express Downstream Port Containment support"
depends on PCIEPORTBUS && PCIEAER
-   default n
help
  This enables PCI Express Downstream Port Containment (DPC)
  driver support.  DPC events from Root and Downstream ports
@@ -139,7 +136,6 @@ config PCIE_DPC
 
 config PCIE_PTM
bool "PCI Express Precision Time Measurement support"
-   default n
depends on PCIEPORTBUS
help
  This enables PCI Express Precision Time Measurement (PTM)

[PATCH] PCI: pcie: remove redundant 'default n' from Kconfig

2018-10-16 Thread Bartlomiej Zolnierkiewicz

'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.

Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or not:

...
One side effect of (and the main motivation for) this change is making
the following two definitions behave exactly the same:

config FOO
bool

config FOO
bool
default n

With this change, neither of these will generate a
'# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
That might make it clearer to people that a bare 'default n' is
redundant.
...

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/pci/pcie/Kconfig |4 
 1 file changed, 4 deletions(-)

Index: b/drivers/pci/pcie/Kconfig
===
--- a/drivers/pci/pcie/Kconfig  2018-10-09 15:58:49.831123212 +0200
+++ b/drivers/pci/pcie/Kconfig  2018-10-16 16:36:32.419732670 +0200
@@ -36,7 +36,6 @@ config PCIEAER
 config PCIEAER_INJECT
tristate "PCI Express error injection support"
depends on PCIEAER && DYNAMIC_FTRACE_WITH_REGS
-   default n
help
  This enables PCI Express Root Port Advanced Error Reporting
  (AER) software error injector.
@@ -84,7 +83,6 @@ config PCIEASPM
 config PCIEASPM_DEBUG
bool "Debug PCI Express ASPM"
depends on PCIEASPM
-   default n
help
  This enables PCI Express ASPM debug support. It will add per-device
  interface to control ASPM.
@@ -129,7 +127,6 @@ config PCIE_PME
 config PCIE_DPC
bool "PCI Express Downstream Port Containment support"
depends on PCIEPORTBUS && PCIEAER
-   default n
help
  This enables PCI Express Downstream Port Containment (DPC)
  driver support.  DPC events from Root and Downstream ports
@@ -139,7 +136,6 @@ config PCIE_DPC
 
 config PCIE_PTM
bool "PCI Express Precision Time Measurement support"
-   default n
depends on PCIEPORTBUS
help
  This enables PCI Express Precision Time Measurement (PTM)

[PATCH] m68k: remove redundant 'default n' from Kconfig

2018-10-16 Thread Bartlomiej Zolnierkiewicz

'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.

Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or not:

...
One side effect of (and the main motivation for) this change is making
the following two definitions behave exactly the same:

config FOO
bool

config FOO
bool
default n

With this change, neither of these will generate a
'# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
That might make it clearer to people that a bare 'default n' is
redundant.
...

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 arch/m68k/Kconfig.machine |2 --
 1 file changed, 2 deletions(-)

Index: b/arch/m68k/Kconfig.machine
===
--- a/arch/m68k/Kconfig.machine 2018-09-03 18:11:11.397792454 +0200
+++ b/arch/m68k/Kconfig.machine 2018-10-16 15:32:04.359635259 +0200
@@ -317,7 +317,6 @@ config UBOOT
help
  If you say Y here kernel will try to collect command
  line parameters from the initial u-boot stack.
-   default n
 
 config 4KSTACKS
bool "Use 4Kb for kernel stacks instead of 8Kb"
@@ -395,7 +394,6 @@ comment "ROM configuration"
 
 config ROM
bool "Specify ROM linker regions"
-   default n
help
  Define a ROM region for the linker script. This creates a kernel
  that can be stored in flash, with possibly the text, and data

[PATCH] m68k: remove redundant 'default n' from Kconfig

2018-10-16 Thread Bartlomiej Zolnierkiewicz

'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.

Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or not:

...
One side effect of (and the main motivation for) this change is making
the following two definitions behave exactly the same:

config FOO
bool

config FOO
bool
default n

With this change, neither of these will generate a
'# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
That might make it clearer to people that a bare 'default n' is
redundant.
...

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 arch/m68k/Kconfig.machine |2 --
 1 file changed, 2 deletions(-)

Index: b/arch/m68k/Kconfig.machine
===
--- a/arch/m68k/Kconfig.machine 2018-09-03 18:11:11.397792454 +0200
+++ b/arch/m68k/Kconfig.machine 2018-10-16 15:32:04.359635259 +0200
@@ -317,7 +317,6 @@ config UBOOT
help
  If you say Y here kernel will try to collect command
  line parameters from the initial u-boot stack.
-   default n
 
 config 4KSTACKS
bool "Use 4Kb for kernel stacks instead of 8Kb"
@@ -395,7 +394,6 @@ comment "ROM configuration"
 
 config ROM
bool "Specify ROM linker regions"
-   default n
help
  Define a ROM region for the linker script. This creates a kernel
  that can be stored in flash, with possibly the text, and data

[PATCH] c6x: remove redundant 'default n' from Kconfig-s

2018-10-16 Thread Bartlomiej Zolnierkiewicz

'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.

Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or not:

...
One side effect of (and the main motivation for) this change is making
the following two definitions behave exactly the same:

config FOO
bool

config FOO
bool
default n

With this change, neither of these will generate a
'# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
That might make it clearer to people that a bare 'default n' is
redundant.
...

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 arch/c6x/Kconfig   |2 --
 arch/c6x/platforms/Kconfig |5 -
 2 files changed, 7 deletions(-)

Index: b/arch/c6x/Kconfig
===
--- a/arch/c6x/Kconfig  2018-10-09 15:58:36.295122871 +0200
+++ b/arch/c6x/Kconfig  2018-10-16 15:28:50.623630380 +0200
@@ -70,14 +70,12 @@ config CMDLINE
 config CMDLINE_FORCE
bool "Force default kernel command string"
depends on CMDLINE_BOOL
-   default n
help
  Set this to have arguments from the default kernel command string
  override those passed by the boot loader.
 
 config CPU_BIG_ENDIAN
bool "Build big-endian kernel"
-   default n
help
  Say Y if you plan on running a kernel in big-endian mode.
  Note that your board must be properly built and your board
Index: b/arch/c6x/platforms/Kconfig
===
--- a/arch/c6x/platforms/Kconfig2018-09-03 18:11:11.249792456 +0200
+++ b/arch/c6x/platforms/Kconfig2018-10-16 15:29:04.891630739 +0200
@@ -2,20 +2,15 @@
 
 config SOC_TMS320C6455
bool "TMS320C6455"
-   default n
 
 config SOC_TMS320C6457
bool "TMS320C6457"
-   default n
 
 config SOC_TMS320C6472
bool "TMS320C6472"
-   default n
 
 config SOC_TMS320C6474
bool "TMS320C6474"
-   default n
 
 config SOC_TMS320C6678
bool "TMS320C6678"
-   default n

[PATCH] c6x: remove redundant 'default n' from Kconfig-s

2018-10-16 Thread Bartlomiej Zolnierkiewicz

'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.

Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or not:

...
One side effect of (and the main motivation for) this change is making
the following two definitions behave exactly the same:

config FOO
bool

config FOO
bool
default n

With this change, neither of these will generate a
'# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
That might make it clearer to people that a bare 'default n' is
redundant.
...

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 arch/c6x/Kconfig   |2 --
 arch/c6x/platforms/Kconfig |5 -
 2 files changed, 7 deletions(-)

Index: b/arch/c6x/Kconfig
===
--- a/arch/c6x/Kconfig  2018-10-09 15:58:36.295122871 +0200
+++ b/arch/c6x/Kconfig  2018-10-16 15:28:50.623630380 +0200
@@ -70,14 +70,12 @@ config CMDLINE
 config CMDLINE_FORCE
bool "Force default kernel command string"
depends on CMDLINE_BOOL
-   default n
help
  Set this to have arguments from the default kernel command string
  override those passed by the boot loader.
 
 config CPU_BIG_ENDIAN
bool "Build big-endian kernel"
-   default n
help
  Say Y if you plan on running a kernel in big-endian mode.
  Note that your board must be properly built and your board
Index: b/arch/c6x/platforms/Kconfig
===
--- a/arch/c6x/platforms/Kconfig2018-09-03 18:11:11.249792456 +0200
+++ b/arch/c6x/platforms/Kconfig2018-10-16 15:29:04.891630739 +0200
@@ -2,20 +2,15 @@
 
 config SOC_TMS320C6455
bool "TMS320C6455"
-   default n
 
 config SOC_TMS320C6457
bool "TMS320C6457"
-   default n
 
 config SOC_TMS320C6472
bool "TMS320C6472"
-   default n
 
 config SOC_TMS320C6474
bool "TMS320C6474"
-   default n
 
 config SOC_TMS320C6678
bool "TMS320C6678"
-   default n

[PATCH v3] ARM: SAMSUNG: limit SAMSUNG_PM_DEBUG config option to non-Exynos platforms

2018-10-15 Thread Bartlomiej Zolnierkiewicz

"Samsung PM Suspend debug" feature (controlled by SAMSUNG_PM_DEBUG
config option) is not working properly (debug messages are not
displayed after resume) on Exynos platforms because GPIOs restore
code is not implemented.

Add PLAT_S3C24XX, ARCH_S3C64XX and ARCH_S5PV210 dependencies to
SAMSUNG_PM_DEBUG config option to hide it on Exynos platforms.
Then convert Exynos code to not require 
header (use pr_debug() directly instead of S3C_PMDBG() macro and
remove redundant s3c_pm_*() calls).

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
v3:
- don't move PM to the line below in Kconfig

v2:
- convert Exynos code to not require  header

Should by applied on top of "[PATCH] ARM: EXYNOS: remove no longer
needed s3c_pm_check_*() calls".

 arch/arm/mach-exynos/suspend.c |   14 --
 arch/arm/plat-samsung/Kconfig  |1 +
 2 files changed, 5 insertions(+), 10 deletions(-)

Index: b/arch/arm/mach-exynos/suspend.c
===
--- a/arch/arm/mach-exynos/suspend.c2018-10-15 17:39:54.628412461 +0200
+++ b/arch/arm/mach-exynos/suspend.c2018-10-15 17:39:54.624412461 +0200
@@ -30,8 +30,6 @@
 #include 
 #include 
 
-#include 
-
 #include "common.h"
 
 #define REG_TABLE_END (-1U)
@@ -490,11 +488,9 @@ static int exynos_suspend_enter(suspend_
 {
int ret;
 
-   s3c_pm_debug_init();
-
-   S3C_PMDBG("%s: suspending the system...\n", __func__);
+   pr_debug("%s: suspending the system...\n", __func__);
 
-   S3C_PMDBG("%s: wakeup masks: %08x,%08x\n", __func__,
+   pr_debug("%s: wakeup masks: %08x,%08x\n", __func__,
exynos_irqwake_intmask, exynos_get_eint_wake_mask());
 
if (exynos_irqwake_intmask == -1U
@@ -504,7 +500,6 @@ static int exynos_suspend_enter(suspend_
return -EINVAL;
}
 
-   s3c_pm_save_uarts();
if (pm_data->pm_prepare)
pm_data->pm_prepare();
flush_cache_all();
@@ -517,12 +512,11 @@ static int exynos_suspend_enter(suspend_
 
if (pm_data->pm_resume_prepare)
pm_data->pm_resume_prepare();
-   s3c_pm_restore_uarts();
 
-   S3C_PMDBG("%s: wakeup stat: %08x\n", __func__,
+   pr_debug("%s: wakeup stat: %08x\n", __func__,
pmu_raw_readl(S5P_WAKEUP_STAT));
 
-   S3C_PMDBG("%s: resuming the system...\n", __func__);
+   pr_debug("%s: resuming the system...\n", __func__);
 
return 0;
 }
Index: b/arch/arm/plat-samsung/Kconfig
===
--- a/arch/arm/plat-samsung/Kconfig 2018-10-15 17:39:54.628412461 +0200
+++ b/arch/arm/plat-samsung/Kconfig 2018-10-15 17:40:35.416413489 +0200
@@ -239,6 +239,7 @@ comment "Power management"
 config SAMSUNG_PM_DEBUG
bool "Samsung PM Suspend debug"
depends on PM && DEBUG_KERNEL
+   depends on PLAT_S3C24XX || ARCH_S3C64XX || ARCH_S5PV210
depends on DEBUG_EXYNOS_UART || DEBUG_S3C24XX_UART || DEBUG_S3C2410_UART
help
  Say Y here if you want verbose debugging from the PM Suspend and

[PATCH v3] ARM: SAMSUNG: limit SAMSUNG_PM_DEBUG config option to non-Exynos platforms

2018-10-15 Thread Bartlomiej Zolnierkiewicz

"Samsung PM Suspend debug" feature (controlled by SAMSUNG_PM_DEBUG
config option) is not working properly (debug messages are not
displayed after resume) on Exynos platforms because GPIOs restore
code is not implemented.

Add PLAT_S3C24XX, ARCH_S3C64XX and ARCH_S5PV210 dependencies to
SAMSUNG_PM_DEBUG config option to hide it on Exynos platforms.
Then convert Exynos code to not require 
header (use pr_debug() directly instead of S3C_PMDBG() macro and
remove redundant s3c_pm_*() calls).

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
v3:
- don't move PM to the line below in Kconfig

v2:
- convert Exynos code to not require  header

Should by applied on top of "[PATCH] ARM: EXYNOS: remove no longer
needed s3c_pm_check_*() calls".

 arch/arm/mach-exynos/suspend.c |   14 --
 arch/arm/plat-samsung/Kconfig  |1 +
 2 files changed, 5 insertions(+), 10 deletions(-)

Index: b/arch/arm/mach-exynos/suspend.c
===
--- a/arch/arm/mach-exynos/suspend.c2018-10-15 17:39:54.628412461 +0200
+++ b/arch/arm/mach-exynos/suspend.c2018-10-15 17:39:54.624412461 +0200
@@ -30,8 +30,6 @@
 #include 
 #include 
 
-#include 
-
 #include "common.h"
 
 #define REG_TABLE_END (-1U)
@@ -490,11 +488,9 @@ static int exynos_suspend_enter(suspend_
 {
int ret;
 
-   s3c_pm_debug_init();
-
-   S3C_PMDBG("%s: suspending the system...\n", __func__);
+   pr_debug("%s: suspending the system...\n", __func__);
 
-   S3C_PMDBG("%s: wakeup masks: %08x,%08x\n", __func__,
+   pr_debug("%s: wakeup masks: %08x,%08x\n", __func__,
exynos_irqwake_intmask, exynos_get_eint_wake_mask());
 
if (exynos_irqwake_intmask == -1U
@@ -504,7 +500,6 @@ static int exynos_suspend_enter(suspend_
return -EINVAL;
}
 
-   s3c_pm_save_uarts();
if (pm_data->pm_prepare)
pm_data->pm_prepare();
flush_cache_all();
@@ -517,12 +512,11 @@ static int exynos_suspend_enter(suspend_
 
if (pm_data->pm_resume_prepare)
pm_data->pm_resume_prepare();
-   s3c_pm_restore_uarts();
 
-   S3C_PMDBG("%s: wakeup stat: %08x\n", __func__,
+   pr_debug("%s: wakeup stat: %08x\n", __func__,
pmu_raw_readl(S5P_WAKEUP_STAT));
 
-   S3C_PMDBG("%s: resuming the system...\n", __func__);
+   pr_debug("%s: resuming the system...\n", __func__);
 
return 0;
 }
Index: b/arch/arm/plat-samsung/Kconfig
===
--- a/arch/arm/plat-samsung/Kconfig 2018-10-15 17:39:54.628412461 +0200
+++ b/arch/arm/plat-samsung/Kconfig 2018-10-15 17:40:35.416413489 +0200
@@ -239,6 +239,7 @@ comment "Power management"
 config SAMSUNG_PM_DEBUG
bool "Samsung PM Suspend debug"
depends on PM && DEBUG_KERNEL
+   depends on PLAT_S3C24XX || ARCH_S3C64XX || ARCH_S5PV210
depends on DEBUG_EXYNOS_UART || DEBUG_S3C24XX_UART || DEBUG_S3C2410_UART
help
  Say Y here if you want verbose debugging from the PM Suspend and

Re: [PATCH v2] ARM: SAMSUNG: limit SAMSUNG_PM_DEBUG config option to non-Exynos platforms

2018-10-15 Thread Bartlomiej Zolnierkiewicz



On 10/15/2018 05:22 PM, Krzysztof Kozlowski wrote:
> On Mon, 15 Oct 2018 at 15:50, Bartlomiej Zolnierkiewicz
>  wrote:
>>
>> "Samsung PM Suspend debug" feature (controlled by SAMSUNG_PM_DEBUG
>> config option) is not working properly (debug messages are not
>> displayed after resume) on Exynos platforms because GPIOs restore
>> code is not implemented.
>>
>> Add PLAT_S3C24XX, ARCH_S3C64XX and ARCH_S5PV210 dependencies to
>> SAMSUNG_PM_DEBUG config option to hide it on Exynos platforms.
>> Then convert Exynos code to not require 
>> header (use pr_debug() directly instead of S3C_PMDBG() macro and
>> remove redundant s3c_pm_*() calls).
>>
>> Signed-off-by: Bartlomiej Zolnierkiewicz 
>> ---
>> v2:
>> - convert Exynos code to not require  header
>>
>> Should by applied on top of "[PATCH] ARM: EXYNOS: remove no longer
>> needed s3c_pm_check_*() calls".
>>
>>  arch/arm/mach-exynos/suspend.c |   14 --
>>  arch/arm/plat-samsung/Kconfig  |3 ++-
>>  2 files changed, 6 insertions(+), 11 deletions(-)
>>
>> Index: b/arch/arm/mach-exynos/suspend.c
>> ===
>> --- a/arch/arm/mach-exynos/suspend.c2018-10-15 15:11:15.296187842 +0200
>> +++ b/arch/arm/mach-exynos/suspend.c2018-10-15 15:22:54.656205454 +0200
>> @@ -30,8 +30,6 @@
>>  #include 
>>  #include 
>>
>> -#include 
>> -
>>  #include "common.h"
>>
>>  #define REG_TABLE_END (-1U)
>> @@ -490,11 +488,9 @@ static int exynos_suspend_enter(suspend_
>>  {
>> int ret;
>>
>> -   s3c_pm_debug_init();
>> -
>> -   S3C_PMDBG("%s: suspending the system...\n", __func__);
>> +   pr_debug("%s: suspending the system...\n", __func__);
>>
>> -   S3C_PMDBG("%s: wakeup masks: %08x,%08x\n", __func__,
>> +   pr_debug("%s: wakeup masks: %08x,%08x\n", __func__,
>> exynos_irqwake_intmask, exynos_get_eint_wake_mask());
>>
>> if (exynos_irqwake_intmask == -1U
>> @@ -504,7 +500,6 @@ static int exynos_suspend_enter(suspend_
>> return -EINVAL;
>> }
>>
>> -   s3c_pm_save_uarts();
>> if (pm_data->pm_prepare)
>> pm_data->pm_prepare();
>> flush_cache_all();
>> @@ -517,12 +512,11 @@ static int exynos_suspend_enter(suspend_
>>
>> if (pm_data->pm_resume_prepare)
>> pm_data->pm_resume_prepare();
>> -   s3c_pm_restore_uarts();
>>
>> -   S3C_PMDBG("%s: wakeup stat: %08x\n", __func__,
>> +   pr_debug("%s: wakeup stat: %08x\n", __func__,
>> pmu_raw_readl(S5P_WAKEUP_STAT));
>>
>> -   S3C_PMDBG("%s: resuming the system...\n", __func__);
>> +   pr_debug("%s: resuming the system...\n", __func__);
>>
>> return 0;
>>  }
>> Index: b/arch/arm/plat-samsung/Kconfig
>> ===
>> --- a/arch/arm/plat-samsung/Kconfig 2018-10-15 15:16:22.804195586 +0200
>> +++ b/arch/arm/plat-samsung/Kconfig 2018-10-15 15:16:22.800195586 +0200
>> @@ -238,7 +238,8 @@ comment "Power management"
>>
>>  config SAMSUNG_PM_DEBUG
>> bool "Samsung PM Suspend debug"
>> -   depends on PM && DEBUG_KERNEL
>> +   depends on DEBUG_KERNEL
> 
> I don't get this change - why moving PM to line below?

My mistake, I will correct it in v3.

[ The idea was to make SAMSUNG_PM_DEBUG consistent with other options
  depending on DEBUG_KERNEL. However after I've checked them it turned
  out that there is no such consistency. I intended to revert this
  change but ultimately I forgot about it.. ]

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

Re: [PATCH v2] ARM: SAMSUNG: limit SAMSUNG_PM_DEBUG config option to non-Exynos platforms

2018-10-15 Thread Bartlomiej Zolnierkiewicz



On 10/15/2018 05:22 PM, Krzysztof Kozlowski wrote:
> On Mon, 15 Oct 2018 at 15:50, Bartlomiej Zolnierkiewicz
>  wrote:
>>
>> "Samsung PM Suspend debug" feature (controlled by SAMSUNG_PM_DEBUG
>> config option) is not working properly (debug messages are not
>> displayed after resume) on Exynos platforms because GPIOs restore
>> code is not implemented.
>>
>> Add PLAT_S3C24XX, ARCH_S3C64XX and ARCH_S5PV210 dependencies to
>> SAMSUNG_PM_DEBUG config option to hide it on Exynos platforms.
>> Then convert Exynos code to not require 
>> header (use pr_debug() directly instead of S3C_PMDBG() macro and
>> remove redundant s3c_pm_*() calls).
>>
>> Signed-off-by: Bartlomiej Zolnierkiewicz 
>> ---
>> v2:
>> - convert Exynos code to not require  header
>>
>> Should by applied on top of "[PATCH] ARM: EXYNOS: remove no longer
>> needed s3c_pm_check_*() calls".
>>
>>  arch/arm/mach-exynos/suspend.c |   14 --
>>  arch/arm/plat-samsung/Kconfig  |3 ++-
>>  2 files changed, 6 insertions(+), 11 deletions(-)
>>
>> Index: b/arch/arm/mach-exynos/suspend.c
>> ===
>> --- a/arch/arm/mach-exynos/suspend.c2018-10-15 15:11:15.296187842 +0200
>> +++ b/arch/arm/mach-exynos/suspend.c2018-10-15 15:22:54.656205454 +0200
>> @@ -30,8 +30,6 @@
>>  #include 
>>  #include 
>>
>> -#include 
>> -
>>  #include "common.h"
>>
>>  #define REG_TABLE_END (-1U)
>> @@ -490,11 +488,9 @@ static int exynos_suspend_enter(suspend_
>>  {
>> int ret;
>>
>> -   s3c_pm_debug_init();
>> -
>> -   S3C_PMDBG("%s: suspending the system...\n", __func__);
>> +   pr_debug("%s: suspending the system...\n", __func__);
>>
>> -   S3C_PMDBG("%s: wakeup masks: %08x,%08x\n", __func__,
>> +   pr_debug("%s: wakeup masks: %08x,%08x\n", __func__,
>> exynos_irqwake_intmask, exynos_get_eint_wake_mask());
>>
>> if (exynos_irqwake_intmask == -1U
>> @@ -504,7 +500,6 @@ static int exynos_suspend_enter(suspend_
>> return -EINVAL;
>> }
>>
>> -   s3c_pm_save_uarts();
>> if (pm_data->pm_prepare)
>> pm_data->pm_prepare();
>> flush_cache_all();
>> @@ -517,12 +512,11 @@ static int exynos_suspend_enter(suspend_
>>
>> if (pm_data->pm_resume_prepare)
>> pm_data->pm_resume_prepare();
>> -   s3c_pm_restore_uarts();
>>
>> -   S3C_PMDBG("%s: wakeup stat: %08x\n", __func__,
>> +   pr_debug("%s: wakeup stat: %08x\n", __func__,
>> pmu_raw_readl(S5P_WAKEUP_STAT));
>>
>> -   S3C_PMDBG("%s: resuming the system...\n", __func__);
>> +   pr_debug("%s: resuming the system...\n", __func__);
>>
>> return 0;
>>  }
>> Index: b/arch/arm/plat-samsung/Kconfig
>> ===
>> --- a/arch/arm/plat-samsung/Kconfig 2018-10-15 15:16:22.804195586 +0200
>> +++ b/arch/arm/plat-samsung/Kconfig 2018-10-15 15:16:22.800195586 +0200
>> @@ -238,7 +238,8 @@ comment "Power management"
>>
>>  config SAMSUNG_PM_DEBUG
>> bool "Samsung PM Suspend debug"
>> -   depends on PM && DEBUG_KERNEL
>> +   depends on DEBUG_KERNEL
> 
> I don't get this change - why moving PM to line below?

My mistake, I will correct it in v3.

[ The idea was to make SAMSUNG_PM_DEBUG consistent with other options
  depending on DEBUG_KERNEL. However after I've checked them it turned
  out that there is no such consistency. I intended to revert this
  change but ultimately I forgot about it.. ]

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

[PATCH v2] ARM: SAMSUNG: limit SAMSUNG_PM_DEBUG config option to non-Exynos platforms

2018-10-15 Thread Bartlomiej Zolnierkiewicz

"Samsung PM Suspend debug" feature (controlled by SAMSUNG_PM_DEBUG
config option) is not working properly (debug messages are not
displayed after resume) on Exynos platforms because GPIOs restore
code is not implemented.

Add PLAT_S3C24XX, ARCH_S3C64XX and ARCH_S5PV210 dependencies to
SAMSUNG_PM_DEBUG config option to hide it on Exynos platforms.
Then convert Exynos code to not require 
header (use pr_debug() directly instead of S3C_PMDBG() macro and
remove redundant s3c_pm_*() calls).

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
v2:
- convert Exynos code to not require  header

Should by applied on top of "[PATCH] ARM: EXYNOS: remove no longer
needed s3c_pm_check_*() calls".

 arch/arm/mach-exynos/suspend.c |   14 --
 arch/arm/plat-samsung/Kconfig  |3 ++-
 2 files changed, 6 insertions(+), 11 deletions(-)

Index: b/arch/arm/mach-exynos/suspend.c
===
--- a/arch/arm/mach-exynos/suspend.c2018-10-15 15:11:15.296187842 +0200
+++ b/arch/arm/mach-exynos/suspend.c2018-10-15 15:22:54.656205454 +0200
@@ -30,8 +30,6 @@
 #include 
 #include 
 
-#include 
-
 #include "common.h"
 
 #define REG_TABLE_END (-1U)
@@ -490,11 +488,9 @@ static int exynos_suspend_enter(suspend_
 {
int ret;
 
-   s3c_pm_debug_init();
-
-   S3C_PMDBG("%s: suspending the system...\n", __func__);
+   pr_debug("%s: suspending the system...\n", __func__);
 
-   S3C_PMDBG("%s: wakeup masks: %08x,%08x\n", __func__,
+   pr_debug("%s: wakeup masks: %08x,%08x\n", __func__,
exynos_irqwake_intmask, exynos_get_eint_wake_mask());
 
if (exynos_irqwake_intmask == -1U
@@ -504,7 +500,6 @@ static int exynos_suspend_enter(suspend_
return -EINVAL;
}
 
-   s3c_pm_save_uarts();
if (pm_data->pm_prepare)
pm_data->pm_prepare();
flush_cache_all();
@@ -517,12 +512,11 @@ static int exynos_suspend_enter(suspend_
 
if (pm_data->pm_resume_prepare)
pm_data->pm_resume_prepare();
-   s3c_pm_restore_uarts();
 
-   S3C_PMDBG("%s: wakeup stat: %08x\n", __func__,
+   pr_debug("%s: wakeup stat: %08x\n", __func__,
pmu_raw_readl(S5P_WAKEUP_STAT));
 
-   S3C_PMDBG("%s: resuming the system...\n", __func__);
+   pr_debug("%s: resuming the system...\n", __func__);
 
return 0;
 }
Index: b/arch/arm/plat-samsung/Kconfig
===
--- a/arch/arm/plat-samsung/Kconfig 2018-10-15 15:16:22.804195586 +0200
+++ b/arch/arm/plat-samsung/Kconfig 2018-10-15 15:16:22.800195586 +0200
@@ -238,7 +238,8 @@ comment "Power management"
 
 config SAMSUNG_PM_DEBUG
bool "Samsung PM Suspend debug"
-   depends on PM && DEBUG_KERNEL
+   depends on DEBUG_KERNEL
+   depends on PM && (PLAT_S3C24XX || ARCH_S3C64XX || ARCH_S5PV210)
depends on DEBUG_EXYNOS_UART || DEBUG_S3C24XX_UART || DEBUG_S3C2410_UART
help
  Say Y here if you want verbose debugging from the PM Suspend and

[PATCH v2] ARM: SAMSUNG: limit SAMSUNG_PM_DEBUG config option to non-Exynos platforms

2018-10-15 Thread Bartlomiej Zolnierkiewicz

"Samsung PM Suspend debug" feature (controlled by SAMSUNG_PM_DEBUG
config option) is not working properly (debug messages are not
displayed after resume) on Exynos platforms because GPIOs restore
code is not implemented.

Add PLAT_S3C24XX, ARCH_S3C64XX and ARCH_S5PV210 dependencies to
SAMSUNG_PM_DEBUG config option to hide it on Exynos platforms.
Then convert Exynos code to not require 
header (use pr_debug() directly instead of S3C_PMDBG() macro and
remove redundant s3c_pm_*() calls).

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
v2:
- convert Exynos code to not require  header

Should by applied on top of "[PATCH] ARM: EXYNOS: remove no longer
needed s3c_pm_check_*() calls".

 arch/arm/mach-exynos/suspend.c |   14 --
 arch/arm/plat-samsung/Kconfig  |3 ++-
 2 files changed, 6 insertions(+), 11 deletions(-)

Index: b/arch/arm/mach-exynos/suspend.c
===
--- a/arch/arm/mach-exynos/suspend.c2018-10-15 15:11:15.296187842 +0200
+++ b/arch/arm/mach-exynos/suspend.c2018-10-15 15:22:54.656205454 +0200
@@ -30,8 +30,6 @@
 #include 
 #include 
 
-#include 
-
 #include "common.h"
 
 #define REG_TABLE_END (-1U)
@@ -490,11 +488,9 @@ static int exynos_suspend_enter(suspend_
 {
int ret;
 
-   s3c_pm_debug_init();
-
-   S3C_PMDBG("%s: suspending the system...\n", __func__);
+   pr_debug("%s: suspending the system...\n", __func__);
 
-   S3C_PMDBG("%s: wakeup masks: %08x,%08x\n", __func__,
+   pr_debug("%s: wakeup masks: %08x,%08x\n", __func__,
exynos_irqwake_intmask, exynos_get_eint_wake_mask());
 
if (exynos_irqwake_intmask == -1U
@@ -504,7 +500,6 @@ static int exynos_suspend_enter(suspend_
return -EINVAL;
}
 
-   s3c_pm_save_uarts();
if (pm_data->pm_prepare)
pm_data->pm_prepare();
flush_cache_all();
@@ -517,12 +512,11 @@ static int exynos_suspend_enter(suspend_
 
if (pm_data->pm_resume_prepare)
pm_data->pm_resume_prepare();
-   s3c_pm_restore_uarts();
 
-   S3C_PMDBG("%s: wakeup stat: %08x\n", __func__,
+   pr_debug("%s: wakeup stat: %08x\n", __func__,
pmu_raw_readl(S5P_WAKEUP_STAT));
 
-   S3C_PMDBG("%s: resuming the system...\n", __func__);
+   pr_debug("%s: resuming the system...\n", __func__);
 
return 0;
 }
Index: b/arch/arm/plat-samsung/Kconfig
===
--- a/arch/arm/plat-samsung/Kconfig 2018-10-15 15:16:22.804195586 +0200
+++ b/arch/arm/plat-samsung/Kconfig 2018-10-15 15:16:22.800195586 +0200
@@ -238,7 +238,8 @@ comment "Power management"
 
 config SAMSUNG_PM_DEBUG
bool "Samsung PM Suspend debug"
-   depends on PM && DEBUG_KERNEL
+   depends on DEBUG_KERNEL
+   depends on PM && (PLAT_S3C24XX || ARCH_S3C64XX || ARCH_S5PV210)
depends on DEBUG_EXYNOS_UART || DEBUG_S3C24XX_UART || DEBUG_S3C2410_UART
help
  Say Y here if you want verbose debugging from the PM Suspend and

[PATCH] ARM: EXYNOS: remove no longer needed s3c_pm_check_*() calls

2018-10-15 Thread Bartlomiej Zolnierkiewicz

Since commit 6862fdf2201a ("ARM: samsung: Limit SAMSUNG_PM_CHECK
config option to non-Exynos platforms") s3c_pm_check_*() calls
are redundant and can be removed.

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 arch/arm/mach-exynos/suspend.c |7 ---
 1 file changed, 7 deletions(-)

Index: b/arch/arm/mach-exynos/suspend.c
===
--- a/arch/arm/mach-exynos/suspend.c2018-10-09 15:58:35.495122851 +0200
+++ b/arch/arm/mach-exynos/suspend.c2018-10-15 15:08:52.420184244 +0200
@@ -508,7 +508,6 @@ static int exynos_suspend_enter(suspend_
if (pm_data->pm_prepare)
pm_data->pm_prepare();
flush_cache_all();
-   s3c_pm_check_store();
 
ret = call_firmware_op(suspend);
if (ret == -ENOSYS)
@@ -523,8 +522,6 @@ static int exynos_suspend_enter(suspend_
S3C_PMDBG("%s: wakeup stat: %08x\n", __func__,
pmu_raw_readl(S5P_WAKEUP_STAT));
 
-   s3c_pm_check_restore();
-
S3C_PMDBG("%s: resuming the system...\n", __func__);
 
return 0;
@@ -548,8 +545,6 @@ static int exynos_suspend_prepare(void)
return ret;
}
 
-   s3c_pm_check_prepare();
-
return 0;
 }
 
@@ -557,8 +552,6 @@ static void exynos_suspend_finish(void)
 {
int ret;
 
-   s3c_pm_check_cleanup();
-
ret = regulator_suspend_finish();
if (ret)
pr_warn("Failed to resume regulators from suspend (%d)\n", ret);

[PATCH] ARM: EXYNOS: remove no longer needed s3c_pm_check_*() calls

2018-10-15 Thread Bartlomiej Zolnierkiewicz

Since commit 6862fdf2201a ("ARM: samsung: Limit SAMSUNG_PM_CHECK
config option to non-Exynos platforms") s3c_pm_check_*() calls
are redundant and can be removed.

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 arch/arm/mach-exynos/suspend.c |7 ---
 1 file changed, 7 deletions(-)

Index: b/arch/arm/mach-exynos/suspend.c
===
--- a/arch/arm/mach-exynos/suspend.c2018-10-09 15:58:35.495122851 +0200
+++ b/arch/arm/mach-exynos/suspend.c2018-10-15 15:08:52.420184244 +0200
@@ -508,7 +508,6 @@ static int exynos_suspend_enter(suspend_
if (pm_data->pm_prepare)
pm_data->pm_prepare();
flush_cache_all();
-   s3c_pm_check_store();
 
ret = call_firmware_op(suspend);
if (ret == -ENOSYS)
@@ -523,8 +522,6 @@ static int exynos_suspend_enter(suspend_
S3C_PMDBG("%s: wakeup stat: %08x\n", __func__,
pmu_raw_readl(S5P_WAKEUP_STAT));
 
-   s3c_pm_check_restore();
-
S3C_PMDBG("%s: resuming the system...\n", __func__);
 
return 0;
@@ -548,8 +545,6 @@ static int exynos_suspend_prepare(void)
return ret;
}
 
-   s3c_pm_check_prepare();
-
return 0;
 }
 
@@ -557,8 +552,6 @@ static void exynos_suspend_finish(void)
 {
int ret;
 
-   s3c_pm_check_cleanup();
-
ret = regulator_suspend_finish();
if (ret)
pr_warn("Failed to resume regulators from suspend (%d)\n", ret);

Re: [PATCH] mfd: remove redundant 'default n' from Kconfig

2018-10-12 Thread Bartlomiej Zolnierkiewicz



On 10/11/2018 07:48 AM, Lee Jones wrote:
> On Wed, 10 Oct 2018, Bartlomiej Zolnierkiewicz wrote:
> 
>> 'default n' is the default value for any bool or tristate Kconfig
>> setting so there is no need to write it explicitly.
>>
>> Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
>> is not set' for visible symbols") the Kconfig behavior is the same
>> regardless of 'default n' being present or not:
>>
>> ...
>> One side effect of (and the main motivation for) this change is making
>> the following two definitions behave exactly the same:
>> 
>> config FOO
>> bool
>> 
>> config FOO
>> bool
>> default n
>> 
>> With this change, neither of these will generate a
>> '# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
>>     That might make it clearer to people that a bare 'default n' is
>> redundant.
>> ...
>>
>> Signed-off-by: Bartlomiej Zolnierkiewicz 
>> ---
>>  drivers/mfd/Kconfig |6 --
>>  1 file changed, 6 deletions(-)
> 
> The change looks okay to me, but I would also like you to include the
> Maintainers/Reviewers for the affected source files.

Could you please explain in more details what do you mean?

The only affected source file is drivers/mfd/Kconfig:

$ ./scripts/get_maintainer.pl -f drivers/mfd/Kconfig 
Lee Jones  (supporter:MULTIFUNCTION DEVICES (MFD))
linux-kernel@vger.kernel.org (open list)

> Also, I assume you are not just submitting these changes to the MFD
> subsystem.  My suggesting is to change each subsystem per patch (as
> you have done here), and submit them in one patch-set with each of the
> subsystem Maintainers included, so each of us has some visibility into
> how the general idea is being received.

The general idea is trivial - remove redundant "default n" from Kconfig
files and as a result cut ~700 LOC kernel wide. I assume that this is so
trivial change that there is no need for longer deliberations.

Also I'm sorry but I simply cannot invest few days straight in preparing
the full patchset. OTOH investing few minutes a day or a week is fine so
this is why I'm doing this change incrementally.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

Re: [PATCH] mfd: remove redundant 'default n' from Kconfig

2018-10-12 Thread Bartlomiej Zolnierkiewicz



On 10/11/2018 07:48 AM, Lee Jones wrote:
> On Wed, 10 Oct 2018, Bartlomiej Zolnierkiewicz wrote:
> 
>> 'default n' is the default value for any bool or tristate Kconfig
>> setting so there is no need to write it explicitly.
>>
>> Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
>> is not set' for visible symbols") the Kconfig behavior is the same
>> regardless of 'default n' being present or not:
>>
>> ...
>> One side effect of (and the main motivation for) this change is making
>> the following two definitions behave exactly the same:
>> 
>> config FOO
>> bool
>> 
>> config FOO
>> bool
>> default n
>> 
>> With this change, neither of these will generate a
>> '# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
>>     That might make it clearer to people that a bare 'default n' is
>> redundant.
>> ...
>>
>> Signed-off-by: Bartlomiej Zolnierkiewicz 
>> ---
>>  drivers/mfd/Kconfig |6 --
>>  1 file changed, 6 deletions(-)
> 
> The change looks okay to me, but I would also like you to include the
> Maintainers/Reviewers for the affected source files.

Could you please explain in more details what do you mean?

The only affected source file is drivers/mfd/Kconfig:

$ ./scripts/get_maintainer.pl -f drivers/mfd/Kconfig 
Lee Jones  (supporter:MULTIFUNCTION DEVICES (MFD))
linux-kernel@vger.kernel.org (open list)

> Also, I assume you are not just submitting these changes to the MFD
> subsystem.  My suggesting is to change each subsystem per patch (as
> you have done here), and submit them in one patch-set with each of the
> subsystem Maintainers included, so each of us has some visibility into
> how the general idea is being received.

The general idea is trivial - remove redundant "default n" from Kconfig
files and as a result cut ~700 LOC kernel wide. I assume that this is so
trivial change that there is no need for longer deliberations.

Also I'm sorry but I simply cannot invest few days straight in preparing
the full patchset. OTOH investing few minutes a day or a week is fine so
this is why I'm doing this change incrementally.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

[PATCH] nios2: remove redundant 'default n' from Kconfig-s

2018-10-10 Thread Bartlomiej Zolnierkiewicz

'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.

Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or not:

...
One side effect of (and the main motivation for) this change is making
the following two definitions behave exactly the same:

config FOO
bool

config FOO
bool
default n

With this change, neither of these will generate a
'# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
That might make it clearer to people that a bare 'default n' is
redundant.
...

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 arch/nios2/Kconfig   |1 -
 arch/nios2/platform/Kconfig.platform |9 -
 2 files changed, 10 deletions(-)

Index: b/arch/nios2/Kconfig
===
--- a/arch/nios2/Kconfig2018-10-09 15:58:36.543122877 +0200
+++ b/arch/nios2/Kconfig2018-10-10 16:57:50.411927641 +0200
@@ -126,7 +126,6 @@ config NIOS2_CMDLINE_IGNORE_DTB
 
 config NIOS2_PASS_CMDLINE
bool "Passed kernel command line from u-boot"
-   default n
help
  Use bootargs env variable from u-boot for kernel command line.
  will override "Default kernel command string".
Index: b/arch/nios2/platform/Kconfig.platform
===
--- a/arch/nios2/platform/Kconfig.platform  2018-09-03 18:11:12.057792442 
+0200
+++ b/arch/nios2/platform/Kconfig.platform  2018-10-10 16:58:37.951928838 
+0200
@@ -17,7 +17,6 @@ comment "Device tree"
 
 config NIOS2_DTB_AT_PHYS_ADDR
bool "DTB at physical address"
-   default n
help
  When enabled you can select a physical address to load the dtb from.
  Normally this address is passed by a bootloader such as u-boot but
@@ -37,7 +36,6 @@ config NIOS2_DTB_PHYS_ADDR
 
 config NIOS2_DTB_SOURCE_BOOL
bool "Compile and link device tree into kernel image"
-   default n
help
  This allows you to specify a dts (device tree source) file
  which will be compiled and linked into the kernel image.
@@ -62,21 +60,18 @@ config NIOS2_ARCH_REVISION
 
 config NIOS2_HW_MUL_SUPPORT
bool "Enable MUL instruction"
-   default n
help
  Set to true if you configured the Nios II to include the MUL
  instruction.  This will enable the -mhw-mul compiler flag.
 
 config NIOS2_HW_MULX_SUPPORT
bool "Enable MULX instruction"
-   default n
help
  Set to true if you configured the Nios II to include the MULX
  instruction.  Enables the -mhw-mulx compiler flag.
 
 config NIOS2_HW_DIV_SUPPORT
bool "Enable DIV instruction"
-   default n
help
  Set to true if you configured the Nios II to include the DIV
  instruction.  Enables the -mhw-div compiler flag.
@@ -84,7 +79,6 @@ config NIOS2_HW_DIV_SUPPORT
 config NIOS2_BMX_SUPPORT
bool "Enable BMX instructions"
depends on NIOS2_ARCH_REVISION = 2
-   default n
help
  Set to true if you configured the Nios II R2 to include
  the BMX Bit Manipulation Extension instructions. Enables
@@ -93,7 +87,6 @@ config NIOS2_BMX_SUPPORT
 config NIOS2_CDX_SUPPORT
bool "Enable CDX instructions"
depends on NIOS2_ARCH_REVISION = 2
-   default n
help
  Set to true if you configured the Nios II R2 to include
  the CDX Bit Manipulation Extension instructions. Enables
@@ -101,13 +94,11 @@ config NIOS2_CDX_SUPPORT
 
 config NIOS2_FPU_SUPPORT
bool "Custom floating point instr support"
-   default n
help
  Enables the -mcustom-fpu-cfg=60-1 compiler flag.
 
 config NIOS2_CI_SWAB_SUPPORT
bool "Byteswap custom instruction"
-   default n
help
  Use the byteswap (endian converter) Nios II custom instruction 
provided
  by Altera and which can be enabled in QSYS builder. This accelerates

[PATCH] nios2: remove redundant 'default n' from Kconfig-s

2018-10-10 Thread Bartlomiej Zolnierkiewicz

'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.

Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or not:

...
One side effect of (and the main motivation for) this change is making
the following two definitions behave exactly the same:

config FOO
bool

config FOO
bool
default n

With this change, neither of these will generate a
'# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
That might make it clearer to people that a bare 'default n' is
redundant.
...

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 arch/nios2/Kconfig   |1 -
 arch/nios2/platform/Kconfig.platform |9 -
 2 files changed, 10 deletions(-)

Index: b/arch/nios2/Kconfig
===
--- a/arch/nios2/Kconfig2018-10-09 15:58:36.543122877 +0200
+++ b/arch/nios2/Kconfig2018-10-10 16:57:50.411927641 +0200
@@ -126,7 +126,6 @@ config NIOS2_CMDLINE_IGNORE_DTB
 
 config NIOS2_PASS_CMDLINE
bool "Passed kernel command line from u-boot"
-   default n
help
  Use bootargs env variable from u-boot for kernel command line.
  will override "Default kernel command string".
Index: b/arch/nios2/platform/Kconfig.platform
===
--- a/arch/nios2/platform/Kconfig.platform  2018-09-03 18:11:12.057792442 
+0200
+++ b/arch/nios2/platform/Kconfig.platform  2018-10-10 16:58:37.951928838 
+0200
@@ -17,7 +17,6 @@ comment "Device tree"
 
 config NIOS2_DTB_AT_PHYS_ADDR
bool "DTB at physical address"
-   default n
help
  When enabled you can select a physical address to load the dtb from.
  Normally this address is passed by a bootloader such as u-boot but
@@ -37,7 +36,6 @@ config NIOS2_DTB_PHYS_ADDR
 
 config NIOS2_DTB_SOURCE_BOOL
bool "Compile and link device tree into kernel image"
-   default n
help
  This allows you to specify a dts (device tree source) file
  which will be compiled and linked into the kernel image.
@@ -62,21 +60,18 @@ config NIOS2_ARCH_REVISION
 
 config NIOS2_HW_MUL_SUPPORT
bool "Enable MUL instruction"
-   default n
help
  Set to true if you configured the Nios II to include the MUL
  instruction.  This will enable the -mhw-mul compiler flag.
 
 config NIOS2_HW_MULX_SUPPORT
bool "Enable MULX instruction"
-   default n
help
  Set to true if you configured the Nios II to include the MULX
  instruction.  Enables the -mhw-mulx compiler flag.
 
 config NIOS2_HW_DIV_SUPPORT
bool "Enable DIV instruction"
-   default n
help
  Set to true if you configured the Nios II to include the DIV
  instruction.  Enables the -mhw-div compiler flag.
@@ -84,7 +79,6 @@ config NIOS2_HW_DIV_SUPPORT
 config NIOS2_BMX_SUPPORT
bool "Enable BMX instructions"
depends on NIOS2_ARCH_REVISION = 2
-   default n
help
  Set to true if you configured the Nios II R2 to include
  the BMX Bit Manipulation Extension instructions. Enables
@@ -93,7 +87,6 @@ config NIOS2_BMX_SUPPORT
 config NIOS2_CDX_SUPPORT
bool "Enable CDX instructions"
depends on NIOS2_ARCH_REVISION = 2
-   default n
help
  Set to true if you configured the Nios II R2 to include
  the CDX Bit Manipulation Extension instructions. Enables
@@ -101,13 +94,11 @@ config NIOS2_CDX_SUPPORT
 
 config NIOS2_FPU_SUPPORT
bool "Custom floating point instr support"
-   default n
help
  Enables the -mcustom-fpu-cfg=60-1 compiler flag.
 
 config NIOS2_CI_SWAB_SUPPORT
bool "Byteswap custom instruction"
-   default n
help
  Use the byteswap (endian converter) Nios II custom instruction 
provided
  by Altera and which can be enabled in QSYS builder. This accelerates

[PATCH] mfd: remove redundant 'default n' from Kconfig

2018-10-10 Thread Bartlomiej Zolnierkiewicz

'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.

Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or not:

...
One side effect of (and the main motivation for) this change is making
the following two definitions behave exactly the same:

config FOO
bool

config FOO
bool
default n

With this change, neither of these will generate a
'# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
That might make it clearer to people that a bare 'default n' is
redundant.
...

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/mfd/Kconfig |6 --
 1 file changed, 6 deletions(-)

Index: b/drivers/mfd/Kconfig
===
--- a/drivers/mfd/Kconfig   2018-10-09 15:58:40.547122978 +0200
+++ b/drivers/mfd/Kconfig   2018-10-10 16:49:37.575915230 +0200
@@ -8,7 +8,6 @@ menu "Multifunction device drivers"
 config MFD_CORE
tristate
select IRQ_DOMAIN
-   default n
 
 config MFD_CS5535
tristate "AMD CS5535 and CS5536 southbridge core functions"
@@ -870,7 +869,6 @@ config MFD_VIPERBOARD
 tristate "Nano River Technologies Viperboard"
select MFD_CORE
depends on USB
-   default n
help
  Say yes here if you want support for Nano River Technologies
  Viperboard.
@@ -1575,7 +1573,6 @@ config MFD_TWL4030_AUDIO
bool "TI TWL4030 Audio"
depends on TWL4030_CORE
select MFD_CORE
-   default n
 
 config TWL6040_CORE
bool "TI TWL6040 audio codec"
@@ -1583,7 +1580,6 @@ config TWL6040_CORE
select MFD_CORE
select REGMAP_I2C
select REGMAP_IRQ
-   default n
help
  Say yes here if you want support for Texas Instruments TWL6040 audio
  codec.
@@ -1605,7 +1601,6 @@ config MFD_WL1273_CORE
tristate "TI WL1273 FM radio"
depends on I2C
select MFD_CORE
-   default n
help
  This is the core driver for the TI WL1273 FM radio. This MFD
  driver connects the radio-wl1273 V4L2 module and the wl1273
@@ -1649,7 +1644,6 @@ config MFD_TC3589X
 
 config MFD_TMIO
bool
-   default n
 
 config MFD_T7L66XB
bool "Toshiba T7L66XB"

[PATCH] mfd: remove redundant 'default n' from Kconfig

2018-10-10 Thread Bartlomiej Zolnierkiewicz

'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.

Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or not:

...
One side effect of (and the main motivation for) this change is making
the following two definitions behave exactly the same:

config FOO
bool

config FOO
bool
default n

With this change, neither of these will generate a
'# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
That might make it clearer to people that a bare 'default n' is
redundant.
...

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/mfd/Kconfig |6 --
 1 file changed, 6 deletions(-)

Index: b/drivers/mfd/Kconfig
===
--- a/drivers/mfd/Kconfig   2018-10-09 15:58:40.547122978 +0200
+++ b/drivers/mfd/Kconfig   2018-10-10 16:49:37.575915230 +0200
@@ -8,7 +8,6 @@ menu "Multifunction device drivers"
 config MFD_CORE
tristate
select IRQ_DOMAIN
-   default n
 
 config MFD_CS5535
tristate "AMD CS5535 and CS5536 southbridge core functions"
@@ -870,7 +869,6 @@ config MFD_VIPERBOARD
 tristate "Nano River Technologies Viperboard"
select MFD_CORE
depends on USB
-   default n
help
  Say yes here if you want support for Nano River Technologies
  Viperboard.
@@ -1575,7 +1573,6 @@ config MFD_TWL4030_AUDIO
bool "TI TWL4030 Audio"
depends on TWL4030_CORE
select MFD_CORE
-   default n
 
 config TWL6040_CORE
bool "TI TWL6040 audio codec"
@@ -1583,7 +1580,6 @@ config TWL6040_CORE
select MFD_CORE
select REGMAP_I2C
select REGMAP_IRQ
-   default n
help
  Say yes here if you want support for Texas Instruments TWL6040 audio
  codec.
@@ -1605,7 +1601,6 @@ config MFD_WL1273_CORE
tristate "TI WL1273 FM radio"
depends on I2C
select MFD_CORE
-   default n
help
  This is the core driver for the TI WL1273 FM radio. This MFD
  driver connects the radio-wl1273 V4L2 module and the wl1273
@@ -1649,7 +1644,6 @@ config MFD_TC3589X
 
 config MFD_TMIO
bool
-   default n
 
 config MFD_T7L66XB
bool "Toshiba T7L66XB"

[PATCH] ACPI: remove redundant 'default n' from Kconfig

2018-10-10 Thread Bartlomiej Zolnierkiewicz

'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.

Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or not:

...
One side effect of (and the main motivation for) this change is making
the following two definitions behave exactly the same:

config FOO
bool

config FOO
bool
default n

With this change, neither of these will generate a
'# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
That might make it clearer to people that a bare 'default n' is
redundant.
...

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/acpi/Kconfig |6 --
 1 file changed, 6 deletions(-)

Index: b/drivers/acpi/Kconfig
===
--- a/drivers/acpi/Kconfig  2018-09-26 15:54:31.942819766 +0200
+++ b/drivers/acpi/Kconfig  2018-10-10 16:38:09.691897907 +0200
@@ -138,7 +138,6 @@ config ACPI_REV_OVERRIDE_POSSIBLE
 
 config ACPI_EC_DEBUGFS
tristate "EC read/write access through /sys/kernel/debug/ec"
-   default n
help
  Say N to disable Embedded Controller /sys/kernel/debug interface
 
@@ -283,7 +282,6 @@ config ACPI_PROCESSOR
 config ACPI_IPMI
tristate "IPMI"
depends on IPMI_HANDLER
-   default n
help
  This driver enables the ACPI to access the BMC controller. And it
  uses the IPMI request/response message to communicate with BMC
@@ -361,7 +359,6 @@ config ACPI_TABLE_UPGRADE
 
 config ACPI_DEBUG
bool "Debug Statements"
-   default n
help
  The ACPI subsystem can produce debug output.  Saying Y enables this
  output and increases the kernel size by around 50K.
@@ -374,7 +371,6 @@ config ACPI_DEBUG
 config ACPI_PCI_SLOT
bool "PCI slot detection driver"
depends on SYSFS
-   default n
help
  This driver creates entries in /sys/bus/pci/slots/ for all PCI
  slots in the system.  This can help correlate PCI bus addresses,
@@ -436,7 +432,6 @@ config ACPI_HED
 config ACPI_CUSTOM_METHOD
tristate "Allow ACPI methods to be inserted/replaced at run time"
depends on DEBUG_FS
-   default n
help
  This debug facility allows ACPI AML methods to be inserted and/or
  replaced without rebooting the system. For details refer to:
@@ -481,7 +476,6 @@ config ACPI_EXTLOG
tristate "Extended Error Log support"
depends on X86_MCE && X86_LOCAL_APIC && EDAC
select UEFI_CPER
-   default n
help
  Certain usages such as Predictive Failure Analysis (PFA) require
  more information about the error than what can be described in

[PATCH] ACPI: remove redundant 'default n' from Kconfig

2018-10-10 Thread Bartlomiej Zolnierkiewicz

'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.

Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or not:

...
One side effect of (and the main motivation for) this change is making
the following two definitions behave exactly the same:

config FOO
bool

config FOO
bool
default n

With this change, neither of these will generate a
'# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
That might make it clearer to people that a bare 'default n' is
redundant.
...

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/acpi/Kconfig |6 --
 1 file changed, 6 deletions(-)

Index: b/drivers/acpi/Kconfig
===
--- a/drivers/acpi/Kconfig  2018-09-26 15:54:31.942819766 +0200
+++ b/drivers/acpi/Kconfig  2018-10-10 16:38:09.691897907 +0200
@@ -138,7 +138,6 @@ config ACPI_REV_OVERRIDE_POSSIBLE
 
 config ACPI_EC_DEBUGFS
tristate "EC read/write access through /sys/kernel/debug/ec"
-   default n
help
  Say N to disable Embedded Controller /sys/kernel/debug interface
 
@@ -283,7 +282,6 @@ config ACPI_PROCESSOR
 config ACPI_IPMI
tristate "IPMI"
depends on IPMI_HANDLER
-   default n
help
  This driver enables the ACPI to access the BMC controller. And it
  uses the IPMI request/response message to communicate with BMC
@@ -361,7 +359,6 @@ config ACPI_TABLE_UPGRADE
 
 config ACPI_DEBUG
bool "Debug Statements"
-   default n
help
  The ACPI subsystem can produce debug output.  Saying Y enables this
  output and increases the kernel size by around 50K.
@@ -374,7 +371,6 @@ config ACPI_DEBUG
 config ACPI_PCI_SLOT
bool "PCI slot detection driver"
depends on SYSFS
-   default n
help
  This driver creates entries in /sys/bus/pci/slots/ for all PCI
  slots in the system.  This can help correlate PCI bus addresses,
@@ -436,7 +432,6 @@ config ACPI_HED
 config ACPI_CUSTOM_METHOD
tristate "Allow ACPI methods to be inserted/replaced at run time"
depends on DEBUG_FS
-   default n
help
  This debug facility allows ACPI AML methods to be inserted and/or
  replaced without rebooting the system. For details refer to:
@@ -481,7 +476,6 @@ config ACPI_EXTLOG
tristate "Extended Error Log support"
depends on X86_MCE && X86_LOCAL_APIC && EDAC
select UEFI_CPER
-   default n
help
  Certain usages such as Predictive Failure Analysis (PFA) require
  more information about the error than what can be described in

[PATCH] ata: remove redundant 'default n' from Kconfig

2018-10-09 Thread Bartlomiej Zolnierkiewicz

'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.

Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or not:

...
One side effect of (and the main motivation for) this change is making
the following two definitions behave exactly the same:

config FOO
bool

config FOO
bool
default n

With this change, neither of these will generate a
'# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
That might make it clearer to people that a bare 'default n' is
redundant.
...

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/ata/Kconfig |2 --
 1 file changed, 2 deletions(-)

Index: b/drivers/ata/Kconfig
===
--- a/drivers/ata/Kconfig   2018-10-09 15:58:37.319122897 +0200
+++ b/drivers/ata/Kconfig   2018-10-09 16:43:07.823190149 +0200
@@ -33,7 +33,6 @@ if ATA
 
 config ATA_NONSTANDARD
bool
-   default n
 
 config ATA_VERBOSE_ERROR
bool "Verbose ATA error reporting"
@@ -62,7 +61,6 @@ config ATA_ACPI
 config SATA_ZPODD
bool "SATA Zero Power Optical Disc Drive (ZPODD) support"
depends on ATA_ACPI && PM
-   default n
help
  This option adds support for SATA Zero Power Optical Disc
  Drive (ZPODD). It requires both the ODD and the platform

[PATCH] ata: remove redundant 'default n' from Kconfig

2018-10-09 Thread Bartlomiej Zolnierkiewicz

'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.

Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or not:

...
One side effect of (and the main motivation for) this change is making
the following two definitions behave exactly the same:

config FOO
bool

config FOO
bool
default n

With this change, neither of these will generate a
'# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
That might make it clearer to people that a bare 'default n' is
redundant.
...

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/ata/Kconfig |2 --
 1 file changed, 2 deletions(-)

Index: b/drivers/ata/Kconfig
===
--- a/drivers/ata/Kconfig   2018-10-09 15:58:37.319122897 +0200
+++ b/drivers/ata/Kconfig   2018-10-09 16:43:07.823190149 +0200
@@ -33,7 +33,6 @@ if ATA
 
 config ATA_NONSTANDARD
bool
-   default n
 
 config ATA_VERBOSE_ERROR
bool "Verbose ATA error reporting"
@@ -62,7 +61,6 @@ config ATA_ACPI
 config SATA_ZPODD
bool "SATA Zero Power Optical Disc Drive (ZPODD) support"
depends on ATA_ACPI && PM
-   default n
help
  This option adds support for SATA Zero Power Optical Disc
  Drive (ZPODD). It requires both the ODD and the platform

Re: [RESEND PATCH v2 3/3] ARM: dts: imx28-cfa10036: Fix the reset gpio signal polarity

2018-10-09 Thread Bartlomiej Zolnierkiewicz



On 10/09/2018 03:18 PM, Vokáč Michal wrote:
> On 9.10.2018 14:36, Fabio Estevam wrote:
>> Hi Michal,
>>
>> On Tue, Oct 9, 2018 at 5:30 AM Vokáč Michal  wrote:
>>
>>> Sorry for the inconvenience :( Lesson learned..
>>>
>>> So in other words (no offense): broken drivers need to stay broken because
>>> users may already get used to the broken behavior?
>>
>> In order to keep the old dtb's working you could introduce a new
>> property (like reset-gpio-active-low, for example).
>>
>> Then the driver behavior can be made untouched for the old dtb's and
>> only new dtb's with this new property would have the correct GPIO
>> reset behavior.
> 
> Thank you very much Fabio!
> I saw these xxx-active-low/high properties in many device tree
> sources wondering why the heck people use them when they could
> use GPIO_ACTIVE_LOW/HIGH. And this is the explanation.
> 
> And I feel like an idiot once again: git grep -l "reset-active-low"
> first hit is:
> 
>   Documentation/devicetree/bindings/display/ssd1307fb.txt
> 
> Oooops.
> The weird thing is that usage of reset-active-low is documented
> in the example but it is not implemented.
> 
> So the patch no.2 should be reverted and patch no.3 not applied at all.

OK, I've applied the patch below to fbdev-for-next tree.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics


>From 64f83a816b27c7b5e026a74ecb5c61dbabfae997 Mon Sep 17 00:00:00 2001
From: Bartlomiej Zolnierkiewicz 
Date: Tue, 9 Oct 2018 15:18:42 +0200
Subject: [PATCH] Revert "video: ssd1307fb: Do not hard code active-low reset
 sequence"

This reverts commit 9827f26374fb85e1811f2adbcc25c8a3992dbe7f.

On 10/09/2018 02:20 AM, Shawn Guo wrote:

> Well, it means the change breaks the ABI between kernel and device tree,
> e.g. the new kernel will not work with existing/installed DTBs.

Revert the change until DTB compatibility issue is resolved.

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/video/fbdev/ssd1307fb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 3b361bc..4061a20 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -667,10 +667,10 @@ static int ssd1307fb_probe(struct i2c_client *client,
 
if (par->reset) {
/* Reset the screen */
-   gpiod_set_value_cansleep(par->reset, 1);
-   udelay(4);
gpiod_set_value_cansleep(par->reset, 0);
udelay(4);
+   gpiod_set_value_cansleep(par->reset, 1);
+   udelay(4);
}
 
if (par->vbat_reg) {
-- 
1.9.1

Re: [RESEND PATCH v2 3/3] ARM: dts: imx28-cfa10036: Fix the reset gpio signal polarity

2018-10-09 Thread Bartlomiej Zolnierkiewicz



On 10/09/2018 03:18 PM, Vokáč Michal wrote:
> On 9.10.2018 14:36, Fabio Estevam wrote:
>> Hi Michal,
>>
>> On Tue, Oct 9, 2018 at 5:30 AM Vokáč Michal  wrote:
>>
>>> Sorry for the inconvenience :( Lesson learned..
>>>
>>> So in other words (no offense): broken drivers need to stay broken because
>>> users may already get used to the broken behavior?
>>
>> In order to keep the old dtb's working you could introduce a new
>> property (like reset-gpio-active-low, for example).
>>
>> Then the driver behavior can be made untouched for the old dtb's and
>> only new dtb's with this new property would have the correct GPIO
>> reset behavior.
> 
> Thank you very much Fabio!
> I saw these xxx-active-low/high properties in many device tree
> sources wondering why the heck people use them when they could
> use GPIO_ACTIVE_LOW/HIGH. And this is the explanation.
> 
> And I feel like an idiot once again: git grep -l "reset-active-low"
> first hit is:
> 
>   Documentation/devicetree/bindings/display/ssd1307fb.txt
> 
> Oooops.
> The weird thing is that usage of reset-active-low is documented
> in the example but it is not implemented.
> 
> So the patch no.2 should be reverted and patch no.3 not applied at all.

OK, I've applied the patch below to fbdev-for-next tree.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics


>From 64f83a816b27c7b5e026a74ecb5c61dbabfae997 Mon Sep 17 00:00:00 2001
From: Bartlomiej Zolnierkiewicz 
Date: Tue, 9 Oct 2018 15:18:42 +0200
Subject: [PATCH] Revert "video: ssd1307fb: Do not hard code active-low reset
 sequence"

This reverts commit 9827f26374fb85e1811f2adbcc25c8a3992dbe7f.

On 10/09/2018 02:20 AM, Shawn Guo wrote:

> Well, it means the change breaks the ABI between kernel and device tree,
> e.g. the new kernel will not work with existing/installed DTBs.

Revert the change until DTB compatibility issue is resolved.

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/video/fbdev/ssd1307fb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 3b361bc..4061a20 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -667,10 +667,10 @@ static int ssd1307fb_probe(struct i2c_client *client,
 
if (par->reset) {
/* Reset the screen */
-   gpiod_set_value_cansleep(par->reset, 1);
-   udelay(4);
gpiod_set_value_cansleep(par->reset, 0);
udelay(4);
+   gpiod_set_value_cansleep(par->reset, 1);
+   udelay(4);
}
 
if (par->vbat_reg) {
-- 
1.9.1

Re: [RESEND PATCH v2 3/3] ARM: dts: imx28-cfa10036: Fix the reset gpio signal polarity

2018-10-09 Thread Bartlomiej Zolnierkiewicz



On 10/09/2018 02:20 AM, Shawn Guo wrote:
> On Mon, Oct 08, 2018 at 11:45:36AM +, Vokáč Michal wrote:
>> On 27.9.2018 11:24, Michal Vokáč wrote:
>>> The reset signal of the SSD1306 OLED display is actually active-low.
>>> Adapt the DT to reflect the real world.
>>>
>>> Signed-off-by: Michal Vokáč 
>>> ---
>>> v2 changes: New patch in the series
>>
>> Bartlomiej just queued the first two patches for v4.20.
>> Will somebody take this one? Otherwise this SoM will end up with
>> broken OLED display reset.
> 
> Well, it means the change breaks the ABI between kernel and device tree,
> e.g. the new kernel will not work with existing/installed DTBs.

Should I revert this sdd10307fb patch then?

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

Re: [RESEND PATCH v2 3/3] ARM: dts: imx28-cfa10036: Fix the reset gpio signal polarity

2018-10-09 Thread Bartlomiej Zolnierkiewicz



On 10/09/2018 02:20 AM, Shawn Guo wrote:
> On Mon, Oct 08, 2018 at 11:45:36AM +, Vokáč Michal wrote:
>> On 27.9.2018 11:24, Michal Vokáč wrote:
>>> The reset signal of the SSD1306 OLED display is actually active-low.
>>> Adapt the DT to reflect the real world.
>>>
>>> Signed-off-by: Michal Vokáč 
>>> ---
>>> v2 changes: New patch in the series
>>
>> Bartlomiej just queued the first two patches for v4.20.
>> Will somebody take this one? Otherwise this SoM will end up with
>> broken OLED display reset.
> 
> Well, it means the change breaks the ABI between kernel and device tree,
> e.g. the new kernel will not work with existing/installed DTBs.

Should I revert this sdd10307fb patch then?

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

Re: [RESEND PATCH v2 2/3] video: ssd1307fb: Do not hard code active-low reset sequence

2018-10-08 Thread Bartlomiej Zolnierkiewicz



On 09/27/2018 11:24 AM, Michal Vokáč wrote:
> The SSD130x OLED display reset signal is active low. Now the reset
> sequence is implemented in such a way that users are forced to
> define reset-gpios as GPIO_ACTIVE_HIGH in DT to make the reset work.
> 
> Do not hard code the active-low sequence into the driver but instead
> allow the user to specify the gpio as GPIO_ACTIVE_LOW to reflect
> the real world.
> 
> Signed-off-by: Michal Vokáč 

Patch queued for 4.20, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

Re: [RESEND PATCH v2 2/3] video: ssd1307fb: Do not hard code active-low reset sequence

2018-10-08 Thread Bartlomiej Zolnierkiewicz



On 09/27/2018 11:24 AM, Michal Vokáč wrote:
> The SSD130x OLED display reset signal is active low. Now the reset
> sequence is implemented in such a way that users are forced to
> define reset-gpios as GPIO_ACTIVE_HIGH in DT to make the reset work.
> 
> Do not hard code the active-low sequence into the driver but instead
> allow the user to specify the gpio as GPIO_ACTIVE_LOW to reflect
> the real world.
> 
> Signed-off-by: Michal Vokáč 

Patch queued for 4.20, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

Re: [RESEND PATCH v2 1/3] video: ssd1307fb: Use gpiod_set_value_cansleep() for reset

2018-10-08 Thread Bartlomiej Zolnierkiewicz



On 09/27/2018 11:24 AM, Michal Vokáč wrote:
> The reset signal can be produced by GPIO expander that can sleep.
> In that case the probe function fails. Allow using GPIO expanders for
> the reset signal by using the non-atomic gpiod_set_value_cansleep()
> function.
> 
> Signed-off-by: Michal Vokáč 
> Reviewed-by: Fabio Estevam 

Patch queued for 4.20, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

Re: [RESEND PATCH v2 1/3] video: ssd1307fb: Use gpiod_set_value_cansleep() for reset

2018-10-08 Thread Bartlomiej Zolnierkiewicz



On 09/27/2018 11:24 AM, Michal Vokáč wrote:
> The reset signal can be produced by GPIO expander that can sleep.
> In that case the probe function fails. Allow using GPIO expanders for
> the reset signal by using the non-atomic gpiod_set_value_cansleep()
> function.
> 
> Signed-off-by: Michal Vokáč 
> Reviewed-by: Fabio Estevam 

Patch queued for 4.20, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

Re: [PATCH v4] video: fbdev: omapfb: lcd_ams_delta: use GPIO lookup table

2018-10-08 Thread Bartlomiej Zolnierkiewicz



On 10/03/2018 03:03 PM, Janusz Krzysztofik wrote:
> Now as Amstrad Delta board - the only user of this driver - provides
> GPIO lookup tables, switch from GPIO numbers to GPIO descriptors and
> use the table to locate required GPIO pins.
> 
> Declare static variables for storing GPIO descriptors and replace
> gpio_ function calls with their gpiod_ equivalents. Move GPIO lookup
> to the driver probe function so device initialization can be deferred
> instead of aborted if a GPIO pin is not yet available.
> 
> Pin naming used by the driver should be followed while respective GPIO
> lookup table is initialized by a board init code.
> 
> Signed-off-by: Janusz Krzysztofik 
> Reviewed-by: Linus Walleij 

Patch queued for 4.20, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

Re: [PATCH v4] video: fbdev: omapfb: lcd_ams_delta: use GPIO lookup table

2018-10-08 Thread Bartlomiej Zolnierkiewicz



On 10/03/2018 03:03 PM, Janusz Krzysztofik wrote:
> Now as Amstrad Delta board - the only user of this driver - provides
> GPIO lookup tables, switch from GPIO numbers to GPIO descriptors and
> use the table to locate required GPIO pins.
> 
> Declare static variables for storing GPIO descriptors and replace
> gpio_ function calls with their gpiod_ equivalents. Move GPIO lookup
> to the driver probe function so device initialization can be deferred
> instead of aborted if a GPIO pin is not yet available.
> 
> Pin naming used by the driver should be followed while respective GPIO
> lookup table is initialized by a board init code.
> 
> Signed-off-by: Janusz Krzysztofik 
> Reviewed-by: Linus Walleij 

Patch queued for 4.20, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

Re: [PATCH] Video: vgastate: fixed a spacing coding style

2018-10-08 Thread Bartlomiej Zolnierkiewicz



On 08/24/2018 02:49 PM, Mehdi Bounya wrote:
> Removed a space between function name and open parant.
> 
> Signed-off-by: Mehdi Bounya 

Patch queued for 4.20, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

Re: [PATCH] Video: vgastate: fixed a spacing coding style

2018-10-08 Thread Bartlomiej Zolnierkiewicz



On 08/24/2018 02:49 PM, Mehdi Bounya wrote:
> Removed a space between function name and open parant.
> 
> Signed-off-by: Mehdi Bounya 

Patch queued for 4.20, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

Re: [PATCH] ata: ep93xx: Use proper enums for directions

2018-10-04 Thread Bartlomiej Zolnierkiewicz



On 10/04/2018 04:37 AM, Nathan Chancellor wrote:
> Clang warns when one enumerated type is implicitly converted to another.
> 
> drivers/ata/pata_ep93xx.c:662:36: warning: implicit conversion from
> enumeration type 'enum dma_data_direction' to different enumeration type
> 'enum dma_transfer_direction' [-Wenum-conversion]
> drv_data->dma_rx_data.direction = DMA_FROM_DEVICE;
> ~ ^~~
> drivers/ata/pata_ep93xx.c:670:36: warning: implicit conversion from
> enumeration type 'enum dma_data_direction' to different enumeration type
> 'enum dma_transfer_direction' [-Wenum-conversion]
> drv_data->dma_tx_data.direction = DMA_TO_DEVICE;
> ~ ^
> drivers/ata/pata_ep93xx.c:681:19: warning: implicit conversion from
> enumeration type 'enum dma_data_direction' to different enumeration type
> 'enum dma_transfer_direction' [-Wenum-conversion]
> conf.direction = DMA_FROM_DEVICE;
>~ ^~~
> drivers/ata/pata_ep93xx.c:692:19: warning: implicit conversion from
> enumeration type 'enum dma_data_direction' to different enumeration type
> 'enum dma_transfer_direction' [-Wenum-conversion]
> conf.direction = DMA_TO_DEVICE;
>~ ^
> 
> Use the equivalent valued enums from the expected type so that Clang no
> longer warns about a conversion.
> 
> DMA_TO_DEVICE = DMA_MEM_TO_DEV = 1
> DMA_FROM_DEVICE = DMA_DEV_TO_MEM = 2
> 
> Signed-off-by: Nathan Chancellor 

Acked-by: Bartlomiej Zolnierkiewicz 

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

Re: [PATCH] ata: ep93xx: Use proper enums for directions

2018-10-04 Thread Bartlomiej Zolnierkiewicz



On 10/04/2018 04:37 AM, Nathan Chancellor wrote:
> Clang warns when one enumerated type is implicitly converted to another.
> 
> drivers/ata/pata_ep93xx.c:662:36: warning: implicit conversion from
> enumeration type 'enum dma_data_direction' to different enumeration type
> 'enum dma_transfer_direction' [-Wenum-conversion]
> drv_data->dma_rx_data.direction = DMA_FROM_DEVICE;
> ~ ^~~
> drivers/ata/pata_ep93xx.c:670:36: warning: implicit conversion from
> enumeration type 'enum dma_data_direction' to different enumeration type
> 'enum dma_transfer_direction' [-Wenum-conversion]
> drv_data->dma_tx_data.direction = DMA_TO_DEVICE;
> ~ ^
> drivers/ata/pata_ep93xx.c:681:19: warning: implicit conversion from
> enumeration type 'enum dma_data_direction' to different enumeration type
> 'enum dma_transfer_direction' [-Wenum-conversion]
> conf.direction = DMA_FROM_DEVICE;
>~ ^~~
> drivers/ata/pata_ep93xx.c:692:19: warning: implicit conversion from
> enumeration type 'enum dma_data_direction' to different enumeration type
> 'enum dma_transfer_direction' [-Wenum-conversion]
> conf.direction = DMA_TO_DEVICE;
>~ ^
> 
> Use the equivalent valued enums from the expected type so that Clang no
> longer warns about a conversion.
> 
> DMA_TO_DEVICE = DMA_MEM_TO_DEV = 1
> DMA_FROM_DEVICE = DMA_DEV_TO_MEM = 2
> 
> Signed-off-by: Nathan Chancellor 

Acked-by: Bartlomiej Zolnierkiewicz 

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

[GIT PULL] fbdev fixes for v4.19-rc7

2018-10-02 Thread Bartlomiej Zolnierkiewicz

Hi Greg,

Please pull fbdev fixes for v4.19-rc7 (please see the signed tag
description for details).

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics


The following changes since commit 6bf4ca7fbc85d80446ac01c0d1d77db4d91a6d84:

  Linux 4.19-rc5 (2018-09-23 19:15:18 +0200)

are available in the git repository at:

  https://github.com/bzolnier/linux.git tags/fbdev-v4.19-rc7

for you to fetch changes up to 7c968791f7753bf0e52a21729498509ea3dd751b:

  video/fbdev/stifb: Fix spelling mistake in fall-through annotation 
(2018-09-26 18:50:54 +0200)


fbdev fixes for v4.19-rc7:

- fix OMAPFB_MEMORY_READ ioctl to not leak kernel memory in omapfb driver
  (Tomi Valkeinen)

- add missing prepare/unprepare clock operations in pxa168fb driver
  (Lubomir Rintel)

- add nobgrt option in efifb driver to disable ACPI BGRT logo restore
  (Hans de Goede)

- fix spelling mistake in fall-through annotation in stifb driver
  (Gustavo A. R. Silva)

- fix URL for uvesafb repository in the documentation (Adam Jackson)


Adam Jackson (1):
  uvesafb: Fix URLs in the documentation

Bartlomiej Zolnierkiewicz (1):
  Merge tag 'v4.19-rc5' of https://git.kernel.org/.../torvalds/linux into 
fbdev-for-next

Gustavo A. R. Silva (1):
  video/fbdev/stifb: Fix spelling mistake in fall-through annotation

Hans de Goede (1):
  efifb: BGRT: Add nobgrt option

Lubomir Rintel (1):
  pxa168fb: prepare the clock

Tomi Valkeinen (1):
  fbdev/omapfb: fix omapfb_memory_read infoleak

 Documentation/fb/uvesafb.txt| 5 +++--
 MAINTAINERS | 2 +-
 drivers/video/fbdev/efifb.c | 6 ++
 drivers/video/fbdev/omap2/omapfb/omapfb-ioctl.c | 5 -
 drivers/video/fbdev/pxa168fb.c  | 6 +++---
 drivers/video/fbdev/stifb.c | 2 +-
 6 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/Documentation/fb/uvesafb.txt b/Documentation/fb/uvesafb.txt
index f6362d8..aa92419 100644
--- a/Documentation/fb/uvesafb.txt
+++ b/Documentation/fb/uvesafb.txt
@@ -15,7 +15,8 @@ than x86.  Check the v86d documentation for a list of 
currently supported
 arches.
 
 v86d source code can be downloaded from the following website:
-  http://dev.gentoo.org/~spock/projects/uvesafb
+
+  https://github.com/mjanusz/v86d
 
 Please refer to the v86d documentation for detailed configuration and
 installation instructions.
@@ -177,7 +178,7 @@ from the Video BIOS if you set pixclock to 0 in 
fb_var_screeninfo.
 
 --
  Michal Januszewski 
- Last updated: 2009-03-30
+ Last updated: 2017-10-10
 
  Documentation of the uvesafb options is loosely based on vesafb.txt.
 
diff --git a/MAINTAINERS b/MAINTAINERS
index 02a3961..97e565f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15389,7 +15389,7 @@ S:  Maintained
 UVESAFB DRIVER
 M: Michal Januszewski 
 L: linux-fb...@vger.kernel.org
-W: http://dev.gentoo.org/~spock/projects/uvesafb/
+W: https://github.com/mjanusz/v86d
 S: Maintained
 F: Documentation/fb/uvesafb.txt
 F: drivers/video/fbdev/uvesafb.*
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 3946649..ba906876 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -42,6 +42,7 @@ struct bmp_dib_header {
u32 colors_important;
 } __packed;
 
+static bool use_bgrt = true;
 static bool request_mem_succeeded = false;
 static u64 mem_flags = EFI_MEMORY_WC | EFI_MEMORY_UC;
 
@@ -160,6 +161,9 @@ static void efifb_show_boot_graphics(struct fb_info *info)
void *bgrt_image = NULL;
u8 *dst = info->screen_base;
 
+   if (!use_bgrt)
+   return;
+
if (!bgrt_tab.image_address) {
pr_info("efifb: No BGRT, not showing boot graphics\n");
return;
@@ -290,6 +294,8 @@ static int efifb_setup(char *options)
screen_info.lfb_width = 
simple_strtoul(this_opt+6, NULL, 0);
else if (!strcmp(this_opt, "nowc"))
mem_flags &= ~EFI_MEMORY_WC;
+   else if (!strcmp(this_opt, "nobgrt"))
+   use_bgrt = false;
}
}
 
diff --git a/drivers/video/fbdev/omap2/omapfb/omapfb-ioctl.c 
b/drivers/video/fbdev/omap2/omapfb/omapfb-ioctl.c
index ef69273..a3edb20 100644
--- a/drivers/video/fbdev/omap2/omapfb/omapfb-ioctl.c
+++ b/drivers/video/fbdev/omap2/omapfb/omapfb-ioctl.c
@@ -496,6 +496,9 @@ static int omapfb_memory_read(struct fb_info *fbi,
if (!access_ok(VERIFY_WRITE, mr->buffer, mr->buffer_size))
return -EFAULT;
 
+   if (mr->w > 4096 || mr->h > 4096)
+   return -EINVAL;
+
if (mr->w * mr->h * 3 > mr->buffer

[GIT PULL] fbdev fixes for v4.19-rc7

2018-10-02 Thread Bartlomiej Zolnierkiewicz

Hi Greg,

Please pull fbdev fixes for v4.19-rc7 (please see the signed tag
description for details).

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics


The following changes since commit 6bf4ca7fbc85d80446ac01c0d1d77db4d91a6d84:

  Linux 4.19-rc5 (2018-09-23 19:15:18 +0200)

are available in the git repository at:

  https://github.com/bzolnier/linux.git tags/fbdev-v4.19-rc7

for you to fetch changes up to 7c968791f7753bf0e52a21729498509ea3dd751b:

  video/fbdev/stifb: Fix spelling mistake in fall-through annotation 
(2018-09-26 18:50:54 +0200)


fbdev fixes for v4.19-rc7:

- fix OMAPFB_MEMORY_READ ioctl to not leak kernel memory in omapfb driver
  (Tomi Valkeinen)

- add missing prepare/unprepare clock operations in pxa168fb driver
  (Lubomir Rintel)

- add nobgrt option in efifb driver to disable ACPI BGRT logo restore
  (Hans de Goede)

- fix spelling mistake in fall-through annotation in stifb driver
  (Gustavo A. R. Silva)

- fix URL for uvesafb repository in the documentation (Adam Jackson)


Adam Jackson (1):
  uvesafb: Fix URLs in the documentation

Bartlomiej Zolnierkiewicz (1):
  Merge tag 'v4.19-rc5' of https://git.kernel.org/.../torvalds/linux into 
fbdev-for-next

Gustavo A. R. Silva (1):
  video/fbdev/stifb: Fix spelling mistake in fall-through annotation

Hans de Goede (1):
  efifb: BGRT: Add nobgrt option

Lubomir Rintel (1):
  pxa168fb: prepare the clock

Tomi Valkeinen (1):
  fbdev/omapfb: fix omapfb_memory_read infoleak

 Documentation/fb/uvesafb.txt| 5 +++--
 MAINTAINERS | 2 +-
 drivers/video/fbdev/efifb.c | 6 ++
 drivers/video/fbdev/omap2/omapfb/omapfb-ioctl.c | 5 -
 drivers/video/fbdev/pxa168fb.c  | 6 +++---
 drivers/video/fbdev/stifb.c | 2 +-
 6 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/Documentation/fb/uvesafb.txt b/Documentation/fb/uvesafb.txt
index f6362d8..aa92419 100644
--- a/Documentation/fb/uvesafb.txt
+++ b/Documentation/fb/uvesafb.txt
@@ -15,7 +15,8 @@ than x86.  Check the v86d documentation for a list of 
currently supported
 arches.
 
 v86d source code can be downloaded from the following website:
-  http://dev.gentoo.org/~spock/projects/uvesafb
+
+  https://github.com/mjanusz/v86d
 
 Please refer to the v86d documentation for detailed configuration and
 installation instructions.
@@ -177,7 +178,7 @@ from the Video BIOS if you set pixclock to 0 in 
fb_var_screeninfo.
 
 --
  Michal Januszewski 
- Last updated: 2009-03-30
+ Last updated: 2017-10-10
 
  Documentation of the uvesafb options is loosely based on vesafb.txt.
 
diff --git a/MAINTAINERS b/MAINTAINERS
index 02a3961..97e565f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15389,7 +15389,7 @@ S:  Maintained
 UVESAFB DRIVER
 M: Michal Januszewski 
 L: linux-fb...@vger.kernel.org
-W: http://dev.gentoo.org/~spock/projects/uvesafb/
+W: https://github.com/mjanusz/v86d
 S: Maintained
 F: Documentation/fb/uvesafb.txt
 F: drivers/video/fbdev/uvesafb.*
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 3946649..ba906876 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -42,6 +42,7 @@ struct bmp_dib_header {
u32 colors_important;
 } __packed;
 
+static bool use_bgrt = true;
 static bool request_mem_succeeded = false;
 static u64 mem_flags = EFI_MEMORY_WC | EFI_MEMORY_UC;
 
@@ -160,6 +161,9 @@ static void efifb_show_boot_graphics(struct fb_info *info)
void *bgrt_image = NULL;
u8 *dst = info->screen_base;
 
+   if (!use_bgrt)
+   return;
+
if (!bgrt_tab.image_address) {
pr_info("efifb: No BGRT, not showing boot graphics\n");
return;
@@ -290,6 +294,8 @@ static int efifb_setup(char *options)
screen_info.lfb_width = 
simple_strtoul(this_opt+6, NULL, 0);
else if (!strcmp(this_opt, "nowc"))
mem_flags &= ~EFI_MEMORY_WC;
+   else if (!strcmp(this_opt, "nobgrt"))
+   use_bgrt = false;
}
}
 
diff --git a/drivers/video/fbdev/omap2/omapfb/omapfb-ioctl.c 
b/drivers/video/fbdev/omap2/omapfb/omapfb-ioctl.c
index ef69273..a3edb20 100644
--- a/drivers/video/fbdev/omap2/omapfb/omapfb-ioctl.c
+++ b/drivers/video/fbdev/omap2/omapfb/omapfb-ioctl.c
@@ -496,6 +496,9 @@ static int omapfb_memory_read(struct fb_info *fbi,
if (!access_ok(VERIFY_WRITE, mr->buffer, mr->buffer_size))
return -EFAULT;
 
+   if (mr->w > 4096 || mr->h > 4096)
+   return -EINVAL;
+
if (mr->w * mr->h * 3 > mr->buffer

Re: [PATCH] ARM: SAMSUNG: limit SAMSUNG_PM_DEBUG config option to non-Exynos platforms

2018-09-28 Thread Bartlomiej Zolnierkiewicz

On 09/28/2018 03:54 PM, Krzysztof Kozlowski wrote:
> On Fri, 28 Sep 2018 at 15:37, Bartlomiej Zolnierkiewicz
>  wrote:
>>
>> "Samsung PM Suspend debug" feature (controlled by SAMSUNG_PM_DEBUG
>> config option) is not working properly (debug messages are not
>> displayed after resume) on Exynos platforms because GPIOs restore
>> code is not implemented.
> 
> AFAIR, it worked properly for the suspend part showing more logs.
> Unless it changed, the feature looks still useful.

Yes, it shows few additional messages from mach/plat specific suspend
code but it breaks the assumption that features (even debug ones)
work correctly and make you invest time in debugging known broken
code.

In case it is needed/useful (which should be rather rare situation)
one can always easily revert the commit locally.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

Re: [PATCH] ARM: SAMSUNG: limit SAMSUNG_PM_DEBUG config option to non-Exynos platforms

2018-09-28 Thread Bartlomiej Zolnierkiewicz

On 09/28/2018 03:54 PM, Krzysztof Kozlowski wrote:
> On Fri, 28 Sep 2018 at 15:37, Bartlomiej Zolnierkiewicz
>  wrote:
>>
>> "Samsung PM Suspend debug" feature (controlled by SAMSUNG_PM_DEBUG
>> config option) is not working properly (debug messages are not
>> displayed after resume) on Exynos platforms because GPIOs restore
>> code is not implemented.
> 
> AFAIR, it worked properly for the suspend part showing more logs.
> Unless it changed, the feature looks still useful.

Yes, it shows few additional messages from mach/plat specific suspend
code but it breaks the assumption that features (even debug ones)
work correctly and make you invest time in debugging known broken
code.

In case it is needed/useful (which should be rather rare situation)
one can always easily revert the commit locally.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

[PATCH] ARM: SAMSUNG: limit SAMSUNG_PM_DEBUG config option to non-Exynos platforms

2018-09-28 Thread Bartlomiej Zolnierkiewicz

"Samsung PM Suspend debug" feature (controlled by SAMSUNG_PM_DEBUG
config option) is not working properly (debug messages are not
displayed after resume) on Exynos platforms because GPIOs restore
code is not implemented.

Add PLAT_S3C24XX, ARCH_S3C64XX and ARCH_S5PV210 dependencies to
SAMSUNG_PM_DEBUG config option to hide it on Exynos platforms.

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 arch/arm/plat-samsung/Kconfig |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Index: b/arch/arm/plat-samsung/Kconfig
===
--- a/arch/arm/plat-samsung/Kconfig 2018-09-28 15:20:06.041911426 +0200
+++ b/arch/arm/plat-samsung/Kconfig 2018-09-28 15:20:06.037911426 +0200
@@ -238,7 +238,8 @@ comment "Power management"
 
 config SAMSUNG_PM_DEBUG
bool "Samsung PM Suspend debug"
-   depends on PM && DEBUG_KERNEL
+   depends on DEBUG_KERNEL
+   depends on PM && (PLAT_S3C24XX || ARCH_S3C64XX || ARCH_S5PV210)
depends on DEBUG_EXYNOS_UART || DEBUG_S3C24XX_UART || DEBUG_S3C2410_UART
help
  Say Y here if you want verbose debugging from the PM Suspend and

[PATCH] ARM: SAMSUNG: limit SAMSUNG_PM_DEBUG config option to non-Exynos platforms

2018-09-28 Thread Bartlomiej Zolnierkiewicz

"Samsung PM Suspend debug" feature (controlled by SAMSUNG_PM_DEBUG
config option) is not working properly (debug messages are not
displayed after resume) on Exynos platforms because GPIOs restore
code is not implemented.

Add PLAT_S3C24XX, ARCH_S3C64XX and ARCH_S5PV210 dependencies to
SAMSUNG_PM_DEBUG config option to hide it on Exynos platforms.

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 arch/arm/plat-samsung/Kconfig |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Index: b/arch/arm/plat-samsung/Kconfig
===
--- a/arch/arm/plat-samsung/Kconfig 2018-09-28 15:20:06.041911426 +0200
+++ b/arch/arm/plat-samsung/Kconfig 2018-09-28 15:20:06.037911426 +0200
@@ -238,7 +238,8 @@ comment "Power management"
 
 config SAMSUNG_PM_DEBUG
bool "Samsung PM Suspend debug"
-   depends on PM && DEBUG_KERNEL
+   depends on DEBUG_KERNEL
+   depends on PM && (PLAT_S3C24XX || ARCH_S3C64XX || ARCH_S5PV210)
depends on DEBUG_EXYNOS_UART || DEBUG_S3C24XX_UART || DEBUG_S3C2410_UART
help
  Say Y here if you want verbose debugging from the PM Suspend and

[PATCH] ARM: SAMSUNG: limit SAMSUNG_PM_CHECK config option to non-Exynos platforms

2018-09-28 Thread Bartlomiej Zolnierkiewicz

"S3C2410 PM Suspend Memory CRC" feature (controlled by
SAMSUNG_PM_CHECK config option) is incompatible with highmem
(uses phys_to_virt() instead of proper mapping) which is used by
the majority of Exynos boards. The issue manifests itself in OOPS
on affected boards, i.e. on Odroid-U3 I got the following one:

[   18.757127] Unable to handle kernel paging request at virtual address 
f000
[   18.757127] pgd = 1c0f9bb4
[   18.757127] [f000] *pgd=
[   18.757127] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[   18.757127] Modules linked in:
[   18.757127] CPU: 0 PID: 1357 Comm: rtcwake Not tainted 
4.19.0-rc1-next-20180830 #35
[   18.757127] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[   18.757127] PC is at crc32_le+0x30/0x150
[   18.757127] LR is at s3c_pm_makecheck+0x34/0x54
[   18.757127] pc : []lr : []psr: 00d3
[   18.757127] sp : ed2e3db0  ip : 2000  fp : 2000
[   18.757127] r10:   r9 : c0c2f6e8  r8 : c0fc0734
[   18.757127] r7 : 01000200  r6 : efffce40  r5 : ec68c000  r4 : effc
[   18.757127] r3 : c0a25dc0  r2 :   r1 : effc  r0 : 
[   18.757127] Flags: nzcv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment 
none
[   18.757127] Control: 10c5387d  Table: 6d24c04a  DAC: 0051
[   18.757127] Process rtcwake (pid: 1357, stack limit = 0x104b670f)
[   18.757127] Stack: (0xed2e3db0 to 0xed2e4000)
[   18.757127] 3da0: c0fc0734  
7000 ec68c000
[   18.757127] 3dc0: efffce40 01000200 c0fc0734 c0c2f6e8  c0fac13c 
efffce40 ec68
[   18.757127] 3de0: c0121f58 c0121efc c0fc773c c0f0f3cc ec68 c0121f58 
01000200 c0121ecc
[   18.757127] 3e00: c0fc773c c0f0d9e0 c0ce4d00  c0fac13c c01210b8 
c0121054 c16d17ec
[   18.757127] 3e20: 0003 c018893c c0f07470 ec60b300 ec60b880 c017cc5c 
 6053
[   18.757127] 3e40: c0f07470 c0faa913 0003 c0f07470 c0fac13c c0c2f6f8 
c0faa913 c0a035c4
[   18.757127] 3e60: c0c2f71c c0189534 0001 0006  0003 
c0c286c8 c16d180c
[   18.757127] 3e80: 0003 ec41c940  0004  c0186ce8 
0004 ec4210c0
[   18.757127] 3ea0: 0004 ec41c940 0004  ec4210d0 c09db434 
0004 c02fa63c
[   18.757127] 3ec0: ec4210c0 ec41c940 ed2e3f80 c02f97a4   
c0a0dec4 b6f1a000
[   18.757127] 3ee0: ed1f8f00 ed2e3f80 0004 ed2e2000 b6f1a000 c027b198 
0001 c017ccd4
[   18.757127] 3f00: 0001 c0f53b64 ed1301f4 c0198fa4 c0faa925 c01992d8 
d166c958 
[   18.757127] 3f20:  c027cad0 0001  c027b4b8  
ed118554 ed1f8f00
[   18.757127] 3f40: ed1f8f00 0004 b6f1a000  ed2e3f80 c027b418 
b6f1a000 c023e65c
[   18.757127] 3f60: 0022   ed1f8f00 ed1f8f00 0004 
b6f1a000 c027b5d8
[   18.757127] 3f80:    0004 b6f1a000 000160e0 
0004 c01011c4
[   18.757127] 3fa0: 0004 c0101000 0004 b6f1a000 0004 b6f1a000 
0004 
[   18.757127] 3fc0: 0004 b6f1a000 000160e0 0004 0004 b6f1a000 
0004 
[   18.757127] 3fe0:  be880b2c b6e21a6c b6e77a0c 6050 0004 
 
[   18.757127] [] (crc32_le) from [] 
(s3c_pm_makecheck+0x34/0x54)
[   18.757127] [] (s3c_pm_makecheck) from [] 
(s3c_pm_run_res+0x74/0x8c)
[   18.757127] [] (s3c_pm_run_res) from [] 
(s3c_pm_run_res+0x44/0x8c)
[   18.757127] [] (s3c_pm_run_res) from [] 
(exynos_suspend_enter+0x64/0x148)
[   18.757127] [] (exynos_suspend_enter) from [] 
(suspend_devices_and_enter+0x9ec/0xe74)
[   18.757127] [] (suspend_devices_and_enter) from [] 
(pm_suspend+0x770/0xc04)
[   18.757127] [] (pm_suspend) from [] 
(state_store+0x6c/0xcc)
[   18.757127] [] (state_store) from [] 
(kobj_attr_store+0x14/0x20)
[   18.757127] [] (kobj_attr_store) from [] 
(sysfs_kf_write+0x4c/0x50)
[   18.757127] [] (sysfs_kf_write) from [] 
(kernfs_fop_write+0xfc/0x1e4)
[   18.757127] [] (kernfs_fop_write) from [] 
(__vfs_write+0x2c/0x140)
[   18.757127] [] (__vfs_write) from [] 
(vfs_write+0xa4/0x160)
[   18.757127] [] (vfs_write) from [] (ksys_write+0x40/0x8c)
[   18.757127] [] (ksys_write) from [] 
(ret_fast_syscall+0x0/0x28)
[   18.757127] Exception stack(0xed2e3fa8 to 0xed2e3ff0)
[   18.757127] 3fa0:   0004 b6f1a000 0004 b6f1a000 
0004 
[   18.757127] 3fc0: 0004 b6f1a000 000160e0 0004 0004 b6f1a000 
0004 
[   18.757127] 3fe0:  be880b2c b6e21a6c b6e77a0c
[   18.757127] Code: 0a2a e59f3120 e1a04001 e1a0c00b (e5945004)
[   18.757127] ---[ end trace 213166221066122e ]---

Add PLAT_S3C24XX, ARCH_S3C64XX and ARCH_S5PV210 dependencies to
SAMSUNG_PM_CHECK config option to hide it on Exynos platforms.

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 arch/arm/plat-samsung/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/arch/arm/plat-samsung/Kconfig
===
--- a/arc

[PATCH] ARM: SAMSUNG: limit SAMSUNG_PM_CHECK config option to non-Exynos platforms

2018-09-28 Thread Bartlomiej Zolnierkiewicz

"S3C2410 PM Suspend Memory CRC" feature (controlled by
SAMSUNG_PM_CHECK config option) is incompatible with highmem
(uses phys_to_virt() instead of proper mapping) which is used by
the majority of Exynos boards. The issue manifests itself in OOPS
on affected boards, i.e. on Odroid-U3 I got the following one:

[   18.757127] Unable to handle kernel paging request at virtual address 
f000
[   18.757127] pgd = 1c0f9bb4
[   18.757127] [f000] *pgd=
[   18.757127] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[   18.757127] Modules linked in:
[   18.757127] CPU: 0 PID: 1357 Comm: rtcwake Not tainted 
4.19.0-rc1-next-20180830 #35
[   18.757127] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[   18.757127] PC is at crc32_le+0x30/0x150
[   18.757127] LR is at s3c_pm_makecheck+0x34/0x54
[   18.757127] pc : []lr : []psr: 00d3
[   18.757127] sp : ed2e3db0  ip : 2000  fp : 2000
[   18.757127] r10:   r9 : c0c2f6e8  r8 : c0fc0734
[   18.757127] r7 : 01000200  r6 : efffce40  r5 : ec68c000  r4 : effc
[   18.757127] r3 : c0a25dc0  r2 :   r1 : effc  r0 : 
[   18.757127] Flags: nzcv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment 
none
[   18.757127] Control: 10c5387d  Table: 6d24c04a  DAC: 0051
[   18.757127] Process rtcwake (pid: 1357, stack limit = 0x104b670f)
[   18.757127] Stack: (0xed2e3db0 to 0xed2e4000)
[   18.757127] 3da0: c0fc0734  
7000 ec68c000
[   18.757127] 3dc0: efffce40 01000200 c0fc0734 c0c2f6e8  c0fac13c 
efffce40 ec68
[   18.757127] 3de0: c0121f58 c0121efc c0fc773c c0f0f3cc ec68 c0121f58 
01000200 c0121ecc
[   18.757127] 3e00: c0fc773c c0f0d9e0 c0ce4d00  c0fac13c c01210b8 
c0121054 c16d17ec
[   18.757127] 3e20: 0003 c018893c c0f07470 ec60b300 ec60b880 c017cc5c 
 6053
[   18.757127] 3e40: c0f07470 c0faa913 0003 c0f07470 c0fac13c c0c2f6f8 
c0faa913 c0a035c4
[   18.757127] 3e60: c0c2f71c c0189534 0001 0006  0003 
c0c286c8 c16d180c
[   18.757127] 3e80: 0003 ec41c940  0004  c0186ce8 
0004 ec4210c0
[   18.757127] 3ea0: 0004 ec41c940 0004  ec4210d0 c09db434 
0004 c02fa63c
[   18.757127] 3ec0: ec4210c0 ec41c940 ed2e3f80 c02f97a4   
c0a0dec4 b6f1a000
[   18.757127] 3ee0: ed1f8f00 ed2e3f80 0004 ed2e2000 b6f1a000 c027b198 
0001 c017ccd4
[   18.757127] 3f00: 0001 c0f53b64 ed1301f4 c0198fa4 c0faa925 c01992d8 
d166c958 
[   18.757127] 3f20:  c027cad0 0001  c027b4b8  
ed118554 ed1f8f00
[   18.757127] 3f40: ed1f8f00 0004 b6f1a000  ed2e3f80 c027b418 
b6f1a000 c023e65c
[   18.757127] 3f60: 0022   ed1f8f00 ed1f8f00 0004 
b6f1a000 c027b5d8
[   18.757127] 3f80:    0004 b6f1a000 000160e0 
0004 c01011c4
[   18.757127] 3fa0: 0004 c0101000 0004 b6f1a000 0004 b6f1a000 
0004 
[   18.757127] 3fc0: 0004 b6f1a000 000160e0 0004 0004 b6f1a000 
0004 
[   18.757127] 3fe0:  be880b2c b6e21a6c b6e77a0c 6050 0004 
 
[   18.757127] [] (crc32_le) from [] 
(s3c_pm_makecheck+0x34/0x54)
[   18.757127] [] (s3c_pm_makecheck) from [] 
(s3c_pm_run_res+0x74/0x8c)
[   18.757127] [] (s3c_pm_run_res) from [] 
(s3c_pm_run_res+0x44/0x8c)
[   18.757127] [] (s3c_pm_run_res) from [] 
(exynos_suspend_enter+0x64/0x148)
[   18.757127] [] (exynos_suspend_enter) from [] 
(suspend_devices_and_enter+0x9ec/0xe74)
[   18.757127] [] (suspend_devices_and_enter) from [] 
(pm_suspend+0x770/0xc04)
[   18.757127] [] (pm_suspend) from [] 
(state_store+0x6c/0xcc)
[   18.757127] [] (state_store) from [] 
(kobj_attr_store+0x14/0x20)
[   18.757127] [] (kobj_attr_store) from [] 
(sysfs_kf_write+0x4c/0x50)
[   18.757127] [] (sysfs_kf_write) from [] 
(kernfs_fop_write+0xfc/0x1e4)
[   18.757127] [] (kernfs_fop_write) from [] 
(__vfs_write+0x2c/0x140)
[   18.757127] [] (__vfs_write) from [] 
(vfs_write+0xa4/0x160)
[   18.757127] [] (vfs_write) from [] (ksys_write+0x40/0x8c)
[   18.757127] [] (ksys_write) from [] 
(ret_fast_syscall+0x0/0x28)
[   18.757127] Exception stack(0xed2e3fa8 to 0xed2e3ff0)
[   18.757127] 3fa0:   0004 b6f1a000 0004 b6f1a000 
0004 
[   18.757127] 3fc0: 0004 b6f1a000 000160e0 0004 0004 b6f1a000 
0004 
[   18.757127] 3fe0:  be880b2c b6e21a6c b6e77a0c
[   18.757127] Code: 0a2a e59f3120 e1a04001 e1a0c00b (e5945004)
[   18.757127] ---[ end trace 213166221066122e ]---

Add PLAT_S3C24XX, ARCH_S3C64XX and ARCH_S5PV210 dependencies to
SAMSUNG_PM_CHECK config option to hide it on Exynos platforms.

Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 arch/arm/plat-samsung/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/arch/arm/plat-samsung/Kconfig
===
--- a/arc

Re: [PATCH 01/17] thermal: add thermal_zone_device_toggle() helper

2018-09-17 Thread Bartlomiej Zolnierkiewicz



On 09/14/2018 01:40 PM, Bartlomiej Zolnierkiewicz wrote:

[...]

>>> --- a/include/linux/thermal.h
>>> +++ b/include/linux/thermal.h
>>> @@ -467,6 +467,7 @@ struct thermal_cooling_device *
>>>  int thermal_zone_get_temp(struct thermal_zone_device *tz, int *temp);
>>>  int thermal_zone_get_slope(struct thermal_zone_device *tz);
>>>  int thermal_zone_get_offset(struct thermal_zone_device *tz);
>>> +int thermal_zone_device_toggle(struct thermal_zone_device *tz, bool on);
>>>  
>>
>> You missed the #else section of the #if IS_ENABLED(CONFIG_THERMAL),
>> didn't you?
> 
> No, this function shouldn't be used outside of CONFIG_THERMAL.

Please disregard my previous comment. I see now that the CONFIG_THERMAL=n
stub is needed and I will add it in the next patch revision.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

Re: [PATCH 01/17] thermal: add thermal_zone_device_toggle() helper

2018-09-17 Thread Bartlomiej Zolnierkiewicz



On 09/14/2018 01:40 PM, Bartlomiej Zolnierkiewicz wrote:

[...]

>>> --- a/include/linux/thermal.h
>>> +++ b/include/linux/thermal.h
>>> @@ -467,6 +467,7 @@ struct thermal_cooling_device *
>>>  int thermal_zone_get_temp(struct thermal_zone_device *tz, int *temp);
>>>  int thermal_zone_get_slope(struct thermal_zone_device *tz);
>>>  int thermal_zone_get_offset(struct thermal_zone_device *tz);
>>> +int thermal_zone_device_toggle(struct thermal_zone_device *tz, bool on);
>>>  
>>
>> You missed the #else section of the #if IS_ENABLED(CONFIG_THERMAL),
>> didn't you?
> 
> No, this function shouldn't be used outside of CONFIG_THERMAL.

Please disregard my previous comment. I see now that the CONFIG_THERMAL=n
stub is needed and I will add it in the next patch revision.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

Re: [PATCH 00/17] thermal: enable/check sensor after its setup is finished

2018-09-14 Thread Bartlomiej Zolnierkiewicz



On 09/10/2018 07:37 PM, Eduardo Valentin wrote:
> On Tue, Apr 10, 2018 at 02:41:54PM +0200, Bartlomiej Zolnierkiewicz wrote:
>> Hi,
>>
>> [devm]_thermal_zone_of_sensor_register() is used to register
>> thermal sensor by thermal drivers using DeviceTree. Besides
>> registering sensor this function also immediately enables it
>> (using ->set_mode method) and then checks it with a update call
>> to the thermal core (which ends up using ->get_temp method).
> 
> Yeah, pretty much the driver needs to be ready to answer to callbacks
> once it calls thermal_*_register() method.
> 
>> For many DT thermal drivers this causes a problem because
> 
> Can you be more specific? Are you seeing this problem in samsung driver
> or in other drivers too?

We were hitting the issue in exynos driver and we have added
workaround for it in the driver itself (commit 0eb875d88aaa
"thermal: exynos: Reading temperature makes sense only when TMU
is turned on").

After that I did the audit of all DT thermal drivers and found
the issue in majority of them (patches #5-16):

- bcm2835
- brcmstb
- hisi_thermal
- tsens
- qoriq
- rcar_gen3_thermal
- rockchip_thermal
- exynos
- tegra
- ti-soc-thermal
- uniphier
- zx2967

>> [devm]_thermal_zone_of_sensor_register() need to be called in
>> order to obtain data about thermal trips which are then used to
>> finish hardware sensor setup (only after which ->get_temp can
>> be used). The issue has been observed when using Samsung Exynos
> 
> Oh I see, this is because trip info is read by the of thermal thermal
> then, correct?

Yes, some drivers need trip info for sensor configuration.

There is also related issue for drivers that support IRQ
(i.e. exynos and rockchip ones):

- sensor should be enabled only after IRQ handler is requested
  (because otherwise we might get IRQs that we can't handle)

- IRQ handler needs tzd structure which is obtained from
  [devm_]thermal_zone_of_sensor_register()

- after [devm_]thermal_zone_of_sensor_register() call core
  thermal code assumes that sensor is enabled and ready to
  use (the core may call ->get_temp)

>> thermal driver and fixed internally in the driver in commit
>> d8efad71e5b6 ("thermal: exynos: Reading temperature makes sense
>> only when TMU is turned on"). However after this commit there
>> are now following warnings from the thermal core visible:
>>
>> [3.453602] thermal thermal_zone0: failed to read out thermal zone (-22)
>> [3.483468] thermal thermal_zone1: failed to read out thermal zone (-22)
>> [3.505965] thermal thermal_zone2: failed to read out thermal zone (-22)
>> [3.528455] thermal thermal_zone3: failed to read out thermal zone (-22)
>> [3.550939] thermal thermal_zone4: failed to read out thermal zone (-22)
>>
>> This patchset attempts to directly address the thermal core
>> problem with [devm]_thermal_zone_of_sensor_register() and
>> affected DT thermal drivers. In order to achieve this sensor
>> registration, enable and check operations are separated and
>> corresponding drivers are modified to use the new helpers to
>> enable and check sensor explicitly.
>>
> 
> Ok. Up to this point I followed that this is a samsung driver issue, not
> we need to change the core to fix adapt to it?

Well, we need core changes (patches #2 and #4) for (IMHO) cleaner and
more straightforward solution (with it the core can have the valid info
about the sensor state all the time).

Alternatively we can add workarounds (like the one we added in exynos
driver) to all affected DT thermal drivers (with this solution sensor
can be disabled while the core will think that it is enabled)..

> And adapting the core should be fine to fit a new use/fix something,
> as long the issue is well described..
> 
>> Tested on Exynos5422 based Odroid-XU3 Lite board (aforementioned
>> warnings from the thermal core are now gone).
>>
>> Best regards,
>> --
>> Bartlomiej Zolnierkiewicz
>> Samsung R Institute Poland
>> Samsung Electronics
>>
>>
>> Bartlomiej Zolnierkiewicz (17):
>>   thermal: add thermal_zone_device_toggle() helper
>>   thermal: separate sensor registration and enable
>>   thermal: add thermal_zone_device_check() helper
>>   thermal: do sensor checking explicitly in drivers
>>   thermal: bcm2835: enable/check sensor after its setup is finished
>>   thermal: brcmstb: enable/check sensor after its setup is finished
>>   thermal: hisi_thermal: enable/check sensor after its setup is finished
>>   thermal: qcom: tsens: enable/check sensor after its setup is finished
>>   thermal: qoriq: enable/check sensor after its setup is finished
>>   thermal: rcar_gen

Re: [PATCH 00/17] thermal: enable/check sensor after its setup is finished

2018-09-14 Thread Bartlomiej Zolnierkiewicz



On 09/10/2018 07:37 PM, Eduardo Valentin wrote:
> On Tue, Apr 10, 2018 at 02:41:54PM +0200, Bartlomiej Zolnierkiewicz wrote:
>> Hi,
>>
>> [devm]_thermal_zone_of_sensor_register() is used to register
>> thermal sensor by thermal drivers using DeviceTree. Besides
>> registering sensor this function also immediately enables it
>> (using ->set_mode method) and then checks it with a update call
>> to the thermal core (which ends up using ->get_temp method).
> 
> Yeah, pretty much the driver needs to be ready to answer to callbacks
> once it calls thermal_*_register() method.
> 
>> For many DT thermal drivers this causes a problem because
> 
> Can you be more specific? Are you seeing this problem in samsung driver
> or in other drivers too?

We were hitting the issue in exynos driver and we have added
workaround for it in the driver itself (commit 0eb875d88aaa
"thermal: exynos: Reading temperature makes sense only when TMU
is turned on").

After that I did the audit of all DT thermal drivers and found
the issue in majority of them (patches #5-16):

- bcm2835
- brcmstb
- hisi_thermal
- tsens
- qoriq
- rcar_gen3_thermal
- rockchip_thermal
- exynos
- tegra
- ti-soc-thermal
- uniphier
- zx2967

>> [devm]_thermal_zone_of_sensor_register() need to be called in
>> order to obtain data about thermal trips which are then used to
>> finish hardware sensor setup (only after which ->get_temp can
>> be used). The issue has been observed when using Samsung Exynos
> 
> Oh I see, this is because trip info is read by the of thermal thermal
> then, correct?

Yes, some drivers need trip info for sensor configuration.

There is also related issue for drivers that support IRQ
(i.e. exynos and rockchip ones):

- sensor should be enabled only after IRQ handler is requested
  (because otherwise we might get IRQs that we can't handle)

- IRQ handler needs tzd structure which is obtained from
  [devm_]thermal_zone_of_sensor_register()

- after [devm_]thermal_zone_of_sensor_register() call core
  thermal code assumes that sensor is enabled and ready to
  use (the core may call ->get_temp)

>> thermal driver and fixed internally in the driver in commit
>> d8efad71e5b6 ("thermal: exynos: Reading temperature makes sense
>> only when TMU is turned on"). However after this commit there
>> are now following warnings from the thermal core visible:
>>
>> [3.453602] thermal thermal_zone0: failed to read out thermal zone (-22)
>> [3.483468] thermal thermal_zone1: failed to read out thermal zone (-22)
>> [3.505965] thermal thermal_zone2: failed to read out thermal zone (-22)
>> [3.528455] thermal thermal_zone3: failed to read out thermal zone (-22)
>> [3.550939] thermal thermal_zone4: failed to read out thermal zone (-22)
>>
>> This patchset attempts to directly address the thermal core
>> problem with [devm]_thermal_zone_of_sensor_register() and
>> affected DT thermal drivers. In order to achieve this sensor
>> registration, enable and check operations are separated and
>> corresponding drivers are modified to use the new helpers to
>> enable and check sensor explicitly.
>>
> 
> Ok. Up to this point I followed that this is a samsung driver issue, not
> we need to change the core to fix adapt to it?

Well, we need core changes (patches #2 and #4) for (IMHO) cleaner and
more straightforward solution (with it the core can have the valid info
about the sensor state all the time).

Alternatively we can add workarounds (like the one we added in exynos
driver) to all affected DT thermal drivers (with this solution sensor
can be disabled while the core will think that it is enabled)..

> And adapting the core should be fine to fit a new use/fix something,
> as long the issue is well described..
> 
>> Tested on Exynos5422 based Odroid-XU3 Lite board (aforementioned
>> warnings from the thermal core are now gone).
>>
>> Best regards,
>> --
>> Bartlomiej Zolnierkiewicz
>> Samsung R Institute Poland
>> Samsung Electronics
>>
>>
>> Bartlomiej Zolnierkiewicz (17):
>>   thermal: add thermal_zone_device_toggle() helper
>>   thermal: separate sensor registration and enable
>>   thermal: add thermal_zone_device_check() helper
>>   thermal: do sensor checking explicitly in drivers
>>   thermal: bcm2835: enable/check sensor after its setup is finished
>>   thermal: brcmstb: enable/check sensor after its setup is finished
>>   thermal: hisi_thermal: enable/check sensor after its setup is finished
>>   thermal: qcom: tsens: enable/check sensor after its setup is finished
>>   thermal: qoriq: enable/check sensor after its setup is finished
>>   thermal: rcar_gen

Re: [PATCH 01/17] thermal: add thermal_zone_device_toggle() helper

2018-09-14 Thread Bartlomiej Zolnierkiewicz



On 09/10/2018 07:16 PM, Eduardo Valentin wrote:
> On Tue, Apr 10, 2018 at 02:41:55PM +0200, Bartlomiej Zolnierkiewicz wrote:
>> Add thermal_zone_device_toggle() helper. Then update core code and
>> drivers to use it.
> 
> Cool, but I think it would be good to have some sort of rational here
> at the commit message telling why this helper is being added, 
> don't you agree?

Ok, I will enhance the patch description (the rationale is removing
code duplication and preparation for changes in the later patches from
the series).

>> Signed-off-by: Bartlomiej Zolnierkiewicz 
>> ---
>>  drivers/thermal/hisi_thermal.c | 14 ++
>>  drivers/thermal/of-thermal.c   |  2 +-
>>  drivers/thermal/rockchip_thermal.c | 22 +-
>>  drivers/thermal/thermal_helpers.c  | 15 +++
>>  drivers/thermal/thermal_sysfs.c|  8 +---
>>  include/linux/thermal.h|  1 +
>>  6 files changed, 29 insertions(+), 33 deletions(-)
>>
>> diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
>> index 761d055..9428499 100644
>> --- a/drivers/thermal/hisi_thermal.c
>> +++ b/drivers/thermal/hisi_thermal.c
>> @@ -515,15 +515,6 @@ static int hisi_thermal_register_sensor(struct 
>> platform_device *pdev,
>>  };
>>  MODULE_DEVICE_TABLE(of, of_hisi_thermal_match);
>>  
>> -static void hisi_thermal_toggle_sensor(struct hisi_thermal_sensor *sensor,
>> -   bool on)
>> -{
>> -struct thermal_zone_device *tzd = sensor->tzd;
>> -
>> -tzd->ops->set_mode(tzd,
>> -on ? THERMAL_DEVICE_ENABLED : THERMAL_DEVICE_DISABLED);
>> -}
>> -
>>  static int hisi_thermal_probe(struct platform_device *pdev)
>>  {
>>  struct hisi_thermal_data *data;
>> @@ -571,7 +562,7 @@ static int hisi_thermal_probe(struct platform_device 
>> *pdev)
>>  }
>>  }
>>  
>> -hisi_thermal_toggle_sensor(>sensor, true);
>> +thermal_zone_device_toggle((>sensor)->tzd, true);
>>  
>>  return 0;
>>  }
>> @@ -579,9 +570,8 @@ static int hisi_thermal_probe(struct platform_device 
>> *pdev)
>>  static int hisi_thermal_remove(struct platform_device *pdev)
>>  {
>>  struct hisi_thermal_data *data = platform_get_drvdata(pdev);
>> -struct hisi_thermal_sensor *sensor = >sensor;
>>  
>> -hisi_thermal_toggle_sensor(sensor, false);
>> +thermal_zone_device_toggle((>sensor)->tzd, false);
>>  
>>  data->disable_sensor(data);
>>  
>> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
>> index e09f035..f138b78 100644
>> --- a/drivers/thermal/of-thermal.c
>> +++ b/drivers/thermal/of-thermal.c
>> @@ -510,7 +510,7 @@ struct thermal_zone_device *
>>  tzd = thermal_zone_of_add_sensor(child, sensor_np,
>>   data, ops);
>>  if (!IS_ERR(tzd))
>> -tzd->ops->set_mode(tzd, THERMAL_DEVICE_ENABLED);
>> +thermal_zone_device_toggle(tzd, true);
>>  
>>  of_node_put(sensor_specs.np);
>>  of_node_put(child);
>> diff --git a/drivers/thermal/rockchip_thermal.c 
>> b/drivers/thermal/rockchip_thermal.c
>> index f36375d..c191e41 100644
>> --- a/drivers/thermal/rockchip_thermal.c
>> +++ b/drivers/thermal/rockchip_thermal.c
>> @@ -1022,15 +1022,6 @@ static void rk_tsadcv2_tshut_mode(int chn, void 
>> __iomem *regs,
>>  };
>>  MODULE_DEVICE_TABLE(of, of_rockchip_thermal_match);
>>  
>> -static void
>> -rockchip_thermal_toggle_sensor(struct rockchip_thermal_sensor *sensor, bool 
>> on)
>> -{
>> -struct thermal_zone_device *tzd = sensor->tzd;
>> -
>> -tzd->ops->set_mode(tzd,
>> -on ? THERMAL_DEVICE_ENABLED : THERMAL_DEVICE_DISABLED);
>> -}
>> -
>>  static irqreturn_t rockchip_thermal_alarm_irq_thread(int irq, void *dev)
>>  {
>>  struct rockchip_thermal_data *thermal = dev;
>> @@ -1292,7 +1283,7 @@ static int rockchip_thermal_probe(struct 
>> platform_device *pdev)
>>  thermal->chip->control(thermal->regs, true);
>>  
>>  for (i = 0; i < thermal->chip->chn_num; i++)
>> -rockchip_thermal_toggle_sensor(>sensors[i], true);
>> +thermal_zone_device_toggle((>sensors[i])->tzd, true);
>>  
>>  platform_set_drvdata(pdev, thermal)

Re: [PATCH 01/17] thermal: add thermal_zone_device_toggle() helper

2018-09-14 Thread Bartlomiej Zolnierkiewicz



On 09/10/2018 07:16 PM, Eduardo Valentin wrote:
> On Tue, Apr 10, 2018 at 02:41:55PM +0200, Bartlomiej Zolnierkiewicz wrote:
>> Add thermal_zone_device_toggle() helper. Then update core code and
>> drivers to use it.
> 
> Cool, but I think it would be good to have some sort of rational here
> at the commit message telling why this helper is being added, 
> don't you agree?

Ok, I will enhance the patch description (the rationale is removing
code duplication and preparation for changes in the later patches from
the series).

>> Signed-off-by: Bartlomiej Zolnierkiewicz 
>> ---
>>  drivers/thermal/hisi_thermal.c | 14 ++
>>  drivers/thermal/of-thermal.c   |  2 +-
>>  drivers/thermal/rockchip_thermal.c | 22 +-
>>  drivers/thermal/thermal_helpers.c  | 15 +++
>>  drivers/thermal/thermal_sysfs.c|  8 +---
>>  include/linux/thermal.h|  1 +
>>  6 files changed, 29 insertions(+), 33 deletions(-)
>>
>> diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
>> index 761d055..9428499 100644
>> --- a/drivers/thermal/hisi_thermal.c
>> +++ b/drivers/thermal/hisi_thermal.c
>> @@ -515,15 +515,6 @@ static int hisi_thermal_register_sensor(struct 
>> platform_device *pdev,
>>  };
>>  MODULE_DEVICE_TABLE(of, of_hisi_thermal_match);
>>  
>> -static void hisi_thermal_toggle_sensor(struct hisi_thermal_sensor *sensor,
>> -   bool on)
>> -{
>> -struct thermal_zone_device *tzd = sensor->tzd;
>> -
>> -tzd->ops->set_mode(tzd,
>> -on ? THERMAL_DEVICE_ENABLED : THERMAL_DEVICE_DISABLED);
>> -}
>> -
>>  static int hisi_thermal_probe(struct platform_device *pdev)
>>  {
>>  struct hisi_thermal_data *data;
>> @@ -571,7 +562,7 @@ static int hisi_thermal_probe(struct platform_device 
>> *pdev)
>>  }
>>  }
>>  
>> -hisi_thermal_toggle_sensor(>sensor, true);
>> +thermal_zone_device_toggle((>sensor)->tzd, true);
>>  
>>  return 0;
>>  }
>> @@ -579,9 +570,8 @@ static int hisi_thermal_probe(struct platform_device 
>> *pdev)
>>  static int hisi_thermal_remove(struct platform_device *pdev)
>>  {
>>  struct hisi_thermal_data *data = platform_get_drvdata(pdev);
>> -struct hisi_thermal_sensor *sensor = >sensor;
>>  
>> -hisi_thermal_toggle_sensor(sensor, false);
>> +thermal_zone_device_toggle((>sensor)->tzd, false);
>>  
>>  data->disable_sensor(data);
>>  
>> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
>> index e09f035..f138b78 100644
>> --- a/drivers/thermal/of-thermal.c
>> +++ b/drivers/thermal/of-thermal.c
>> @@ -510,7 +510,7 @@ struct thermal_zone_device *
>>  tzd = thermal_zone_of_add_sensor(child, sensor_np,
>>   data, ops);
>>  if (!IS_ERR(tzd))
>> -tzd->ops->set_mode(tzd, THERMAL_DEVICE_ENABLED);
>> +thermal_zone_device_toggle(tzd, true);
>>  
>>  of_node_put(sensor_specs.np);
>>  of_node_put(child);
>> diff --git a/drivers/thermal/rockchip_thermal.c 
>> b/drivers/thermal/rockchip_thermal.c
>> index f36375d..c191e41 100644
>> --- a/drivers/thermal/rockchip_thermal.c
>> +++ b/drivers/thermal/rockchip_thermal.c
>> @@ -1022,15 +1022,6 @@ static void rk_tsadcv2_tshut_mode(int chn, void 
>> __iomem *regs,
>>  };
>>  MODULE_DEVICE_TABLE(of, of_rockchip_thermal_match);
>>  
>> -static void
>> -rockchip_thermal_toggle_sensor(struct rockchip_thermal_sensor *sensor, bool 
>> on)
>> -{
>> -struct thermal_zone_device *tzd = sensor->tzd;
>> -
>> -tzd->ops->set_mode(tzd,
>> -on ? THERMAL_DEVICE_ENABLED : THERMAL_DEVICE_DISABLED);
>> -}
>> -
>>  static irqreturn_t rockchip_thermal_alarm_irq_thread(int irq, void *dev)
>>  {
>>  struct rockchip_thermal_data *thermal = dev;
>> @@ -1292,7 +1283,7 @@ static int rockchip_thermal_probe(struct 
>> platform_device *pdev)
>>  thermal->chip->control(thermal->regs, true);
>>  
>>  for (i = 0; i < thermal->chip->chn_num; i++)
>> -rockchip_thermal_toggle_sensor(>sensors[i], true);
>> +thermal_zone_device_toggle((>sensors[i])->tzd, true);
>>  
>>  platform_set_drvdata(pdev, thermal)

Re: [PATCH] PM / devfreq: Add new name attribute for sysfs

2018-08-29 Thread Bartlomiej Zolnierkiewicz



Hi Chanwoo,

On Wednesday, August 29, 2018 04:34:06 PM Chanwoo Choi wrote:
> commit 4585fbcb5331 ("PM / devfreq: Modify the device name as devfreq(X) for
> sysfs") changed the node name to devfreq(x). After this commit, it is not
> possible to get the device name through /sys/class/devfreq/devfreq(X)/*.
> 
> Add new name attribute in order to get device name.

Could you please describe the issue encountered in more detail
(what the old device name is needed for)?
 
> Cc: sta...@vger.kernel.org
> Fixes: 4585fbcb5331 ("PM / devfreq: Modify the device name as devfreq(X) for 
> sysfs")
> Signed-off-by: Chanwoo Choi 
> ---
>  drivers/devfreq/devfreq.c | 11 +++
>  include/linux/devfreq.h   |  3 +++
>  2 files changed, 14 insertions(+)
> 
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 4c49bb1330b5..2145563d5ee5 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -620,6 +620,9 @@ struct devfreq *devfreq_add_device(struct device *dev,
>   }
>   devfreq->max_freq = devfreq->scaling_max_freq;
> 
> + devfreq->name = dev_name(devfreq->dev.parent);

It seems that 'dev' can be used instead of 'devfreq->dev.parent'.

> + if (IS_ERR_OR_NULL(devfreq->name))

Error values are not encoded into pointer returned by dev_name()
(drivers/base/ code is only checking for pointer being NULL).

> + return -EINVAL;

This leaks 'devfreq' object and doesn't encode return value into
pointer returned by devfreq_add_device(), it should be replaced by:

err = -EINVAL;
goto err_dev;

>   dev_set_name(>dev, "devfreq%d",
>   atomic_inc_return(_no));
>   err = device_register(>dev);

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

Re: [PATCH] PM / devfreq: Add new name attribute for sysfs

2018-08-29 Thread Bartlomiej Zolnierkiewicz



Hi Chanwoo,

On Wednesday, August 29, 2018 04:34:06 PM Chanwoo Choi wrote:
> commit 4585fbcb5331 ("PM / devfreq: Modify the device name as devfreq(X) for
> sysfs") changed the node name to devfreq(x). After this commit, it is not
> possible to get the device name through /sys/class/devfreq/devfreq(X)/*.
> 
> Add new name attribute in order to get device name.

Could you please describe the issue encountered in more detail
(what the old device name is needed for)?
 
> Cc: sta...@vger.kernel.org
> Fixes: 4585fbcb5331 ("PM / devfreq: Modify the device name as devfreq(X) for 
> sysfs")
> Signed-off-by: Chanwoo Choi 
> ---
>  drivers/devfreq/devfreq.c | 11 +++
>  include/linux/devfreq.h   |  3 +++
>  2 files changed, 14 insertions(+)
> 
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 4c49bb1330b5..2145563d5ee5 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -620,6 +620,9 @@ struct devfreq *devfreq_add_device(struct device *dev,
>   }
>   devfreq->max_freq = devfreq->scaling_max_freq;
> 
> + devfreq->name = dev_name(devfreq->dev.parent);

It seems that 'dev' can be used instead of 'devfreq->dev.parent'.

> + if (IS_ERR_OR_NULL(devfreq->name))

Error values are not encoded into pointer returned by dev_name()
(drivers/base/ code is only checking for pointer being NULL).

> + return -EINVAL;

This leaks 'devfreq' object and doesn't encode return value into
pointer returned by devfreq_add_device(), it should be replaced by:

err = -EINVAL;
goto err_dev;

>   dev_set_name(>dev, "devfreq%d",
>   atomic_inc_return(_no));
>   err = device_register(>dev);

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

[GIT PULL] fbdev changes for v4.19

2018-08-23 Thread Bartlomiej Zolnierkiewicz



Hi Linus,

Please pull fbdev changes for v4.19. There are mostly small fixes and
cleanups for fb drivers (the biggest updates are for udlfb and pxafb
drivers). This PR also adds deferred console takeover support to the
console code and efifb driver. Please see the signed tag description
for details.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics


The following changes since commit 334bb8972a131e604a741e9b284d8867190c723e:

  console: dummycon: export dummycon_[un]register_output_notifier (2018-06-29 
11:46:19 +0200)

are available in the git repository at:

  https://github.com/bzolnier/linux.git tags/fbdev-v4.19

for you to fetch changes up to f39684524b391c5a7ed0ac44db4fec3357af1c5d:

  Documentation/fb: corrections for fbcon.txt (2018-08-10 17:23:02 +0200)


fbdev changes for v4.19:

- add support for deferred console takeover, when enabled defers
  fbcon taking over the console from the dummy console until the
  first text is displayed on the console - together with the "quiet"
  kernel commandline option this allows fbcon to still be used
  together with a smooth graphical bootup (Hans de Goede)

- improve console locking debugging code (Thomas Zimmermann)

- copy the ACPI BGRT boot graphics to the framebuffer when deferred
  console takeover support is used in efifb driver (Hans de Goede)

- update udlfb driver - fix lost console when the user unplugs a USB
  adapter, fix the screen corruption issue, fix locking and add some
  performance optimizations (Mikulas Patocka)

- update pxafb driver - fix using uninitialized memory, switch to
  devm_* API, handle initialization errors and add support for
  lcd-supply regulator (Daniel Mack)

- add support for boards booted with a DeviceTree in pxa3xx_gcu
  driver (Daniel Mack)

- rename omap2 module to omap2fb.ko to avoid conflicts with omap1
  driver (Arnd Bergmann)

- enable ACPI-based enumeration for goldfishfb driver (Yu Ning)

- fix goldfishfb driver to make user space Android code use 60 fps
  (Christoffer Dall)

- print big fat warning when nomodeset kernel parameter is used in
  vgacon driver (Lyude Paul)

- remove VLA usage from fsl-diu-fb driver (Kees Cook)

- misc fixes (Julia Lawall, Geert Uytterhoeven, Fredrik Noring,
  Yisheng Xie, Dan Carpenter, Daniel Vetter, Anton Vasilyev, Randy
  Dunlap, Gustavo A. R. Silva, Colin Ian King, Fengguang Wu)

- misc cleanups (Roman Kiryanov, Yisheng Xie, Colin Ian King)


Anton Vasilyev (1):
  video: goldfishfb: fix memory leak on driver remove

Arnd Bergmann (1):
  omapfb: rename omap2 module to omap2fb.ko

Bartlomiej Zolnierkiewicz (3):
  Merge tag 'v4.18-rc2' of https://git.kernel.org/.../torvalds/linux into 
fbdev-for-next
  Merge tag 'ib-fbdev-drm-v4.19-deferred-console-takeover' of 
https://github.com/bzolnier/linux into fbdev-for-next
  Merge tag 'ib-fbdev-drm-v4.19-deferred-console-takeover-fixup' of 
https://github.com/bzolnier/linux into fbdev-for-next

Christoffer Dall (1):
  video: fbdev: Set pixclock = 0 in goldfishfb

Colin Ian King (2):
  video: fbdev: tridentfb: remove deadcode on unreachable case statement
  omapfb: encoder-tpd12s015: remove redundant pointer 'in'

Dan Carpenter (2):
  video: fbdev: metronomefb: fix some off by one bugs
  fbdev: omapfb: off by one in omapfb_register_client()

Daniel Mack (6):
  dt-bindings: display: add devicetree bindings for pxa300-gcu
  video: fbdev: pxa3xx_gcu: add devicetree bindings
  video: fbdev: pxafb: clear allocated memory for video modes
  video: fbdev: pxafb: switch to devm_* API
  video: fbdev: pxafb: handle errors from pxafb_init_fbinfo() correctly
  video: fbdev: pxafb: Add support for lcd-supply regulator

Daniel Vetter (1):
  fbdev: fix modedb docs in fb_find_mode

Fredrik Noring (1):
  fbdev: Distinguish between interlaced and progressive modes

Geert Uytterhoeven (1):
  video: fbdev: simplefb: Stop including 

Gustavo A. R. Silva (3):
  fbdev: fbmem: mark expected switch fall-through
  omapfb: Mark expected switch fall-throughs
  video: fbdev: mark expected switch fall-throughs

Hans de Goede (7):
  efi/bgrt: Drop __initdata from bgrt_image_size
  efifb: Copy the ACPI BGRT boot graphics to the framebuffer
  efifb: BGRT: Do not copy the boot graphics for non native resolutions
  fbcon: Only allow FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER if fbdev is 
builtin
  fbcon: Only defer console takeover if the current console driver is the 
dummycon
  dummycon: Stop exporting dummycon_[un]register_output_notifier
  fbcon: Do not takeover the console from atomic context

Julia Lawall (1):
  omapfb: encoder-tpd12s015: fix error return code

Kees Cook (1):
  video: fbdev: fsl-diu-fb: Remove VLA usage

Lyude Paul (1):
  video/console/vgacon: Pri

[GIT PULL] fbdev changes for v4.19

2018-08-23 Thread Bartlomiej Zolnierkiewicz



Hi Linus,

Please pull fbdev changes for v4.19. There are mostly small fixes and
cleanups for fb drivers (the biggest updates are for udlfb and pxafb
drivers). This PR also adds deferred console takeover support to the
console code and efifb driver. Please see the signed tag description
for details.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics


The following changes since commit 334bb8972a131e604a741e9b284d8867190c723e:

  console: dummycon: export dummycon_[un]register_output_notifier (2018-06-29 
11:46:19 +0200)

are available in the git repository at:

  https://github.com/bzolnier/linux.git tags/fbdev-v4.19

for you to fetch changes up to f39684524b391c5a7ed0ac44db4fec3357af1c5d:

  Documentation/fb: corrections for fbcon.txt (2018-08-10 17:23:02 +0200)


fbdev changes for v4.19:

- add support for deferred console takeover, when enabled defers
  fbcon taking over the console from the dummy console until the
  first text is displayed on the console - together with the "quiet"
  kernel commandline option this allows fbcon to still be used
  together with a smooth graphical bootup (Hans de Goede)

- improve console locking debugging code (Thomas Zimmermann)

- copy the ACPI BGRT boot graphics to the framebuffer when deferred
  console takeover support is used in efifb driver (Hans de Goede)

- update udlfb driver - fix lost console when the user unplugs a USB
  adapter, fix the screen corruption issue, fix locking and add some
  performance optimizations (Mikulas Patocka)

- update pxafb driver - fix using uninitialized memory, switch to
  devm_* API, handle initialization errors and add support for
  lcd-supply regulator (Daniel Mack)

- add support for boards booted with a DeviceTree in pxa3xx_gcu
  driver (Daniel Mack)

- rename omap2 module to omap2fb.ko to avoid conflicts with omap1
  driver (Arnd Bergmann)

- enable ACPI-based enumeration for goldfishfb driver (Yu Ning)

- fix goldfishfb driver to make user space Android code use 60 fps
  (Christoffer Dall)

- print big fat warning when nomodeset kernel parameter is used in
  vgacon driver (Lyude Paul)

- remove VLA usage from fsl-diu-fb driver (Kees Cook)

- misc fixes (Julia Lawall, Geert Uytterhoeven, Fredrik Noring,
  Yisheng Xie, Dan Carpenter, Daniel Vetter, Anton Vasilyev, Randy
  Dunlap, Gustavo A. R. Silva, Colin Ian King, Fengguang Wu)

- misc cleanups (Roman Kiryanov, Yisheng Xie, Colin Ian King)


Anton Vasilyev (1):
  video: goldfishfb: fix memory leak on driver remove

Arnd Bergmann (1):
  omapfb: rename omap2 module to omap2fb.ko

Bartlomiej Zolnierkiewicz (3):
  Merge tag 'v4.18-rc2' of https://git.kernel.org/.../torvalds/linux into 
fbdev-for-next
  Merge tag 'ib-fbdev-drm-v4.19-deferred-console-takeover' of 
https://github.com/bzolnier/linux into fbdev-for-next
  Merge tag 'ib-fbdev-drm-v4.19-deferred-console-takeover-fixup' of 
https://github.com/bzolnier/linux into fbdev-for-next

Christoffer Dall (1):
  video: fbdev: Set pixclock = 0 in goldfishfb

Colin Ian King (2):
  video: fbdev: tridentfb: remove deadcode on unreachable case statement
  omapfb: encoder-tpd12s015: remove redundant pointer 'in'

Dan Carpenter (2):
  video: fbdev: metronomefb: fix some off by one bugs
  fbdev: omapfb: off by one in omapfb_register_client()

Daniel Mack (6):
  dt-bindings: display: add devicetree bindings for pxa300-gcu
  video: fbdev: pxa3xx_gcu: add devicetree bindings
  video: fbdev: pxafb: clear allocated memory for video modes
  video: fbdev: pxafb: switch to devm_* API
  video: fbdev: pxafb: handle errors from pxafb_init_fbinfo() correctly
  video: fbdev: pxafb: Add support for lcd-supply regulator

Daniel Vetter (1):
  fbdev: fix modedb docs in fb_find_mode

Fredrik Noring (1):
  fbdev: Distinguish between interlaced and progressive modes

Geert Uytterhoeven (1):
  video: fbdev: simplefb: Stop including 

Gustavo A. R. Silva (3):
  fbdev: fbmem: mark expected switch fall-through
  omapfb: Mark expected switch fall-throughs
  video: fbdev: mark expected switch fall-throughs

Hans de Goede (7):
  efi/bgrt: Drop __initdata from bgrt_image_size
  efifb: Copy the ACPI BGRT boot graphics to the framebuffer
  efifb: BGRT: Do not copy the boot graphics for non native resolutions
  fbcon: Only allow FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER if fbdev is 
builtin
  fbcon: Only defer console takeover if the current console driver is the 
dummycon
  dummycon: Stop exporting dummycon_[un]register_output_notifier
  fbcon: Do not takeover the console from atomic context

Julia Lawall (1):
  omapfb: encoder-tpd12s015: fix error return code

Kees Cook (1):
  video: fbdev: fsl-diu-fb: Remove VLA usage

Lyude Paul (1):
  video/console/vgacon: Pri

Re: [PATCH 01/14] thermal: ti-soc-thermal: fix TALERT IRQ handling for DRA752

2018-07-27 Thread Bartlomiej Zolnierkiewicz

On Friday, July 27, 2018 10:13:51 AM Keerthy wrote:
> 
> On Wednesday 25 July 2018 07:57 PM, Bartlomiej Zolnierkiewicz wrote:
> > On Wednesday, July 11, 2018 07:49:41 AM J, KEERTHY wrote:
> >>
> >> On 5/14/2018 5:12 PM, Bartlomiej Zolnierkiewicz wrote:
> >>> .report_temperature is not set in dra752_data which
> >>> results in temperature updates not being propagated by
> >>> ti_bandgap_talert_irq_handler() (it doesn't make much
> >>> sense to handle TALERT IRQ without reporting temperature
> >>> updates to the thermal core). Fix it.
> >>
> >> ATM no one is using TALERT as the thermal software polls on the 
> >> temperature. No real benefit from TALERT.
> >>
> >> TALERT is set at different temperature and software polling thresholds 
> >> come from Device tree and i believe its best for software to go by 
> >> polling and then act on trip points.
> > 
> > Could you please explain what do you mean by "no one is using
> > TALERT"?
> > 
> > The code in ti_bandgap_probe() sets TALERT thresholds and requests
> > IRQ if the TI_BANDGAP_FEATURE_TALERT feature flag is set (and this
> > flag is set in omap4460_data, omap4470_data, omap5430_data and
> > dra752_data).
> 
> The software thresholds and the polling takes care of reducing the
> temperature. What i actually meant was we never relied on talert and the
> polling takes care of keeping a check on the temperature.

OK I see, maybe TALERT handling can be removed altogether?

If not can we make TALERT behavior on DRA752 consistent with other
chipsets supporting TALERT (this is useful for code unification
between OMAP5430 and DRA752)?

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

Re: [PATCH 01/14] thermal: ti-soc-thermal: fix TALERT IRQ handling for DRA752

2018-07-27 Thread Bartlomiej Zolnierkiewicz

On Friday, July 27, 2018 10:13:51 AM Keerthy wrote:
> 
> On Wednesday 25 July 2018 07:57 PM, Bartlomiej Zolnierkiewicz wrote:
> > On Wednesday, July 11, 2018 07:49:41 AM J, KEERTHY wrote:
> >>
> >> On 5/14/2018 5:12 PM, Bartlomiej Zolnierkiewicz wrote:
> >>> .report_temperature is not set in dra752_data which
> >>> results in temperature updates not being propagated by
> >>> ti_bandgap_talert_irq_handler() (it doesn't make much
> >>> sense to handle TALERT IRQ without reporting temperature
> >>> updates to the thermal core). Fix it.
> >>
> >> ATM no one is using TALERT as the thermal software polls on the 
> >> temperature. No real benefit from TALERT.
> >>
> >> TALERT is set at different temperature and software polling thresholds 
> >> come from Device tree and i believe its best for software to go by 
> >> polling and then act on trip points.
> > 
> > Could you please explain what do you mean by "no one is using
> > TALERT"?
> > 
> > The code in ti_bandgap_probe() sets TALERT thresholds and requests
> > IRQ if the TI_BANDGAP_FEATURE_TALERT feature flag is set (and this
> > flag is set in omap4460_data, omap4470_data, omap5430_data and
> > dra752_data).
> 
> The software thresholds and the polling takes care of reducing the
> temperature. What i actually meant was we never relied on talert and the
> polling takes care of keeping a check on the temperature.

OK I see, maybe TALERT handling can be removed altogether?

If not can we make TALERT behavior on DRA752 consistent with other
chipsets supporting TALERT (this is useful for code unification
between OMAP5430 and DRA752)?

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

Re: [PATCH v2] Documentation: dt-bindings: Explicitly mark Samsung Exynos SoC bindings as unstable

2018-07-26 Thread Bartlomiej Zolnierkiewicz

On Monday, May 28, 2018 09:13:27 PM Krzysztof Kozlowski wrote:
> From: Marek Szyprowski 
> 
> Samsung Exynos SoCs and boards related bindings evolved since the initial
> introduction, but initially the bindings were minimal and a bit incomplete
> (they never described all the hardware modules available in the SoCs).
> Since then some significant (not fully compatible) changes have been
> already committed a few times (like gpio replaced by pinctrl, display ddc,
> mfc reserved memory, some core clocks added to various hardware modules,
> added more required nodes).
> 
> On the other side there are no boards which have device tree embedded in
> the bootloader. Device tree blob is always compiled from the kernel tree
> and updated together with the kernel image.
> 
> Thus to avoid further adding a bunch of workarounds for old/missing
> bindings, make development of new platforms easier and allow to make
> cleanup of the existing code and device tree files, lets mark some
> Samsung Exynos SoC platform bindings as unstable. This means that
> bindings can may change at any time and users should use the dtb file
> compiled from the same kernel source tree as the kernel image.
> 
> Signed-off-by: Marek Szyprowski 
> Signed-off-by: Krzysztof Kozlowski 

Acked-by: Bartlomiej Zolnierkiewicz 

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

Re: [PATCH v2] Documentation: dt-bindings: Explicitly mark Samsung Exynos SoC bindings as unstable

2018-07-26 Thread Bartlomiej Zolnierkiewicz

On Monday, May 28, 2018 09:13:27 PM Krzysztof Kozlowski wrote:
> From: Marek Szyprowski 
> 
> Samsung Exynos SoCs and boards related bindings evolved since the initial
> introduction, but initially the bindings were minimal and a bit incomplete
> (they never described all the hardware modules available in the SoCs).
> Since then some significant (not fully compatible) changes have been
> already committed a few times (like gpio replaced by pinctrl, display ddc,
> mfc reserved memory, some core clocks added to various hardware modules,
> added more required nodes).
> 
> On the other side there are no boards which have device tree embedded in
> the bootloader. Device tree blob is always compiled from the kernel tree
> and updated together with the kernel image.
> 
> Thus to avoid further adding a bunch of workarounds for old/missing
> bindings, make development of new platforms easier and allow to make
> cleanup of the existing code and device tree files, lets mark some
> Samsung Exynos SoC platform bindings as unstable. This means that
> bindings can may change at any time and users should use the dtb file
> compiled from the same kernel source tree as the kernel image.
> 
> Signed-off-by: Marek Szyprowski 
> Signed-off-by: Krzysztof Kozlowski 

Acked-by: Bartlomiej Zolnierkiewicz 

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

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

201 - 300 of 5838 matches

Mail list logo