[PATCH v2 0/3] hwmon: Add reset support to aspeed-pwm-tach

[PATCH v2 0/3] hwmon: Add reset support to aspeed-pwm-tach

[Joel Stanley]

Gunter,

This adds reset controller support to the ASPEED pwm/tach driver. The reset
controller and clock driver is currently under review, so to test those patches
must be merged in to fully test these changes[1].

To address your concerns from v1:

This driver was not usable as-is upstream. I believe the developer(s) tested and
deployed it in the OpenBMC kernel tree which has some hacks in mach-aspeed to
release all of the resets. The other way they could have tested it is by
booting an OpenBMC kernel, which releases the resets, and then testing the
upstream kernel without performing a power cycle as the resets are not
reasserted on reboot.

I realise it is not ideal to be changing already merged bindings. I don't plan
on it becoming a habit.

There is no BIOS or other ROM that runs before Linux on a BMC to release
the resets. We do have u-boot, but that does not modify the pwm reset.

I haven't added a Kconfig dependency on the RESET_CONTROLLER as the driver can
build without it, and when the ASPEED clk/reset driver is merged, the platform
will always have that option selected.

I've given this version a day of testing on hardware I have access to.

[1] https://lwn.net/Articles/737697/

Joel Stanley (3):
  hwmon: (aspeed-pwm-tacho) Sort headers
  hwmon: (aspeed-pwm-tacho) Deassert reset in probe
  dt-bindings: hwmon: aspeed-pwm-tacho: Add reset node

 .../devicetree/bindings/hwmon/aspeed-pwm-tacho.txt | 14 ++++-------
 drivers/hwmon/aspeed-pwm-tacho.c                   | 27 +++++++++++++++++++---
 2 files changed, 29 insertions(+), 12 deletions(-)

-- 
2.14.1

[PATCH v2 0/3] hwmon: Add reset support to aspeed-pwm-tach

[Joel Stanley]

Gunter,

This adds reset controller support to the ASPEED pwm/tach driver. The reset
controller and clock driver is currently under review, so to test those patches
must be merged in to fully test these changes[1].

To address your concerns from v1:

This driver was not usable as-is upstream. I believe the developer(s) tested and
deployed it in the OpenBMC kernel tree which has some hacks in mach-aspeed to
release all of the resets. The other way they could have tested it is by
booting an OpenBMC kernel, which releases the resets, and then testing the
upstream kernel without performing a power cycle as the resets are not
reasserted on reboot.

I realise it is not ideal to be changing already merged bindings. I don't plan
on it becoming a habit.

There is no BIOS or other ROM that runs before Linux on a BMC to release
the resets. We do have u-boot, but that does not modify the pwm reset.

I haven't added a Kconfig dependency on the RESET_CONTROLLER as the driver can
build without it, and when the ASPEED clk/reset driver is merged, the platform
will always have that option selected.

I've given this version a day of testing on hardware I have access to.

[1] https://lwn.net/Articles/737697/

Joel Stanley (3):
  hwmon: (aspeed-pwm-tacho) Sort headers
  hwmon: (aspeed-pwm-tacho) Deassert reset in probe
  dt-bindings: hwmon: aspeed-pwm-tacho: Add reset node

 .../devicetree/bindings/hwmon/aspeed-pwm-tacho.txt | 14 ++++-------
 drivers/hwmon/aspeed-pwm-tacho.c                   | 27 +++++++++++++++++++---
 2 files changed, 29 insertions(+), 12 deletions(-)

-- 
2.14.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/3] hwmon: (aspeed-pwm-tacho) Sort headers

[Joel Stanley]

Sort the headers in preperation for future changes.

Signed-off-by: Joel Stanley <joel@jms.id.au>
---
 drivers/hwmon/aspeed-pwm-tacho.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/hwmon/aspeed-pwm-tacho.c b/drivers/hwmon/aspeed-pwm-tacho.c
index f914e5f41048..63a95e23ca81 100644
--- a/drivers/hwmon/aspeed-pwm-tacho.c
+++ b/drivers/hwmon/aspeed-pwm-tacho.c
@@ -7,19 +7,19 @@
  */
 
 #include <linux/clk.h>
+#include <linux/delay.h>
 #include <linux/errno.h>
 #include <linux/gpio/consumer.h>
-#include <linux/delay.h>
 #include <linux/hwmon.h>
 #include <linux/hwmon-sysfs.h>
 #include <linux/io.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
-#include <linux/of_platform.h>
 #include <linux/of_device.h>
+#include <linux/of_platform.h>
 #include <linux/platform_device.h>
-#include <linux/sysfs.h>
 #include <linux/regmap.h>
+#include <linux/sysfs.h>
 #include <linux/thermal.h>
 
 /* ASPEED PWM & FAN Tach Register Definition */
-- 
2.14.1

[PATCH v2 2/3] hwmon: (aspeed-pwm-tacho) Deassert reset in probe

[Joel Stanley]

The ASPEED SoC must deassert a reset in order to use the PWM/tach
peripheral.

Signed-off-by: Joel Stanley <joel@jms.id.au>
---
v2:
 - Correct horrible mistakes
 - Boot tested and hwmon sysfs files checked
---
 drivers/hwmon/aspeed-pwm-tacho.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/drivers/hwmon/aspeed-pwm-tacho.c b/drivers/hwmon/aspeed-pwm-tacho.c
index 63a95e23ca81..77bb7a4bbed4 100644
--- a/drivers/hwmon/aspeed-pwm-tacho.c
+++ b/drivers/hwmon/aspeed-pwm-tacho.c
@@ -19,6 +19,7 @@
 #include <linux/of_platform.h>
 #include <linux/platform_device.h>
 #include <linux/regmap.h>
+#include <linux/reset.h>
 #include <linux/sysfs.h>
 #include <linux/thermal.h>
 
@@ -181,6 +182,7 @@ struct aspeed_cooling_device {
 
 struct aspeed_pwm_tacho_data {
 	struct regmap *regmap;
+	struct reset_control *rst;
 	unsigned long clk_freq;
 	bool pwm_present[8];
 	bool fan_tach_present[16];
@@ -931,6 +933,15 @@ static int aspeed_pwm_tacho_probe(struct platform_device *pdev)
 			&aspeed_pwm_tacho_regmap_config);
 	if (IS_ERR(priv->regmap))
 		return PTR_ERR(priv->regmap);
+
+	priv->rst = devm_reset_control_get_exclusive(dev, NULL);
+	if (IS_ERR(priv->rst)) {
+		dev_err(dev,
+			"missing or invalid reset controller device tree entry");
+		return PTR_ERR(priv->rst);
+	}
+	reset_control_deassert(priv->rst);
+
 	regmap_write(priv->regmap, ASPEED_PTCR_TACH_SOURCE, 0);
 	regmap_write(priv->regmap, ASPEED_PTCR_TACH_SOURCE_EXT, 0);
 
@@ -960,6 +971,15 @@ static int aspeed_pwm_tacho_probe(struct platform_device *pdev)
 	return PTR_ERR_OR_ZERO(hwmon);
 }
 
+static int aspeed_pwm_tacho_remove(struct platform_device *pdev)
+{
+	struct aspeed_pwm_tacho_data *priv = platform_get_drvdata(pdev);
+
+	reset_control_assert(priv->rst);
+
+	return 0;
+}
+
 static const struct of_device_id of_pwm_tacho_match_table[] = {
 	{ .compatible = "aspeed,ast2400-pwm-tacho", },
 	{ .compatible = "aspeed,ast2500-pwm-tacho", },
@@ -969,6 +989,7 @@ MODULE_DEVICE_TABLE(of, of_pwm_tacho_match_table);
 
 static struct platform_driver aspeed_pwm_tacho_driver = {
 	.probe		= aspeed_pwm_tacho_probe,
+	.remove 	= aspeed_pwm_tacho_remove,
 	.driver		= {
 		.name	= "aspeed_pwm_tacho",
 		.of_match_table = of_pwm_tacho_match_table,
-- 
2.14.1

[PATCH v2 2/3] hwmon: (aspeed-pwm-tacho) Deassert reset in probe

[Joel Stanley]

The ASPEED SoC must deassert a reset in order to use the PWM/tach
peripheral.

Signed-off-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
---
v2:
 - Correct horrible mistakes
 - Boot tested and hwmon sysfs files checked
---
 drivers/hwmon/aspeed-pwm-tacho.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/drivers/hwmon/aspeed-pwm-tacho.c b/drivers/hwmon/aspeed-pwm-tacho.c
index 63a95e23ca81..77bb7a4bbed4 100644
--- a/drivers/hwmon/aspeed-pwm-tacho.c
+++ b/drivers/hwmon/aspeed-pwm-tacho.c
@@ -19,6 +19,7 @@
 #include <linux/of_platform.h>
 #include <linux/platform_device.h>
 #include <linux/regmap.h>
+#include <linux/reset.h>
 #include <linux/sysfs.h>
 #include <linux/thermal.h>
 
@@ -181,6 +182,7 @@ struct aspeed_cooling_device {
 
 struct aspeed_pwm_tacho_data {
 	struct regmap *regmap;
+	struct reset_control *rst;
 	unsigned long clk_freq;
 	bool pwm_present[8];
 	bool fan_tach_present[16];
@@ -931,6 +933,15 @@ static int aspeed_pwm_tacho_probe(struct platform_device *pdev)
 			&aspeed_pwm_tacho_regmap_config);
 	if (IS_ERR(priv->regmap))
 		return PTR_ERR(priv->regmap);
+
+	priv->rst = devm_reset_control_get_exclusive(dev, NULL);
+	if (IS_ERR(priv->rst)) {
+		dev_err(dev,
+			"missing or invalid reset controller device tree entry");
+		return PTR_ERR(priv->rst);
+	}
+	reset_control_deassert(priv->rst);
+
 	regmap_write(priv->regmap, ASPEED_PTCR_TACH_SOURCE, 0);
 	regmap_write(priv->regmap, ASPEED_PTCR_TACH_SOURCE_EXT, 0);
 
@@ -960,6 +971,15 @@ static int aspeed_pwm_tacho_probe(struct platform_device *pdev)
 	return PTR_ERR_OR_ZERO(hwmon);
 }
 
+static int aspeed_pwm_tacho_remove(struct platform_device *pdev)
+{
+	struct aspeed_pwm_tacho_data *priv = platform_get_drvdata(pdev);
+
+	reset_control_assert(priv->rst);
+
+	return 0;
+}
+
 static const struct of_device_id of_pwm_tacho_match_table[] = {
 	{ .compatible = "aspeed,ast2400-pwm-tacho", },
 	{ .compatible = "aspeed,ast2500-pwm-tacho", },
@@ -969,6 +989,7 @@ MODULE_DEVICE_TABLE(of, of_pwm_tacho_match_table);
 
 static struct platform_driver aspeed_pwm_tacho_driver = {
 	.probe		= aspeed_pwm_tacho_probe,
+	.remove 	= aspeed_pwm_tacho_remove,
 	.driver		= {
 		.name	= "aspeed_pwm_tacho",
 		.of_match_table = of_pwm_tacho_match_table,
-- 
2.14.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/3] dt-bindings: hwmon: aspeed-pwm-tacho: Add reset node

[Joel Stanley]

The device tree bindings are updated to document the resets phandle, and
the example is updated to match what is expected for both the reset and
clock phandle.

Note that the bindings should have always had the reset controller, as
the hardware is unusable without it.

Signed-off-by: Joel Stanley <joel@jms.id.au>
---
 .../devicetree/bindings/hwmon/aspeed-pwm-tacho.txt         | 14 +++++---------
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt b/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
index 367c8203213b..3ac02988a1a5 100644
--- a/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
+++ b/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
@@ -22,8 +22,9 @@ Required properties for pwm-tacho node:
 - compatible : should be "aspeed,ast2400-pwm-tacho" for AST2400 and
 	       "aspeed,ast2500-pwm-tacho" for AST2500.
 
-- clocks : a fixed clock providing input clock frequency(PWM
-	   and Fan Tach clock)
+- clocks : phandle to clock provider with the clock number in the second cell
+
+- resets : phandle to reset controller with the reset number in the second cell
 
 fan subnode format:
 ===================
@@ -48,19 +49,14 @@ Required properties for each child node:
 
 Examples:
 
-pwm_tacho_fixed_clk: fixedclk {
-	compatible = "fixed-clock";
-	#clock-cells = <0>;
-	clock-frequency = <24000000>;
-};
-
 pwm_tacho: pwmtachocontroller@1e786000 {
 	#address-cells = <1>;
 	#size-cells = <1>;
 	#cooling-cells = <2>;
 	reg = <0x1E786000 0x1000>;
 	compatible = "aspeed,ast2500-pwm-tacho";
-	clocks = <&pwm_tacho_fixed_clk>;
+	clocks = <&syscon ASPEED_CLK_APB>;
+	resets = <&syscon ASPEED_RESET_PWM>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_pwm0_default &pinctrl_pwm1_default>;
 
-- 
2.14.1

Re: [PATCH v2 2/3] hwmon: (aspeed-pwm-tacho) Deassert reset in probe

[Guenter Roeck]

On Thu, Nov 02, 2017 at 02:53:48PM +1100, Joel Stanley wrote:
> The ASPEED SoC must deassert a reset in order to use the PWM/tach
> peripheral.
> 
Again, you claim that the current driver would not work at all, which
is simply not correct. It doesn't work if the chip wasn't taken out
of reset by other means. This doesn't take into account situations and
hardware where the chip is taken out of reset automatically at boot,
or by the ROM monitor/BIOS. It assumes that the reset pin can _always_
be controlled by software.

Similar, it forces the chip into reset when the driver is removed,
which is even worse. Unload the driver, and no more fan control ?
Really ? Then why is there an autonomous chip for fan control
to start with ? This is questionable even if the reset pin is
optional.

You'll have to make reset handling optional for me to accept it.
I am quite sure that I said that before.

Guenter

> Signed-off-by: Joel Stanley <joel@jms.id.au>
> ---
> v2:
>  - Correct horrible mistakes
>  - Boot tested and hwmon sysfs files checked
> ---
>  drivers/hwmon/aspeed-pwm-tacho.c | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
> 
> diff --git a/drivers/hwmon/aspeed-pwm-tacho.c b/drivers/hwmon/aspeed-pwm-tacho.c
> index 63a95e23ca81..77bb7a4bbed4 100644
> --- a/drivers/hwmon/aspeed-pwm-tacho.c
> +++ b/drivers/hwmon/aspeed-pwm-tacho.c
> @@ -19,6 +19,7 @@
>  #include <linux/of_platform.h>
>  #include <linux/platform_device.h>
>  #include <linux/regmap.h>
> +#include <linux/reset.h>
>  #include <linux/sysfs.h>
>  #include <linux/thermal.h>
>  
> @@ -181,6 +182,7 @@ struct aspeed_cooling_device {
>  
>  struct aspeed_pwm_tacho_data {
>  	struct regmap *regmap;
> +	struct reset_control *rst;
>  	unsigned long clk_freq;
>  	bool pwm_present[8];
>  	bool fan_tach_present[16];
> @@ -931,6 +933,15 @@ static int aspeed_pwm_tacho_probe(struct platform_device *pdev)
>  			&aspeed_pwm_tacho_regmap_config);
>  	if (IS_ERR(priv->regmap))
>  		return PTR_ERR(priv->regmap);
> +
> +	priv->rst = devm_reset_control_get_exclusive(dev, NULL);
> +	if (IS_ERR(priv->rst)) {
> +		dev_err(dev,
> +			"missing or invalid reset controller device tree entry");
> +		return PTR_ERR(priv->rst);
> +	}
> +	reset_control_deassert(priv->rst);
> +
>  	regmap_write(priv->regmap, ASPEED_PTCR_TACH_SOURCE, 0);
>  	regmap_write(priv->regmap, ASPEED_PTCR_TACH_SOURCE_EXT, 0);
>  
> @@ -960,6 +971,15 @@ static int aspeed_pwm_tacho_probe(struct platform_device *pdev)
>  	return PTR_ERR_OR_ZERO(hwmon);
>  }
>  
> +static int aspeed_pwm_tacho_remove(struct platform_device *pdev)
> +{
> +	struct aspeed_pwm_tacho_data *priv = platform_get_drvdata(pdev);
> +
> +	reset_control_assert(priv->rst);
> +
> +	return 0;
> +}
> +
>  static const struct of_device_id of_pwm_tacho_match_table[] = {
>  	{ .compatible = "aspeed,ast2400-pwm-tacho", },
>  	{ .compatible = "aspeed,ast2500-pwm-tacho", },
> @@ -969,6 +989,7 @@ MODULE_DEVICE_TABLE(of, of_pwm_tacho_match_table);
>  
>  static struct platform_driver aspeed_pwm_tacho_driver = {
>  	.probe		= aspeed_pwm_tacho_probe,
> +	.remove 	= aspeed_pwm_tacho_remove,
>  	.driver		= {
>  		.name	= "aspeed_pwm_tacho",
>  		.of_match_table = of_pwm_tacho_match_table,
> -- 
> 2.14.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/3] hwmon: (aspeed-pwm-tacho) Deassert reset in probe

[Joel Stanley]

On Fri, Nov 3, 2017 at 1:54 AM, Guenter Roeck <linux@roeck-us.net> wrote:
> On Thu, Nov 02, 2017 at 02:53:48PM +1100, Joel Stanley wrote:
>> The ASPEED SoC must deassert a reset in order to use the PWM/tach
>> peripheral.
>>
> Again, you claim that the current driver would not work at all, which
> is simply not correct. It doesn't work if the chip wasn't taken out
> of reset by other means. This doesn't take into account situations and
> hardware where the chip is taken out of reset automatically at boot, h
> or by the ROM monitor/BIOS. It assumes that the reset pin can _always_
> be controlled by software.

The reset is internal to the SoC. There is no pin to speak of, just a
wire inside the SoC, so it can always be controlled by software.

There's SoC does not release any resets automatically; the default
value on boot is for the reset to be asserted and this is not
configurable.

> Similar, it forces the chip into reset when the driver is removed,
> which is even worse. Unload the driver, and no more fan control ?
> Really ? Then why is there an autonomous chip for fan control
> to start with ? This is questionable even if the reset pin is
> optional.

Similarly, the PWM/Tach unit is inside the SoC; it's not an external device.

It would be strange to remove the driver and expect the system to keep
operating normally.

> You'll have to make reset handling optional for me to accept it.
> I am quite sure that I said that before.

Please reconsider in light of the details above. It does not make any
sense to build a system without this reset.

Cheers,

Joel

>
> Guenter
>
>> Signed-off-by: Joel Stanley <joel@jms.id.au>
>> ---
>> v2:
>>  - Correct horrible mistakes
>>  - Boot tested and hwmon sysfs files checked
>> ---
>>  drivers/hwmon/aspeed-pwm-tacho.c | 21 +++++++++++++++++++++
>>  1 file changed, 21 insertions(+)
>>
>> diff --git a/drivers/hwmon/aspeed-pwm-tacho.c b/drivers/hwmon/aspeed-pwm-tacho.c
>> index 63a95e23ca81..77bb7a4bbed4 100644
>> --- a/drivers/hwmon/aspeed-pwm-tacho.c
>> +++ b/drivers/hwmon/aspeed-pwm-tacho.c
>> @@ -19,6 +19,7 @@
>>  #include <linux/of_platform.h>
>>  #include <linux/platform_device.h>
>>  #include <linux/regmap.h>
>> +#include <linux/reset.h>
>>  #include <linux/sysfs.h>
>>  #include <linux/thermal.h>
>>
>> @@ -181,6 +182,7 @@ struct aspeed_cooling_device {
>>
>>  struct aspeed_pwm_tacho_data {
>>       struct regmap *regmap;
>> +     struct reset_control *rst;
>>       unsigned long clk_freq;
>>       bool pwm_present[8];
>>       bool fan_tach_present[16];
>> @@ -931,6 +933,15 @@ static int aspeed_pwm_tacho_probe(struct platform_device *pdev)
>>                       &aspeed_pwm_tacho_regmap_config);
>>       if (IS_ERR(priv->regmap))
>>               return PTR_ERR(priv->regmap);
>> +
>> +     priv->rst = devm_reset_control_get_exclusive(dev, NULL);
>> +     if (IS_ERR(priv->rst)) {
>> +             dev_err(dev,
>> +                     "missing or invalid reset controller device tree entry");
>> +             return PTR_ERR(priv->rst);
>> +     }
>> +     reset_control_deassert(priv->rst);
>> +
>>       regmap_write(priv->regmap, ASPEED_PTCR_TACH_SOURCE, 0);
>>       regmap_write(priv->regmap, ASPEED_PTCR_TACH_SOURCE_EXT, 0);
>>
>> @@ -960,6 +971,15 @@ static int aspeed_pwm_tacho_probe(struct platform_device *pdev)
>>       return PTR_ERR_OR_ZERO(hwmon);
>>  }
>>
>> +static int aspeed_pwm_tacho_remove(struct platform_device *pdev)
>> +{
>> +     struct aspeed_pwm_tacho_data *priv = platform_get_drvdata(pdev);
>> +
>> +     reset_control_assert(priv->rst);
>> +
>> +     return 0;
>> +}
>> +
>>  static const struct of_device_id of_pwm_tacho_match_table[] = {
>>       { .compatible = "aspeed,ast2400-pwm-tacho", },
>>       { .compatible = "aspeed,ast2500-pwm-tacho", },
>> @@ -969,6 +989,7 @@ MODULE_DEVICE_TABLE(of, of_pwm_tacho_match_table);
>>
>>  static struct platform_driver aspeed_pwm_tacho_driver = {
>>       .probe          = aspeed_pwm_tacho_probe,
>> +     .remove         = aspeed_pwm_tacho_remove,
>>       .driver         = {
>>               .name   = "aspeed_pwm_tacho",
>>               .of_match_table = of_pwm_tacho_match_table,
>> --
>> 2.14.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/3] hwmon: (aspeed-pwm-tacho) Deassert reset in probe

[Joel Stanley]

On Fri, Nov 3, 2017 at 1:54 AM, Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org> wrote:
> On Thu, Nov 02, 2017 at 02:53:48PM +1100, Joel Stanley wrote:
>> The ASPEED SoC must deassert a reset in order to use the PWM/tach
>> peripheral.
>>
> Again, you claim that the current driver would not work at all, which
> is simply not correct. It doesn't work if the chip wasn't taken out
> of reset by other means. This doesn't take into account situations and
> hardware where the chip is taken out of reset automatically at boot, h
> or by the ROM monitor/BIOS. It assumes that the reset pin can _always_
> be controlled by software.

The reset is internal to the SoC. There is no pin to speak of, just a
wire inside the SoC, so it can always be controlled by software.

There's SoC does not release any resets automatically; the default
value on boot is for the reset to be asserted and this is not
configurable.

> Similar, it forces the chip into reset when the driver is removed,
> which is even worse. Unload the driver, and no more fan control ?
> Really ? Then why is there an autonomous chip for fan control
> to start with ? This is questionable even if the reset pin is
> optional.

Similarly, the PWM/Tach unit is inside the SoC; it's not an external device.

It would be strange to remove the driver and expect the system to keep
operating normally.

> You'll have to make reset handling optional for me to accept it.
> I am quite sure that I said that before.

Please reconsider in light of the details above. It does not make any
sense to build a system without this reset.

Cheers,

Joel

>
> Guenter
>
>> Signed-off-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
>> ---
>> v2:
>>  - Correct horrible mistakes
>>  - Boot tested and hwmon sysfs files checked
>> ---
>>  drivers/hwmon/aspeed-pwm-tacho.c | 21 +++++++++++++++++++++
>>  1 file changed, 21 insertions(+)
>>
>> diff --git a/drivers/hwmon/aspeed-pwm-tacho.c b/drivers/hwmon/aspeed-pwm-tacho.c
>> index 63a95e23ca81..77bb7a4bbed4 100644
>> --- a/drivers/hwmon/aspeed-pwm-tacho.c
>> +++ b/drivers/hwmon/aspeed-pwm-tacho.c
>> @@ -19,6 +19,7 @@
>>  #include <linux/of_platform.h>
>>  #include <linux/platform_device.h>
>>  #include <linux/regmap.h>
>> +#include <linux/reset.h>
>>  #include <linux/sysfs.h>
>>  #include <linux/thermal.h>
>>
>> @@ -181,6 +182,7 @@ struct aspeed_cooling_device {
>>
>>  struct aspeed_pwm_tacho_data {
>>       struct regmap *regmap;
>> +     struct reset_control *rst;
>>       unsigned long clk_freq;
>>       bool pwm_present[8];
>>       bool fan_tach_present[16];
>> @@ -931,6 +933,15 @@ static int aspeed_pwm_tacho_probe(struct platform_device *pdev)
>>                       &aspeed_pwm_tacho_regmap_config);
>>       if (IS_ERR(priv->regmap))
>>               return PTR_ERR(priv->regmap);
>> +
>> +     priv->rst = devm_reset_control_get_exclusive(dev, NULL);
>> +     if (IS_ERR(priv->rst)) {
>> +             dev_err(dev,
>> +                     "missing or invalid reset controller device tree entry");
>> +             return PTR_ERR(priv->rst);
>> +     }
>> +     reset_control_deassert(priv->rst);
>> +
>>       regmap_write(priv->regmap, ASPEED_PTCR_TACH_SOURCE, 0);
>>       regmap_write(priv->regmap, ASPEED_PTCR_TACH_SOURCE_EXT, 0);
>>
>> @@ -960,6 +971,15 @@ static int aspeed_pwm_tacho_probe(struct platform_device *pdev)
>>       return PTR_ERR_OR_ZERO(hwmon);
>>  }
>>
>> +static int aspeed_pwm_tacho_remove(struct platform_device *pdev)
>> +{
>> +     struct aspeed_pwm_tacho_data *priv = platform_get_drvdata(pdev);
>> +
>> +     reset_control_assert(priv->rst);
>> +
>> +     return 0;
>> +}
>> +
>>  static const struct of_device_id of_pwm_tacho_match_table[] = {
>>       { .compatible = "aspeed,ast2400-pwm-tacho", },
>>       { .compatible = "aspeed,ast2500-pwm-tacho", },
>> @@ -969,6 +989,7 @@ MODULE_DEVICE_TABLE(of, of_pwm_tacho_match_table);
>>
>>  static struct platform_driver aspeed_pwm_tacho_driver = {
>>       .probe          = aspeed_pwm_tacho_probe,
>> +     .remove         = aspeed_pwm_tacho_remove,
>>       .driver         = {
>>               .name   = "aspeed_pwm_tacho",
>>               .of_match_table = of_pwm_tacho_match_table,
>> --
>> 2.14.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/3] hwmon: (aspeed-pwm-tacho) Deassert reset in probe

[Guenter Roeck]

On 11/02/2017 07:32 PM, Joel Stanley wrote:
> On Fri, Nov 3, 2017 at 1:54 AM, Guenter Roeck <linux@roeck-us.net> wrote:
>> On Thu, Nov 02, 2017 at 02:53:48PM +1100, Joel Stanley wrote:
>>> The ASPEED SoC must deassert a reset in order to use the PWM/tach
>>> peripheral.
>>>
>> Again, you claim that the current driver would not work at all, which
>> is simply not correct. It doesn't work if the chip wasn't taken out
>> of reset by other means. This doesn't take into account situations and
>> hardware where the chip is taken out of reset automatically at boot, h
>> or by the ROM monitor/BIOS. It assumes that the reset pin can _always_
>> be controlled by software.
> 
> The reset is internal to the SoC. There is no pin to speak of, just a
> wire inside the SoC, so it can always be controlled by software.
> 
> There's SoC does not release any resets automatically; the default
> value on boot is for the reset to be asserted and this is not
> configurable.
> 
>> Similar, it forces the chip into reset when the driver is removed,
>> which is even worse. Unload the driver, and no more fan control ?
>> Really ? Then why is there an autonomous chip for fan control
>> to start with ? This is questionable even if the reset pin is
>> optional.
> 
> Similarly, the PWM/Tach unit is inside the SoC; it's not an external device.
> 
> It would be strange to remove the driver and expect the system to keep
> operating normally.
> 
>> You'll have to make reset handling optional for me to accept it.
>> I am quite sure that I said that before.
> 
> Please reconsider in light of the details above. It does not make any
> sense to build a system without this reset.
> 

So you are saying that this driver never worked ? Hard to believe.
I'll need input from other users.

Guenter

Re: [PATCH v2 2/3] hwmon: (aspeed-pwm-tacho) Deassert reset in probe

[Guenter Roeck]

On 11/02/2017 07:32 PM, Joel Stanley wrote:
> On Fri, Nov 3, 2017 at 1:54 AM, Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org> wrote:
>> On Thu, Nov 02, 2017 at 02:53:48PM +1100, Joel Stanley wrote:
>>> The ASPEED SoC must deassert a reset in order to use the PWM/tach
>>> peripheral.
>>>
>> Again, you claim that the current driver would not work at all, which
>> is simply not correct. It doesn't work if the chip wasn't taken out
>> of reset by other means. This doesn't take into account situations and
>> hardware where the chip is taken out of reset automatically at boot, h
>> or by the ROM monitor/BIOS. It assumes that the reset pin can _always_
>> be controlled by software.
> 
> The reset is internal to the SoC. There is no pin to speak of, just a
> wire inside the SoC, so it can always be controlled by software.
> 
> There's SoC does not release any resets automatically; the default
> value on boot is for the reset to be asserted and this is not
> configurable.
> 
>> Similar, it forces the chip into reset when the driver is removed,
>> which is even worse. Unload the driver, and no more fan control ?
>> Really ? Then why is there an autonomous chip for fan control
>> to start with ? This is questionable even if the reset pin is
>> optional.
> 
> Similarly, the PWM/Tach unit is inside the SoC; it's not an external device.
> 
> It would be strange to remove the driver and expect the system to keep
> operating normally.
> 
>> You'll have to make reset handling optional for me to accept it.
>> I am quite sure that I said that before.
> 
> Please reconsider in light of the details above. It does not make any
> sense to build a system without this reset.
> 

So you are saying that this driver never worked ? Hard to believe.
I'll need input from other users.

Guenter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v2,1/3] hwmon: (aspeed-pwm-tacho) Sort headers

[Guenter Roeck]

On Thu, Nov 02, 2017 at 02:53:47PM +1100, Joel wrote:
> Sort the headers in preperation for future changes.
> 
> Signed-off-by: Joel Stanley <joel@jms.id.au>

Applied to hwmon-next.

Thanks,
Guenter

> ---
>  drivers/hwmon/aspeed-pwm-tacho.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/hwmon/aspeed-pwm-tacho.c b/drivers/hwmon/aspeed-pwm-tacho.c
> index f914e5f41048..63a95e23ca81 100644
> --- a/drivers/hwmon/aspeed-pwm-tacho.c
> +++ b/drivers/hwmon/aspeed-pwm-tacho.c
> @@ -7,19 +7,19 @@
>   */
>  
>  #include <linux/clk.h>
> +#include <linux/delay.h>
>  #include <linux/errno.h>
>  #include <linux/gpio/consumer.h>
> -#include <linux/delay.h>
>  #include <linux/hwmon.h>
>  #include <linux/hwmon-sysfs.h>
>  #include <linux/io.h>
>  #include <linux/kernel.h>
>  #include <linux/module.h>
> -#include <linux/of_platform.h>
>  #include <linux/of_device.h>
> +#include <linux/of_platform.h>
>  #include <linux/platform_device.h>
> -#include <linux/sysfs.h>
>  #include <linux/regmap.h>
> +#include <linux/sysfs.h>
>  #include <linux/thermal.h>
>  
>  /* ASPEED PWM & FAN Tach Register Definition */

Re: [PATCH v2 3/3] dt-bindings: hwmon: aspeed-pwm-tacho: Add reset node

[Rob Herring]

On Thu, Nov 02, 2017 at 02:53:49PM +1100, Joel Stanley wrote:
> The device tree bindings are updated to document the resets phandle, and
> the example is updated to match what is expected for both the reset and
> clock phandle.
> 
> Note that the bindings should have always had the reset controller, as
> the hardware is unusable without it.
> 
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> ---
>  .../devicetree/bindings/hwmon/aspeed-pwm-tacho.txt         | 14 +++++---------
>  1 file changed, 5 insertions(+), 9 deletions(-)

Acked-by: Rob Herring <robh@kernel.org>

Re: [PATCH v2 3/3] dt-bindings: hwmon: aspeed-pwm-tacho: Add reset node

[Rob Herring]

On Thu, Nov 02, 2017 at 02:53:49PM +1100, Joel Stanley wrote:
> The device tree bindings are updated to document the resets phandle, and
> the example is updated to match what is expected for both the reset and
> clock phandle.
> 
> Note that the bindings should have always had the reset controller, as
> the hardware is unusable without it.
> 
> Signed-off-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
> ---
>  .../devicetree/bindings/hwmon/aspeed-pwm-tacho.txt         | 14 +++++---------
>  1 file changed, 5 insertions(+), 9 deletions(-)

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v2,2/3] hwmon: (aspeed-pwm-tacho) Deassert reset in probe

[Guenter Roeck]

On Thu, Nov 02, 2017 at 02:53:48PM +1100, Joel wrote:
> The ASPEED SoC must deassert a reset in order to use the PWM/tach
> peripheral.
> 
> Signed-off-by: Joel Stanley <joel@jms.id.au>

I have not heard from anyone objecting to this change, so I am going to
accept it. See below for a list of changes required to get there.

> ---
> v2:
>  - Correct horrible mistakes
>  - Boot tested and hwmon sysfs files checked
> ---
>  drivers/hwmon/aspeed-pwm-tacho.c | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
> 
> diff --git a/drivers/hwmon/aspeed-pwm-tacho.c b/drivers/hwmon/aspeed-pwm-tacho.c
> index 63a95e23ca81..77bb7a4bbed4 100644
> --- a/drivers/hwmon/aspeed-pwm-tacho.c
> +++ b/drivers/hwmon/aspeed-pwm-tacho.c
> @@ -19,6 +19,7 @@
>  #include <linux/of_platform.h>
>  #include <linux/platform_device.h>
>  #include <linux/regmap.h>
> +#include <linux/reset.h>
>  #include <linux/sysfs.h>
>  #include <linux/thermal.h>
>  
> @@ -181,6 +182,7 @@ struct aspeed_cooling_device {
>  
>  struct aspeed_pwm_tacho_data {
>  	struct regmap *regmap;
> +	struct reset_control *rst;
>  	unsigned long clk_freq;
>  	bool pwm_present[8];
>  	bool fan_tach_present[16];
> @@ -931,6 +933,15 @@ static int aspeed_pwm_tacho_probe(struct platform_device *pdev)
>  			&aspeed_pwm_tacho_regmap_config);
>  	if (IS_ERR(priv->regmap))
>  		return PTR_ERR(priv->regmap);
> +
> +	priv->rst = devm_reset_control_get_exclusive(dev, NULL);
> +	if (IS_ERR(priv->rst)) {
> +		dev_err(dev,
> +			"missing or invalid reset controller device tree entry");
> +		return PTR_ERR(priv->rst);
> +	}
> +	reset_control_deassert(priv->rst);
> +
>  	regmap_write(priv->regmap, ASPEED_PTCR_TACH_SOURCE, 0);
>  	regmap_write(priv->regmap, ASPEED_PTCR_TACH_SOURCE_EXT, 0);
>  
> @@ -960,6 +971,15 @@ static int aspeed_pwm_tacho_probe(struct platform_device *pdev)
>  	return PTR_ERR_OR_ZERO(hwmon);
>  }
>  
> +static int aspeed_pwm_tacho_remove(struct platform_device *pdev)
> +{
> +	struct aspeed_pwm_tacho_data *priv = platform_get_drvdata(pdev);
> +
> +	reset_control_assert(priv->rst);

This asserts reset before the hwmon device is removed. Please use
devm_add_action_or_reset() after reset_control_deassert() to avoid
this problem.

> +
> +	return 0;
> +}
> +
>  static const struct of_device_id of_pwm_tacho_match_table[] = {
>  	{ .compatible = "aspeed,ast2400-pwm-tacho", },
>  	{ .compatible = "aspeed,ast2500-pwm-tacho", },
> @@ -969,6 +989,7 @@ MODULE_DEVICE_TABLE(of, of_pwm_tacho_match_table);
>  
>  static struct platform_driver aspeed_pwm_tacho_driver = {
>  	.probe		= aspeed_pwm_tacho_probe,
> +	.remove 	= aspeed_pwm_tacho_remove,

... and by doing that you won't need the remove function, and you don't
have to fix the checkpatch error here.

>  	.driver		= {
>  		.name	= "aspeed_pwm_tacho",
>  		.of_match_table = of_pwm_tacho_match_table,

Re: [v2,2/3] hwmon: (aspeed-pwm-tacho) Deassert reset in probe

[Guenter Roeck]

On Thu, Nov 02, 2017 at 02:53:48PM +1100, Joel wrote:
> The ASPEED SoC must deassert a reset in order to use the PWM/tach
> peripheral.
> 
> Signed-off-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>

I have not heard from anyone objecting to this change, so I am going to
accept it. See below for a list of changes required to get there.

> ---
> v2:
>  - Correct horrible mistakes
>  - Boot tested and hwmon sysfs files checked
> ---
>  drivers/hwmon/aspeed-pwm-tacho.c | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
> 
> diff --git a/drivers/hwmon/aspeed-pwm-tacho.c b/drivers/hwmon/aspeed-pwm-tacho.c
> index 63a95e23ca81..77bb7a4bbed4 100644
> --- a/drivers/hwmon/aspeed-pwm-tacho.c
> +++ b/drivers/hwmon/aspeed-pwm-tacho.c
> @@ -19,6 +19,7 @@
>  #include <linux/of_platform.h>
>  #include <linux/platform_device.h>
>  #include <linux/regmap.h>
> +#include <linux/reset.h>
>  #include <linux/sysfs.h>
>  #include <linux/thermal.h>
>  
> @@ -181,6 +182,7 @@ struct aspeed_cooling_device {
>  
>  struct aspeed_pwm_tacho_data {
>  	struct regmap *regmap;
> +	struct reset_control *rst;
>  	unsigned long clk_freq;
>  	bool pwm_present[8];
>  	bool fan_tach_present[16];
> @@ -931,6 +933,15 @@ static int aspeed_pwm_tacho_probe(struct platform_device *pdev)
>  			&aspeed_pwm_tacho_regmap_config);
>  	if (IS_ERR(priv->regmap))
>  		return PTR_ERR(priv->regmap);
> +
> +	priv->rst = devm_reset_control_get_exclusive(dev, NULL);
> +	if (IS_ERR(priv->rst)) {
> +		dev_err(dev,
> +			"missing or invalid reset controller device tree entry");
> +		return PTR_ERR(priv->rst);
> +	}
> +	reset_control_deassert(priv->rst);
> +
>  	regmap_write(priv->regmap, ASPEED_PTCR_TACH_SOURCE, 0);
>  	regmap_write(priv->regmap, ASPEED_PTCR_TACH_SOURCE_EXT, 0);
>  
> @@ -960,6 +971,15 @@ static int aspeed_pwm_tacho_probe(struct platform_device *pdev)
>  	return PTR_ERR_OR_ZERO(hwmon);
>  }
>  
> +static int aspeed_pwm_tacho_remove(struct platform_device *pdev)
> +{
> +	struct aspeed_pwm_tacho_data *priv = platform_get_drvdata(pdev);
> +
> +	reset_control_assert(priv->rst);

This asserts reset before the hwmon device is removed. Please use
devm_add_action_or_reset() after reset_control_deassert() to avoid
this problem.

> +
> +	return 0;
> +}
> +
>  static const struct of_device_id of_pwm_tacho_match_table[] = {
>  	{ .compatible = "aspeed,ast2400-pwm-tacho", },
>  	{ .compatible = "aspeed,ast2500-pwm-tacho", },
> @@ -969,6 +989,7 @@ MODULE_DEVICE_TABLE(of, of_pwm_tacho_match_table);
>  
>  static struct platform_driver aspeed_pwm_tacho_driver = {
>  	.probe		= aspeed_pwm_tacho_probe,
> +	.remove 	= aspeed_pwm_tacho_remove,

... and by doing that you won't need the remove function, and you don't
have to fix the checkpatch error here.

>  	.driver		= {
>  		.name	= "aspeed_pwm_tacho",
>  		.of_match_table = of_pwm_tacho_match_table,
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html