devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v4 00/11] Add support for Kontron sl28cpld
@ 2020-06-04 21:10 Michael Walle
  2020-06-04 21:10 ` [PATCH v4 01/11] dt-bindings: mfd: Add bindings for sl28cpld Michael Walle
                   ` (11 more replies)
  0 siblings, 12 replies; 74+ messages in thread
From: Michael Walle @ 2020-06-04 21:10 UTC (permalink / raw)
  To: linux-gpio, devicetree, linux-kernel, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm-kernel
  Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Jean Delvare,
	Guenter Roeck, Lee Jones, Thierry Reding, Uwe Kleine-König,
	Wim Van Sebroeck, Shawn Guo, Li Yang, Thomas Gleixner,
	Jason Cooper, Marc Zyngier, Mark Brown, Greg Kroah-Hartman,
	Andy Shevchenko, Michael Walle

The Kontron sl28cpld is a board management chip providing gpio, pwm, fan
monitoring and an interrupt controller. For now this controller is used on
the Kontron SMARC-sAL28 board. But because of its flexible nature, it
might also be used on other boards in the future. The individual blocks
(like gpio, pwm, etc) are kept intentionally small. The MFD core driver
then instantiates different (or multiple of the same) blocks. It also
provides the register layout so it might be updated in the future without a
device tree change; and support other boards with a different layout or
functionalities.

See also [1] for more information.

This is my first take of a MFD driver. I don't know whether the subsystem
maintainers should only be CCed on the patches which affect the subsystem
or on all patches for this series. I've chosen the latter so you can get a
more complete picture.

[1] https://lore.kernel.org/linux-devicetree/0e3e8204ab992d75aa07fc36af7e4ab2@walle.cc/

Changes since v3:
 - use of_platform_populate() to populate internal devices using the
   internal register offsets as unit-addresses
 - because we don't use mfd_cells anymore, we cannot use IORESOURCE_REG,
   but instead parse the reg property in each individual driver
 - dropped the following patches because they were already merged:
     gpiolib: Introduce gpiochip_irqchip_add_domain()
     gpio: add a reusable generic gpio_chip using regmap
 - dropped the following patches because they are no longer needed:
     include/linux/ioport.h: add helper to define REG resource constructs
     mfd: mfd-core: Don't overwrite the dma_mask of the child device
     mfd: mfd-core: match device tree node against reg property
 - rephrase commit messages, as suggested by Thomas Gleixner

Changes since v2:
As suggested by Guenter Roeck:
 - added sl28cpld.rst to index.rst
 - removed sl28cpld_wdt_status()
 - reverse christmas tree local variable ordering
 - assign device_property_read_bool() retval directly
 - introduce WDT_DEFAULT_TIMEOUT and use it if the hardware reports
   0 as timeout.
 - set WDOG_HW_RUNNING if applicable
 - remove platform_set_drvdata() leftover

As suggested by Bartosz Golaszewski:
 - don't export gpio_regmap_simple_xlate()
 - combine local variable declaration of the same type
 - drop the "struct gpio_regmap_addr", instead use -1 to force an address
   offset of zero
 - fix typo
 - use "struct gpio_regmap_config" pattern, keep "struct gpio_regmap"
   private. this also means we need a getter/setter for the driver_data
   element.

As suggested by Linus Walleij:
 - don't store irq_domain in gpio-regmap. drop to_irq() altogether for now.
   Instead there is now a new patch which lets us set the irqdomain of the
   gpiochip_irqchip and use its .to_irq() function. This way we don't have
   to expose the gpio_chip inside the gpio-regmap to the user.

Changes since v1:
 - use of_match_table in all drivers, needed for automatic module loading,
   when using OF_MFD_CELL()
 - add new gpio-regmap.c which adds a generic regmap gpio_chip
   implementation
 - new patch for reqmap_irq, so we can reuse its implementation
 - remove almost any code from gpio-sl28cpld.c, instead use gpio-regmap and
   regmap-irq
 - change the handling of the mfd core vs device tree nodes; add a new
   property "of_reg" to the mfd_cell struct which, when set, is matched to
   the unit-address of the device tree nodes.
 - fix sl28cpld watchdog when it is not initialized by the bootloader.
   Explicitly set the operation mode.
 - also add support for kontron,assert-wdt-timeout-pin in sl28cpld-wdt.

As suggested by Bartosz Golaszewski:
 - define registers as hex
 - make gpio enum uppercase
 - move parent regmap check before memory allocation
 - use device_property_read_bool() instead of the of_ version
 - mention the gpio flavors in the bindings documentation

As suggested by Guenter Roeck:
 - cleanup #includes and sort them
 - use devm_watchdog_register_device()
 - use watchdog_stop_on_reboot()
 - provide a Documentation/hwmon/sl28cpld.rst
 - cleaned up the weird tristate->bool and I2C=y issue. Instead mention
   that the MFD driver is bool because of the following intc patch
 - removed the SL28CPLD_IRQ typo

As suggested by Rob Herring:
 - combine all dt bindings docs into one patch
 - change the node name for all gpio flavors to "gpio"
 - removed the interrupts-extended rule
 - cleaned up the unit-address space, see above

Michael Walle (11):
  dt-bindings: mfd: Add bindings for sl28cpld
  mfd: Add support for Kontron sl28cpld management controller
  irqchip: add sl28cpld interrupt controller support
  watchdog: add support for sl28cpld watchdog
  pwm: add support for sl28cpld PWM controller
  gpio: add support for the sl28cpld GPIO controller
  hwmon: add support for the sl28cpld hardware monitoring controller
  arm64: dts: freescale: sl28: enable sl28cpld
  arm64: dts: freescale: sl28: map GPIOs to input events
  arm64: dts: freescale: sl28: enable LED support
  arm64: dts: freescale: sl28: enable fan support

 .../bindings/gpio/kontron,sl28cpld-gpio.yaml  |  54 ++++
 .../hwmon/kontron,sl28cpld-hwmon.yaml         |  27 ++
 .../kontron,sl28cpld-intc.yaml                |  54 ++++
 .../bindings/mfd/kontron,sl28cpld.yaml        | 153 ++++++++++++
 .../bindings/pwm/kontron,sl28cpld-pwm.yaml    |  35 +++
 .../watchdog/kontron,sl28cpld-wdt.yaml        |  35 +++
 Documentation/hwmon/index.rst                 |   1 +
 Documentation/hwmon/sl28cpld.rst              |  36 +++
 .../fsl-ls1028a-kontron-kbox-a-230-ls.dts     |  14 ++
 .../fsl-ls1028a-kontron-sl28-var3-ads2.dts    |   9 +
 .../freescale/fsl-ls1028a-kontron-sl28.dts    | 134 ++++++++++
 drivers/gpio/Kconfig                          |  11 +
 drivers/gpio/Makefile                         |   1 +
 drivers/gpio/gpio-sl28cpld.c                  | 180 ++++++++++++++
 drivers/hwmon/Kconfig                         |  10 +
 drivers/hwmon/Makefile                        |   1 +
 drivers/hwmon/sl28cpld-hwmon.c                | 150 ++++++++++++
 drivers/irqchip/Kconfig                       |   3 +
 drivers/irqchip/Makefile                      |   1 +
 drivers/irqchip/irq-sl28cpld.c                | 102 ++++++++
 drivers/mfd/Kconfig                           |  21 ++
 drivers/mfd/Makefile                          |   2 +
 drivers/mfd/sl28cpld.c                        |  79 ++++++
 drivers/pwm/Kconfig                           |  10 +
 drivers/pwm/Makefile                          |   1 +
 drivers/pwm/pwm-sl28cpld.c                    | 201 +++++++++++++++
 drivers/watchdog/Kconfig                      |  11 +
 drivers/watchdog/Makefile                     |   1 +
 drivers/watchdog/sl28cpld_wdt.c               | 231 ++++++++++++++++++
 29 files changed, 1568 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/kontron,sl28cpld-gpio.yaml
 create mode 100644 Documentation/devicetree/bindings/hwmon/kontron,sl28cpld-hwmon.yaml
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/kontron,sl28cpld-intc.yaml
 create mode 100644 Documentation/devicetree/bindings/mfd/kontron,sl28cpld.yaml
 create mode 100644 Documentation/devicetree/bindings/pwm/kontron,sl28cpld-pwm.yaml
 create mode 100644 Documentation/devicetree/bindings/watchdog/kontron,sl28cpld-wdt.yaml
 create mode 100644 Documentation/hwmon/sl28cpld.rst
 create mode 100644 drivers/gpio/gpio-sl28cpld.c
 create mode 100644 drivers/hwmon/sl28cpld-hwmon.c
 create mode 100644 drivers/irqchip/irq-sl28cpld.c
 create mode 100644 drivers/mfd/sl28cpld.c
 create mode 100644 drivers/pwm/pwm-sl28cpld.c
 create mode 100644 drivers/watchdog/sl28cpld_wdt.c

-- 
2.20.1


^ permalink raw reply	[flat|nested] 74+ messages in thread

* [PATCH v4 01/11] dt-bindings: mfd: Add bindings for sl28cpld
  2020-06-04 21:10 [PATCH v4 00/11] Add support for Kontron sl28cpld Michael Walle
@ 2020-06-04 21:10 ` Michael Walle
  2020-06-09 16:28   ` Rob Herring
  2020-06-04 21:10 ` [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller Michael Walle
                   ` (10 subsequent siblings)
  11 siblings, 1 reply; 74+ messages in thread
From: Michael Walle @ 2020-06-04 21:10 UTC (permalink / raw)
  To: linux-gpio, devicetree, linux-kernel, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm-kernel
  Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Jean Delvare,
	Guenter Roeck, Lee Jones, Thierry Reding, Uwe Kleine-König,
	Wim Van Sebroeck, Shawn Guo, Li Yang, Thomas Gleixner,
	Jason Cooper, Marc Zyngier, Mark Brown, Greg Kroah-Hartman,
	Andy Shevchenko, Michael Walle

Add a device tree bindings for the board management controller found on
the Kontron SMARC-sAL28 board.

Signed-off-by: Michael Walle <michael@walle.cc>
---
 .../bindings/gpio/kontron,sl28cpld-gpio.yaml  |  54 +++++++
 .../hwmon/kontron,sl28cpld-hwmon.yaml         |  27 ++++
 .../kontron,sl28cpld-intc.yaml                |  54 +++++++
 .../bindings/mfd/kontron,sl28cpld.yaml        | 153 ++++++++++++++++++
 .../bindings/pwm/kontron,sl28cpld-pwm.yaml    |  35 ++++
 .../watchdog/kontron,sl28cpld-wdt.yaml        |  35 ++++
 6 files changed, 358 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/kontron,sl28cpld-gpio.yaml
 create mode 100644 Documentation/devicetree/bindings/hwmon/kontron,sl28cpld-hwmon.yaml
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/kontron,sl28cpld-intc.yaml
 create mode 100644 Documentation/devicetree/bindings/mfd/kontron,sl28cpld.yaml
 create mode 100644 Documentation/devicetree/bindings/pwm/kontron,sl28cpld-pwm.yaml
 create mode 100644 Documentation/devicetree/bindings/watchdog/kontron,sl28cpld-wdt.yaml

diff --git a/Documentation/devicetree/bindings/gpio/kontron,sl28cpld-gpio.yaml b/Documentation/devicetree/bindings/gpio/kontron,sl28cpld-gpio.yaml
new file mode 100644
index 000000000000..9a63a158a796
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/kontron,sl28cpld-gpio.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/kontron,sl28cpld-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GPIO driver for the sl28cpld board management controller
+
+maintainers:
+  - Michael Walle <michael@walle.cc>
+
+description: |
+  This module is part of the sl28cpld multi-function device. For more
+  details see Documentation/devicetree/bindings/mfd/kontron,sl28cpld.yaml.
+
+  There are three flavors of the GPIO controller, one full featured
+  input/output with interrupt support (kontron,sl28cpld-gpio), one
+  output-only (kontron,sl28-gpo) and one input-only (kontron,sl28-gpi).
+
+  Each controller supports 8 GPIO lines.
+
+properties:
+  compatible:
+    enum:
+      - kontron,sl28cpld-gpio
+      - kontron,sl28cpld-gpi
+      - kontron,sl28cpld-gpo
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  "#interrupt-cells":
+    const: 2
+
+  interrupt-controller: true
+
+  "#gpio-cells":
+    const: 2
+
+  gpio-controller: true
+
+  gpio-line-names:
+      minItems: 1
+      maxItems: 8
+
+required:
+  - compatible
+  - "#gpio-cells"
+  - gpio-controller
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/hwmon/kontron,sl28cpld-hwmon.yaml b/Documentation/devicetree/bindings/hwmon/kontron,sl28cpld-hwmon.yaml
new file mode 100644
index 000000000000..1cebd61c6c32
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/kontron,sl28cpld-hwmon.yaml
@@ -0,0 +1,27 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/kontron,sl28cpld-hwmon.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Hardware monitoring driver for the sl28cpld board management controller
+
+maintainers:
+  - Michael Walle <michael@walle.cc>
+
+description: |
+  This module is part of the sl28cpld multi-function device. For more
+  details see Documentation/devicetree/bindings/mfd/kontron,sl28cpld.yaml.
+
+properties:
+  compatible:
+    enum:
+      - kontron,sl28cpld-fan
+
+  reg:
+    maxItems: 1
+
+required:
+  - compatible
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/interrupt-controller/kontron,sl28cpld-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/kontron,sl28cpld-intc.yaml
new file mode 100644
index 000000000000..4c39e9ff9aea
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/kontron,sl28cpld-intc.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/kontron,sl28cpld-intc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Interrupt controller driver for the sl28cpld board management controller
+
+maintainers:
+  - Michael Walle <michael@walle.cc>
+
+description: |
+  This module is part of the sl28cpld multi-function device. For more
+  details see Documentation/devicetree/bindings/mfd/kontron,sl28cpld.yaml.
+
+  The following interrupts are available. All types and levels are fixed
+  and handled by the board management controller.
+
+  ==== ============= ==================================
+   IRQ line/device   description
+  ==== ============= ==================================
+    0  RTC_INT#      Interrupt line from on-board RTC
+    1  SMB_ALERT#    Event on SMB_ALERT# line (P1)
+    2  ESPI_ALERT0#  Event on ESPI_ALERT0# line (S43)
+    3  ESPI_ALERT1#  Event on ESPI_ALERT1# line (S44)
+    4  PWR_BTN#      Event on PWR_BTN# line (P128)
+    5  SLEEP#        Event on SLEEP# line (S149)
+    6  watchdog      Interrupt of the internal watchdog
+    7  n/a           not used
+  ==== ============= ==================================
+
+properties:
+  compatible:
+    enum:
+      - kontron,sl28cpld-intc
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  "#interrupt-cells":
+    const: 2
+
+  interrupt-controller: true
+
+required:
+  - compatible
+  - interrupts
+  - "#interrupt-cells"
+  - interrupt-controller
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/mfd/kontron,sl28cpld.yaml b/Documentation/devicetree/bindings/mfd/kontron,sl28cpld.yaml
new file mode 100644
index 000000000000..1d13bb24afb8
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/kontron,sl28cpld.yaml
@@ -0,0 +1,153 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/kontron,sl28cpld.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Kontron's sl28cpld board management controller
+
+maintainers:
+  - Michael Walle <michael@walle.cc>
+
+description: |
+  The board management controller may contain different IP blocks like
+  watchdog, fan monitoring, PWM controller, interrupt controller and a
+  GPIO controller.
+
+properties:
+  compatible:
+    const: kontron,sl28cpld-r1
+
+  reg:
+    description:
+      I2C device address.
+    maxItems: 1
+
+  "#address-cells":
+    const: 1
+
+  "#size-cells":
+    const: 0
+
+  "#interrupt-cells":
+    const: 2
+
+  interrupts:
+    maxItems: 1
+
+  interrupt-controller: true
+
+patternProperties:
+  "^gpio(@[0-9]+)?$":
+    $ref: ../gpio/kontron,sl28cpld-gpio.yaml
+
+  "^hwmon(@[0-9]+)?$":
+    $ref: ../hwmon/kontron,sl28cpld-hwmon.yaml
+
+  "^interrupt-controller(@[0-9]+)?$":
+    $ref: ../interrupt-controller/kontron,sl28cpld-intc.yaml
+
+  "^pwm(@[0-9]+)?$":
+    $ref: ../pwm/kontron,sl28cpld-pwm.yaml
+
+  "^watchdog(@[0-9]+)?$":
+    $ref: ../watchdog/kontron,sl28cpld-wdt.yaml
+
+required:
+  - "#address-cells"
+  - "#size-cells"
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        sl28cpld@4a {
+            #address-cells = <1>;
+            #size-cells = <0>;
+            compatible = "kontron,sl28cpld-r1";
+            reg = <0x4a>;
+
+            watchdog@4 {
+                compatible = "kontron,sl28cpld-wdt";
+                reg = <0x4>;
+                kontron,assert-wdt-timeout-pin;
+            };
+
+            hwmon@b {
+                compatible = "kontron,sl28cpld-fan";
+                reg = <0xb>;
+            };
+
+            pwm@c {
+                #pwm-cells = <2>;
+                compatible = "kontron,sl28cpld-pwm";
+                reg = <0xc>;
+            };
+
+            pwm@e {
+                #pwm-cells = <2>;
+                compatible = "kontron,sl28cpld-pwm";
+                reg = <0xe>;
+            };
+
+            gpio@10 {
+                compatible = "kontron,sl28cpld-gpio";
+                reg = <0x10>;
+                interrupts-extended = <&gpio2 6
+                               IRQ_TYPE_EDGE_FALLING>;
+
+                gpio-controller;
+                #gpio-cells = <2>;
+                gpio-line-names = "a", "b", "c";
+
+                interrupt-controller;
+                #interrupt-cells = <2>;
+            };
+
+            gpio@15 {
+                compatible = "kontron,sl28cpld-gpio";
+                reg = <0x15>;
+                interrupts-extended = <&gpio2 6
+                               IRQ_TYPE_EDGE_FALLING>;
+
+                gpio-controller;
+                #gpio-cells = <2>;
+
+                interrupt-controller;
+                #interrupt-cells = <2>;
+            };
+
+            gpio@1a {
+                compatible = "kontron,sl28cpld-gpo";
+                reg = <0x1a>;
+
+                gpio-controller;
+                #gpio-cells = <2>;
+            };
+
+            gpio@1b {
+                compatible = "kontron,sl28cpld-gpi";
+                reg = <0x1b>;
+
+                gpio-controller;
+                #gpio-cells = <2>;
+            };
+
+            interrupt-controller@1c {
+                compatible = "kontron,sl28cpld-intc";
+                reg = <0x1c>;
+                interrupts-extended = <&gpio2 6
+                               IRQ_TYPE_EDGE_FALLING>;
+
+                interrupt-controller;
+                #interrupt-cells = <2>;
+            };
+        };
+    };
diff --git a/Documentation/devicetree/bindings/pwm/kontron,sl28cpld-pwm.yaml b/Documentation/devicetree/bindings/pwm/kontron,sl28cpld-pwm.yaml
new file mode 100644
index 000000000000..02fe88c30233
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/kontron,sl28cpld-pwm.yaml
@@ -0,0 +1,35 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/kontron,sl28cpld-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PWM driver for the sl28cpld board management controller
+
+maintainers:
+  - Michael Walle <michael@walle.cc>
+
+description: |
+  This module is part of the sl28cpld multi-function device. For more
+  details see Documentation/devicetree/bindings/mfd/kontron,sl28cpld.yaml.
+
+  The controller supports one PWM channel and supports only four distinct
+  frequencies (250Hz, 500Hz, 1kHz, 2kHz).
+
+allOf:
+  - $ref: pwm.yaml#
+
+properties:
+  compatible:
+    const: kontron,sl28cpld-pwm
+
+  reg:
+    maxItems: 1
+
+  "#pwm-cells":
+    const: 2
+
+required:
+  - compatible
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/watchdog/kontron,sl28cpld-wdt.yaml b/Documentation/devicetree/bindings/watchdog/kontron,sl28cpld-wdt.yaml
new file mode 100644
index 000000000000..dd6559f2973a
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/kontron,sl28cpld-wdt.yaml
@@ -0,0 +1,35 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/kontron,sl28cpld-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Watchdog driver for the sl28cpld board management controller
+
+maintainers:
+  - Michael Walle <michael@walle.cc>
+
+description: |
+  This module is part of the sl28cpld multi-function device. For more
+  details see Documentation/devicetree/bindings/mfd/kontron,sl28cpld.yaml.
+
+allOf:
+  - $ref: watchdog.yaml#
+
+properties:
+  compatible:
+    const: kontron,sl28cpld-wdt
+
+  reg:
+    maxItems: 1
+
+  kontron,assert-wdt-timeout-pin:
+    description: The SMARC standard defines a WDT_TIME_OUT# pin. If this
+      property is set, this output will be pulsed when the watchdog bites
+      and the system resets.
+    type: boolean
+
+required:
+  - compatible
+
+additionalProperties: false
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 74+ messages in thread

* [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-04 21:10 [PATCH v4 00/11] Add support for Kontron sl28cpld Michael Walle
  2020-06-04 21:10 ` [PATCH v4 01/11] dt-bindings: mfd: Add bindings for sl28cpld Michael Walle
@ 2020-06-04 21:10 ` Michael Walle
  2020-06-05  6:57   ` Lee Jones
  2020-06-05  8:01   ` Andy Shevchenko
  2020-06-04 21:10 ` [PATCH v4 03/11] irqchip: add sl28cpld interrupt controller support Michael Walle
                   ` (9 subsequent siblings)
  11 siblings, 2 replies; 74+ messages in thread
From: Michael Walle @ 2020-06-04 21:10 UTC (permalink / raw)
  To: linux-gpio, devicetree, linux-kernel, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm-kernel
  Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Jean Delvare,
	Guenter Roeck, Lee Jones, Thierry Reding, Uwe Kleine-König,
	Wim Van Sebroeck, Shawn Guo, Li Yang, Thomas Gleixner,
	Jason Cooper, Marc Zyngier, Mark Brown, Greg Kroah-Hartman,
	Andy Shevchenko, Michael Walle

Add the core support for the board management controller found on the
SMARC-sAL28 board. It consists of the following functions:
 - watchdog
 - GPIO controller
 - PWM controller
 - fan sensor
 - interrupt controller

At the moment, this controller is used on the Kontron SMARC-sAL28 board.

Please note that the MFD driver is defined as bool in the Kconfig
because the next patch will add interrupt support.

Signed-off-by: Michael Walle <michael@walle.cc>
---
 drivers/mfd/Kconfig    | 19 ++++++++++
 drivers/mfd/Makefile   |  2 ++
 drivers/mfd/sl28cpld.c | 79 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 100 insertions(+)
 create mode 100644 drivers/mfd/sl28cpld.c

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 4f8b73d92df3..5c0cd514d197 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -2109,5 +2109,24 @@ config SGI_MFD_IOC3
 	  If you have an SGI Origin, Octane, or a PCI IOC3 card,
 	  then say Y. Otherwise say N.
 
+config MFD_SL28CPLD
+	bool "Kontron sl28 core driver"
+	depends on I2C=y
+	depends on OF
+	select REGMAP_I2C
+	select MFD_CORE
+	help
+	  This option enables support for the board management controller
+	  found on the Kontron sl28 CPLD. You have to select individual
+	  functions, such as watchdog, GPIO, etc, under the corresponding menus
+	  in order to enable them.
+
+	  Currently supported boards are:
+
+		Kontron SMARC-sAL28
+
+	  To compile this driver as a module, choose M here: the module will be
+	  called sl28cpld.
+
 endmenu
 endif
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 9367a92f795a..be59fb40aa28 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -264,3 +264,5 @@ obj-$(CONFIG_MFD_ROHM_BD718XX)	+= rohm-bd718x7.o
 obj-$(CONFIG_MFD_STMFX) 	+= stmfx.o
 
 obj-$(CONFIG_SGI_MFD_IOC3)	+= ioc3.o
+
+obj-$(CONFIG_MFD_SL28CPLD)	+= sl28cpld.o
diff --git a/drivers/mfd/sl28cpld.c b/drivers/mfd/sl28cpld.c
new file mode 100644
index 000000000000..a23194bb6efa
--- /dev/null
+++ b/drivers/mfd/sl28cpld.c
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * MFD core for the sl28cpld.
+ *
+ * Copyright 2019 Kontron Europe GmbH
+ */
+
+#include <linux/i2c.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/mfd/core.h>
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/regmap.h>
+
+#define SL28CPLD_VERSION	0x03
+#define SL28CPLD_MIN_REQ_VERSION 14
+
+struct sl28cpld {
+	struct device *dev;
+	struct regmap *regmap;
+};
+
+static const struct regmap_config sl28cpld_regmap_config = {
+	.reg_bits = 8,
+	.val_bits = 8,
+	.reg_stride = 1,
+};
+
+static int sl28cpld_probe(struct i2c_client *i2c)
+{
+	struct sl28cpld *sl28cpld;
+	struct device *dev = &i2c->dev;
+	unsigned int cpld_version;
+	int ret;
+
+	sl28cpld = devm_kzalloc(dev, sizeof(*sl28cpld), GFP_KERNEL);
+	if (!sl28cpld)
+		return -ENOMEM;
+
+	sl28cpld->regmap = devm_regmap_init_i2c(i2c, &sl28cpld_regmap_config);
+	if (IS_ERR(sl28cpld->regmap))
+		return PTR_ERR(sl28cpld->regmap);
+
+	ret = regmap_read(sl28cpld->regmap, SL28CPLD_VERSION, &cpld_version);
+	if (ret)
+		return ret;
+
+	if (cpld_version < SL28CPLD_MIN_REQ_VERSION) {
+		dev_err(dev, "unsupported CPLD version %d\n", cpld_version);
+		return -ENODEV;
+	}
+
+	sl28cpld->dev = dev;
+	i2c_set_clientdata(i2c, sl28cpld);
+
+	dev_info(dev, "successfully probed. CPLD version %d\n", cpld_version);
+
+	return devm_of_platform_populate(&i2c->dev);
+}
+
+static const struct of_device_id sl28cpld_of_match[] = {
+	{ .compatible = "kontron,sl28cpld-r1", },
+	{}
+};
+MODULE_DEVICE_TABLE(of, sl28cpld_of_match);
+
+static struct i2c_driver sl28cpld_driver = {
+	.probe_new = sl28cpld_probe,
+	.driver = {
+		.name = "sl28cpld",
+		.of_match_table = of_match_ptr(sl28cpld_of_match),
+	},
+};
+module_i2c_driver(sl28cpld_driver);
+
+MODULE_DESCRIPTION("sl28cpld MFD Core Driver");
+MODULE_AUTHOR("Michael Walle <michael@walle.cc>");
+MODULE_LICENSE("GPL");
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 74+ messages in thread

* [PATCH v4 03/11] irqchip: add sl28cpld interrupt controller support
  2020-06-04 21:10 [PATCH v4 00/11] Add support for Kontron sl28cpld Michael Walle
  2020-06-04 21:10 ` [PATCH v4 01/11] dt-bindings: mfd: Add bindings for sl28cpld Michael Walle
  2020-06-04 21:10 ` [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller Michael Walle
@ 2020-06-04 21:10 ` Michael Walle
  2020-06-05  1:26   ` kernel test robot
                     ` (2 more replies)
  2020-06-04 21:10 ` [PATCH v4 04/11] watchdog: add support for sl28cpld watchdog Michael Walle
                   ` (8 subsequent siblings)
  11 siblings, 3 replies; 74+ messages in thread
From: Michael Walle @ 2020-06-04 21:10 UTC (permalink / raw)
  To: linux-gpio, devicetree, linux-kernel, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm-kernel
  Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Jean Delvare,
	Guenter Roeck, Lee Jones, Thierry Reding, Uwe Kleine-König,
	Wim Van Sebroeck, Shawn Guo, Li Yang, Thomas Gleixner,
	Jason Cooper, Marc Zyngier, Mark Brown, Greg Kroah-Hartman,
	Andy Shevchenko, Michael Walle

Add support for the interrupt controller inside the sl28 CPLD management
controller.

The interrupt controller can handle at most 8 interrupts and is really
simplistic and consists only of an interrupt mask and an interrupt
pending register.

Signed-off-by: Michael Walle <michael@walle.cc>
---
 drivers/irqchip/Kconfig        |   3 +
 drivers/irqchip/Makefile       |   1 +
 drivers/irqchip/irq-sl28cpld.c | 102 +++++++++++++++++++++++++++++++++
 drivers/mfd/Kconfig            |   2 +
 4 files changed, 108 insertions(+)
 create mode 100644 drivers/irqchip/irq-sl28cpld.c

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 3e473f4eb175..c4b840bc982e 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -246,6 +246,9 @@ config RENESAS_RZA1_IRQC
 	  Enable support for the Renesas RZ/A1 Interrupt Controller, to use up
 	  to 8 external interrupts with configurable sense select.
 
+config SL28CPLD_INTC
+	bool
+
 config ST_IRQCHIP
 	bool
 	select REGMAP
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 3a4ce283189a..bcd9797a5aed 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -110,3 +110,4 @@ obj-$(CONFIG_LOONGSON_HTPIC)		+= irq-loongson-htpic.o
 obj-$(CONFIG_LOONGSON_HTVEC)		+= irq-loongson-htvec.o
 obj-$(CONFIG_LOONGSON_PCH_PIC)		+= irq-loongson-pch-pic.o
 obj-$(CONFIG_LOONGSON_PCH_MSI)		+= irq-loongson-pch-msi.o
+obj-$(CONFIG_SL28CPLD_INTC)		+= irq-sl28cpld.o
diff --git a/drivers/irqchip/irq-sl28cpld.c b/drivers/irqchip/irq-sl28cpld.c
new file mode 100644
index 000000000000..2151f1b390d7
--- /dev/null
+++ b/drivers/irqchip/irq-sl28cpld.c
@@ -0,0 +1,102 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * sl28cpld interrupt controller driver.
+ *
+ * Copyright 2019 Kontron Europe GmbH
+ */
+
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/property.h>
+#include <linux/regmap.h>
+
+#define INTC_IE 0x00
+#define INTC_IP 0x01
+
+static const struct regmap_irq sl28cpld_irqs[] = {
+	REGMAP_IRQ_REG_LINE(0, 8),
+	REGMAP_IRQ_REG_LINE(1, 8),
+	REGMAP_IRQ_REG_LINE(2, 8),
+	REGMAP_IRQ_REG_LINE(3, 8),
+	REGMAP_IRQ_REG_LINE(4, 8),
+	REGMAP_IRQ_REG_LINE(5, 8),
+	REGMAP_IRQ_REG_LINE(6, 8),
+	REGMAP_IRQ_REG_LINE(7, 8),
+};
+
+struct sl28cpld_intc {
+	struct regmap *regmap;
+	struct regmap_irq_chip chip;
+	struct regmap_irq_chip_data *irq_data;
+};
+
+static int sl28cpld_intc_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct sl28cpld_intc *irqchip;
+	unsigned int irq;
+	u32 base;
+	int ret;
+
+	if (!dev->parent)
+		return -ENODEV;
+
+	irqchip = devm_kzalloc(dev, sizeof(*irqchip), GFP_KERNEL);
+	if (!irqchip)
+		return -ENOMEM;
+
+	irqchip->regmap = dev_get_regmap(dev->parent, NULL);
+	if (!irqchip->regmap)
+		return -ENODEV;
+
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0)
+		return irq;
+
+	ret = device_property_read_u32(&pdev->dev, "reg", &base);
+	if (ret)
+		return -EINVAL;
+
+	irqchip->chip.name = "sl28cpld-intc";
+	irqchip->chip.irqs = sl28cpld_irqs;
+	irqchip->chip.num_irqs = ARRAY_SIZE(sl28cpld_irqs);
+	irqchip->chip.num_regs = 1;
+	irqchip->chip.status_base = base + INTC_IP;
+	irqchip->chip.mask_base = base + INTC_IE;
+	irqchip->chip.mask_invert = true,
+	irqchip->chip.ack_base = base + INTC_IP;
+
+	return devm_regmap_add_irq_chip_np(&pdev->dev, dev->of_node,
+					   irqchip->regmap, irq,
+					   IRQF_SHARED | IRQF_ONESHOT, 0,
+					   &irqchip->chip, &irqchip->irq_data);
+}
+
+static const struct of_device_id sl28cpld_intc_of_match[] = {
+	{ .compatible = "kontron,sl28cpld-intc" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, sl28cpld_intc_of_match);
+
+static const struct platform_device_id sl28cpld_intc_id_table[] = {
+	{ "sl28cpld-intc" },
+	{}
+};
+MODULE_DEVICE_TABLE(platform, sl28cpld_intc_id_table);
+
+static struct platform_driver sl28cpld_intc_driver = {
+	.probe	= sl28cpld_intc_probe,
+	.id_table = sl28cpld_intc_id_table,
+	.driver = {
+		.name = KBUILD_MODNAME,
+		.of_match_table = sl28cpld_intc_of_match,
+	}
+};
+module_platform_driver(sl28cpld_intc_driver);
+
+MODULE_DESCRIPTION("sl28cpld Interrupt Controller Driver");
+MODULE_AUTHOR("Michael Walle <michael@walle.cc>");
+MODULE_LICENSE("GPL");
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 5c0cd514d197..9c84c5746698 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -2114,6 +2114,8 @@ config MFD_SL28CPLD
 	depends on I2C=y
 	depends on OF
 	select REGMAP_I2C
+	select REGMAP_IRQ
+	select SL28CPLD_INTC
 	select MFD_CORE
 	help
 	  This option enables support for the board management controller
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 74+ messages in thread

* [PATCH v4 04/11] watchdog: add support for sl28cpld watchdog
  2020-06-04 21:10 [PATCH v4 00/11] Add support for Kontron sl28cpld Michael Walle
                   ` (2 preceding siblings ...)
  2020-06-04 21:10 ` [PATCH v4 03/11] irqchip: add sl28cpld interrupt controller support Michael Walle
@ 2020-06-04 21:10 ` Michael Walle
  2020-06-05  8:14   ` Andy Shevchenko
  2020-06-04 21:10 ` [PATCH v4 05/11] pwm: add support for sl28cpld PWM controller Michael Walle
                   ` (7 subsequent siblings)
  11 siblings, 1 reply; 74+ messages in thread
From: Michael Walle @ 2020-06-04 21:10 UTC (permalink / raw)
  To: linux-gpio, devicetree, linux-kernel, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm-kernel
  Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Jean Delvare,
	Guenter Roeck, Lee Jones, Thierry Reding, Uwe Kleine-König,
	Wim Van Sebroeck, Shawn Guo, Li Yang, Thomas Gleixner,
	Jason Cooper, Marc Zyngier, Mark Brown, Greg Kroah-Hartman,
	Andy Shevchenko, Michael Walle

Add support for the watchdog of the sl28cpld board management
controller. This is part of a multi-function device driver.

Signed-off-by: Michael Walle <michael@walle.cc>
Acked-by: Guenter Roeck <linux@roeck-us.net>
---
 drivers/watchdog/Kconfig        |  11 ++
 drivers/watchdog/Makefile       |   1 +
 drivers/watchdog/sl28cpld_wdt.c | 231 ++++++++++++++++++++++++++++++++
 3 files changed, 243 insertions(+)
 create mode 100644 drivers/watchdog/sl28cpld_wdt.c

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 55b910c453da..2c7b0f10151e 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -340,6 +340,17 @@ config MLX_WDT
 	  To compile this driver as a module, choose M here: the
 	  module will be called mlx-wdt.
 
+config SL28CPLD_WATCHDOG
+	tristate "Kontron sl28 watchdog"
+	depends on MFD_SL28CPLD
+	select WATCHDOG_CORE
+	help
+	  Say Y here to include support for the watchdog timer
+	  on the Kontron sl28 CPLD.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called sl28cpld_wdt.
+
 # ALPHA Architecture
 
 # ARM Architecture
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 97bed1d3d97c..aa6e41126901 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -225,3 +225,4 @@ obj-$(CONFIG_MENF21BMC_WATCHDOG) += menf21bmc_wdt.o
 obj-$(CONFIG_MENZ069_WATCHDOG) += menz69_wdt.o
 obj-$(CONFIG_RAVE_SP_WATCHDOG) += rave-sp-wdt.o
 obj-$(CONFIG_STPMIC1_WATCHDOG) += stpmic1_wdt.o
+obj-$(CONFIG_SL28CPLD_WATCHDOG) += sl28cpld_wdt.o
diff --git a/drivers/watchdog/sl28cpld_wdt.c b/drivers/watchdog/sl28cpld_wdt.c
new file mode 100644
index 000000000000..6c9518dc454a
--- /dev/null
+++ b/drivers/watchdog/sl28cpld_wdt.c
@@ -0,0 +1,231 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * sl28cpld watchdog driver.
+ *
+ * Copyright 2019 Kontron Europe GmbH
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/watchdog.h>
+
+/*
+ * Watchdog timer block registers.
+ */
+#define WDT_CTRL			0x00
+#define  WDT_CTRL_EN			BIT(0)
+#define  WDT_CTRL_LOCK			BIT(2)
+#define  WDT_CTRL_ASSERT_SYS_RESET	BIT(6)
+#define  WDT_CTRL_ASSERT_WDT_TIMEOUT	BIT(7)
+#define WDT_TIMEOUT			0x01
+#define WDT_KICK			0x02
+#define  WDT_KICK_VALUE			0x6b
+#define WDT_COUNT			0x03
+
+#define WDT_DEFAULT_TIMEOUT		10
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, 0);
+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
+				__MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+static int timeout;
+module_param(timeout, int, 0);
+MODULE_PARM_DESC(timeout, "Initial watchdog timeout in seconds");
+
+struct sl28cpld_wdt {
+	struct watchdog_device wdd;
+	struct regmap *regmap;
+	u32 offset;
+	bool assert_wdt_timeout;
+};
+
+static int sl28cpld_wdt_ping(struct watchdog_device *wdd)
+{
+	struct sl28cpld_wdt *wdt = watchdog_get_drvdata(wdd);
+
+	return regmap_write(wdt->regmap, wdt->offset + WDT_KICK,
+			    WDT_KICK_VALUE);
+}
+
+static int sl28cpld_wdt_start(struct watchdog_device *wdd)
+{
+	struct sl28cpld_wdt *wdt = watchdog_get_drvdata(wdd);
+	unsigned int val;
+
+	val = WDT_CTRL_EN | WDT_CTRL_ASSERT_SYS_RESET;
+	if (wdt->assert_wdt_timeout)
+		val |= WDT_CTRL_ASSERT_WDT_TIMEOUT;
+	if (nowayout)
+		val |= WDT_CTRL_LOCK;
+
+	return regmap_update_bits(wdt->regmap, wdt->offset + WDT_CTRL,
+				  val, val);
+}
+
+static int sl28cpld_wdt_stop(struct watchdog_device *wdd)
+{
+	struct sl28cpld_wdt *wdt = watchdog_get_drvdata(wdd);
+
+	return regmap_update_bits(wdt->regmap, wdt->offset + WDT_CTRL,
+				  WDT_CTRL_EN, 0);
+}
+
+static unsigned int sl28cpld_wdt_get_timeleft(struct watchdog_device *wdd)
+{
+	struct sl28cpld_wdt *wdt = watchdog_get_drvdata(wdd);
+	unsigned int val;
+	int ret;
+
+	ret = regmap_read(wdt->regmap, wdt->offset + WDT_COUNT, &val);
+
+	return (ret < 0) ? 0 : val;
+}
+
+static int sl28cpld_wdt_set_timeout(struct watchdog_device *wdd,
+				    unsigned int timeout)
+{
+	struct sl28cpld_wdt *wdt = watchdog_get_drvdata(wdd);
+	int ret;
+
+	ret = regmap_write(wdt->regmap, wdt->offset + WDT_TIMEOUT, timeout);
+	if (!ret)
+		wdd->timeout = timeout;
+
+	return ret;
+}
+
+static const struct watchdog_info sl28cpld_wdt_info = {
+	.options = WDIOF_MAGICCLOSE | WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING,
+	.identity = "sl28cpld watchdog",
+};
+
+static struct watchdog_ops sl28cpld_wdt_ops = {
+	.owner = THIS_MODULE,
+	.start = sl28cpld_wdt_start,
+	.stop = sl28cpld_wdt_stop,
+	.ping = sl28cpld_wdt_ping,
+	.set_timeout = sl28cpld_wdt_set_timeout,
+	.get_timeleft = sl28cpld_wdt_get_timeleft,
+};
+
+static int sl28cpld_wdt_probe(struct platform_device *pdev)
+{
+	struct watchdog_device *wdd;
+	struct sl28cpld_wdt *wdt;
+	unsigned int status;
+	unsigned int val;
+	int ret;
+
+	if (!pdev->dev.parent)
+		return -ENODEV;
+
+	wdt = devm_kzalloc(&pdev->dev, sizeof(*wdt), GFP_KERNEL);
+	if (!wdt)
+		return -ENOMEM;
+
+	wdt->regmap = dev_get_regmap(pdev->dev.parent, NULL);
+	if (!wdt->regmap)
+		return -ENODEV;
+
+	ret = device_property_read_u32(&pdev->dev, "reg", &wdt->offset);
+	if (ret)
+		return -EINVAL;
+
+	wdt->assert_wdt_timeout = device_property_read_bool(&pdev->dev,
+							    "kontron,assert-wdt-timeout-pin");
+
+	/* initialize struct watchdog_device */
+	wdd = &wdt->wdd;
+	wdd->parent = &pdev->dev;
+	wdd->info = &sl28cpld_wdt_info;
+	wdd->ops = &sl28cpld_wdt_ops;
+	wdd->min_timeout = 1;
+	wdd->max_timeout = 255;
+
+	watchdog_set_drvdata(wdd, wdt);
+	watchdog_stop_on_reboot(wdd);
+
+	/*
+	 * Read the status early, in case of an error, we haven't modified the
+	 * hardware.
+	 */
+	ret = regmap_read(wdt->regmap, wdt->offset + WDT_CTRL, &status);
+	if (ret < 0)
+		return ret;
+
+	/*
+	 * Initial timeout value, may be overwritten by device tree or module
+	 * parmeter in watchdog_init_timeout().
+	 *
+	 * Reading a zero here means that either the hardware has a default
+	 * value of zero (which is very unlikely and definitely a hardware
+	 * bug) or the bootloader set it to zero. In any case, we handle
+	 * this case gracefully and set out own timeout.
+	 */
+	ret = regmap_read(wdt->regmap, wdt->offset + WDT_TIMEOUT, &val);
+	if (ret < 0)
+		return ret;
+
+	if (val)
+		wdd->timeout = val;
+	else
+		wdd->timeout = WDT_DEFAULT_TIMEOUT;
+
+	watchdog_init_timeout(wdd, timeout, &pdev->dev);
+	sl28cpld_wdt_set_timeout(wdd, wdd->timeout);
+
+	/* if the watchdog is locked, we set nowayout */
+	if (status & WDT_CTRL_LOCK)
+		nowayout = true;
+	watchdog_set_nowayout(wdd, nowayout);
+
+	/*
+	 * If watchdog is already running, keep it enabled, but make
+	 * sure its mode is set correctly.
+	 */
+	if (status & WDT_CTRL_EN) {
+		sl28cpld_wdt_start(wdd);
+		set_bit(WDOG_HW_RUNNING, &wdd->status);
+	}
+
+	ret = devm_watchdog_register_device(&pdev->dev, wdd);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to register watchdog device\n");
+		return ret;
+	}
+
+	dev_info(&pdev->dev, "initial timeout %d sec%s\n",
+		 wdd->timeout, nowayout ? ", nowayout" : "");
+
+	return 0;
+}
+
+static const struct of_device_id sl28cpld_wdt_of_match[] = {
+	{ .compatible = "kontron,sl28cpld-wdt" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, sl28cpld_wdt_of_match);
+
+static const struct platform_device_id sl28cpld_wdt_id_table[] = {
+	{ "sl28cpld-wdt" },
+	{},
+};
+MODULE_DEVICE_TABLE(platform, sl28cpld_wdt_id_table);
+
+static struct platform_driver sl28cpld_wdt_driver = {
+	.probe = sl28cpld_wdt_probe,
+	.id_table = sl28cpld_wdt_id_table,
+	.driver = {
+		.name = KBUILD_MODNAME,
+		.of_match_table = sl28cpld_wdt_of_match,
+	},
+};
+module_platform_driver(sl28cpld_wdt_driver);
+
+MODULE_DESCRIPTION("sl28cpld Watchdog Driver");
+MODULE_AUTHOR("Michael Walle <michael@walle.cc>");
+MODULE_LICENSE("GPL");
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 74+ messages in thread

* [PATCH v4 05/11] pwm: add support for sl28cpld PWM controller
  2020-06-04 21:10 [PATCH v4 00/11] Add support for Kontron sl28cpld Michael Walle
                   ` (3 preceding siblings ...)
  2020-06-04 21:10 ` [PATCH v4 04/11] watchdog: add support for sl28cpld watchdog Michael Walle
@ 2020-06-04 21:10 ` Michael Walle
  2020-06-05  8:15   ` Andy Shevchenko
  2020-06-05  8:49   ` Lee Jones
  2020-06-04 21:10 ` [PATCH v4 06/11] gpio: add support for the sl28cpld GPIO controller Michael Walle
                   ` (6 subsequent siblings)
  11 siblings, 2 replies; 74+ messages in thread
From: Michael Walle @ 2020-06-04 21:10 UTC (permalink / raw)
  To: linux-gpio, devicetree, linux-kernel, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm-kernel
  Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Jean Delvare,
	Guenter Roeck, Lee Jones, Thierry Reding, Uwe Kleine-König,
	Wim Van Sebroeck, Shawn Guo, Li Yang, Thomas Gleixner,
	Jason Cooper, Marc Zyngier, Mark Brown, Greg Kroah-Hartman,
	Andy Shevchenko, Michael Walle

Add support for the PWM controller of the sl28cpld board management
controller. This is part of a multi-function device driver.

The controller has one PWM channel and can just generate four distinct
frequencies.

Signed-off-by: Michael Walle <michael@walle.cc>
---
 drivers/pwm/Kconfig        |  10 ++
 drivers/pwm/Makefile       |   1 +
 drivers/pwm/pwm-sl28cpld.c | 201 +++++++++++++++++++++++++++++++++++++
 3 files changed, 212 insertions(+)
 create mode 100644 drivers/pwm/pwm-sl28cpld.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index cb8d739067d2..a39371c11ff6 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -437,6 +437,16 @@ config PWM_SIFIVE
 	  To compile this driver as a module, choose M here: the module
 	  will be called pwm-sifive.
 
+config PWM_SL28CPLD
+	tristate "Kontron sl28 PWM support"
+	depends on MFD_SL28CPLD
+	help
+	  Generic PWM framework driver for board management controller
+	  found on the Kontron sl28 CPLD.
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called pwm-sl28cpld.
+
 config PWM_SPEAR
 	tristate "STMicroelectronics SPEAr PWM support"
 	depends on PLAT_SPEAR || COMPILE_TEST
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index a59c710e98c7..c479623724e8 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_PWM_RENESAS_TPU)	+= pwm-renesas-tpu.o
 obj-$(CONFIG_PWM_ROCKCHIP)	+= pwm-rockchip.o
 obj-$(CONFIG_PWM_SAMSUNG)	+= pwm-samsung.o
 obj-$(CONFIG_PWM_SIFIVE)	+= pwm-sifive.o
+obj-$(CONFIG_PWM_SL28CPLD)	+= pwm-sl28cpld.o
 obj-$(CONFIG_PWM_SPEAR)		+= pwm-spear.o
 obj-$(CONFIG_PWM_SPRD)		+= pwm-sprd.o
 obj-$(CONFIG_PWM_STI)		+= pwm-sti.o
diff --git a/drivers/pwm/pwm-sl28cpld.c b/drivers/pwm/pwm-sl28cpld.c
new file mode 100644
index 000000000000..d82303f509f5
--- /dev/null
+++ b/drivers/pwm/pwm-sl28cpld.c
@@ -0,0 +1,201 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * sl28cpld PWM driver.
+ *
+ * Copyright 2019 Kontron Europe GmbH
+ */
+
+#include <linux/bitfield.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/pwm.h>
+#include <linux/regmap.h>
+
+/*
+ * PWM timer block registers.
+ */
+#define PWM_CTRL		0x00
+#define   PWM_ENABLE		BIT(7)
+#define   PWM_MODE_250HZ	0
+#define   PWM_MODE_500HZ	1
+#define   PWM_MODE_1KHZ		2
+#define   PWM_MODE_2KHZ		3
+#define   PWM_MODE_MASK		GENMASK(1, 0)
+#define PWM_CYCLE		0x01
+#define   PWM_CYCLE_MAX		0x7f
+
+struct sl28cpld_pwm {
+	struct pwm_chip pwm_chip;
+	struct regmap *regmap;
+	u32 offset;
+};
+
+struct sl28cpld_pwm_periods {
+	u8 ctrl;
+	unsigned long duty_cycle;
+};
+
+struct sl28cpld_pwm_config {
+	unsigned long period_ns;
+	u8 max_duty_cycle;
+};
+
+static struct sl28cpld_pwm_config sl28cpld_pwm_config[] = {
+	[PWM_MODE_250HZ] = { .period_ns = 4000000, .max_duty_cycle = 0x80 },
+	[PWM_MODE_500HZ] = { .period_ns = 2000000, .max_duty_cycle = 0x40 },
+	[PWM_MODE_1KHZ] = { .period_ns = 1000000, .max_duty_cycle = 0x20 },
+	[PWM_MODE_2KHZ] = { .period_ns =  500000, .max_duty_cycle = 0x10 },
+};
+
+static inline struct sl28cpld_pwm *to_sl28cpld_pwm(struct pwm_chip *chip)
+{
+	return container_of(chip, struct sl28cpld_pwm, pwm_chip);
+}
+
+static void sl28cpld_pwm_get_state(struct pwm_chip *chip,
+				   struct pwm_device *pwm,
+				   struct pwm_state *state)
+{
+	struct sl28cpld_pwm *spc = to_sl28cpld_pwm(chip);
+	static struct sl28cpld_pwm_config *config;
+	unsigned int reg;
+	unsigned long cycle;
+	unsigned int mode;
+
+	regmap_read(spc->regmap, spc->offset + PWM_CTRL, &reg);
+
+	state->enabled = reg & PWM_ENABLE;
+
+	mode = FIELD_GET(PWM_MODE_MASK, reg);
+	config = &sl28cpld_pwm_config[mode];
+	state->period = config->period_ns;
+
+	regmap_read(spc->regmap, spc->offset + PWM_CYCLE, &reg);
+	cycle = reg * config->period_ns;
+	state->duty_cycle = DIV_ROUND_CLOSEST_ULL(cycle,
+						  config->max_duty_cycle);
+}
+
+static int sl28cpld_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+			      const struct pwm_state *state)
+{
+	struct sl28cpld_pwm *spc = to_sl28cpld_pwm(chip);
+	struct sl28cpld_pwm_config *config;
+	unsigned long long cycle;
+	int ret;
+	int mode;
+	u8 ctrl;
+
+	/* update config, first search best matching period */
+	for (mode = 0; mode < ARRAY_SIZE(sl28cpld_pwm_config); mode++) {
+		config = &sl28cpld_pwm_config[mode];
+		if (state->period == config->period_ns)
+			break;
+	}
+
+	if (mode == ARRAY_SIZE(sl28cpld_pwm_config))
+		return -EINVAL;
+
+	ctrl = FIELD_PREP(PWM_MODE_MASK, mode);
+	if (state->enabled)
+		ctrl |= PWM_ENABLE;
+
+	cycle = state->duty_cycle * config->max_duty_cycle;
+	do_div(cycle, state->period);
+
+	/*
+	 * The hardware doesn't allow to set max_duty_cycle if the
+	 * 250Hz mode is enabled. But since this is "all-high" output
+	 * just use the 500Hz mode with the duty cycle to max value.
+	 */
+	if (cycle == config->max_duty_cycle) {
+		ctrl &= ~PWM_MODE_MASK;
+		ctrl |= FIELD_PREP(PWM_MODE_MASK, PWM_MODE_500HZ);
+		cycle = PWM_CYCLE_MAX;
+	}
+
+	ret = regmap_write(spc->regmap, spc->offset + PWM_CTRL, ctrl);
+	if (ret)
+		return ret;
+
+	return regmap_write(spc->regmap, spc->offset + PWM_CYCLE, (u8)cycle);
+}
+
+static const struct pwm_ops sl28cpld_pwm_ops = {
+	.apply = sl28cpld_pwm_apply,
+	.get_state = sl28cpld_pwm_get_state,
+	.owner = THIS_MODULE,
+};
+
+static int sl28cpld_pwm_probe(struct platform_device *pdev)
+{
+	struct sl28cpld_pwm *pwm;
+	struct pwm_chip *chip;
+	int ret;
+
+	if (!pdev->dev.parent)
+		return -ENODEV;
+
+	pwm = devm_kzalloc(&pdev->dev, sizeof(*pwm), GFP_KERNEL);
+	if (!pwm)
+		return -ENOMEM;
+
+	pwm->regmap = dev_get_regmap(pdev->dev.parent, NULL);
+	if (!pwm->regmap)
+		return -ENODEV;
+
+	ret = device_property_read_u32(&pdev->dev, "reg", &pwm->offset);
+	if (ret)
+		return -EINVAL;
+
+	/* initialize struct pwm_chip */
+	chip = &pwm->pwm_chip;
+	chip->dev = &pdev->dev;
+	chip->ops = &sl28cpld_pwm_ops;
+	chip->base = -1;
+	chip->npwm = 1;
+
+	ret = pwmchip_add(&pwm->pwm_chip);
+	if (ret < 0)
+		return ret;
+
+	platform_set_drvdata(pdev, pwm);
+
+	return 0;
+}
+
+static int sl28cpld_pwm_remove(struct platform_device *pdev)
+{
+	struct sl28cpld_pwm *pwm = platform_get_drvdata(pdev);
+
+	return pwmchip_remove(&pwm->pwm_chip);
+}
+
+static const struct of_device_id sl28cpld_pwm_of_match[] = {
+	{ .compatible = "kontron,sl28cpld-pwm" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, sl28cpld_pwm_of_match);
+
+static const struct platform_device_id sl28cpld_pwm_id_table[] = {
+	{"sl28cpld-pwm"},
+	{},
+};
+MODULE_DEVICE_TABLE(platform, sl28cpld_pwm_id_table);
+
+static struct platform_driver sl28cpld_pwm_driver = {
+	.probe = sl28cpld_pwm_probe,
+	.remove	= sl28cpld_pwm_remove,
+	.id_table = sl28cpld_pwm_id_table,
+	.driver = {
+		.name = KBUILD_MODNAME,
+		.of_match_table = sl28cpld_pwm_of_match,
+	},
+};
+module_platform_driver(sl28cpld_pwm_driver);
+
+MODULE_DESCRIPTION("sl28cpld PWM Driver");
+MODULE_AUTHOR("Michael Walle <michael@walle.cc>");
+MODULE_LICENSE("GPL");
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 74+ messages in thread

* [PATCH v4 06/11] gpio: add support for the sl28cpld GPIO controller
  2020-06-04 21:10 [PATCH v4 00/11] Add support for Kontron sl28cpld Michael Walle
                   ` (4 preceding siblings ...)
  2020-06-04 21:10 ` [PATCH v4 05/11] pwm: add support for sl28cpld PWM controller Michael Walle
@ 2020-06-04 21:10 ` Michael Walle
  2020-06-05 12:00   ` Andy Shevchenko
  2020-06-04 21:10 ` [PATCH v4 07/11] hwmon: add support for the sl28cpld hardware monitoring controller Michael Walle
                   ` (5 subsequent siblings)
  11 siblings, 1 reply; 74+ messages in thread
From: Michael Walle @ 2020-06-04 21:10 UTC (permalink / raw)
  To: linux-gpio, devicetree, linux-kernel, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm-kernel
  Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Jean Delvare,
	Guenter Roeck, Lee Jones, Thierry Reding, Uwe Kleine-König,
	Wim Van Sebroeck, Shawn Guo, Li Yang, Thomas Gleixner,
	Jason Cooper, Marc Zyngier, Mark Brown, Greg Kroah-Hartman,
	Andy Shevchenko, Michael Walle

Add support for the GPIO controller of the sl28 board management
controller. This driver is part of a multi-function device.

A controller has 8 lines. There are three different flavors:
full-featured GPIO with interrupt support, input-only and output-only.

Signed-off-by: Michael Walle <michael@walle.cc>
---
 drivers/gpio/Kconfig         |  11 +++
 drivers/gpio/Makefile        |   1 +
 drivers/gpio/gpio-sl28cpld.c | 180 +++++++++++++++++++++++++++++++++++
 3 files changed, 192 insertions(+)
 create mode 100644 drivers/gpio/gpio-sl28cpld.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index bcacd9c74aa8..a325d2d619a8 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -1215,6 +1215,17 @@ config GPIO_RC5T583
 	  This driver provides the support for driving/reading the gpio pins
 	  of RC5T583 device through standard gpio library.
 
+config GPIO_SL28CPLD
+	tristate "Kontron sl28 GPIO"
+	depends on MFD_SL28CPLD
+	select GPIO_REGMAP
+	select GPIOLIB_IRQCHIP
+	help
+	  This enables support for the GPIOs found on the Kontron sl28 CPLD.
+
+	  This driver can also be built as a module. If so, the module will be
+	  called gpio-sl28cpld.
+
 config GPIO_STMPE
 	bool "STMPE GPIOs"
 	depends on MFD_STMPE
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 1e4894e0bf0f..152127a9b339 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -130,6 +130,7 @@ obj-$(CONFIG_GPIO_SCH311X)		+= gpio-sch311x.o
 obj-$(CONFIG_GPIO_SCH)			+= gpio-sch.o
 obj-$(CONFIG_GPIO_SIFIVE)		+= gpio-sifive.o
 obj-$(CONFIG_GPIO_SIOX)			+= gpio-siox.o
+obj-$(CONFIG_GPIO_SL28CPLD)		+= gpio-sl28cpld.o
 obj-$(CONFIG_GPIO_SODAVILLE)		+= gpio-sodaville.o
 obj-$(CONFIG_GPIO_SPEAR_SPICS)		+= gpio-spear-spics.o
 obj-$(CONFIG_GPIO_SPRD)			+= gpio-sprd.o
diff --git a/drivers/gpio/gpio-sl28cpld.c b/drivers/gpio/gpio-sl28cpld.c
new file mode 100644
index 000000000000..800e218ee624
--- /dev/null
+++ b/drivers/gpio/gpio-sl28cpld.c
@@ -0,0 +1,180 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * sl28cpld GPIO driver.
+ *
+ * Copyright 2019 Michael Walle <michael@walle.cc>
+ */
+
+#include <linux/device.h>
+#include <linux/gpio/regmap.h>
+#include <linux/gpio/driver.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+
+/* GPIO flavor */
+#define GPIO_REG_DIR	0x00
+#define GPIO_REG_OUT	0x01
+#define GPIO_REG_IN	0x02
+#define GPIO_REG_IE	0x03
+#define GPIO_REG_IP	0x04
+
+/* input-only flavor */
+#define GPI_REG_IN	0x00
+
+/* output-only flavor */
+#define GPO_REG_OUT	0x00
+
+enum sl28cpld_gpio_type {
+	SL28CPLD_GPIO = 1,
+	SL28CPLD_GPI,
+	SL28CPLD_GPO,
+};
+
+struct sl28cpld_gpio {
+	struct regmap_irq_chip irq_chip;
+	struct regmap_irq_chip_data *irq_data;
+};
+
+static const struct regmap_irq sl28cpld_gpio_irqs[] = {
+	REGMAP_IRQ_REG_LINE(0, 8),
+	REGMAP_IRQ_REG_LINE(1, 8),
+	REGMAP_IRQ_REG_LINE(2, 8),
+	REGMAP_IRQ_REG_LINE(3, 8),
+	REGMAP_IRQ_REG_LINE(4, 8),
+	REGMAP_IRQ_REG_LINE(5, 8),
+	REGMAP_IRQ_REG_LINE(6, 8),
+	REGMAP_IRQ_REG_LINE(7, 8),
+};
+
+static int sl28cpld_gpio_irq_init(struct device *dev,
+				  struct sl28cpld_gpio *gpio,
+				  struct regmap *regmap, unsigned int base,
+				  int irq)
+{
+	struct regmap_irq_chip *irq_chip = &gpio->irq_chip;
+
+	irq_chip->name = "sl28cpld-gpio-irq",
+	irq_chip->irqs = sl28cpld_gpio_irqs;
+	irq_chip->num_irqs = ARRAY_SIZE(sl28cpld_gpio_irqs);
+	irq_chip->num_regs = 1;
+	irq_chip->status_base = base + GPIO_REG_IP;
+	irq_chip->mask_base = base + GPIO_REG_IE;
+	irq_chip->mask_invert = true,
+	irq_chip->ack_base = base + GPIO_REG_IP;
+
+	return devm_regmap_add_irq_chip_np(dev, dev_of_node(dev), regmap,
+					   irq, IRQF_SHARED | IRQF_ONESHOT, 0,
+					   irq_chip, &gpio->irq_data);
+}
+
+static int sl28cpld_gpio_probe(struct platform_device *pdev)
+{
+	const struct platform_device_id *dev_id;
+	struct gpio_regmap_config config = {0};
+	enum sl28cpld_gpio_type type;
+	struct sl28cpld_gpio *gpio;
+	bool irq_support = false;
+	struct regmap *regmap;
+	int irq, ret;
+	u32 base;
+
+	if (!pdev->dev.parent)
+		return -ENODEV;
+
+	dev_id = platform_get_device_id(pdev);
+	if (dev_id)
+		type = dev_id->driver_data;
+	else
+		type = (uintptr_t)of_device_get_match_data(&pdev->dev);
+	if (!type)
+		return -ENODEV;
+
+	gpio = devm_kzalloc(&pdev->dev, sizeof(*gpio), GFP_KERNEL);
+	if (!gpio)
+		return -ENOMEM;
+
+	ret = device_property_read_u32(&pdev->dev, "reg", &base);
+	if (ret)
+		return -EINVAL;
+
+	regmap = dev_get_regmap(pdev->dev.parent, NULL);
+	if (!regmap)
+		return -ENODEV;
+
+	config.regmap = regmap;
+	config.parent = &pdev->dev;
+	config.ngpio = 8;
+
+	switch (type) {
+	case SL28CPLD_GPIO:
+		config.reg_dat_base = base + GPIO_REG_IN;
+		config.reg_set_base = base + GPIO_REG_OUT;
+		/* reg_dir_out_base might be zero */
+		config.reg_dir_out_base = GPIO_REGMAP_ADDR(base +
+							   GPIO_REG_DIR);
+		irq_support = true;
+		break;
+	case SL28CPLD_GPO:
+		config.reg_set_base = base + GPO_REG_OUT;
+		break;
+	case SL28CPLD_GPI:
+		config.reg_dat_base = base + GPI_REG_IN;
+		break;
+	default:
+		dev_err(&pdev->dev, "unknown type %d\n", type);
+		return -ENODEV;
+	}
+
+	if (irq_support &&
+	    device_property_read_bool(&pdev->dev, "interrupt-controller")) {
+		irq = platform_get_irq(pdev, 0);
+		if (irq < 0)
+			return irq;
+
+		ret = sl28cpld_gpio_irq_init(&pdev->dev, gpio, regmap,
+					     base, irq);
+		if (ret)
+			return ret;
+
+		config.irq_domain = regmap_irq_get_domain(gpio->irq_data);
+	}
+
+	return PTR_ERR_OR_ZERO(devm_gpio_regmap_register(&pdev->dev, &config));
+}
+
+static const struct of_device_id sl28cpld_gpio_of_match[] = {
+	{ .compatible = "kontron,sl28cpld-gpio",
+	  .data = (void *)SL28CPLD_GPIO },
+	{ .compatible = "kontron,sl28cpld-gpi",
+	  .data = (void *)SL28CPLD_GPI },
+	{ .compatible = "kontron,sl28cpld-gpo",
+	  .data = (void *)SL28CPLD_GPO },
+	{},
+};
+MODULE_DEVICE_TABLE(of, sl28cpld_gpio_of_match);
+
+static const struct platform_device_id sl28cpld_gpio_id_table[] = {
+	{ "sl28cpld-gpio", SL28CPLD_GPIO },
+	{ "sl28cpld-gpi", SL28CPLD_GPI },
+	{ "sl28cpld-gpo", SL28CPLD_GPO },
+	{}
+};
+MODULE_DEVICE_TABLE(platform, sl28cpld_gpio_id_table);
+
+static struct platform_driver sl28cpld_gpio_driver = {
+	.probe = sl28cpld_gpio_probe,
+	.id_table = sl28cpld_gpio_id_table,
+	.driver = {
+		.name = KBUILD_MODNAME,
+		.of_match_table = sl28cpld_gpio_of_match,
+	},
+};
+module_platform_driver(sl28cpld_gpio_driver);
+
+MODULE_DESCRIPTION("sl28cpld GPIO Driver");
+MODULE_AUTHOR("Michael Walle <michael@walle.cc>");
+MODULE_LICENSE("GPL");
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 74+ messages in thread

* [PATCH v4 07/11] hwmon: add support for the sl28cpld hardware monitoring controller
  2020-06-04 21:10 [PATCH v4 00/11] Add support for Kontron sl28cpld Michael Walle
                   ` (5 preceding siblings ...)
  2020-06-04 21:10 ` [PATCH v4 06/11] gpio: add support for the sl28cpld GPIO controller Michael Walle
@ 2020-06-04 21:10 ` Michael Walle
  2020-06-05 12:06   ` Andy Shevchenko
  2020-06-04 21:10 ` [PATCH v4 08/11] arm64: dts: freescale: sl28: enable sl28cpld Michael Walle
                   ` (4 subsequent siblings)
  11 siblings, 1 reply; 74+ messages in thread
From: Michael Walle @ 2020-06-04 21:10 UTC (permalink / raw)
  To: linux-gpio, devicetree, linux-kernel, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm-kernel
  Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Jean Delvare,
	Guenter Roeck, Lee Jones, Thierry Reding, Uwe Kleine-König,
	Wim Van Sebroeck, Shawn Guo, Li Yang, Thomas Gleixner,
	Jason Cooper, Marc Zyngier, Mark Brown, Greg Kroah-Hartman,
	Andy Shevchenko, Michael Walle

Add support for the hardware monitoring controller of the sl28cpld board
management controller. This driver is part of a multi-function device.

Signed-off-by: Michael Walle <michael@walle.cc>
Acked-by: Guenter Roeck <linux@roeck-us.net>
---
 Documentation/hwmon/index.rst    |   1 +
 Documentation/hwmon/sl28cpld.rst |  36 ++++++++
 drivers/hwmon/Kconfig            |  10 +++
 drivers/hwmon/Makefile           |   1 +
 drivers/hwmon/sl28cpld-hwmon.c   | 150 +++++++++++++++++++++++++++++++
 5 files changed, 198 insertions(+)
 create mode 100644 Documentation/hwmon/sl28cpld.rst
 create mode 100644 drivers/hwmon/sl28cpld-hwmon.c

diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index 55ff4b7c5349..1f4beb7449c7 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -153,6 +153,7 @@ Hardware Monitoring Kernel Drivers
    sht3x
    shtc1
    sis5595
+   sl28cpld
    smm665
    smsc47b397
    smsc47m192
diff --git a/Documentation/hwmon/sl28cpld.rst b/Documentation/hwmon/sl28cpld.rst
new file mode 100644
index 000000000000..7ed65f78250c
--- /dev/null
+++ b/Documentation/hwmon/sl28cpld.rst
@@ -0,0 +1,36 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+Kernel driver sl28cpld
+======================
+
+Supported chips:
+
+   * Kontron sl28cpld
+
+     Prefix: 'sl28cpld'
+
+     Datasheet: not available
+
+Authors: Michael Walle <michael@walle.cc>
+
+Description
+-----------
+
+The sl28cpld is a board management controller which also exposes a hardware
+monitoring controller. At the moment this controller supports a single fan
+supervisor. In the future there might be other flavours and additional
+hardware monitoring might be supported.
+
+The fan supervisor has a 7 bit counter register and a counter period of 1
+second. If the 7 bit counter overflows, the supervisor will automatically
+switch to x8 mode to support a wider input range at the loss of
+granularity.
+
+Sysfs entries
+-------------
+
+The following attributes are supported.
+
+======================= ========================================================
+fan1_input		Fan RPM. Assuming 2 pulses per revolution.
+======================= ========================================================
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 288ae9f63588..e1cab08e80ce 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1459,6 +1459,16 @@ config SENSORS_RASPBERRYPI_HWMON
 	  This driver can also be built as a module. If so, the module
 	  will be called raspberrypi-hwmon.
 
+config SENSORS_SL28CPLD
+	tristate "Kontron sl28cpl hardware monitoring driver"
+	depends on MFD_SL28CPLD
+	help
+	  If you say yes here you get support for the fan supervisor of the
+	  sl28cpld board management controller.
+
+	  This driver can also be built as a module.  If so, the module
+	  will be called sl28cpld-hwmon.
+
 config SENSORS_SHT15
 	tristate "Sensiron humidity and temperature sensors. SHT15 and compat."
 	depends on GPIOLIB || COMPILE_TEST
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 3e32c21f5efe..03822f6bf970 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -158,6 +158,7 @@ obj-$(CONFIG_SENSORS_S3C)	+= s3c-hwmon.o
 obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o
 obj-$(CONFIG_SENSORS_SCH5627)	+= sch5627.o
 obj-$(CONFIG_SENSORS_SCH5636)	+= sch5636.o
+obj-$(CONFIG_SENSORS_SL28CPLD)	+= sl28cpld-hwmon.o
 obj-$(CONFIG_SENSORS_SHT15)	+= sht15.o
 obj-$(CONFIG_SENSORS_SHT21)	+= sht21.o
 obj-$(CONFIG_SENSORS_SHT3x)	+= sht3x.o
diff --git a/drivers/hwmon/sl28cpld-hwmon.c b/drivers/hwmon/sl28cpld-hwmon.c
new file mode 100644
index 000000000000..de24964a7322
--- /dev/null
+++ b/drivers/hwmon/sl28cpld-hwmon.c
@@ -0,0 +1,150 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * sl28cpld hardware monitoring driver.
+ *
+ * Copyright 2019 Kontron Europe GmbH
+ */
+
+#include <linux/bitfield.h>
+#include <linux/hwmon.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+
+#define FAN_INPUT		0x00
+#define   FAN_SCALE_X8		BIT(7)
+#define   FAN_VALUE_MASK	GENMASK(6, 0)
+
+struct sl28cpld_hwmon {
+	struct regmap *regmap;
+	u32 offset;
+};
+
+static umode_t sl28cpld_hwmon_is_visible(const void *data,
+					 enum hwmon_sensor_types type,
+					 u32 attr, int channel)
+{
+	return 0444;
+}
+
+static int sl28cpld_hwmon_read(struct device *dev,
+			       enum hwmon_sensor_types type, u32 attr,
+			       int channel, long *input)
+{
+	struct sl28cpld_hwmon *hwmon = dev_get_drvdata(dev);
+	unsigned int value;
+	int ret;
+
+	switch (attr) {
+	case hwmon_fan_input:
+		ret = regmap_read(hwmon->regmap, hwmon->offset + FAN_INPUT,
+				  &value);
+		if (ret)
+			return ret;
+		/*
+		 * The register has a 7 bit value and 1 bit which indicates the
+		 * scale. If the MSB is set, then the lower 7 bit has to be
+		 * multiplied by 8, to get the correct reading.
+		 */
+		if (value & FAN_SCALE_X8)
+			value = FIELD_GET(FAN_VALUE_MASK, value) << 3;
+
+		/*
+		 * The counter period is 1000ms and the sysfs specification
+		 * says we should asssume 2 pulses per revolution.
+		 */
+		value *= 60 / 2;
+
+		break;
+	default:
+		return -EOPNOTSUPP;
+	}
+
+	*input = value;
+	return 0;
+}
+
+static const u32 sl28cpld_hwmon_fan_config[] = {
+	HWMON_F_INPUT,
+	0
+};
+
+static const struct hwmon_channel_info sl28cpld_hwmon_fan = {
+	.type = hwmon_fan,
+	.config = sl28cpld_hwmon_fan_config,
+};
+
+static const struct hwmon_channel_info *sl28cpld_hwmon_info[] = {
+	&sl28cpld_hwmon_fan,
+	NULL
+};
+
+static const struct hwmon_ops sl28cpld_hwmon_ops = {
+	.is_visible = sl28cpld_hwmon_is_visible,
+	.read = sl28cpld_hwmon_read,
+};
+
+static const struct hwmon_chip_info sl28cpld_hwmon_chip_info = {
+	.ops = &sl28cpld_hwmon_ops,
+	.info = sl28cpld_hwmon_info,
+};
+
+static int sl28cpld_hwmon_probe(struct platform_device *pdev)
+{
+	struct sl28cpld_hwmon *hwmon;
+	struct device *hwmon_dev;
+	int ret;
+
+	if (!pdev->dev.parent)
+		return -ENODEV;
+
+	hwmon = devm_kzalloc(&pdev->dev, sizeof(*hwmon), GFP_KERNEL);
+	if (!hwmon)
+		return -ENOMEM;
+
+	hwmon->regmap = dev_get_regmap(pdev->dev.parent, NULL);
+	if (!hwmon->regmap)
+		return -ENODEV;
+
+	ret = device_property_read_u32(&pdev->dev, "reg", &hwmon->offset);
+	if (ret)
+		return -EINVAL;
+
+	hwmon_dev = devm_hwmon_device_register_with_info(&pdev->dev,
+				"sl28cpld_hwmon", hwmon,
+				&sl28cpld_hwmon_chip_info, NULL);
+	if (IS_ERR(hwmon_dev)) {
+		dev_err(&pdev->dev, "failed to register as hwmon device");
+		return PTR_ERR(hwmon_dev);
+	}
+
+	return 0;
+}
+
+static const struct of_device_id sl28cpld_hwmon_of_match[] = {
+	{ .compatible = "kontron,sl28cpld-fan" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, sl28cpld_hwmon_of_match);
+
+static const struct platform_device_id sl28cpld_hwmon_id_table[] = {
+	{ "sl28cpld-fan" },
+	{}
+};
+MODULE_DEVICE_TABLE(platform, sl28cpld_hwmon_id_table);
+
+static struct platform_driver sl28cpld_hwmon_driver = {
+	.probe = sl28cpld_hwmon_probe,
+	.id_table = sl28cpld_hwmon_id_table,
+	.driver = {
+		.name = KBUILD_MODNAME,
+		.of_match_table = sl28cpld_hwmon_of_match,
+	},
+};
+module_platform_driver(sl28cpld_hwmon_driver);
+
+MODULE_DESCRIPTION("sl28cpld Hardware Monitoring Driver");
+MODULE_AUTHOR("Michael Walle <michael@walle.cc>");
+MODULE_LICENSE("GPL");
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 74+ messages in thread

* [PATCH v4 08/11] arm64: dts: freescale: sl28: enable sl28cpld
  2020-06-04 21:10 [PATCH v4 00/11] Add support for Kontron sl28cpld Michael Walle
                   ` (6 preceding siblings ...)
  2020-06-04 21:10 ` [PATCH v4 07/11] hwmon: add support for the sl28cpld hardware monitoring controller Michael Walle
@ 2020-06-04 21:10 ` Michael Walle
  2020-06-04 21:10 ` [PATCH v4 09/11] arm64: dts: freescale: sl28: map GPIOs to input events Michael Walle
                   ` (3 subsequent siblings)
  11 siblings, 0 replies; 74+ messages in thread
From: Michael Walle @ 2020-06-04 21:10 UTC (permalink / raw)
  To: linux-gpio, devicetree, linux-kernel, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm-kernel
  Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Jean Delvare,
	Guenter Roeck, Lee Jones, Thierry Reding, Uwe Kleine-König,
	Wim Van Sebroeck, Shawn Guo, Li Yang, Thomas Gleixner,
	Jason Cooper, Marc Zyngier, Mark Brown, Greg Kroah-Hartman,
	Andy Shevchenko, Michael Walle

Add the board management controller node.

Signed-off-by: Michael Walle <michael@walle.cc>
---
 .../freescale/fsl-ls1028a-kontron-sl28.dts    | 102 ++++++++++++++++++
 1 file changed, 102 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dts
index 360b3a168c10..8712fe82727b 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dts
@@ -8,6 +8,7 @@
 
 /dts-v1/;
 #include "fsl-ls1028a.dtsi"
+#include <dt-bindings/interrupt-controller/irq.h>
 
 / {
 	model = "Kontron SMARC-sAL28";
@@ -170,6 +171,107 @@
 		reg = <0x32>;
 	};
 
+	sl28cpld@4a {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "kontron,sl28cpld-r1";
+		reg = <0x4a>;
+
+		watchdog@4 {
+			compatible = "kontron,sl28cpld-wdt";
+			reg = <0x4>;
+			kontron,assert-wdt-timeout-pin;
+		};
+
+		hwmon@b {
+			compatible = "kontron,sl28cpld-fan";
+			reg = <0xb>;
+		};
+
+		sl28cpld_pwm0: pwm@c {
+			#pwm-cells = <2>;
+			compatible = "kontron,sl28cpld-pwm";
+			reg = <0xc>;
+		};
+
+		sl28cpld_pwm1: pwm@e {
+			#pwm-cells = <2>;
+			compatible = "kontron,sl28cpld-pwm";
+			reg = <0xe>;
+		};
+
+		sl28cpld_gpio0: gpio@10 {
+			compatible = "kontron,sl28cpld-gpio";
+			reg = <0x10>;
+			interrupts-extended = <&gpio2 6
+					       IRQ_TYPE_EDGE_FALLING>;
+
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-line-names =
+				"GPIO0_CAM0_PWR_N", "GPIO1_CAM1_PWR_N",
+				"GPIO2_CAM0_RST_N", "GPIO3_CAM1_RST_N",
+				"GPIO4_HDA_RST_N", "GPIO5_PWM_OUT",
+				"GPIO6_TACHIN", "GPIO7";
+
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+
+		sl28cpld_gpio1: gpio@15 {
+			compatible = "kontron,sl28cpld-gpio";
+			reg = <0x15>;
+			interrupts-extended = <&gpio2 6
+					       IRQ_TYPE_EDGE_FALLING>;
+
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-line-names =
+				"GPIO8", "GPIO9", "GPIO10", "GPIO11",
+				"", "", "", "";
+
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+
+		sl28cpld_gpio2: gpio@1a {
+			compatible = "kontron,sl28cpld-gpo";
+			reg = <0x1a>;
+
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-line-names =
+				"LCD0 voltage enable",
+				"LCD0 backlight enable",
+				"eMMC reset", "LVDS bridge reset",
+				"LVDS bridge power-down",
+				"SDIO power enable",
+				"", "";
+		};
+
+		sl28cpld_gpio3: gpio@1b {
+			compatible = "kontron,sl28cpld-gpi";
+			reg = <0x1b>;
+
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-line-names =
+				"Power button", "Force recovery", "Sleep",
+				"Battery low", "Lid state", "Charging",
+				"Charger present", "";
+		};
+
+		sl28cpld_intc: interrupt-controller@1c {
+			compatible = "kontron,sl28cpld-intc";
+			reg = <0x1c>;
+			interrupts-extended = <&gpio2 6
+					       IRQ_TYPE_EDGE_FALLING>;
+
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+	};
+
 	eeprom@50 {
 		compatible = "atmel,24c32";
 		reg = <0x50>;
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 74+ messages in thread

* [PATCH v4 09/11] arm64: dts: freescale: sl28: map GPIOs to input events
  2020-06-04 21:10 [PATCH v4 00/11] Add support for Kontron sl28cpld Michael Walle
                   ` (7 preceding siblings ...)
  2020-06-04 21:10 ` [PATCH v4 08/11] arm64: dts: freescale: sl28: enable sl28cpld Michael Walle
@ 2020-06-04 21:10 ` Michael Walle
  2020-06-04 21:10 ` [PATCH v4 10/11] arm64: dts: freescale: sl28: enable LED support Michael Walle
                   ` (2 subsequent siblings)
  11 siblings, 0 replies; 74+ messages in thread
From: Michael Walle @ 2020-06-04 21:10 UTC (permalink / raw)
  To: linux-gpio, devicetree, linux-kernel, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm-kernel
  Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Jean Delvare,
	Guenter Roeck, Lee Jones, Thierry Reding, Uwe Kleine-König,
	Wim Van Sebroeck, Shawn Guo, Li Yang, Thomas Gleixner,
	Jason Cooper, Marc Zyngier, Mark Brown, Greg Kroah-Hartman,
	Andy Shevchenko, Michael Walle

Now that we have support for GPIO lines of the SMARC connector, map the
sleep, power and lid switch signals to the corresponding keys using the
gpio-keys and gpio-keys-polled drivers. The power and sleep signals have
dedicated interrupts, thus we use these ones. The lid switch is just
mapped to a GPIO input and needs polling.

Signed-off-by: Michael Walle <michael@walle.cc>
---
 .../freescale/fsl-ls1028a-kontron-sl28.dts    | 32 +++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dts
index 8712fe82727b..c4fd99efdbba 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dts
@@ -9,6 +9,8 @@
 /dts-v1/;
 #include "fsl-ls1028a.dtsi"
 #include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
 
 / {
 	model = "Kontron SMARC-sAL28";
@@ -23,6 +25,36 @@
 		spi1 = &dspi2;
 	};
 
+	buttons0 {
+		compatible = "gpio-keys";
+
+		power-button {
+			interrupts-extended = <&sl28cpld_intc
+					       4 IRQ_TYPE_EDGE_BOTH>;
+			linux,code = <KEY_POWER>;
+			label = "Power";
+		};
+
+		sleep-button {
+			interrupts-extended = <&sl28cpld_intc
+					       5 IRQ_TYPE_EDGE_BOTH>;
+			linux,code = <KEY_SLEEP>;
+			label = "Sleep";
+		};
+	};
+
+	buttons1 {
+		compatible = "gpio-keys-polled";
+		poll-interval = <200>;
+
+		lid-switch {
+			linux,input-type = <EV_SW>;
+			linux,code = <SW_LID>;
+			gpios = <&sl28cpld_gpio3 4 GPIO_ACTIVE_LOW>;
+			label = "Lid";
+		};
+	};
+
 	chosen {
 		stdout-path = "serial0:115200n8";
 	};
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 74+ messages in thread

* [PATCH v4 10/11] arm64: dts: freescale: sl28: enable LED support
  2020-06-04 21:10 [PATCH v4 00/11] Add support for Kontron sl28cpld Michael Walle
                   ` (8 preceding siblings ...)
  2020-06-04 21:10 ` [PATCH v4 09/11] arm64: dts: freescale: sl28: map GPIOs to input events Michael Walle
@ 2020-06-04 21:10 ` Michael Walle
  2020-06-04 21:10 ` [PATCH v4 11/11] arm64: dts: freescale: sl28: enable fan support Michael Walle
  2020-06-05  6:13 ` [PATCH v4 00/11] Add support for Kontron sl28cpld Lee Jones
  11 siblings, 0 replies; 74+ messages in thread
From: Michael Walle @ 2020-06-04 21:10 UTC (permalink / raw)
  To: linux-gpio, devicetree, linux-kernel, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm-kernel
  Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Jean Delvare,
	Guenter Roeck, Lee Jones, Thierry Reding, Uwe Kleine-König,
	Wim Van Sebroeck, Shawn Guo, Li Yang, Thomas Gleixner,
	Jason Cooper, Marc Zyngier, Mark Brown, Greg Kroah-Hartman,
	Andy Shevchenko, Michael Walle

Now that we have support for GPIO lines of the SMARC connector, enable
LED support on the KBox A-230-LS. There are two LEDs without fixed
functions, one is yellow and one is green. Unfortunately, it is just one
multi-color LED, thus while it is possible to enable both at the same
time it is hard to tell the difference between "yellow only" and "yellow
and green".

Signed-off-by: Michael Walle <michael@walle.cc>
---
 .../fsl-ls1028a-kontron-kbox-a-230-ls.dts          | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-kbox-a-230-ls.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-kbox-a-230-ls.dts
index 4b4cc6a1573d..49cf4fe05c80 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-kbox-a-230-ls.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-kbox-a-230-ls.dts
@@ -16,6 +16,20 @@
 	model = "Kontron KBox A-230-LS";
 	compatible = "kontron,kbox-a-230-ls", "kontron,sl28-var4",
 		     "kontron,sl28", "fsl,ls1028a";
+
+	leds {
+		compatible = "gpio-leds";
+
+		user_yellow {
+			label = "s1914:yellow:user";
+			gpios = <&sl28cpld_gpio0 0 0>;
+		};
+
+		user_green {
+			label = "s1914:green:user";
+			gpios = <&sl28cpld_gpio1 3 0>;
+		};
+	};
 };
 
 &enetc_mdio_pf3 {
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 74+ messages in thread

* [PATCH v4 11/11] arm64: dts: freescale: sl28: enable fan support
  2020-06-04 21:10 [PATCH v4 00/11] Add support for Kontron sl28cpld Michael Walle
                   ` (9 preceding siblings ...)
  2020-06-04 21:10 ` [PATCH v4 10/11] arm64: dts: freescale: sl28: enable LED support Michael Walle
@ 2020-06-04 21:10 ` Michael Walle
  2020-06-05  6:13 ` [PATCH v4 00/11] Add support for Kontron sl28cpld Lee Jones
  11 siblings, 0 replies; 74+ messages in thread
From: Michael Walle @ 2020-06-04 21:10 UTC (permalink / raw)
  To: linux-gpio, devicetree, linux-kernel, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm-kernel
  Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Jean Delvare,
	Guenter Roeck, Lee Jones, Thierry Reding, Uwe Kleine-König,
	Wim Van Sebroeck, Shawn Guo, Li Yang, Thomas Gleixner,
	Jason Cooper, Marc Zyngier, Mark Brown, Greg Kroah-Hartman,
	Andy Shevchenko, Michael Walle

Add a pwm-fan mapped to the PWM channel 0 which is connected to the
fan connector of the carrier.

Signed-off-by: Michael Walle <michael@walle.cc>
---
 .../dts/freescale/fsl-ls1028a-kontron-sl28-var3-ads2.dts | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3-ads2.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3-ads2.dts
index 0973a6a45217..c45d7b40e374 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3-ads2.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3-ads2.dts
@@ -15,6 +15,15 @@
 	compatible = "kontron,sl28-var3-ads2", "kontron,sl28-var3",
 		     "kontron,sl28", "fsl,ls1028a";
 
+	pwm-fan {
+		compatible = "pwm-fan";
+		cooling-min-state = <0>;
+		cooling-max-state = <3>;
+		#cooling-cells = <2>;
+		pwms = <&sl28cpld_pwm0 0 4000000>;
+		cooling-levels = <1 128 192 255>;
+	};
+
 	sound {
 		#address-cells = <1>;
 		#size-cells = <0>;
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 03/11] irqchip: add sl28cpld interrupt controller support
  2020-06-04 21:10 ` [PATCH v4 03/11] irqchip: add sl28cpld interrupt controller support Michael Walle
@ 2020-06-05  1:26   ` kernel test robot
  2020-06-05  8:07   ` Andy Shevchenko
  2020-06-08 15:12   ` kernel test robot
  2 siblings, 0 replies; 74+ messages in thread
From: kernel test robot @ 2020-06-05  1:26 UTC (permalink / raw)
  To: Michael Walle, linux-gpio, devicetree, linux-kernel, linux-hwmon,
	linux-pwm, linux-watchdog, linux-arm-kernel
  Cc: kbuild-all, Linus Walleij, Bartosz Golaszewski, Rob Herring

[-- Attachment #1: Type: text/plain, Size: 2927 bytes --]

Hi Michael,

I love your patch! Perhaps something to improve:

[auto build test WARNING on next-20200604]
[cannot apply to gpio/for-next hwmon/hwmon-next ljones-mfd/for-mfd-next shawnguo/for-next v5.7 v5.7-rc7 v5.7-rc6 v5.7]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:    https://github.com/0day-ci/linux/commits/Michael-Walle/Add-support-for-Kontron-sl28cpld/20200605-051333
base:    d4899e5542c15062cc55cac0ca99025bb64edc61
config: mips-allyesconfig (attached as .config)
compiler: mips-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=mips 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All warnings (new ones prefixed by >>, old ones prefixed by <<):

drivers/irqchip/irq-sl28cpld.c: In function 'sl28cpld_intc_probe':
>> drivers/irqchip/irq-sl28cpld.c:56:10: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
56 |  if (irq < 0)
|          ^

vim +56 drivers/irqchip/irq-sl28cpld.c

    35	
    36	static int sl28cpld_intc_probe(struct platform_device *pdev)
    37	{
    38		struct device *dev = &pdev->dev;
    39		struct sl28cpld_intc *irqchip;
    40		unsigned int irq;
    41		u32 base;
    42		int ret;
    43	
    44		if (!dev->parent)
    45			return -ENODEV;
    46	
    47		irqchip = devm_kzalloc(dev, sizeof(*irqchip), GFP_KERNEL);
    48		if (!irqchip)
    49			return -ENOMEM;
    50	
    51		irqchip->regmap = dev_get_regmap(dev->parent, NULL);
    52		if (!irqchip->regmap)
    53			return -ENODEV;
    54	
    55		irq = platform_get_irq(pdev, 0);
  > 56		if (irq < 0)
    57			return irq;
    58	
    59		ret = device_property_read_u32(&pdev->dev, "reg", &base);
    60		if (ret)
    61			return -EINVAL;
    62	
    63		irqchip->chip.name = "sl28cpld-intc";
    64		irqchip->chip.irqs = sl28cpld_irqs;
    65		irqchip->chip.num_irqs = ARRAY_SIZE(sl28cpld_irqs);
    66		irqchip->chip.num_regs = 1;
    67		irqchip->chip.status_base = base + INTC_IP;
    68		irqchip->chip.mask_base = base + INTC_IE;
    69		irqchip->chip.mask_invert = true,
    70		irqchip->chip.ack_base = base + INTC_IP;
    71	
    72		return devm_regmap_add_irq_chip_np(&pdev->dev, dev->of_node,
    73						   irqchip->regmap, irq,
    74						   IRQF_SHARED | IRQF_ONESHOT, 0,
    75						   &irqchip->chip, &irqchip->irq_data);
    76	}
    77	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 66540 bytes --]

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 00/11] Add support for Kontron sl28cpld
  2020-06-04 21:10 [PATCH v4 00/11] Add support for Kontron sl28cpld Michael Walle
                   ` (10 preceding siblings ...)
  2020-06-04 21:10 ` [PATCH v4 11/11] arm64: dts: freescale: sl28: enable fan support Michael Walle
@ 2020-06-05  6:13 ` Lee Jones
  11 siblings, 0 replies; 74+ messages in thread
From: Lee Jones @ 2020-06-05  6:13 UTC (permalink / raw)
  To: Michael Walle
  Cc: linux-gpio, devicetree, linux-kernel, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm-kernel, Linus Walleij,
	Bartosz Golaszewski, Rob Herring, Jean Delvare, Guenter Roeck,
	Thierry Reding, Uwe Kleine-König, Wim Van Sebroeck,
	Shawn Guo, Li Yang, Thomas Gleixner, Jason Cooper, Marc Zyngier,
	Mark Brown, Greg Kroah-Hartman, Andy Shevchenko

On Thu, 04 Jun 2020, Michael Walle wrote:

> The Kontron sl28cpld is a board management chip providing gpio, pwm, fan
> monitoring and an interrupt controller. For now this controller is used on
> the Kontron SMARC-sAL28 board. But because of its flexible nature, it
> might also be used on other boards in the future. The individual blocks
> (like gpio, pwm, etc) are kept intentionally small. The MFD core driver
> then instantiates different (or multiple of the same) blocks. It also
> provides the register layout so it might be updated in the future without a
> device tree change; and support other boards with a different layout or
> functionalities.
> 
> See also [1] for more information.
> 
> This is my first take of a MFD driver. I don't know whether the subsystem
> maintainers should only be CCed on the patches which affect the subsystem
> or on all patches for this series. I've chosen the latter so you can get a
> more complete picture.

You chose wisely. :)

> [1] https://lore.kernel.org/linux-devicetree/0e3e8204ab992d75aa07fc36af7e4ab2@walle.cc/
> 
> Changes since v3:
>  - use of_platform_populate() to populate internal devices using the
>    internal register offsets as unit-addresses
>  - because we don't use mfd_cells anymore, we cannot use IORESOURCE_REG,
>    but instead parse the reg property in each individual driver
>  - dropped the following patches because they were already merged:
>      gpiolib: Introduce gpiochip_irqchip_add_domain()
>      gpio: add a reusable generic gpio_chip using regmap
>  - dropped the following patches because they are no longer needed:
>      include/linux/ioport.h: add helper to define REG resource constructs
>      mfd: mfd-core: Don't overwrite the dma_mask of the child device
>      mfd: mfd-core: match device tree node against reg property
>  - rephrase commit messages, as suggested by Thomas Gleixner

It's great to have this changelog overview.

However it's equally, if not arguably more important to have a more
fine grained changelog in each of the patches, usually placed between
the '---' and the diff stat.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-04 21:10 ` [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller Michael Walle
@ 2020-06-05  6:57   ` Lee Jones
  2020-06-05  9:51     ` Michael Walle
  2020-06-05 10:50     ` Mark Brown
  2020-06-05  8:01   ` Andy Shevchenko
  1 sibling, 2 replies; 74+ messages in thread
From: Lee Jones @ 2020-06-05  6:57 UTC (permalink / raw)
  To: Michael Walle, broonie
  Cc: linux-gpio, devicetree, linux-kernel, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm-kernel, Linus Walleij,
	Bartosz Golaszewski, Rob Herring, Jean Delvare, Guenter Roeck,
	Thierry Reding, Uwe Kleine-König, Wim Van Sebroeck,
	Shawn Guo, Li Yang, Thomas Gleixner, Jason Cooper, Marc Zyngier,
	Mark Brown, Greg Kroah-Hartman, Andy Shevchenko

Mark, what do you think?

On Thu, 04 Jun 2020, Michael Walle wrote:

> Add the core support for the board management controller found on the
> SMARC-sAL28 board. It consists of the following functions:
>  - watchdog
>  - GPIO controller
>  - PWM controller
>  - fan sensor
>  - interrupt controller
> 
> At the moment, this controller is used on the Kontron SMARC-sAL28 board.
> 
> Please note that the MFD driver is defined as bool in the Kconfig
> because the next patch will add interrupt support.
> 
> Signed-off-by: Michael Walle <michael@walle.cc>
> ---
>  drivers/mfd/Kconfig    | 19 ++++++++++
>  drivers/mfd/Makefile   |  2 ++
>  drivers/mfd/sl28cpld.c | 79 ++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 100 insertions(+)
>  create mode 100644 drivers/mfd/sl28cpld.c
> 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 4f8b73d92df3..5c0cd514d197 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -2109,5 +2109,24 @@ config SGI_MFD_IOC3
>  	  If you have an SGI Origin, Octane, or a PCI IOC3 card,
>  	  then say Y. Otherwise say N.
>  
> +config MFD_SL28CPLD
> +	bool "Kontron sl28 core driver"

"Kontron SL28 Core Driver"

> +	depends on I2C=y
> +	depends on OF
> +	select REGMAP_I2C
> +	select MFD_CORE
> +	help
> +	  This option enables support for the board management controller
> +	  found on the Kontron sl28 CPLD. You have to select individual

I can't find any reference to the "Kontron sl28 CPLD" online.

Is there a datasheet?

> +	  functions, such as watchdog, GPIO, etc, under the corresponding menus
> +	  in order to enable them.
> +
> +	  Currently supported boards are:
> +
> +		Kontron SMARC-sAL28
> +
> +	  To compile this driver as a module, choose M here: the module will be
> +	  called sl28cpld.
> +
>  endmenu
>  endif
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 9367a92f795a..be59fb40aa28 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -264,3 +264,5 @@ obj-$(CONFIG_MFD_ROHM_BD718XX)	+= rohm-bd718x7.o
>  obj-$(CONFIG_MFD_STMFX) 	+= stmfx.o
>  
>  obj-$(CONFIG_SGI_MFD_IOC3)	+= ioc3.o
> +
> +obj-$(CONFIG_MFD_SL28CPLD)	+= sl28cpld.o
> diff --git a/drivers/mfd/sl28cpld.c b/drivers/mfd/sl28cpld.c
> new file mode 100644
> index 000000000000..a23194bb6efa
> --- /dev/null
> +++ b/drivers/mfd/sl28cpld.c
> @@ -0,0 +1,79 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * MFD core for the sl28cpld.

Ideally this would match the Kconfig subject line.

> + * Copyright 2019 Kontron Europe GmbH

This is out of date.

> + */
> +
> +#include <linux/i2c.h>
> +#include <linux/interrupt.h>
> +#include <linux/kernel.h>
> +#include <linux/mfd/core.h>
> +#include <linux/module.h>
> +#include <linux/of_platform.h>
> +#include <linux/regmap.h>
> +
> +#define SL28CPLD_VERSION	0x03
> +#define SL28CPLD_MIN_REQ_VERSION 14
> +
> +struct sl28cpld {
> +	struct device *dev;
> +	struct regmap *regmap;
> +};

Why do you need this structure?

> +static const struct regmap_config sl28cpld_regmap_config = {
> +	.reg_bits = 8,
> +	.val_bits = 8,
> +	.reg_stride = 1,
> +};
> +
> +static int sl28cpld_probe(struct i2c_client *i2c)
> +{
> +	struct sl28cpld *sl28cpld;
> +	struct device *dev = &i2c->dev;
> +	unsigned int cpld_version;
> +	int ret;
> +
> +	sl28cpld = devm_kzalloc(dev, sizeof(*sl28cpld), GFP_KERNEL);
> +	if (!sl28cpld)
> +		return -ENOMEM;
> +
> +	sl28cpld->regmap = devm_regmap_init_i2c(i2c, &sl28cpld_regmap_config);
> +	if (IS_ERR(sl28cpld->regmap))
> +		return PTR_ERR(sl28cpld->regmap);

This is now a shared memory allocator and not an MFD at all.

I'm clamping down on these type of drivers!

Please find a better way to accomplish this.

Potentially using "simple-mfd" and "simple-regmap".

The former already exists and does what you want.  The latter doesn't
yet exist, but could solve your and lots of other contributor's
issues.

Heck maybe I'll implement it myself if this keeps happening.

> +	ret = regmap_read(sl28cpld->regmap, SL28CPLD_VERSION, &cpld_version);
> +	if (ret)
> +		return ret;
> +
> +	if (cpld_version < SL28CPLD_MIN_REQ_VERSION) {
> +		dev_err(dev, "unsupported CPLD version %d\n", cpld_version);
> +		return -ENODEV;
> +	}
> +
> +	sl28cpld->dev = dev;
> +	i2c_set_clientdata(i2c, sl28cpld);

If the struct definition is in here, how do you use it elsewhere?

> +	dev_info(dev, "successfully probed. CPLD version %d\n", cpld_version);
> +
> +	return devm_of_platform_populate(&i2c->dev);
> +}
> +
> +static const struct of_device_id sl28cpld_of_match[] = {
> +	{ .compatible = "kontron,sl28cpld-r1", },
> +	{}
> +};
> +MODULE_DEVICE_TABLE(of, sl28cpld_of_match);
> +
> +static struct i2c_driver sl28cpld_driver = {
> +	.probe_new = sl28cpld_probe,
> +	.driver = {
> +		.name = "sl28cpld",
> +		.of_match_table = of_match_ptr(sl28cpld_of_match),
> +	},
> +};
> +module_i2c_driver(sl28cpld_driver);
> +
> +MODULE_DESCRIPTION("sl28cpld MFD Core Driver");
> +MODULE_AUTHOR("Michael Walle <michael@walle.cc>");
> +MODULE_LICENSE("GPL");

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-04 21:10 ` [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller Michael Walle
  2020-06-05  6:57   ` Lee Jones
@ 2020-06-05  8:01   ` Andy Shevchenko
  2020-06-05  8:02     ` Andy Shevchenko
  2020-06-05 10:09     ` Michael Walle
  1 sibling, 2 replies; 74+ messages in thread
From: Andy Shevchenko @ 2020-06-05  8:01 UTC (permalink / raw)
  To: Michael Walle
  Cc: open list:GPIO SUBSYSTEM, devicetree, Linux Kernel Mailing List,
	linux-hwmon, linux-pwm, linux-watchdog, linux-arm Mailing List,
	Linus Walleij, Bartosz Golaszewski, Rob Herring, Jean Delvare,
	Guenter Roeck, Lee Jones, Thierry Reding, Uwe Kleine-König,
	Wim Van Sebroeck, Shawn Guo, Li Yang, Thomas Gleixner,
	Jason Cooper, Marc Zyngier, Mark Brown, Greg Kroah-Hartman,
	Andy Shevchenko

On Fri, Jun 5, 2020 at 12:16 AM Michael Walle <michael@walle.cc> wrote:
>
> Add the core support for the board management controller found on the
> SMARC-sAL28 board. It consists of the following functions:
>  - watchdog
>  - GPIO controller
>  - PWM controller
>  - fan sensor
>  - interrupt controller
>
> At the moment, this controller is used on the Kontron SMARC-sAL28 board.
>
> Please note that the MFD driver is defined as bool in the Kconfig
> because the next patch will add interrupt support.

...

> +config MFD_SL28CPLD
> +       bool "Kontron sl28 core driver"
> +       depends on I2C=y

Why not module?

> +       depends on OF

I didn't find an evidence this is needed.

No Compile Test?

> +       select REGMAP_I2C
> +       select MFD_CORE

...

> +#include <linux/of_platform.h>

No evidence of user of this.
I think you meant mod_devicetable.h.

...

> +static struct i2c_driver sl28cpld_driver = {
> +       .probe_new = sl28cpld_probe,
> +       .driver = {
> +               .name = "sl28cpld",
> +               .of_match_table = of_match_ptr(sl28cpld_of_match),

Drop of_match_ptr(). It has a little sense in this context (depends OF).
It will have a little sense even if you drop depends OF b/c you will
introduce a compiler warning.

> +       },
> +};


-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-05  8:01   ` Andy Shevchenko
@ 2020-06-05  8:02     ` Andy Shevchenko
  2020-06-05 10:09     ` Michael Walle
  1 sibling, 0 replies; 74+ messages in thread
From: Andy Shevchenko @ 2020-06-05  8:02 UTC (permalink / raw)
  To: Michael Walle
  Cc: open list:GPIO SUBSYSTEM, devicetree, Linux Kernel Mailing List,
	linux-hwmon, linux-pwm, linux-watchdog, linux-arm Mailing List,
	Linus Walleij, Bartosz Golaszewski, Rob Herring, Jean Delvare,
	Guenter Roeck, Lee Jones, Thierry Reding, Uwe Kleine-König,
	Wim Van Sebroeck, Shawn Guo, Li Yang, Thomas Gleixner,
	Jason Cooper, Marc Zyngier, Mark Brown, Greg Kroah-Hartman,
	Andy Shevchenko

On Fri, Jun 5, 2020 at 11:01 AM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Fri, Jun 5, 2020 at 12:16 AM Michael Walle <michael@walle.cc> wrote:

...

> > Please note that the MFD driver is defined as bool in the Kconfig
> > because the next patch will add interrupt support.

> > +       bool "Kontron sl28 core driver"
> > +       depends on I2C=y
>
> Why not module?

To be clear, I have read above, but it didn't shed a light.

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 03/11] irqchip: add sl28cpld interrupt controller support
  2020-06-04 21:10 ` [PATCH v4 03/11] irqchip: add sl28cpld interrupt controller support Michael Walle
  2020-06-05  1:26   ` kernel test robot
@ 2020-06-05  8:07   ` Andy Shevchenko
  2020-06-08 15:12   ` kernel test robot
  2 siblings, 0 replies; 74+ messages in thread
From: Andy Shevchenko @ 2020-06-05  8:07 UTC (permalink / raw)
  To: Michael Walle
  Cc: open list:GPIO SUBSYSTEM, devicetree, Linux Kernel Mailing List,
	linux-hwmon, linux-pwm, linux-watchdog, linux-arm Mailing List,
	Linus Walleij, Bartosz Golaszewski, Rob Herring, Jean Delvare,
	Guenter Roeck, Lee Jones, Thierry Reding, Uwe Kleine-König,
	Wim Van Sebroeck, Shawn Guo, Li Yang, Thomas Gleixner,
	Jason Cooper, Marc Zyngier, Mark Brown, Greg Kroah-Hartman,
	Andy Shevchenko

On Fri, Jun 5, 2020 at 12:13 AM Michael Walle <michael@walle.cc> wrote:
>
> Add support for the interrupt controller inside the sl28 CPLD management
> controller.
>
> The interrupt controller can handle at most 8 interrupts and is really
> simplistic and consists only of an interrupt mask and an interrupt
> pending register.

...

> +config SL28CPLD_INTC
> +       bool

Same Q: Why not module?

...

> +static const struct of_device_id sl28cpld_intc_of_match[] = {
> +       { .compatible = "kontron,sl28cpld-intc" },

> +       {},

There is no point to have comma in terminator line.

> +};


-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 04/11] watchdog: add support for sl28cpld watchdog
  2020-06-04 21:10 ` [PATCH v4 04/11] watchdog: add support for sl28cpld watchdog Michael Walle
@ 2020-06-05  8:14   ` Andy Shevchenko
  2020-06-05 10:24     ` Michael Walle
  0 siblings, 1 reply; 74+ messages in thread
From: Andy Shevchenko @ 2020-06-05  8:14 UTC (permalink / raw)
  To: Michael Walle
  Cc: open list:GPIO SUBSYSTEM, devicetree, Linux Kernel Mailing List,
	linux-hwmon, linux-pwm, linux-watchdog, linux-arm Mailing List,
	Linus Walleij, Bartosz Golaszewski, Rob Herring, Jean Delvare,
	Guenter Roeck, Lee Jones, Thierry Reding, Uwe Kleine-König,
	Wim Van Sebroeck, Shawn Guo, Li Yang, Thomas Gleixner,
	Jason Cooper, Marc Zyngier, Mark Brown, Greg Kroah-Hartman,
	Andy Shevchenko

On Fri, Jun 5, 2020 at 12:14 AM Michael Walle <michael@walle.cc> wrote:
>
> Add support for the watchdog of the sl28cpld board management
> controller. This is part of a multi-function device driver.

...

> +#include <linux/of_device.h>

Didn't find a user of this.

...

> +static bool nowayout = WATCHDOG_NOWAYOUT;
> +module_param(nowayout, bool, 0);
> +MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
> +                               __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
> +
> +static int timeout;
> +module_param(timeout, int, 0);
> +MODULE_PARM_DESC(timeout, "Initial watchdog timeout in seconds");

Guenter ACKed this, but I'm wondering why we still need module parameters...

...

> +       int ret;
> +
> +       ret = regmap_read(wdt->regmap, wdt->offset + WDT_COUNT, &val);
> +
> +       return (ret < 0) ? 0 : val;

Besides extra parentheses and questionable ' < 0' part, the following
would look better I think

ret = ...
if (ret)
  return 0;

return val;

...

> +       int ret;
> +
> +       ret = regmap_write(wdt->regmap, wdt->offset + WDT_TIMEOUT, timeout);
> +       if (!ret)
> +               wdd->timeout = timeout;
> +
> +       return ret;

Similar story here:

ret = ...
if (ret)
  return ret;

wdd->... = ...
return 0;

...

> +       ret = regmap_read(wdt->regmap, wdt->offset + WDT_CTRL, &status);

> +       if (ret < 0)

What ' < 0' means? Do we have some positive return values?
Ditto for all your code.

> +               return ret;

...

> +       if (status & WDT_CTRL_EN) {
> +               sl28cpld_wdt_start(wdd);

> +               set_bit(WDOG_HW_RUNNING, &wdd->status);

Do you need atomic op here? Why?

> +       }

...

> +static const struct of_device_id sl28cpld_wdt_of_match[] = {
> +       { .compatible = "kontron,sl28cpld-wdt" },

> +       {},

No comma.

> +};

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 05/11] pwm: add support for sl28cpld PWM controller
  2020-06-04 21:10 ` [PATCH v4 05/11] pwm: add support for sl28cpld PWM controller Michael Walle
@ 2020-06-05  8:15   ` Andy Shevchenko
  2020-06-05  8:49   ` Lee Jones
  1 sibling, 0 replies; 74+ messages in thread
From: Andy Shevchenko @ 2020-06-05  8:15 UTC (permalink / raw)
  To: Michael Walle
  Cc: open list:GPIO SUBSYSTEM, devicetree, Linux Kernel Mailing List,
	linux-hwmon, linux-pwm, linux-watchdog, linux-arm Mailing List,
	Linus Walleij, Bartosz Golaszewski, Rob Herring, Jean Delvare,
	Guenter Roeck, Lee Jones, Thierry Reding, Uwe Kleine-König,
	Wim Van Sebroeck, Shawn Guo, Li Yang, Thomas Gleixner,
	Jason Cooper, Marc Zyngier, Mark Brown, Greg Kroah-Hartman,
	Andy Shevchenko

On Fri, Jun 5, 2020 at 12:16 AM Michael Walle <michael@walle.cc> wrote:
>
> Add support for the PWM controller of the sl28cpld board management
> controller. This is part of a multi-function device driver.
>
> The controller has one PWM channel and can just generate four distinct
> frequencies.

So same comments (extra comma, cargo cult headers, etc) are applied
here and perhaps to all other patches in the series.

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 05/11] pwm: add support for sl28cpld PWM controller
  2020-06-04 21:10 ` [PATCH v4 05/11] pwm: add support for sl28cpld PWM controller Michael Walle
  2020-06-05  8:15   ` Andy Shevchenko
@ 2020-06-05  8:49   ` Lee Jones
  2020-06-05  9:33     ` Andy Shevchenko
                       ` (2 more replies)
  1 sibling, 3 replies; 74+ messages in thread
From: Lee Jones @ 2020-06-05  8:49 UTC (permalink / raw)
  To: Michael Walle
  Cc: linux-gpio, devicetree, linux-kernel, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm-kernel, Linus Walleij,
	Bartosz Golaszewski, Rob Herring, Jean Delvare, Guenter Roeck,
	Thierry Reding, Uwe Kleine-König, Wim Van Sebroeck,
	Shawn Guo, Li Yang, Thomas Gleixner, Jason Cooper, Marc Zyngier,
	Mark Brown, Greg Kroah-Hartman, Andy Shevchenko

On Thu, 04 Jun 2020, Michael Walle wrote:

> Add support for the PWM controller of the sl28cpld board management
> controller. This is part of a multi-function device driver.
> 
> The controller has one PWM channel and can just generate four distinct
> frequencies.
> 
> Signed-off-by: Michael Walle <michael@walle.cc>
> ---
>  drivers/pwm/Kconfig        |  10 ++
>  drivers/pwm/Makefile       |   1 +
>  drivers/pwm/pwm-sl28cpld.c | 201 +++++++++++++++++++++++++++++++++++++
>  3 files changed, 212 insertions(+)
>  create mode 100644 drivers/pwm/pwm-sl28cpld.c
> 
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index cb8d739067d2..a39371c11ff6 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -437,6 +437,16 @@ config PWM_SIFIVE
>  	  To compile this driver as a module, choose M here: the module
>  	  will be called pwm-sifive.
>  
> +config PWM_SL28CPLD
> +	tristate "Kontron sl28 PWM support"
> +	depends on MFD_SL28CPLD
> +	help
> +	  Generic PWM framework driver for board management controller
> +	  found on the Kontron sl28 CPLD.
> +
> +	  To compile this driver as a module, choose M here: the module
> +	  will be called pwm-sl28cpld.
> +
>  config PWM_SPEAR
>  	tristate "STMicroelectronics SPEAr PWM support"
>  	depends on PLAT_SPEAR || COMPILE_TEST
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index a59c710e98c7..c479623724e8 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -41,6 +41,7 @@ obj-$(CONFIG_PWM_RENESAS_TPU)	+= pwm-renesas-tpu.o
>  obj-$(CONFIG_PWM_ROCKCHIP)	+= pwm-rockchip.o
>  obj-$(CONFIG_PWM_SAMSUNG)	+= pwm-samsung.o
>  obj-$(CONFIG_PWM_SIFIVE)	+= pwm-sifive.o
> +obj-$(CONFIG_PWM_SL28CPLD)	+= pwm-sl28cpld.o
>  obj-$(CONFIG_PWM_SPEAR)		+= pwm-spear.o
>  obj-$(CONFIG_PWM_SPRD)		+= pwm-sprd.o
>  obj-$(CONFIG_PWM_STI)		+= pwm-sti.o
> diff --git a/drivers/pwm/pwm-sl28cpld.c b/drivers/pwm/pwm-sl28cpld.c
> new file mode 100644
> index 000000000000..d82303f509f5
> --- /dev/null
> +++ b/drivers/pwm/pwm-sl28cpld.c
> @@ -0,0 +1,201 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * sl28cpld PWM driver.
> + *
> + * Copyright 2019 Kontron Europe GmbH

This is out of date.

> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/pwm.h>
> +#include <linux/regmap.h>
> +
> +/*
> + * PWM timer block registers.
> + */
> +#define PWM_CTRL		0x00
> +#define   PWM_ENABLE		BIT(7)
> +#define   PWM_MODE_250HZ	0
> +#define   PWM_MODE_500HZ	1
> +#define   PWM_MODE_1KHZ		2
> +#define   PWM_MODE_2KHZ		3
> +#define   PWM_MODE_MASK		GENMASK(1, 0)
> +#define PWM_CYCLE		0x01
> +#define   PWM_CYCLE_MAX		0x7f
> +
> +struct sl28cpld_pwm {
> +	struct pwm_chip pwm_chip;
> +	struct regmap *regmap;
> +	u32 offset;
> +};
> +
> +struct sl28cpld_pwm_periods {
> +	u8 ctrl;
> +	unsigned long duty_cycle;
> +};
> +
> +struct sl28cpld_pwm_config {
> +	unsigned long period_ns;
> +	u8 max_duty_cycle;
> +};

Also, instead of hand rolling your own structure here, I think it
would be prudent to re-use something that already exists.  Seeing as
this will be used to describe possible state, perhaps 'struct
pwm_state' would be suitable - leaving polarity and enabled
unpopulated of course.

Ah wait (sorry, thinking allowed and on-the-fly here), what is
max_duty_cycle here?  I assume this does not have the same
meaning/value-type as the one in 'struct pwm_state'.  What does
max_duty_cycle represent in your use-case?

> +static struct sl28cpld_pwm_config sl28cpld_pwm_config[] = {
> +	[PWM_MODE_250HZ] = { .period_ns = 4000000, .max_duty_cycle = 0x80 },
> +	[PWM_MODE_500HZ] = { .period_ns = 2000000, .max_duty_cycle = 0x40 },
> +	[PWM_MODE_1KHZ] = { .period_ns = 1000000, .max_duty_cycle = 0x20 },
> +	[PWM_MODE_2KHZ] = { .period_ns =  500000, .max_duty_cycle = 0x10 },
> +};

Tiny nit: If you lined these up from the '{'s it would be easier to
see/compare the period_ns values at first glance, rather than having
to count the ' 's and '0's.

> +static inline struct sl28cpld_pwm *to_sl28cpld_pwm(struct pwm_chip *chip)
> +{
> +	return container_of(chip, struct sl28cpld_pwm, pwm_chip);
> +}

Why not save yourself the trouble and just:

  struct sl28cpld_pwm *pwm = dev_get_drvdata(chip->dev);

> +static void sl28cpld_pwm_get_state(struct pwm_chip *chip,
> +				   struct pwm_device *pwm,
> +				   struct pwm_state *state)
> +{
> +	struct sl28cpld_pwm *spc = to_sl28cpld_pwm(chip);
> +	static struct sl28cpld_pwm_config *config;
> +	unsigned int reg;
> +	unsigned long cycle;

Why is this 'long' here and 'long long' in *_apply()?

> +	unsigned int mode;
> +
> +	regmap_read(spc->regmap, spc->offset + PWM_CTRL, &reg);
> +
> +	state->enabled = reg & PWM_ENABLE;
> +
> +	mode = FIELD_GET(PWM_MODE_MASK, reg);
> +	config = &sl28cpld_pwm_config[mode];
> +	state->period = config->period_ns;
> +
> +	regmap_read(spc->regmap, spc->offset + PWM_CYCLE, &reg);
> +	cycle = reg * config->period_ns;
> +	state->duty_cycle = DIV_ROUND_CLOSEST_ULL(cycle,
> +						  config->max_duty_cycle);
> +}
> +
> +static int sl28cpld_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> +			      const struct pwm_state *state)
> +{
> +	struct sl28cpld_pwm *spc = to_sl28cpld_pwm(chip);
> +	struct sl28cpld_pwm_config *config;
> +	unsigned long long cycle;
> +	int ret;
> +	int mode;
> +	u8 ctrl;
> +
> +	/* update config, first search best matching period */

Please use correct grammar (less full stops) in comments.

> +	for (mode = 0; mode < ARRAY_SIZE(sl28cpld_pwm_config); mode++) {
> +		config = &sl28cpld_pwm_config[mode];
> +		if (state->period == config->period_ns)
> +			break;
> +	}
> +
> +	if (mode == ARRAY_SIZE(sl28cpld_pwm_config))
> +		return -EINVAL;
> +
> +	ctrl = FIELD_PREP(PWM_MODE_MASK, mode);
> +	if (state->enabled)
> +		ctrl |= PWM_ENABLE;
> +
> +	cycle = state->duty_cycle * config->max_duty_cycle;
> +	do_div(cycle, state->period);

Forgive my ignorance (I'm new here!), but what are these 2 lines
doing?  Here we are multiplying the current duty_cycle with the
maximum value, then dividing by the period.

So in the case of PWM_MODE_1KHZ with a 50% duty cycle, you'd have:

   (500000 * 0x20[16]) / 1000000 = [0x10]16

Thus, the above gives as a proportional representation of the maximum
valid value for placement into the cycle control register(s), right?

Either way (whether I'm correct or not), I think it would be nice to
mention this in a comment.  Maybe even clarify with a simple example.

> +	/*
> +	 * The hardware doesn't allow to set max_duty_cycle if the
> +	 * 250Hz mode is enabled. But since this is "all-high" output
> +	 * just use the 500Hz mode with the duty cycle to max value.
> +	 */
> +	if (cycle == config->max_duty_cycle) {
> +		ctrl &= ~PWM_MODE_MASK;
> +		ctrl |= FIELD_PREP(PWM_MODE_MASK, PWM_MODE_500HZ);
> +		cycle = PWM_CYCLE_MAX;
> +	}

This is being executed even when 250Hz mode is not enabled.

Is that by design?  If so, it doesn't match the comment.

> +	ret = regmap_write(spc->regmap, spc->offset + PWM_CTRL, ctrl);
> +	if (ret)
> +		return ret;
> +
> +	return regmap_write(spc->regmap, spc->offset + PWM_CYCLE, (u8)cycle);
> +}
> +
> +static const struct pwm_ops sl28cpld_pwm_ops = {
> +	.apply = sl28cpld_pwm_apply,
> +	.get_state = sl28cpld_pwm_get_state,
> +	.owner = THIS_MODULE,
> +};
> +
> +static int sl28cpld_pwm_probe(struct platform_device *pdev)
> +{
> +	struct sl28cpld_pwm *pwm;

This is super confusing.  Here you call it 'pwm', but when you bring
the data to the fore for consumption, you call it something different
('spc') for some reason.

Is there logic behind this?

> +	struct pwm_chip *chip;
> +	int ret;
> +
> +	if (!pdev->dev.parent)
> +		return -ENODEV;
> +
> +	pwm = devm_kzalloc(&pdev->dev, sizeof(*pwm), GFP_KERNEL);
> +	if (!pwm)
> +		return -ENOMEM;
> +
> +	pwm->regmap = dev_get_regmap(pdev->dev.parent, NULL);
> +	if (!pwm->regmap)
> +		return -ENODEV;
> +
> +	ret = device_property_read_u32(&pdev->dev, "reg", &pwm->offset);

Really?  Can you use the 'reg' property in this way?

Side question:
  Do any of your child address spaces actually overlap/intersect?

> +	if (ret)
> +		return -EINVAL;
> +
> +	/* initialize struct pwm_chip */

Proper grammar please.

> +	chip = &pwm->pwm_chip;
> +	chip->dev = &pdev->dev;
> +	chip->ops = &sl28cpld_pwm_ops;
> +	chip->base = -1;
> +	chip->npwm = 1;
> +
> +	ret = pwmchip_add(&pwm->pwm_chip);
> +	if (ret < 0)

Is '> 0' even valid?

Suggest "!ret" here, as you have done above.

> +		return ret;
> +
> +	platform_set_drvdata(pdev, pwm);
> +
> +	return 0;
> +}
> +
> +static int sl28cpld_pwm_remove(struct platform_device *pdev)
> +{
> +	struct sl28cpld_pwm *pwm = platform_get_drvdata(pdev);
> +
> +	return pwmchip_remove(&pwm->pwm_chip);
> +}
> +
> +static const struct of_device_id sl28cpld_pwm_of_match[] = {
> +	{ .compatible = "kontron,sl28cpld-pwm" },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, sl28cpld_pwm_of_match);
> +
> +static const struct platform_device_id sl28cpld_pwm_id_table[] = {
> +	{"sl28cpld-pwm"},

Spaces either side of the "'s please.

> +	{},
> +};
> +MODULE_DEVICE_TABLE(platform, sl28cpld_pwm_id_table);

What are you using this for?

> +static struct platform_driver sl28cpld_pwm_driver = {
> +	.probe = sl28cpld_pwm_probe,
> +	.remove	= sl28cpld_pwm_remove,
> +	.id_table = sl28cpld_pwm_id_table,
> +	.driver = {
> +		.name = KBUILD_MODNAME,

Please just use the quoted name in full.

> +		.of_match_table = sl28cpld_pwm_of_match,
> +	},
> +};
> +module_platform_driver(sl28cpld_pwm_driver);
> +
> +MODULE_DESCRIPTION("sl28cpld PWM Driver");

"SL28CPLD" ?

> +MODULE_AUTHOR("Michael Walle <michael@walle.cc>");
> +MODULE_LICENSE("GPL");

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 05/11] pwm: add support for sl28cpld PWM controller
  2020-06-05  8:49   ` Lee Jones
@ 2020-06-05  9:33     ` Andy Shevchenko
  2020-06-05 11:39     ` Michael Walle
  2020-06-05 18:17     ` Michael Walle
  2 siblings, 0 replies; 74+ messages in thread
From: Andy Shevchenko @ 2020-06-05  9:33 UTC (permalink / raw)
  To: Lee Jones
  Cc: Michael Walle, open list:GPIO SUBSYSTEM, devicetree,
	Linux Kernel Mailing List, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm Mailing List, Linus Walleij,
	Bartosz Golaszewski, Rob Herring, Jean Delvare, Guenter Roeck,
	Thierry Reding, Uwe Kleine-König, Wim Van Sebroeck,
	Shawn Guo, Li Yang, Thomas Gleixner, Jason Cooper, Marc Zyngier,
	Mark Brown, Greg Kroah-Hartman, Andy Shevchenko

On Fri, Jun 5, 2020 at 11:51 AM Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 04 Jun 2020, Michael Walle wrote:

...

> > +     cycle = state->duty_cycle * config->max_duty_cycle;
> > +     do_div(cycle, state->period);
>
> Forgive my ignorance (I'm new here!), but what are these 2 lines
> doing?  Here we are multiplying the current duty_cycle with the
> maximum value, then dividing by the period.
>
> So in the case of PWM_MODE_1KHZ with a 50% duty cycle, you'd have:
>
>    (500000 * 0x20[16]) / 1000000 = [0x10]16
>
> Thus, the above gives as a proportional representation of the maximum
> valid value for placement into the cycle control register(s), right?
>
> Either way (whether I'm correct or not), I think it would be nice to
> mention this in a comment.  Maybe even clarify with a simple example.

IIRC PWM has a helper for that (to calc period based on PWM state and
new duty cycle %).

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-05  6:57   ` Lee Jones
@ 2020-06-05  9:51     ` Michael Walle
  2020-06-05 10:50     ` Mark Brown
  1 sibling, 0 replies; 74+ messages in thread
From: Michael Walle @ 2020-06-05  9:51 UTC (permalink / raw)
  To: Lee Jones
  Cc: broonie, linux-gpio, devicetree, linux-kernel, linux-hwmon,
	linux-pwm, linux-watchdog, linux-arm-kernel, Linus Walleij,
	Bartosz Golaszewski, Rob Herring, Jean Delvare, Guenter Roeck,
	Thierry Reding, Uwe Kleine-König, Wim Van Sebroeck,
	Shawn Guo, Li Yang, Thomas Gleixner, Jason Cooper, Marc Zyngier,
	Greg Kroah-Hartman, Andy Shevchenko

Hi Lee,

thanks for the review.

Am 2020-06-05 08:57, schrieb Lee Jones:
> Mark, what do you think?
> 
> On Thu, 04 Jun 2020, Michael Walle wrote:
> 
>> Add the core support for the board management controller found on the
>> SMARC-sAL28 board. It consists of the following functions:
>>  - watchdog
>>  - GPIO controller
>>  - PWM controller
>>  - fan sensor
>>  - interrupt controller
>> 
>> At the moment, this controller is used on the Kontron SMARC-sAL28 
>> board.
>> 
>> Please note that the MFD driver is defined as bool in the Kconfig
>> because the next patch will add interrupt support.
>> 
>> Signed-off-by: Michael Walle <michael@walle.cc>
>> ---
>>  drivers/mfd/Kconfig    | 19 ++++++++++
>>  drivers/mfd/Makefile   |  2 ++
>>  drivers/mfd/sl28cpld.c | 79 
>> ++++++++++++++++++++++++++++++++++++++++++
>>  3 files changed, 100 insertions(+)
>>  create mode 100644 drivers/mfd/sl28cpld.c
>> 
>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
>> index 4f8b73d92df3..5c0cd514d197 100644
>> --- a/drivers/mfd/Kconfig
>> +++ b/drivers/mfd/Kconfig
>> @@ -2109,5 +2109,24 @@ config SGI_MFD_IOC3
>>  	  If you have an SGI Origin, Octane, or a PCI IOC3 card,
>>  	  then say Y. Otherwise say N.
>> 
>> +config MFD_SL28CPLD
>> +	bool "Kontron sl28 core driver"
> 
> "Kontron SL28 Core Driver"

ok

> 
>> +	depends on I2C=y
>> +	depends on OF
>> +	select REGMAP_I2C
>> +	select MFD_CORE
>> +	help
>> +	  This option enables support for the board management controller
>> +	  found on the Kontron sl28 CPLD. You have to select individual
> 
> I can't find any reference to the "Kontron sl28 CPLD" online.
> 
> Is there a datasheet?

Unfortunately not.

>> +	  functions, such as watchdog, GPIO, etc, under the corresponding 
>> menus
>> +	  in order to enable them.
>> +
>> +	  Currently supported boards are:
>> +
>> +		Kontron SMARC-sAL28
>> +
>> +	  To compile this driver as a module, choose M here: the module will 
>> be
>> +	  called sl28cpld.
>> +
>>  endmenu
>>  endif
>> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
>> index 9367a92f795a..be59fb40aa28 100644
>> --- a/drivers/mfd/Makefile
>> +++ b/drivers/mfd/Makefile
>> @@ -264,3 +264,5 @@ obj-$(CONFIG_MFD_ROHM_BD718XX)	+= rohm-bd718x7.o
>>  obj-$(CONFIG_MFD_STMFX) 	+= stmfx.o
>> 
>>  obj-$(CONFIG_SGI_MFD_IOC3)	+= ioc3.o
>> +
>> +obj-$(CONFIG_MFD_SL28CPLD)	+= sl28cpld.o
>> diff --git a/drivers/mfd/sl28cpld.c b/drivers/mfd/sl28cpld.c
>> new file mode 100644
>> index 000000000000..a23194bb6efa
>> --- /dev/null
>> +++ b/drivers/mfd/sl28cpld.c
>> @@ -0,0 +1,79 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * MFD core for the sl28cpld.
> 
> Ideally this would match the Kconfig subject line.

ok

> 
>> + * Copyright 2019 Kontron Europe GmbH
> 
> This is out of date.

ok

>> + */
>> +
>> +#include <linux/i2c.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/kernel.h>
>> +#include <linux/mfd/core.h>
>> +#include <linux/module.h>
>> +#include <linux/of_platform.h>
>> +#include <linux/regmap.h>
>> +
>> +#define SL28CPLD_VERSION	0x03
>> +#define SL28CPLD_MIN_REQ_VERSION 14
>> +
>> +struct sl28cpld {
>> +	struct device *dev;
>> +	struct regmap *regmap;
>> +};
> 
> Why do you need this structure?

see below

>> +static const struct regmap_config sl28cpld_regmap_config = {
>> +	.reg_bits = 8,
>> +	.val_bits = 8,
>> +	.reg_stride = 1,
>> +};
>> +
>> +static int sl28cpld_probe(struct i2c_client *i2c)
>> +{
>> +	struct sl28cpld *sl28cpld;
>> +	struct device *dev = &i2c->dev;
>> +	unsigned int cpld_version;
>> +	int ret;
>> +
>> +	sl28cpld = devm_kzalloc(dev, sizeof(*sl28cpld), GFP_KERNEL);
>> +	if (!sl28cpld)
>> +		return -ENOMEM;
>> +
>> +	sl28cpld->regmap = devm_regmap_init_i2c(i2c, 
>> &sl28cpld_regmap_config);
>> +	if (IS_ERR(sl28cpld->regmap))
>> +		return PTR_ERR(sl28cpld->regmap);
> 
> This is now a shared memory allocator and not an MFD at all.
> 
> I'm clamping down on these type of drivers!
> 
> Please find a better way to accomplish this.
> 
> Potentially using "simple-mfd" and "simple-regmap".
> 
> The former already exists and does what you want.  The latter doesn't
> yet exist, but could solve your and lots of other contributor's
> issues.

Mh, the former doesn't provide a regmap, correct? Most MMIO drivers 
won't
need it, but this is an I2C device. So yes, I could come up with a
"simple-regmap" proposal. I guess that should go into drivers/mfd/ 
because
it is more than just adding one line, i.e. you would have to configure 
the
regmap and its different interfaces.

But how would you model that version check below for example? (Not that 
I'm
very keen of it.)

> 
> Heck maybe I'll implement it myself if this keeps happening.
> 
>> +	ret = regmap_read(sl28cpld->regmap, SL28CPLD_VERSION, 
>> &cpld_version);
>> +	if (ret)
>> +		return ret;
>> +
>> +	if (cpld_version < SL28CPLD_MIN_REQ_VERSION) {
>> +		dev_err(dev, "unsupported CPLD version %d\n", cpld_version);
>> +		return -ENODEV;
>> +	}
>> +
>> +	sl28cpld->dev = dev;
>> +	i2c_set_clientdata(i2c, sl28cpld);
> 
> If the struct definition is in here, how do you use it elsewhere?

I wanted to store the regmap somewhere, but because there are no users, 
I'll
drop that.

>> +	dev_info(dev, "successfully probed. CPLD version %d\n", 
>> cpld_version);
>> +
>> +	return devm_of_platform_populate(&i2c->dev);
>> +}
>> +
>> +static const struct of_device_id sl28cpld_of_match[] = {
>> +	{ .compatible = "kontron,sl28cpld-r1", },
>> +	{}
>> +};
>> +MODULE_DEVICE_TABLE(of, sl28cpld_of_match);
>> +
>> +static struct i2c_driver sl28cpld_driver = {
>> +	.probe_new = sl28cpld_probe,
>> +	.driver = {
>> +		.name = "sl28cpld",
>> +		.of_match_table = of_match_ptr(sl28cpld_of_match),
>> +	},
>> +};
>> +module_i2c_driver(sl28cpld_driver);
>> +
>> +MODULE_DESCRIPTION("sl28cpld MFD Core Driver");
>> +MODULE_AUTHOR("Michael Walle <michael@walle.cc>");
>> +MODULE_LICENSE("GPL");

-- 
-michael

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-05  8:01   ` Andy Shevchenko
  2020-06-05  8:02     ` Andy Shevchenko
@ 2020-06-05 10:09     ` Michael Walle
  2020-06-05 10:48       ` Andy Shevchenko
  1 sibling, 1 reply; 74+ messages in thread
From: Michael Walle @ 2020-06-05 10:09 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: open list:GPIO SUBSYSTEM, devicetree, Linux Kernel Mailing List,
	linux-hwmon, linux-pwm, linux-watchdog, linux-arm Mailing List,
	Linus Walleij, Bartosz Golaszewski, Rob Herring, Jean Delvare,
	Guenter Roeck, Lee Jones, Thierry Reding, Uwe Kleine-König,
	Wim Van Sebroeck, Shawn Guo, Li Yang, Thomas Gleixner,
	Jason Cooper, Marc Zyngier, Mark Brown, Greg Kroah-Hartman,
	Andy Shevchenko

Hi Andy,

Am 2020-06-05 10:01, schrieb Andy Shevchenko:
> On Fri, Jun 5, 2020 at 12:16 AM Michael Walle <michael@walle.cc> wrote:
>> 
>> Add the core support for the board management controller found on the
>> SMARC-sAL28 board. It consists of the following functions:
>>  - watchdog
>>  - GPIO controller
>>  - PWM controller
>>  - fan sensor
>>  - interrupt controller
>> 
>> At the moment, this controller is used on the Kontron SMARC-sAL28 
>> board.
>> 
>> Please note that the MFD driver is defined as bool in the Kconfig
>> because the next patch will add interrupt support.
> 
> ...
> 
>> +config MFD_SL28CPLD
>> +       bool "Kontron sl28 core driver"
>> +       depends on I2C=y
> 
> Why not module?

There are users of the interupt lines provided by the interrupt 
controller.
For example, the gpio-button driver. If this is compiled into the kernel
(which it is by default in the arm64 defconfig), probing will fail 
because
the interrupt is not found. Is there a better way for that? I guess the 
same
is true for the GPIO driver.

> 
>> +       depends on OF
> 
> I didn't find an evidence this is needed.

see below.

> 
> No Compile Test?

ok

>> +       select REGMAP_I2C
>> +       select MFD_CORE
> 
> ...
> 
>> +#include <linux/of_platform.h>
> 
> No evidence of user of this.
> I think you meant mod_devicetable.h.

devm_of_platform_populate(), so I need CONFIG_OF, too right?


>> +static struct i2c_driver sl28cpld_driver = {
>> +       .probe_new = sl28cpld_probe,
>> +       .driver = {
>> +               .name = "sl28cpld",
>> +               .of_match_table = of_match_ptr(sl28cpld_of_match),
> 
> Drop of_match_ptr(). It has a little sense in this context (depends 
> OF).
> It will have a little sense even if you drop depends OF b/c you will
> introduce a compiler warning.

ok

> 
>> +       },
>> +};

-- 
-michael

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 04/11] watchdog: add support for sl28cpld watchdog
  2020-06-05  8:14   ` Andy Shevchenko
@ 2020-06-05 10:24     ` Michael Walle
  2020-06-05 10:50       ` Andy Shevchenko
  0 siblings, 1 reply; 74+ messages in thread
From: Michael Walle @ 2020-06-05 10:24 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: open list:GPIO SUBSYSTEM, devicetree, Linux Kernel Mailing List,
	linux-hwmon, linux-pwm, linux-watchdog, linux-arm Mailing List,
	Linus Walleij, Bartosz Golaszewski, Rob Herring, Jean Delvare,
	Guenter Roeck, Lee Jones, Thierry Reding, Uwe Kleine-König,
	Wim Van Sebroeck, Shawn Guo, Li Yang, Thomas Gleixner,
	Jason Cooper, Marc Zyngier, Mark Brown, Greg Kroah-Hartman,
	Andy Shevchenko

Am 2020-06-05 10:14, schrieb Andy Shevchenko:
> On Fri, Jun 5, 2020 at 12:14 AM Michael Walle <michael@walle.cc> wrote:
>> 
>> Add support for the watchdog of the sl28cpld board management
>> controller. This is part of a multi-function device driver.
> 
> ...
> 
>> +#include <linux/of_device.h>
> 
> Didn't find a user of this.

I guess mod_devicetable.h then.

> 
> ...
> 
>> +static bool nowayout = WATCHDOG_NOWAYOUT;
>> +module_param(nowayout, bool, 0);
>> +MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started 
>> (default="
>> +                               __MODULE_STRING(WATCHDOG_NOWAYOUT) 
>> ")");
>> +
>> +static int timeout;
>> +module_param(timeout, int, 0);
>> +MODULE_PARM_DESC(timeout, "Initial watchdog timeout in seconds");
> 
> Guenter ACKed this, but I'm wondering why we still need module 
> parameters...

How would a user change the nowayout or the timeout? For the latter 
there is
a device tree entry, but thats not easy changable by the user.

> 
> ...
> 
>> +       int ret;
>> +
>> +       ret = regmap_read(wdt->regmap, wdt->offset + WDT_COUNT, &val);
>> +
>> +       return (ret < 0) ? 0 : val;
> 
> Besides extra parentheses and questionable ' < 0' part, the following
> would look better I think
> 
> ret = ...
> if (ret)
>   return 0;
> 
> return val;

yes, you're right.

> 
> ...
> 
>> +       int ret;
>> +
>> +       ret = regmap_write(wdt->regmap, wdt->offset + WDT_TIMEOUT, 
>> timeout);
>> +       if (!ret)
>> +               wdd->timeout = timeout;
>> +
>> +       return ret;
> 
> Similar story here:
> 
> ret = ...
> if (ret)
>   return ret;
> 
> wdd->... = ...
> return 0;
> 
> ...

ok

> 
>> +       ret = regmap_read(wdt->regmap, wdt->offset + WDT_CTRL, 
>> &status);
> 
>> +       if (ret < 0)
> 
> What ' < 0' means? Do we have some positive return values?
> Ditto for all your code.

probably not, I'll go over all return values and change them.

>> +               return ret;
> 
> ...
> 
>> +       if (status & WDT_CTRL_EN) {
>> +               sl28cpld_wdt_start(wdd);
> 
>> +               set_bit(WDOG_HW_RUNNING, &wdd->status);
> 
> Do you need atomic op here? Why?

I'd say consistency, all watchdog drivers do it like that. I just
had a look at where this is used, but it looks like access from
userspace is protected by a lock.

> 
>> +       }
> 
> ...
> 
>> +static const struct of_device_id sl28cpld_wdt_of_match[] = {
>> +       { .compatible = "kontron,sl28cpld-wdt" },
> 
>> +       {},
> 
> No comma.

yeah ;)

-- 
-michael

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-05 10:09     ` Michael Walle
@ 2020-06-05 10:48       ` Andy Shevchenko
  2020-06-05 11:51         ` Michael Walle
  0 siblings, 1 reply; 74+ messages in thread
From: Andy Shevchenko @ 2020-06-05 10:48 UTC (permalink / raw)
  To: Michael Walle
  Cc: open list:GPIO SUBSYSTEM, devicetree, Linux Kernel Mailing List,
	linux-hwmon, linux-pwm, linux-watchdog, linux-arm Mailing List,
	Linus Walleij, Bartosz Golaszewski, Rob Herring, Jean Delvare,
	Guenter Roeck, Lee Jones, Thierry Reding, Uwe Kleine-König,
	Wim Van Sebroeck, Shawn Guo, Li Yang, Thomas Gleixner,
	Jason Cooper, Marc Zyngier, Mark Brown, Greg Kroah-Hartman,
	Andy Shevchenko

On Fri, Jun 5, 2020 at 1:09 PM Michael Walle <michael@walle.cc> wrote:
> Am 2020-06-05 10:01, schrieb Andy Shevchenko:
> > On Fri, Jun 5, 2020 at 12:16 AM Michael Walle <michael@walle.cc> wrote:

...

> >> +       bool "Kontron sl28 core driver"
> >> +       depends on I2C=y
> >
> > Why not module?
>
> There are users of the interupt lines provided by the interrupt
> controller.
> For example, the gpio-button driver. If this is compiled into the kernel
> (which it is by default in the arm64 defconfig), probing will fail
> because
> the interrupt is not found. Is there a better way for that? I guess the
> same
> is true for the GPIO driver.

And GPIO nicely handles this via deferred probe mechanism. Why it
can't be used here?
So, we really need to have a strong argument to limit module nowadays
to be only builtin.

...

> >> +       depends on OF
> >
> > I didn't find an evidence this is needed.

> >> +#include <linux/of_platform.h>
> >
> > No evidence of user of this.
> > I think you meant mod_devicetable.h.
>
> devm_of_platform_populate(), so I need CONFIG_OF, too right?

Ah, this explains header, thanks!
But it doesn't explain depends OF.

So, perhaps,

depends OF || COMPILE_TEST will be more informative, i.e.
tells "okay, this driver can be compiled w/o OF, but won't be functional".

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-05  6:57   ` Lee Jones
  2020-06-05  9:51     ` Michael Walle
@ 2020-06-05 10:50     ` Mark Brown
  2020-06-05 20:07       ` Michael Walle
  1 sibling, 1 reply; 74+ messages in thread
From: Mark Brown @ 2020-06-05 10:50 UTC (permalink / raw)
  To: Lee Jones
  Cc: Michael Walle, linux-gpio, devicetree, linux-kernel, linux-hwmon,
	linux-pwm, linux-watchdog, linux-arm-kernel, Linus Walleij,
	Bartosz Golaszewski, Rob Herring, Jean Delvare, Guenter Roeck,
	Thierry Reding, Uwe Kleine-König, Wim Van Sebroeck,
	Shawn Guo, Li Yang, Thomas Gleixner, Jason Cooper, Marc Zyngier,
	Greg Kroah-Hartman, Andy Shevchenko

[-- Attachment #1: Type: text/plain, Size: 911 bytes --]

On Fri, Jun 05, 2020 at 07:57:09AM +0100, Lee Jones wrote:
> On Thu, 04 Jun 2020, Michael Walle wrote:

> > +	sl28cpld->regmap = devm_regmap_init_i2c(i2c, &sl28cpld_regmap_config);
> > +	if (IS_ERR(sl28cpld->regmap))
> > +		return PTR_ERR(sl28cpld->regmap);

> This is now a shared memory allocator and not an MFD at all.

> I'm clamping down on these type of drivers!

> Please find a better way to accomplish this.

What is the concern with this?  Looking at the patch I'm guessing the
concern would be that the driver isn't instantiating any MFD children
and instead requiring them to be put in the DT?

> Potentially using "simple-mfd" and "simple-regmap".

> The former already exists and does what you want.  The latter doesn't
> yet exist, but could solve your and lots of other contributor's
> issues.

I have no idea what you are thinking of when you say "simple-regmap" so
it is difficult to comment.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 04/11] watchdog: add support for sl28cpld watchdog
  2020-06-05 10:24     ` Michael Walle
@ 2020-06-05 10:50       ` Andy Shevchenko
  2020-06-05 13:52         ` Guenter Roeck
  0 siblings, 1 reply; 74+ messages in thread
From: Andy Shevchenko @ 2020-06-05 10:50 UTC (permalink / raw)
  To: Michael Walle
  Cc: open list:GPIO SUBSYSTEM, devicetree, Linux Kernel Mailing List,
	linux-hwmon, linux-pwm, linux-watchdog, linux-arm Mailing List,
	Linus Walleij, Bartosz Golaszewski, Rob Herring, Jean Delvare,
	Guenter Roeck, Lee Jones, Thierry Reding, Uwe Kleine-König,
	Wim Van Sebroeck, Shawn Guo, Li Yang, Thomas Gleixner,
	Jason Cooper, Marc Zyngier, Mark Brown, Greg Kroah-Hartman,
	Andy Shevchenko

On Fri, Jun 5, 2020 at 1:24 PM Michael Walle <michael@walle.cc> wrote:
> Am 2020-06-05 10:14, schrieb Andy Shevchenko:
> > On Fri, Jun 5, 2020 at 12:14 AM Michael Walle <michael@walle.cc> wrote:

...

> >> +static bool nowayout = WATCHDOG_NOWAYOUT;
> >> +module_param(nowayout, bool, 0);
> >> +MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started
> >> (default="
> >> +                               __MODULE_STRING(WATCHDOG_NOWAYOUT)
> >> ")");
> >> +
> >> +static int timeout;
> >> +module_param(timeout, int, 0);
> >> +MODULE_PARM_DESC(timeout, "Initial watchdog timeout in seconds");
> >
> > Guenter ACKed this, but I'm wondering why we still need module
> > parameters...
>
> How would a user change the nowayout or the timeout? For the latter
> there is
> a device tree entry, but thats not easy changable by the user.

Yes, it's more question to VIm and Guenter than to you.

...

> >> +       if (status & WDT_CTRL_EN) {
> >> +               sl28cpld_wdt_start(wdd);
> >
> >> +               set_bit(WDOG_HW_RUNNING, &wdd->status);
> >
> > Do you need atomic op here? Why?
>
> I'd say consistency, all watchdog drivers do it like that. I just
> had a look at where this is used, but it looks like access from
> userspace is protected by a lock.

Okay then.

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 05/11] pwm: add support for sl28cpld PWM controller
  2020-06-05  8:49   ` Lee Jones
  2020-06-05  9:33     ` Andy Shevchenko
@ 2020-06-05 11:39     ` Michael Walle
  2020-06-05 18:17     ` Michael Walle
  2 siblings, 0 replies; 74+ messages in thread
From: Michael Walle @ 2020-06-05 11:39 UTC (permalink / raw)
  To: Lee Jones
  Cc: linux-gpio, devicetree, linux-kernel, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm-kernel, Linus Walleij,
	Bartosz Golaszewski, Rob Herring, Jean Delvare, Guenter Roeck,
	Thierry Reding, Uwe Kleine-König, Wim Van Sebroeck,
	Shawn Guo, Li Yang, Thomas Gleixner, Jason Cooper, Marc Zyngier,
	Mark Brown, Greg Kroah-Hartman, Andy Shevchenko

Am 2020-06-05 10:49, schrieb Lee Jones:
> On Thu, 04 Jun 2020, Michael Walle wrote:
> 
>> Add support for the PWM controller of the sl28cpld board management
>> controller. This is part of a multi-function device driver.
>> 
>> The controller has one PWM channel and can just generate four distinct
>> frequencies.
>> 
>> Signed-off-by: Michael Walle <michael@walle.cc>
>> ---
>>  drivers/pwm/Kconfig        |  10 ++
>>  drivers/pwm/Makefile       |   1 +
>>  drivers/pwm/pwm-sl28cpld.c | 201 
>> +++++++++++++++++++++++++++++++++++++
>>  3 files changed, 212 insertions(+)
>>  create mode 100644 drivers/pwm/pwm-sl28cpld.c
>> 
>> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
>> index cb8d739067d2..a39371c11ff6 100644
>> --- a/drivers/pwm/Kconfig
>> +++ b/drivers/pwm/Kconfig
>> @@ -437,6 +437,16 @@ config PWM_SIFIVE
>>  	  To compile this driver as a module, choose M here: the module
>>  	  will be called pwm-sifive.
>> 
>> +config PWM_SL28CPLD
>> +	tristate "Kontron sl28 PWM support"
>> +	depends on MFD_SL28CPLD
>> +	help
>> +	  Generic PWM framework driver for board management controller
>> +	  found on the Kontron sl28 CPLD.
>> +
>> +	  To compile this driver as a module, choose M here: the module
>> +	  will be called pwm-sl28cpld.
>> +
>>  config PWM_SPEAR
>>  	tristate "STMicroelectronics SPEAr PWM support"
>>  	depends on PLAT_SPEAR || COMPILE_TEST
>> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
>> index a59c710e98c7..c479623724e8 100644
>> --- a/drivers/pwm/Makefile
>> +++ b/drivers/pwm/Makefile
>> @@ -41,6 +41,7 @@ obj-$(CONFIG_PWM_RENESAS_TPU)	+= pwm-renesas-tpu.o
>>  obj-$(CONFIG_PWM_ROCKCHIP)	+= pwm-rockchip.o
>>  obj-$(CONFIG_PWM_SAMSUNG)	+= pwm-samsung.o
>>  obj-$(CONFIG_PWM_SIFIVE)	+= pwm-sifive.o
>> +obj-$(CONFIG_PWM_SL28CPLD)	+= pwm-sl28cpld.o
>>  obj-$(CONFIG_PWM_SPEAR)		+= pwm-spear.o
>>  obj-$(CONFIG_PWM_SPRD)		+= pwm-sprd.o
>>  obj-$(CONFIG_PWM_STI)		+= pwm-sti.o
>> diff --git a/drivers/pwm/pwm-sl28cpld.c b/drivers/pwm/pwm-sl28cpld.c
>> new file mode 100644
>> index 000000000000..d82303f509f5
>> --- /dev/null
>> +++ b/drivers/pwm/pwm-sl28cpld.c
>> @@ -0,0 +1,201 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * sl28cpld PWM driver.
>> + *
>> + * Copyright 2019 Kontron Europe GmbH
> 
> This is out of date.

ok

> 
>> + */
>> +
>> +#include <linux/bitfield.h>
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>> +#include <linux/of_device.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/pwm.h>
>> +#include <linux/regmap.h>
>> +
>> +/*
>> + * PWM timer block registers.
>> + */
>> +#define PWM_CTRL		0x00
>> +#define   PWM_ENABLE		BIT(7)
>> +#define   PWM_MODE_250HZ	0
>> +#define   PWM_MODE_500HZ	1
>> +#define   PWM_MODE_1KHZ		2
>> +#define   PWM_MODE_2KHZ		3
>> +#define   PWM_MODE_MASK		GENMASK(1, 0)
>> +#define PWM_CYCLE		0x01
>> +#define   PWM_CYCLE_MAX		0x7f
>> +
>> +struct sl28cpld_pwm {
>> +	struct pwm_chip pwm_chip;
>> +	struct regmap *regmap;
>> +	u32 offset;
>> +};
>> +
>> +struct sl28cpld_pwm_periods {
>> +	u8 ctrl;
>> +	unsigned long duty_cycle;
>> +};
>> +
>> +struct sl28cpld_pwm_config {
>> +	unsigned long period_ns;
>> +	u8 max_duty_cycle;
>> +};
> 
> Also, instead of hand rolling your own structure here, I think it
> would be prudent to re-use something that already exists.  Seeing as
> this will be used to describe possible state, perhaps 'struct
> pwm_state' would be suitable - leaving polarity and enabled
> unpopulated of course.
> 
> Ah wait (sorry, thinking allowed and on-the-fly here), what is
> max_duty_cycle here?  I assume this does not have the same
> meaning/value-type as the one in 'struct pwm_state'.  What does
> max_duty_cycle represent in your use-case?

Its the max value of the PWM_CYCLE register, with one exception
of the 250Hz mode. There it would be 0x7f; but it is used as a scaling
factor too. Thus I added the "fixup" below.

>> +static struct sl28cpld_pwm_config sl28cpld_pwm_config[] = {
>> +	[PWM_MODE_250HZ] = { .period_ns = 4000000, .max_duty_cycle = 0x80 },
>> +	[PWM_MODE_500HZ] = { .period_ns = 2000000, .max_duty_cycle = 0x40 },
>> +	[PWM_MODE_1KHZ] = { .period_ns = 1000000, .max_duty_cycle = 0x20 },
>> +	[PWM_MODE_2KHZ] = { .period_ns =  500000, .max_duty_cycle = 0x10 },
>> +};
> 
> Tiny nit: If you lined these up from the '{'s it would be easier to
> see/compare the period_ns values at first glance, rather than having
> to count the ' 's and '0's.

yep.

> 
>> +static inline struct sl28cpld_pwm *to_sl28cpld_pwm(struct pwm_chip 
>> *chip)
>> +{
>> +	return container_of(chip, struct sl28cpld_pwm, pwm_chip);
>> +}
> 
> Why not save yourself the trouble and just:
> 
>   struct sl28cpld_pwm *pwm = dev_get_drvdata(chip->dev);

looks better, yes.

> 
>> +static void sl28cpld_pwm_get_state(struct pwm_chip *chip,
>> +				   struct pwm_device *pwm,
>> +				   struct pwm_state *state)
>> +{
>> +	struct sl28cpld_pwm *spc = to_sl28cpld_pwm(chip);
>> +	static struct sl28cpld_pwm_config *config;
>> +	unsigned int reg;
>> +	unsigned long cycle;
> 
> Why is this 'long' here and 'long long' in *_apply()?

cycle has a max value of "u8_max * <defined ulong from config above>",
where below it might be "ulong * ulong". But for consinstency, I could
make it unsigned long long here, too.

>> +	unsigned int mode;
>> +
>> +	regmap_read(spc->regmap, spc->offset + PWM_CTRL, &reg);
>> +
>> +	state->enabled = reg & PWM_ENABLE;
>> +
>> +	mode = FIELD_GET(PWM_MODE_MASK, reg);
>> +	config = &sl28cpld_pwm_config[mode];
>> +	state->period = config->period_ns;
>> +
>> +	regmap_read(spc->regmap, spc->offset + PWM_CYCLE, &reg);
>> +	cycle = reg * config->period_ns;
>> +	state->duty_cycle = DIV_ROUND_CLOSEST_ULL(cycle,
>> +						  config->max_duty_cycle);
>> +}
>> +
>> +static int sl28cpld_pwm_apply(struct pwm_chip *chip, struct 
>> pwm_device *pwm,
>> +			      const struct pwm_state *state)
>> +{
>> +	struct sl28cpld_pwm *spc = to_sl28cpld_pwm(chip);
>> +	struct sl28cpld_pwm_config *config;
>> +	unsigned long long cycle;
>> +	int ret;
>> +	int mode;
>> +	u8 ctrl;
>> +
>> +	/* update config, first search best matching period */
> 
> Please use correct grammar (less full stops) in comments.

ok

> 
>> +	for (mode = 0; mode < ARRAY_SIZE(sl28cpld_pwm_config); mode++) {
>> +		config = &sl28cpld_pwm_config[mode];
>> +		if (state->period == config->period_ns)
>> +			break;
>> +	}
>> +
>> +	if (mode == ARRAY_SIZE(sl28cpld_pwm_config))
>> +		return -EINVAL;
>> +
>> +	ctrl = FIELD_PREP(PWM_MODE_MASK, mode);
>> +	if (state->enabled)
>> +		ctrl |= PWM_ENABLE;
>> +
>> +	cycle = state->duty_cycle * config->max_duty_cycle;
>> +	do_div(cycle, state->period);
> 
> Forgive my ignorance (I'm new here!), but what are these 2 lines
> doing?  Here we are multiplying the current duty_cycle with the
> maximum value, then dividing by the period.
> 
> So in the case of PWM_MODE_1KHZ with a 50% duty cycle, you'd have:
> 
>    (500000 * 0x20[16]) / 1000000 = [0x10]16
> 
> Thus, the above gives as a proportional representation of the maximum
> valid value for placement into the cycle control register(s), right?

correct.

> Either way (whether I'm correct or not), I think it would be nice to
> mention this in a comment.  Maybe even clarify with a simple example.

yes, I'll also look into the helper Andy mentioned. Thus it might be
even self explanatory.

>> +	/*
>> +	 * The hardware doesn't allow to set max_duty_cycle if the
>> +	 * 250Hz mode is enabled. But since this is "all-high" output
>> +	 * just use the 500Hz mode with the duty cycle to max value.
>> +	 */
>> +	if (cycle == config->max_duty_cycle) {
>> +		ctrl &= ~PWM_MODE_MASK;
>> +		ctrl |= FIELD_PREP(PWM_MODE_MASK, PWM_MODE_500HZ);
>> +		cycle = PWM_CYCLE_MAX;
>> +	}
> 
> This is being executed even when 250Hz mode is not enabled.
> 
> Is that by design?

Yes because the mode doesn't matter if you have a duty cycle of 100%.
You'd be free to choose any mode except 250Hz.

> If so, it doesn't match the comment.

Mh? Ok its a bit confusing and it might imply that this is only done
for the 250Hz case. But it doensn't mention it is _only_ used for this
mode.

/*
  * The hardware doesn't allow to set max_duty_cycle if the
  * 250Hz mode is enabled, thus we have to trap that here.
  * But because a 100% duty cycle is equal on all modes, i.e.
  * it is just a "all-high" output, we trap any case with a
  * 100% duty cycle and use the 500Hz mode.
  */

>> +	ret = regmap_write(spc->regmap, spc->offset + PWM_CTRL, ctrl);
>> +	if (ret)
>> +		return ret;
>> +
>> +	return regmap_write(spc->regmap, spc->offset + PWM_CYCLE, 
>> (u8)cycle);
>> +}
>> +
>> +static const struct pwm_ops sl28cpld_pwm_ops = {
>> +	.apply = sl28cpld_pwm_apply,
>> +	.get_state = sl28cpld_pwm_get_state,
>> +	.owner = THIS_MODULE,
>> +};
>> +
>> +static int sl28cpld_pwm_probe(struct platform_device *pdev)
>> +{
>> +	struct sl28cpld_pwm *pwm;
> 
> This is super confusing.  Here you call it 'pwm', but when you bring
> the data to the fore for consumption, you call it something different
> ('spc') for some reason.

yeah it is :(

> Is there logic behind this?

And no it is not. sorry for that.

>> +	struct pwm_chip *chip;
>> +	int ret;
>> +
>> +	if (!pdev->dev.parent)
>> +		return -ENODEV;
>> +
>> +	pwm = devm_kzalloc(&pdev->dev, sizeof(*pwm), GFP_KERNEL);
>> +	if (!pwm)
>> +		return -ENOMEM;
>> +
>> +	pwm->regmap = dev_get_regmap(pdev->dev.parent, NULL);
>> +	if (!pwm->regmap)
>> +		return -ENODEV;
>> +
>> +	ret = device_property_read_u32(&pdev->dev, "reg", &pwm->offset);
> 
> Really?  Can you use the 'reg' property in this way?

Well formerly it was IORESOURCE_REG, which gives you a register offset,
see commit 72dcb1197228b ("resources: Add register address resource 
type").
There is also the of_get_address(), but I doubt that would be correct 
here,
because it does bus mapping etc.
So I looked at how other MFD drivers does it, most of the MFD have the
advantage of having fixed register offsets and then just use hardcoded
offsets. But there are some drivers which pull their offset out of the
reg property from the device tree itself.

$ grep -r "read_u32.*\"reg\"" drivers/
$ grep -r "read_u32.*\"reg\".*base" drivers/

Does anyone have a better idea?

> Side question:
>   Do any of your child address spaces actually overlap/intersect?

nope. they are distinct.

> 
>> +	if (ret)
>> +		return -EINVAL;
>> +
>> +	/* initialize struct pwm_chip */
> 
> Proper grammar please.
ok

> 
>> +	chip = &pwm->pwm_chip;
>> +	chip->dev = &pdev->dev;
>> +	chip->ops = &sl28cpld_pwm_ops;
>> +	chip->base = -1;
>> +	chip->npwm = 1;
>> +
>> +	ret = pwmchip_add(&pwm->pwm_chip);
>> +	if (ret < 0)
> 
> Is '> 0' even valid?
> 
> Suggest "!ret" here, as you have done above.

Yes, same comment as Andy had on the other patches.

>> +		return ret;
>> +
>> +	platform_set_drvdata(pdev, pwm);
>> +
>> +	return 0;
>> +}
>> +
>> +static int sl28cpld_pwm_remove(struct platform_device *pdev)
>> +{
>> +	struct sl28cpld_pwm *pwm = platform_get_drvdata(pdev);
>> +
>> +	return pwmchip_remove(&pwm->pwm_chip);
>> +}
>> +
>> +static const struct of_device_id sl28cpld_pwm_of_match[] = {
>> +	{ .compatible = "kontron,sl28cpld-pwm" },
>> +	{},
>> +};
>> +MODULE_DEVICE_TABLE(of, sl28cpld_pwm_of_match);
>> +
>> +static const struct platform_device_id sl28cpld_pwm_id_table[] = {
>> +	{"sl28cpld-pwm"},
> 
> Spaces either side of the "'s please.

ok

> 
>> +	{},
>> +};
>> +MODULE_DEVICE_TABLE(platform, sl28cpld_pwm_id_table);
> 
> What are you using this for?

They are from the time when these drivers were mfd_cells. But I wanted
to keep them here, if in the future there is another mfd driver which
uses these drivers.

>> +static struct platform_driver sl28cpld_pwm_driver = {
>> +	.probe = sl28cpld_pwm_probe,
>> +	.remove	= sl28cpld_pwm_remove,
>> +	.id_table = sl28cpld_pwm_id_table,
>> +	.driver = {
>> +		.name = KBUILD_MODNAME,
> 
> Please just use the quoted name in full.

Mhh, is there any rule for this? Sometimes KBUILD_MODNAME is used
and sometimes an hardcoded name. I thought KBUILD_MODNAME is nice
because it is filled automatically. And the platform probe use
the .id_table anyway.

>> +		.of_match_table = sl28cpld_pwm_of_match,
>> +	},
>> +};
>> +module_platform_driver(sl28cpld_pwm_driver);
>> +
>> +MODULE_DESCRIPTION("sl28cpld PWM Driver");
> 
> "SL28CPLD" ?

Actually no, I want to call that "sl28cpld". The first part
is "sl28" (not SL28) and sl28CPLD looks pretty weird. I tried
to be consistent on Kconfig/dt-bindings/drivers about this
naming.

>> +MODULE_AUTHOR("Michael Walle <michael@walle.cc>");
>> +MODULE_LICENSE("GPL");

-- 
-michael

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-05 10:48       ` Andy Shevchenko
@ 2020-06-05 11:51         ` Michael Walle
  0 siblings, 0 replies; 74+ messages in thread
From: Michael Walle @ 2020-06-05 11:51 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: open list:GPIO SUBSYSTEM, devicetree, Linux Kernel Mailing List,
	linux-hwmon, linux-pwm, linux-watchdog, linux-arm Mailing List,
	Linus Walleij, Bartosz Golaszewski, Rob Herring, Jean Delvare,
	Guenter Roeck, Lee Jones, Thierry Reding, Uwe Kleine-König,
	Wim Van Sebroeck, Shawn Guo, Li Yang, Thomas Gleixner,
	Jason Cooper, Marc Zyngier, Mark Brown, Greg Kroah-Hartman,
	Andy Shevchenko

Am 2020-06-05 12:48, schrieb Andy Shevchenko:
> On Fri, Jun 5, 2020 at 1:09 PM Michael Walle <michael@walle.cc> wrote:
>> Am 2020-06-05 10:01, schrieb Andy Shevchenko:
>> > On Fri, Jun 5, 2020 at 12:16 AM Michael Walle <michael@walle.cc> wrote:
> 
> ...
> 
>> >> +       bool "Kontron sl28 core driver"
>> >> +       depends on I2C=y
>> >
>> > Why not module?
>> 
>> There are users of the interupt lines provided by the interrupt
>> controller.
>> For example, the gpio-button driver. If this is compiled into the 
>> kernel
>> (which it is by default in the arm64 defconfig), probing will fail
>> because
>> the interrupt is not found. Is there a better way for that? I guess 
>> the
>> same
>> is true for the GPIO driver.
> 
> And GPIO nicely handles this via deferred probe mechanism. Why it
> can't be used here?
> So, we really need to have a strong argument to limit module nowadays
> to be only builtin.

Was that a question for me? TBH thats how other interrupt drivers doing
it for now. And it would be the users who need to be fixed, right? Or
even the platform code? Because it will complain with

[    2.962990] irq: no irq domain found for interrupt-controller@1c !
[    2.975762] gpio-keys buttons0: Found button without gpio or irq
[    2.981872] gpio-keys: probe of buttons0 failed with error -22

>> >> +       depends on OF
>> >
>> > I didn't find an evidence this is needed.
> 
>> >> +#include <linux/of_platform.h>
>> >
>> > No evidence of user of this.
>> > I think you meant mod_devicetable.h.
>> 
>> devm_of_platform_populate(), so I need CONFIG_OF, too right?
> 
> Ah, this explains header, thanks!
> But it doesn't explain depends OF.
> 
> So, perhaps,
> 
> depends OF || COMPILE_TEST will be more informative, i.e.
> tells "okay, this driver can be compiled w/o OF, but won't be 
> functional".

ok


-- 
-michael

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 06/11] gpio: add support for the sl28cpld GPIO controller
  2020-06-04 21:10 ` [PATCH v4 06/11] gpio: add support for the sl28cpld GPIO controller Michael Walle
@ 2020-06-05 12:00   ` Andy Shevchenko
  2020-06-05 12:42     ` Michael Walle
  0 siblings, 1 reply; 74+ messages in thread
From: Andy Shevchenko @ 2020-06-05 12:00 UTC (permalink / raw)
  To: Michael Walle
  Cc: open list:GPIO SUBSYSTEM, devicetree, Linux Kernel Mailing List,
	linux-hwmon, linux-pwm, linux-watchdog, linux-arm Mailing List,
	Linus Walleij, Bartosz Golaszewski, Rob Herring, Jean Delvare,
	Guenter Roeck, Lee Jones, Thierry Reding, Uwe Kleine-König,
	Wim Van Sebroeck, Shawn Guo, Li Yang, Thomas Gleixner,
	Jason Cooper, Marc Zyngier, Mark Brown, Greg Kroah-Hartman,
	Andy Shevchenko

On Fri, Jun 5, 2020 at 12:14 AM Michael Walle <michael@walle.cc> wrote:

> Add support for the GPIO controller of the sl28 board management
> controller. This driver is part of a multi-function device.
>
> A controller has 8 lines. There are three different flavors:
> full-featured GPIO with interrupt support, input-only and output-only.

...

> +#include <linux/of_device.h>

I think also not needed.
But wait...

> +       return devm_regmap_add_irq_chip_np(dev, dev_of_node(dev), regmap,

It seems regmap needs to be converted to use fwnode.

> +                                          irq, IRQF_SHARED | IRQF_ONESHOT, 0,
> +                                          irq_chip, &gpio->irq_data);

...

> +       if (!pdev->dev.parent)
> +               return -ENODEV;

Are we expecting to get shot into foot? I mean why we need this check?

> +       dev_id = platform_get_device_id(pdev);
> +       if (dev_id)
> +               type = dev_id->driver_data;

Oh, no. In new code we don't need this. We have facilities to provide
platform data in a form of fwnode.

> +       else
> +               type = (uintptr_t)of_device_get_match_data(&pdev->dev);

So does this. device_get_match_data().

> +       if (!type)
> +               return -ENODEV;

...

> +       if (irq_support &&

Why do you need this flag? Can't simple IRQ number be sufficient?

> +           device_property_read_bool(&pdev->dev, "interrupt-controller")) {
> +               irq = platform_get_irq(pdev, 0);
> +               if (irq < 0)
> +                       return irq;
> +
> +               ret = sl28cpld_gpio_irq_init(&pdev->dev, gpio, regmap,
> +                                            base, irq);
> +               if (ret)
> +                       return ret;
> +
> +               config.irq_domain = regmap_irq_get_domain(gpio->irq_data);
> +       }

...

> +static const struct of_device_id sl28cpld_gpio_of_match[] = {

> +       { .compatible = "kontron,sl28cpld-gpio",
> +         .data = (void *)SL28CPLD_GPIO },
> +       { .compatible = "kontron,sl28cpld-gpi",
> +         .data = (void *)SL28CPLD_GPI },
> +       { .compatible = "kontron,sl28cpld-gpo",
> +         .data = (void *)SL28CPLD_GPO },

All above can be twice less LOCs.

> +       {},

No comma.

> +};


...

> +               .name = KBUILD_MODNAME,

This actually not good idea in long term. File name can change and break an ABI.

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 07/11] hwmon: add support for the sl28cpld hardware monitoring controller
  2020-06-04 21:10 ` [PATCH v4 07/11] hwmon: add support for the sl28cpld hardware monitoring controller Michael Walle
@ 2020-06-05 12:06   ` Andy Shevchenko
  0 siblings, 0 replies; 74+ messages in thread
From: Andy Shevchenko @ 2020-06-05 12:06 UTC (permalink / raw)
  To: Michael Walle
  Cc: open list:GPIO SUBSYSTEM, devicetree, Linux Kernel Mailing List,
	linux-hwmon, linux-pwm, linux-watchdog, linux-arm Mailing List,
	Linus Walleij, Bartosz Golaszewski, Rob Herring, Jean Delvare,
	Guenter Roeck, Lee Jones, Thierry Reding, Uwe Kleine-König,
	Wim Van Sebroeck, Shawn Guo, Li Yang, Thomas Gleixner,
	Jason Cooper, Marc Zyngier, Mark Brown, Greg Kroah-Hartman,
	Andy Shevchenko

On Fri, Jun 5, 2020 at 12:14 AM Michael Walle <michael@walle.cc> wrote:
>
> Add support for the hardware monitoring controller of the sl28cpld board
> management controller. This driver is part of a multi-function device.

...

> +#include <linux/of_device.h>

mod_devicetable.h ?

...


> +       hwmon_dev = devm_hwmon_device_register_with_info(&pdev->dev,
> +                               "sl28cpld_hwmon", hwmon,
> +                               &sl28cpld_hwmon_chip_info, NULL);
> +       if (IS_ERR(hwmon_dev)) {
> +               dev_err(&pdev->dev, "failed to register as hwmon device");

> +               return PTR_ERR(hwmon_dev);
> +       }
> +
> +       return 0;

PTR_ERR_OR_ZERO() ?

...

> +static const struct of_device_id sl28cpld_hwmon_of_match[] = {
> +       { .compatible = "kontron,sl28cpld-fan" },

> +       {},

No comma.

> +};

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 06/11] gpio: add support for the sl28cpld GPIO controller
  2020-06-05 12:00   ` Andy Shevchenko
@ 2020-06-05 12:42     ` Michael Walle
  2020-06-05 13:15       ` Andy Shevchenko
  0 siblings, 1 reply; 74+ messages in thread
From: Michael Walle @ 2020-06-05 12:42 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: open list:GPIO SUBSYSTEM, devicetree, Linux Kernel Mailing List,
	linux-hwmon, linux-pwm, linux-watchdog, linux-arm Mailing List,
	Linus Walleij, Bartosz Golaszewski, Rob Herring, Jean Delvare,
	Guenter Roeck, Lee Jones, Thierry Reding, Uwe Kleine-König,
	Wim Van Sebroeck, Shawn Guo, Li Yang, Thomas Gleixner,
	Jason Cooper, Marc Zyngier, Mark Brown, Greg Kroah-Hartman,
	Andy Shevchenko

Am 2020-06-05 14:00, schrieb Andy Shevchenko:
> On Fri, Jun 5, 2020 at 12:14 AM Michael Walle <michael@walle.cc> wrote:
> 
>> Add support for the GPIO controller of the sl28 board management
>> controller. This driver is part of a multi-function device.
>> 
>> A controller has 8 lines. There are three different flavors:
>> full-featured GPIO with interrupt support, input-only and output-only.
> 
> ...
> 
>> +#include <linux/of_device.h>
> 
> I think also not needed.
> But wait...
> 
>> +       return devm_regmap_add_irq_chip_np(dev, dev_of_node(dev), 
>> regmap,
> 
> It seems regmap needs to be converted to use fwnode.

Mhh, this _np functions was actually part of this series in the
beginning.

>> +                                          irq, IRQF_SHARED | 
>> IRQF_ONESHOT, 0,
>> +                                          irq_chip, &gpio->irq_data);
> 
> ...
> 
>> +       if (!pdev->dev.parent)
>> +               return -ENODEV;
> 
> Are we expecting to get shot into foot? I mean why we need this check?

Can we be sure, that we always have a parent node? You are the first
which complains about this ;) There were some other comments to move
this to the beginning of the function.

> 
>> +       dev_id = platform_get_device_id(pdev);
>> +       if (dev_id)
>> +               type = dev_id->driver_data;
> 
> Oh, no. In new code we don't need this. We have facilities to provide
> platform data in a form of fwnode.

Ok I'll look into that.

But I already have a question, so there are of_property_read_xx(), which
seems to be the old functions, then there is device_property_read_xx() 
and
fwnode_property_read_xx(). What is the difference between the latter 
two?

> 
>> +       else
>> +               type = 
>> (uintptr_t)of_device_get_match_data(&pdev->dev);
> 
> So does this. device_get_match_data().
ok

> 
>> +       if (!type)
>> +               return -ENODEV;
> 
> ...
> 
>> +       if (irq_support &&
> 
> Why do you need this flag? Can't simple IRQ number be sufficient?

I want to make sure, the is no misconfiguration. Eg. only GPIO
flavors which has irq_support set, have the additional interrupt
registers.

> 
>> +           device_property_read_bool(&pdev->dev, 
>> "interrupt-controller")) {
>> +               irq = platform_get_irq(pdev, 0);
>> +               if (irq < 0)
>> +                       return irq;
>> +
>> +               ret = sl28cpld_gpio_irq_init(&pdev->dev, gpio, regmap,
>> +                                            base, irq);
>> +               if (ret)
>> +                       return ret;
>> +
>> +               config.irq_domain = 
>> regmap_irq_get_domain(gpio->irq_data);
>> +       }
> 
> ...
> 
>> +static const struct of_device_id sl28cpld_gpio_of_match[] = {
> 
>> +       { .compatible = "kontron,sl28cpld-gpio",
>> +         .data = (void *)SL28CPLD_GPIO },
>> +       { .compatible = "kontron,sl28cpld-gpi",
>> +         .data = (void *)SL28CPLD_GPI },
>> +       { .compatible = "kontron,sl28cpld-gpo",
>> +         .data = (void *)SL28CPLD_GPO },
> 
> All above can be twice less LOCs.

They are longer than 80 chars. Or do I miss something?

> 
>> +       {},
> 
> No comma.

ok

>> +};
> 
> 
> ...
> 
>> +               .name = KBUILD_MODNAME,
> 
> This actually not good idea in long term. File name can change and 
> break an ABI.

Ahh an explanation, why this is bad. Ok makes sense, although to be 
fair,
.id_table should be used for the driver name matching. I'm not sure if
this is used somewhere else, though.


-- 
-michael

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 06/11] gpio: add support for the sl28cpld GPIO controller
  2020-06-05 12:42     ` Michael Walle
@ 2020-06-05 13:15       ` Andy Shevchenko
  2020-06-05 18:44         ` Michael Walle
  0 siblings, 1 reply; 74+ messages in thread
From: Andy Shevchenko @ 2020-06-05 13:15 UTC (permalink / raw)
  To: Michael Walle
  Cc: open list:GPIO SUBSYSTEM, devicetree, Linux Kernel Mailing List,
	linux-hwmon, linux-pwm, linux-watchdog, linux-arm Mailing List,
	Linus Walleij, Bartosz Golaszewski, Rob Herring, Jean Delvare,
	Guenter Roeck, Lee Jones, Thierry Reding, Uwe Kleine-König,
	Wim Van Sebroeck, Shawn Guo, Li Yang, Thomas Gleixner,
	Jason Cooper, Marc Zyngier, Mark Brown, Greg Kroah-Hartman

On Fri, Jun 05, 2020 at 02:42:53PM +0200, Michael Walle wrote:
> Am 2020-06-05 14:00, schrieb Andy Shevchenko:
> > On Fri, Jun 5, 2020 at 12:14 AM Michael Walle <michael@walle.cc> wrote:

> > > +       return devm_regmap_add_irq_chip_np(dev, dev_of_node(dev),
> > > regmap,
> > 
> > It seems regmap needs to be converted to use fwnode.
> 
> Mhh, this _np functions was actually part of this series in the
> beginning.

Then, please, make them fwnode aware rather than OF centric.

> > > IRQF_ONESHOT, 0,
> > > +                                          irq_chip, &gpio->irq_data);

...

> > > +       dev_id = platform_get_device_id(pdev);
> > > +       if (dev_id)
> > > +               type = dev_id->driver_data;
> > 
> > Oh, no. In new code we don't need this. We have facilities to provide
> > platform data in a form of fwnode.
> 
> Ok I'll look into that.
> 
> But I already have a question, so there are of_property_read_xx(), which
> seems to be the old functions, then there is device_property_read_xx() and
> fwnode_property_read_xx(). What is the difference between the latter two?

It's easy. device_*() requires struct device to be established for this, so,
operates only against devices, while the fwnode_*() operates on pure data which
might or might not be related to any devices. If you understand OF examples
better, consider device node vs. child of such node.

...

> > > +       if (irq_support &&
> > 
> > Why do you need this flag? Can't simple IRQ number be sufficient?
> 
> I want to make sure, the is no misconfiguration. Eg. only GPIO
> flavors which has irq_support set, have the additional interrupt
> registers.

In gpio-dwapb, for example, we simple check two things: a) hardware limitation
(if IRQ is assigned to a proper port) and b) if there is any IRQ comes from DT,
ACPI, etc.

> > > +           device_property_read_bool(&pdev->dev,
> > > "interrupt-controller")) {
> > > +               irq = platform_get_irq(pdev, 0);
> > > +               if (irq < 0)
> > > +                       return irq;
> > > +
> > > +               ret = sl28cpld_gpio_irq_init(&pdev->dev, gpio, regmap,
> > > +                                            base, irq);
> > > +               if (ret)
> > > +                       return ret;
> > > +
> > > +               config.irq_domain =
> > > regmap_irq_get_domain(gpio->irq_data);
> > > +       }

...

> > > +       { .compatible = "kontron,sl28cpld-gpio",
> > > +         .data = (void *)SL28CPLD_GPIO },
> > > +       { .compatible = "kontron,sl28cpld-gpi",
> > > +         .data = (void *)SL28CPLD_GPI },
> > > +       { .compatible = "kontron,sl28cpld-gpo",
> > > +         .data = (void *)SL28CPLD_GPO },
> > 
> > All above can be twice less LOCs.
> 
> They are longer than 80 chars. Or do I miss something?

We have 100 :-)

...

> > > +               .name = KBUILD_MODNAME,
> > 
> > This actually not good idea in long term. File name can change and break
> > an ABI.
> 
> Ahh an explanation, why this is bad. Ok makes sense, although to be fair,
> .id_table should be used for the driver name matching. I'm not sure if
> this is used somewhere else, though.

I saw in my practice chain of renames for a driver. Now, if somebody
somewhere would like to instantiate a platform driver by its name...
Oops, ABI breakage.

And of course using platform data for such device makes less sense.

-- 
With Best Regards,
Andy Shevchenko



^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 04/11] watchdog: add support for sl28cpld watchdog
  2020-06-05 10:50       ` Andy Shevchenko
@ 2020-06-05 13:52         ` Guenter Roeck
  2020-06-05 14:09           ` Andy Shevchenko
  0 siblings, 1 reply; 74+ messages in thread
From: Guenter Roeck @ 2020-06-05 13:52 UTC (permalink / raw)
  To: Andy Shevchenko, Michael Walle
  Cc: open list:GPIO SUBSYSTEM, devicetree, Linux Kernel Mailing List,
	linux-hwmon, linux-pwm, linux-watchdog, linux-arm Mailing List,
	Linus Walleij, Bartosz Golaszewski, Rob Herring, Jean Delvare,
	Lee Jones, Thierry Reding, Uwe Kleine-König,
	Wim Van Sebroeck, Shawn Guo, Li Yang, Thomas Gleixner,
	Jason Cooper, Marc Zyngier, Mark Brown, Greg Kroah-Hartman,
	Andy Shevchenko

On 6/5/20 3:50 AM, Andy Shevchenko wrote:
> On Fri, Jun 5, 2020 at 1:24 PM Michael Walle <michael@walle.cc> wrote:
>> Am 2020-06-05 10:14, schrieb Andy Shevchenko:
>>> On Fri, Jun 5, 2020 at 12:14 AM Michael Walle <michael@walle.cc> wrote:
> 
> ...
> 
>>>> +static bool nowayout = WATCHDOG_NOWAYOUT;
>>>> +module_param(nowayout, bool, 0);
>>>> +MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started
>>>> (default="
>>>> +                               __MODULE_STRING(WATCHDOG_NOWAYOUT)
>>>> ")");
>>>> +
>>>> +static int timeout;
>>>> +module_param(timeout, int, 0);
>>>> +MODULE_PARM_DESC(timeout, "Initial watchdog timeout in seconds");
>>>
>>> Guenter ACKed this, but I'm wondering why we still need module
>>> parameters...
>>
>> How would a user change the nowayout or the timeout? For the latter
>> there is
>> a device tree entry, but thats not easy changable by the user.
> 
> Yes, it's more question to VIm and Guenter than to you.
> 

Has support for providing module parameters with the kernel command line
been discontinued/deprecated, or did it run out of favor ? Sorry if I
missed that.

nowayout has a configuration default. A module parameter is sometimes
provided by drivers to be able to override it. The timeout provided
via devicetree or on the command line is only the initial/default
timeout, and the watchdog daemon can change it after opening the
watchdog device as it sees fit.

Guenter

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 04/11] watchdog: add support for sl28cpld watchdog
  2020-06-05 13:52         ` Guenter Roeck
@ 2020-06-05 14:09           ` Andy Shevchenko
  2020-06-05 15:05             ` Guenter Roeck
  0 siblings, 1 reply; 74+ messages in thread
From: Andy Shevchenko @ 2020-06-05 14:09 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Michael Walle, open list:GPIO SUBSYSTEM, devicetree,
	Linux Kernel Mailing List, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm Mailing List, Linus Walleij,
	Bartosz Golaszewski, Rob Herring, Jean Delvare, Lee Jones,
	Thierry Reding, Uwe Kleine-König, Wim Van Sebroeck,
	Shawn Guo, Li Yang, Thomas Gleixner, Jason Cooper, Marc Zyngier,
	Mark Brown, Greg Kroah-Hartman

On Fri, Jun 05, 2020 at 06:52:00AM -0700, Guenter Roeck wrote:
> On 6/5/20 3:50 AM, Andy Shevchenko wrote:
> > On Fri, Jun 5, 2020 at 1:24 PM Michael Walle <michael@walle.cc> wrote:
> >> Am 2020-06-05 10:14, schrieb Andy Shevchenko:
> >>> On Fri, Jun 5, 2020 at 12:14 AM Michael Walle <michael@walle.cc> wrote:

...

> >>>> +static bool nowayout = WATCHDOG_NOWAYOUT;
> >>>> +module_param(nowayout, bool, 0);
> >>>> +MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started
> >>>> (default="
> >>>> +                               __MODULE_STRING(WATCHDOG_NOWAYOUT)
> >>>> ")");
> >>>> +
> >>>> +static int timeout;
> >>>> +module_param(timeout, int, 0);
> >>>> +MODULE_PARM_DESC(timeout, "Initial watchdog timeout in seconds");
> >>>
> >>> Guenter ACKed this, but I'm wondering why we still need module
> >>> parameters...
> >>
> >> How would a user change the nowayout or the timeout? For the latter
> >> there is
> >> a device tree entry, but thats not easy changable by the user.
> > 
> > Yes, it's more question to VIm and Guenter than to you.
> > 
> 
> Has support for providing module parameters with the kernel command line
> been discontinued/deprecated, or did it run out of favor ? Sorry if I
> missed that.

Latter according to Greg KH. One of the (plenty) examples [1].

[1]: https://www.mail-archive.com/driverdev-devel@linuxdriverproject.org/msg96495.html

> nowayout has a configuration default. A module parameter is sometimes
> provided by drivers to be able to override it. The timeout provided
> via devicetree or on the command line is only the initial/default
> timeout, and the watchdog daemon can change it after opening the
> watchdog device as it sees fit.

Thanks for explanation.

-- 
With Best Regards,
Andy Shevchenko



^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 04/11] watchdog: add support for sl28cpld watchdog
  2020-06-05 14:09           ` Andy Shevchenko
@ 2020-06-05 15:05             ` Guenter Roeck
  2020-06-05 16:04               ` Andy Shevchenko
  0 siblings, 1 reply; 74+ messages in thread
From: Guenter Roeck @ 2020-06-05 15:05 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Michael Walle, open list:GPIO SUBSYSTEM, devicetree,
	Linux Kernel Mailing List, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm Mailing List, Linus Walleij,
	Bartosz Golaszewski, Rob Herring, Jean Delvare, Lee Jones,
	Thierry Reding, Uwe Kleine-König, Wim Van Sebroeck,
	Shawn Guo, Li Yang, Thomas Gleixner, Jason Cooper, Marc Zyngier,
	Mark Brown, Greg Kroah-Hartman

On Fri, Jun 05, 2020 at 05:09:11PM +0300, Andy Shevchenko wrote:
> On Fri, Jun 05, 2020 at 06:52:00AM -0700, Guenter Roeck wrote:
> > On 6/5/20 3:50 AM, Andy Shevchenko wrote:
> > > On Fri, Jun 5, 2020 at 1:24 PM Michael Walle <michael@walle.cc> wrote:
> > >> Am 2020-06-05 10:14, schrieb Andy Shevchenko:
> > >>> On Fri, Jun 5, 2020 at 12:14 AM Michael Walle <michael@walle.cc> wrote:
> 
> ...
> 
> > >>>> +static bool nowayout = WATCHDOG_NOWAYOUT;
> > >>>> +module_param(nowayout, bool, 0);
> > >>>> +MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started
> > >>>> (default="
> > >>>> +                               __MODULE_STRING(WATCHDOG_NOWAYOUT)
> > >>>> ")");
> > >>>> +
> > >>>> +static int timeout;
> > >>>> +module_param(timeout, int, 0);
> > >>>> +MODULE_PARM_DESC(timeout, "Initial watchdog timeout in seconds");
> > >>>
> > >>> Guenter ACKed this, but I'm wondering why we still need module
> > >>> parameters...
> > >>
> > >> How would a user change the nowayout or the timeout? For the latter
> > >> there is
> > >> a device tree entry, but thats not easy changable by the user.
> > > 
> > > Yes, it's more question to VIm and Guenter than to you.
> > > 
> > 
> > Has support for providing module parameters with the kernel command line
> > been discontinued/deprecated, or did it run out of favor ? Sorry if I
> > missed that.
> 
> Latter according to Greg KH. One of the (plenty) examples [1].
> 
> [1]: https://www.mail-archive.com/driverdev-devel@linuxdriverproject.org/msg96495.html
> 
What is the suggested replacement ?

Guenter

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 04/11] watchdog: add support for sl28cpld watchdog
  2020-06-05 15:05             ` Guenter Roeck
@ 2020-06-05 16:04               ` Andy Shevchenko
  2020-06-05 16:34                 ` Guenter Roeck
  0 siblings, 1 reply; 74+ messages in thread
From: Andy Shevchenko @ 2020-06-05 16:04 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Michael Walle, open list:GPIO SUBSYSTEM, devicetree,
	Linux Kernel Mailing List, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm Mailing List, Linus Walleij,
	Bartosz Golaszewski, Rob Herring, Jean Delvare, Lee Jones,
	Thierry Reding, Uwe Kleine-König, Wim Van Sebroeck,
	Shawn Guo, Li Yang, Thomas Gleixner, Jason Cooper, Marc Zyngier,
	Mark Brown, Greg Kroah-Hartman

On Fri, Jun 5, 2020 at 6:05 PM Guenter Roeck <linux@roeck-us.net> wrote:
> On Fri, Jun 05, 2020 at 05:09:11PM +0300, Andy Shevchenko wrote:
> > On Fri, Jun 05, 2020 at 06:52:00AM -0700, Guenter Roeck wrote:
> > > On 6/5/20 3:50 AM, Andy Shevchenko wrote:
> > > > On Fri, Jun 5, 2020 at 1:24 PM Michael Walle <michael@walle.cc> wrote:
> > > >> Am 2020-06-05 10:14, schrieb Andy Shevchenko:
> > > >>> On Fri, Jun 5, 2020 at 12:14 AM Michael Walle <michael@walle.cc> wrote:
> >
> > ...
> >
> > > >>>> +static bool nowayout = WATCHDOG_NOWAYOUT;
> > > >>>> +module_param(nowayout, bool, 0);
> > > >>>> +MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started
> > > >>>> (default="
> > > >>>> +                               __MODULE_STRING(WATCHDOG_NOWAYOUT)
> > > >>>> ")");
> > > >>>> +
> > > >>>> +static int timeout;
> > > >>>> +module_param(timeout, int, 0);
> > > >>>> +MODULE_PARM_DESC(timeout, "Initial watchdog timeout in seconds");
> > > >>>
> > > >>> Guenter ACKed this, but I'm wondering why we still need module
> > > >>> parameters...
> > > >>
> > > >> How would a user change the nowayout or the timeout? For the latter
> > > >> there is
> > > >> a device tree entry, but thats not easy changable by the user.
> > > >
> > > > Yes, it's more question to VIm and Guenter than to you.
> > > >
> > >
> > > Has support for providing module parameters with the kernel command line
> > > been discontinued/deprecated, or did it run out of favor ? Sorry if I
> > > missed that.
> >
> > Latter according to Greg KH. One of the (plenty) examples [1].
> >
> > [1]: https://www.mail-archive.com/driverdev-devel@linuxdriverproject.org/msg96495.html
> >
> What is the suggested replacement ?

In some mails he suggested to use sysfs.

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 04/11] watchdog: add support for sl28cpld watchdog
  2020-06-05 16:04               ` Andy Shevchenko
@ 2020-06-05 16:34                 ` Guenter Roeck
  0 siblings, 0 replies; 74+ messages in thread
From: Guenter Roeck @ 2020-06-05 16:34 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Michael Walle, open list:GPIO SUBSYSTEM, devicetree,
	Linux Kernel Mailing List, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm Mailing List, Linus Walleij,
	Bartosz Golaszewski, Rob Herring, Jean Delvare, Lee Jones,
	Thierry Reding, Uwe Kleine-König, Wim Van Sebroeck,
	Shawn Guo, Li Yang, Thomas Gleixner, Jason Cooper, Marc Zyngier,
	Mark Brown, Greg Kroah-Hartman

On 6/5/20 9:04 AM, Andy Shevchenko wrote:
> On Fri, Jun 5, 2020 at 6:05 PM Guenter Roeck <linux@roeck-us.net> wrote:
>> On Fri, Jun 05, 2020 at 05:09:11PM +0300, Andy Shevchenko wrote:
>>> On Fri, Jun 05, 2020 at 06:52:00AM -0700, Guenter Roeck wrote:
>>>> On 6/5/20 3:50 AM, Andy Shevchenko wrote:
>>>>> On Fri, Jun 5, 2020 at 1:24 PM Michael Walle <michael@walle.cc> wrote:
>>>>>> Am 2020-06-05 10:14, schrieb Andy Shevchenko:
>>>>>>> On Fri, Jun 5, 2020 at 12:14 AM Michael Walle <michael@walle.cc> wrote:
>>>
>>> ...
>>>
>>>>>>>> +static bool nowayout = WATCHDOG_NOWAYOUT;
>>>>>>>> +module_param(nowayout, bool, 0);
>>>>>>>> +MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started
>>>>>>>> (default="
>>>>>>>> +                               __MODULE_STRING(WATCHDOG_NOWAYOUT)
>>>>>>>> ")");
>>>>>>>> +
>>>>>>>> +static int timeout;
>>>>>>>> +module_param(timeout, int, 0);
>>>>>>>> +MODULE_PARM_DESC(timeout, "Initial watchdog timeout in seconds");
>>>>>>>
>>>>>>> Guenter ACKed this, but I'm wondering why we still need module
>>>>>>> parameters...
>>>>>>
>>>>>> How would a user change the nowayout or the timeout? For the latter
>>>>>> there is
>>>>>> a device tree entry, but thats not easy changable by the user.
>>>>>
>>>>> Yes, it's more question to VIm and Guenter than to you.
>>>>>
>>>>
>>>> Has support for providing module parameters with the kernel command line
>>>> been discontinued/deprecated, or did it run out of favor ? Sorry if I
>>>> missed that.
>>>
>>> Latter according to Greg KH. One of the (plenty) examples [1].
>>>
>>> [1]: https://www.mail-archive.com/driverdev-devel@linuxdriverproject.org/msg96495.html
>>>
>> What is the suggested replacement ?
> 
> In some mails he suggested to use sysfs.
> 

Using sysfs specifically to defeat "nowayout" would defeat
its purpose, which is specifically to disable the possibility
to stop the watchdog. Using a module parameter (or rather boot
time parameter) is a bit different since that has to be done
consciously and is only valid for a given boot. The same is
true for the timeout parameter. If one can wait for sysfs (or
userspace) to be active, one can as well use the watchdog
daemon to update the timeout. The use case for the module
/ command line parameter or sysfs based timeout is to be
able to set it _before_ userspace is active.

So sysfs is not really an alternative.

Guenter

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 05/11] pwm: add support for sl28cpld PWM controller
  2020-06-05  8:49   ` Lee Jones
  2020-06-05  9:33     ` Andy Shevchenko
  2020-06-05 11:39     ` Michael Walle
@ 2020-06-05 18:17     ` Michael Walle
  2020-06-08  7:46       ` Lee Jones
  2 siblings, 1 reply; 74+ messages in thread
From: Michael Walle @ 2020-06-05 18:17 UTC (permalink / raw)
  To: Lee Jones
  Cc: linux-gpio, devicetree, linux-kernel, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm-kernel, Linus Walleij,
	Bartosz Golaszewski, Rob Herring, Jean Delvare, Guenter Roeck,
	Thierry Reding, Uwe Kleine-König, Wim Van Sebroeck,
	Shawn Guo, Li Yang, Thomas Gleixner, Jason Cooper, Marc Zyngier,
	Mark Brown, Greg Kroah-Hartman, Andy Shevchenko

Am 2020-06-05 10:49, schrieb Lee Jones:
[..]
>> +static inline struct sl28cpld_pwm *to_sl28cpld_pwm(struct pwm_chip 
>> *chip)
>> +{
>> +	return container_of(chip, struct sl28cpld_pwm, pwm_chip);
>> +}
> 
> Why not save yourself the trouble and just:
> 
>   struct sl28cpld_pwm *pwm = dev_get_drvdata(chip->dev);

Is there a reason why not a single pwm driver uses something like that?

-michael

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 06/11] gpio: add support for the sl28cpld GPIO controller
  2020-06-05 13:15       ` Andy Shevchenko
@ 2020-06-05 18:44         ` Michael Walle
  2020-06-05 21:19           ` Andy Shevchenko
  0 siblings, 1 reply; 74+ messages in thread
From: Michael Walle @ 2020-06-05 18:44 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: open list:GPIO SUBSYSTEM, devicetree, Linux Kernel Mailing List,
	linux-hwmon, linux-pwm, linux-watchdog, linux-arm Mailing List,
	Linus Walleij, Bartosz Golaszewski, Rob Herring, Jean Delvare,
	Guenter Roeck, Lee Jones, Thierry Reding, Uwe Kleine-König,
	Wim Van Sebroeck, Shawn Guo, Li Yang, Thomas Gleixner,
	Jason Cooper, Marc Zyngier, Mark Brown, Greg Kroah-Hartman

Am 2020-06-05 15:15, schrieb Andy Shevchenko:
> On Fri, Jun 05, 2020 at 02:42:53PM +0200, Michael Walle wrote:
>> Am 2020-06-05 14:00, schrieb Andy Shevchenko:
>> > On Fri, Jun 5, 2020 at 12:14 AM Michael Walle <michael@walle.cc> wrote:
> 
>> > > +       return devm_regmap_add_irq_chip_np(dev, dev_of_node(dev),
>> > > regmap,
>> >
>> > It seems regmap needs to be converted to use fwnode.
>> 
>> Mhh, this _np functions was actually part of this series in the
>> beginning.
> 
> Then, please, make them fwnode aware rather than OF centric.

ok

> 
>> > > IRQF_ONESHOT, 0,
>> > > +                                          irq_chip, &gpio->irq_data);
> 
> ...
> 
>> > > +       dev_id = platform_get_device_id(pdev);
>> > > +       if (dev_id)
>> > > +               type = dev_id->driver_data;
>> >
>> > Oh, no. In new code we don't need this. We have facilities to provide
>> > platform data in a form of fwnode.
>> 
>> Ok I'll look into that.
>> 
>> But I already have a question, so there are of_property_read_xx(), 
>> which
>> seems to be the old functions, then there is device_property_read_xx() 
>> and
>> fwnode_property_read_xx(). What is the difference between the latter 
>> two?
> 
> It's easy. device_*() requires struct device to be established for 
> this, so,
> operates only against devices, while the fwnode_*() operates on pure 
> data which
> might or might not be related to any devices. If you understand OF 
> examples
> better, consider device node vs. child of such node.

Ahh thanks, got it.

> 
> ...
> 
>> > > +       if (irq_support &&
>> >
>> > Why do you need this flag? Can't simple IRQ number be sufficient?
>> 
>> I want to make sure, the is no misconfiguration. Eg. only GPIO
>> flavors which has irq_support set, have the additional interrupt
>> registers.
> 
> In gpio-dwapb, for example, we simple check two things: a) hardware 
> limitation
> (if IRQ is assigned to a proper port) and b) if there is any IRQ comes 
> from DT,
> ACPI, etc.

I can't follow you here. irq_support is like your (a); or the
"pp->idx == 0" in your example.

>> > > +           device_property_read_bool(&pdev->dev,
>> > > "interrupt-controller")) {
>> > > +               irq = platform_get_irq(pdev, 0);
>> > > +               if (irq < 0)
>> > > +                       return irq;
>> > > +
>> > > +               ret = sl28cpld_gpio_irq_init(&pdev->dev, gpio, regmap,
>> > > +                                            base, irq);
>> > > +               if (ret)
>> > > +                       return ret;
>> > > +
>> > > +               config.irq_domain =
>> > > regmap_irq_get_domain(gpio->irq_data);
>> > > +       }
> 
> ...
> 
>> > > +       { .compatible = "kontron,sl28cpld-gpio",
>> > > +         .data = (void *)SL28CPLD_GPIO },
>> > > +       { .compatible = "kontron,sl28cpld-gpi",
>> > > +         .data = (void *)SL28CPLD_GPI },
>> > > +       { .compatible = "kontron,sl28cpld-gpo",
>> > > +         .data = (void *)SL28CPLD_GPO },
>> >
>> > All above can be twice less LOCs.
>> 
>> They are longer than 80 chars. Or do I miss something?
> 
> We have 100 :-)

oh come on, since 6 days *g*

>> > > +               .name = KBUILD_MODNAME,
>> >
>> > This actually not good idea in long term. File name can change and break
>> > an ABI.
>> 
>> Ahh an explanation, why this is bad. Ok makes sense, although to be 
>> fair,
>> .id_table should be used for the driver name matching. I'm not sure if
>> this is used somewhere else, though.
> 
> I saw in my practice chain of renames for a driver. Now, if somebody
> somewhere would like to instantiate a platform driver by its name...
> Oops, ABI breakage.
> 
> And of course using platform data for such device makes less sense.

i just removed the id_table from all drivers anyways.

-michael

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-05 10:50     ` Mark Brown
@ 2020-06-05 20:07       ` Michael Walle
  2020-06-06 11:46         ` Mark Brown
  0 siblings, 1 reply; 74+ messages in thread
From: Michael Walle @ 2020-06-05 20:07 UTC (permalink / raw)
  To: Mark Brown
  Cc: Lee Jones, linux-gpio, devicetree, linux-kernel, linux-hwmon,
	linux-pwm, linux-watchdog, linux-arm-kernel, Linus Walleij,
	Bartosz Golaszewski, Rob Herring, Jean Delvare, Guenter Roeck,
	Thierry Reding, Uwe Kleine-König, Wim Van Sebroeck,
	Shawn Guo, Li Yang, Thomas Gleixner, Jason Cooper, Marc Zyngier,
	Greg Kroah-Hartman, Andy Shevchenko

Hi,

Am 2020-06-05 12:50, schrieb Mark Brown:
> On Fri, Jun 05, 2020 at 07:57:09AM +0100, Lee Jones wrote:
>> On Thu, 04 Jun 2020, Michael Walle wrote:
> 
>> > +	sl28cpld->regmap = devm_regmap_init_i2c(i2c, &sl28cpld_regmap_config);
>> > +	if (IS_ERR(sl28cpld->regmap))
>> > +		return PTR_ERR(sl28cpld->regmap);
> 
>> This is now a shared memory allocator and not an MFD at all.
> 
>> I'm clamping down on these type of drivers!
> 
>> Please find a better way to accomplish this.
> 
> What is the concern with this?  Looking at the patch I'm guessing the
> concern would be that the driver isn't instantiating any MFD children
> and instead requiring them to be put in the DT?
> 
>> Potentially using "simple-mfd" and "simple-regmap".
> 
>> The former already exists and does what you want.  The latter doesn't
>> yet exist, but could solve your and lots of other contributor's
>> issues.
> 
> I have no idea what you are thinking of when you say "simple-regmap" so
> it is difficult to comment.

I guess, Lee is suggesting to be able to create a regmap instance via
device tree (and populate its child nodes?). Like
   compatible = "syscon", "simple-mfd";
but for any regmap, not just MMIO.

But, there is more in my driver:
  (1) there is a version check
  (2) there is another function for which there is no suitable linux
      subsystem I'm aware of and thus which I'd like to us sysfs
      attributes for: This controller supports 16 non-volatile
      configuration bits. (this is still TBD)

I don't see what is different between this driver and for example the
gateworks-gsc.c. Just that mine doesn't use a global register set, but
local offsets and a base for each component. From a hardware
perspective its one device behind an I2C address providing different
functions across multiple driver subsystems.

Actually, I've tried to remove the devm_of_platform_populate() and
instead added the "simple-mfd" to my mfd node:
  compatible = "kontron,sl28cpld-r1", "simple-mfd";

I guess that doesn't work because the device is below the i2c bus?

-- 
-michael

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 06/11] gpio: add support for the sl28cpld GPIO controller
  2020-06-05 18:44         ` Michael Walle
@ 2020-06-05 21:19           ` Andy Shevchenko
  0 siblings, 0 replies; 74+ messages in thread
From: Andy Shevchenko @ 2020-06-05 21:19 UTC (permalink / raw)
  To: Michael Walle
  Cc: open list:GPIO SUBSYSTEM, devicetree, Linux Kernel Mailing List,
	linux-hwmon, linux-pwm, linux-watchdog, linux-arm Mailing List,
	Linus Walleij, Bartosz Golaszewski, Rob Herring, Jean Delvare,
	Guenter Roeck, Lee Jones, Thierry Reding, Uwe Kleine-König,
	Wim Van Sebroeck, Shawn Guo, Li Yang, Thomas Gleixner,
	Jason Cooper, Marc Zyngier, Mark Brown, Greg Kroah-Hartman

On Fri, Jun 5, 2020 at 9:44 PM Michael Walle <michael@walle.cc> wrote:
> Am 2020-06-05 15:15, schrieb Andy Shevchenko:
> > On Fri, Jun 05, 2020 at 02:42:53PM +0200, Michael Walle wrote:
> >> Am 2020-06-05 14:00, schrieb Andy Shevchenko:
> >> > On Fri, Jun 5, 2020 at 12:14 AM Michael Walle <michael@walle.cc> wrote:

...

> >> > > +       if (irq_support &&
> >> >
> >> > Why do you need this flag? Can't simple IRQ number be sufficient?
> >>
> >> I want to make sure, the is no misconfiguration. Eg. only GPIO
> >> flavors which has irq_support set, have the additional interrupt
> >> registers.
> >
> > In gpio-dwapb, for example, we simple check two things: a) hardware
> > limitation
> > (if IRQ is assigned to a proper port) and b) if there is any IRQ comes
> > from DT,
> > ACPI, etc.
>
> I can't follow you here. irq_support is like your (a); or the
> "pp->idx == 0" in your example.

And you have type already. Why do you need to duplicate it? Moreover,
is it protection from wrong type to have interrupts?

You can move this all stuff under corresponding switch-case.

> >> > > +           device_property_read_bool(&pdev->dev,
> >> > > "interrupt-controller")) {
> >> > > +               irq = platform_get_irq(pdev, 0);
> >> > > +               if (irq < 0)
> >> > > +                       return irq;
> >> > > +
> >> > > +               ret = sl28cpld_gpio_irq_init(&pdev->dev, gpio, regmap,
> >> > > +                                            base, irq);
> >> > > +               if (ret)
> >> > > +                       return ret;
> >> > > +
> >> > > +               config.irq_domain =
> >> > > regmap_irq_get_domain(gpio->irq_data);


-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-05 20:07       ` Michael Walle
@ 2020-06-06 11:46         ` Mark Brown
  2020-06-06 12:45           ` Michael Walle
  0 siblings, 1 reply; 74+ messages in thread
From: Mark Brown @ 2020-06-06 11:46 UTC (permalink / raw)
  To: Michael Walle
  Cc: Lee Jones, linux-gpio, devicetree, linux-kernel, linux-hwmon,
	linux-pwm, linux-watchdog, linux-arm-kernel, Linus Walleij,
	Bartosz Golaszewski, Rob Herring, Jean Delvare, Guenter Roeck,
	Thierry Reding, Uwe Kleine-König, Wim Van Sebroeck,
	Shawn Guo, Li Yang, Thomas Gleixner, Jason Cooper, Marc Zyngier,
	Greg Kroah-Hartman, Andy Shevchenko

[-- Attachment #1: Type: text/plain, Size: 989 bytes --]

On Fri, Jun 05, 2020 at 10:07:36PM +0200, Michael Walle wrote:
> Am 2020-06-05 12:50, schrieb Mark Brown:

> > I have no idea what you are thinking of when you say "simple-regmap" so
> > it is difficult to comment.

> I guess, Lee is suggesting to be able to create a regmap instance via
> device tree (and populate its child nodes?). Like
>   compatible = "syscon", "simple-mfd";
> but for any regmap, not just MMIO.

I don't understand why this would be anything separate to
simple-mfd.

> But, there is more in my driver:
>  (1) there is a version check
>  (2) there is another function for which there is no suitable linux
>      subsystem I'm aware of and thus which I'd like to us sysfs
>      attributes for: This controller supports 16 non-volatile
>      configuration bits. (this is still TBD)

TBH I'd also say that the enumeration of the subdevices for this
device should be in the device rather than the DT, they don't
seem to be things that exist outside of this one device.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-06 11:46         ` Mark Brown
@ 2020-06-06 12:45           ` Michael Walle
  2020-06-08  8:28             ` Lee Jones
  0 siblings, 1 reply; 74+ messages in thread
From: Michael Walle @ 2020-06-06 12:45 UTC (permalink / raw)
  To: Mark Brown
  Cc: Lee Jones, linux-gpio, devicetree, linux-kernel, linux-hwmon,
	linux-pwm, linux-watchdog, linux-arm-kernel, Linus Walleij,
	Bartosz Golaszewski, Rob Herring, Jean Delvare, Guenter Roeck,
	Thierry Reding, Uwe Kleine-König, Wim Van Sebroeck,
	Shawn Guo, Li Yang, Thomas Gleixner, Jason Cooper, Marc Zyngier,
	Greg Kroah-Hartman, Andy Shevchenko

Am 2020-06-06 13:46, schrieb Mark Brown:
> On Fri, Jun 05, 2020 at 10:07:36PM +0200, Michael Walle wrote:
>> Am 2020-06-05 12:50, schrieb Mark Brown:
> 
>> > I have no idea what you are thinking of when you say "simple-regmap" so
>> > it is difficult to comment.
> 
>> I guess, Lee is suggesting to be able to create a regmap instance via
>> device tree (and populate its child nodes?). Like
>>   compatible = "syscon", "simple-mfd";
>> but for any regmap, not just MMIO.
> 
> I don't understand why this would be anything separate to
> simple-mfd.

Don't just simple-mfd tells the of core, to probe the children this
node? Where does the regmap then come from?

> 
>> But, there is more in my driver:
>>  (1) there is a version check
>>  (2) there is another function for which there is no suitable linux
>>      subsystem I'm aware of and thus which I'd like to us sysfs
>>      attributes for: This controller supports 16 non-volatile
>>      configuration bits. (this is still TBD)
> 
> TBH I'd also say that the enumeration of the subdevices for this
> device should be in the device rather than the DT, they don't
> seem to be things that exist outside of this one device.

We're going circles here, formerly they were enumerated in the MFD.
Yes, they are devices which aren't likely be used outside a
"sl28cpld", but there might there might be other versions of the
sl28cpld with other components on different base addresses. I
don't care if they are enumerated in DT or MFD, actually, I'd
prefer the latter. _But_ I would like to have the device tree
properties for its subdevices, e.g. the ones for the watchdog or
whatever components there might be in the future. MFD core can
match a device tree node today; but only one per unique compatible
string. So what should I use to differentiate the different
subdevices? Rob suggested the internal offset, which I did here.
But then, there is less use in duplicating the offsets in the MFD
just to have the MFD enumerate the subdevices and then match
the device tree nodes against it. I can just use
of_platform_populate() to enumerate the children and I won't
have to duplicate the base addresses.

So here we are, any ideas appreciated.

-michael

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 05/11] pwm: add support for sl28cpld PWM controller
  2020-06-05 18:17     ` Michael Walle
@ 2020-06-08  7:46       ` Lee Jones
  0 siblings, 0 replies; 74+ messages in thread
From: Lee Jones @ 2020-06-08  7:46 UTC (permalink / raw)
  To: Michael Walle
  Cc: linux-gpio, devicetree, linux-kernel, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm-kernel, Linus Walleij,
	Bartosz Golaszewski, Rob Herring, Jean Delvare, Guenter Roeck,
	Thierry Reding, Uwe Kleine-König, Wim Van Sebroeck,
	Shawn Guo, Li Yang, Thomas Gleixner, Jason Cooper, Marc Zyngier,
	Mark Brown, Greg Kroah-Hartman, Andy Shevchenko

On Fri, 05 Jun 2020, Michael Walle wrote:

> Am 2020-06-05 10:49, schrieb Lee Jones:
> [..]
> > > +static inline struct sl28cpld_pwm *to_sl28cpld_pwm(struct pwm_chip
> > > *chip)
> > > +{
> > > +	return container_of(chip, struct sl28cpld_pwm, pwm_chip);
> > > +}
> > 
> > Why not save yourself the trouble and just:
> > 
> >   struct sl28cpld_pwm *pwm = dev_get_drvdata(chip->dev);
> 
> Is there a reason why not a single pwm driver uses something like that?

Copy/paste?  Habit?

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-06 12:45           ` Michael Walle
@ 2020-06-08  8:28             ` Lee Jones
  2020-06-08 10:02               ` Andy Shevchenko
  2020-06-09 16:54               ` Rob Herring
  0 siblings, 2 replies; 74+ messages in thread
From: Lee Jones @ 2020-06-08  8:28 UTC (permalink / raw)
  To: Michael Walle, Rob Herring
  Cc: Mark Brown, linux-gpio, devicetree, linux-kernel, linux-hwmon,
	linux-pwm, linux-watchdog, linux-arm-kernel, Linus Walleij,
	Bartosz Golaszewski, Rob Herring, Jean Delvare, Guenter Roeck,
	Thierry Reding, Uwe Kleine-König, Wim Van Sebroeck,
	Shawn Guo, Li Yang, Thomas Gleixner, Jason Cooper, Marc Zyngier,
	Greg Kroah-Hartman, Andy Shevchenko

Rob, something for you below.

On Sat, 06 Jun 2020, Michael Walle wrote:
> Am 2020-06-06 13:46, schrieb Mark Brown:
> > On Fri, Jun 05, 2020 at 10:07:36PM +0200, Michael Walle wrote:
> > > Am 2020-06-05 12:50, schrieb Mark Brown:
> > 
> > > > I have no idea what you are thinking of when you say "simple-regmap" so
> > > > it is difficult to comment.
> > 
> > > I guess, Lee is suggesting to be able to create a regmap instance via
> > > device tree (and populate its child nodes?). Like
> > >   compatible = "syscon", "simple-mfd";
> > > but for any regmap, not just MMIO.

Bingo!

> > I don't understand why this would be anything separate to
> > simple-mfd.
> 
> Don't just simple-mfd tells the of core, to probe the children this
> node? Where does the regmap then come from?

Right.  I'm suggesting a means to extrapolate complex shared and
sometimes intertwined batches of register sets to be consumed by
multiple (sub-)devices spanning different subsystems.

Actually scrap that.  The most common case I see is a single Regmap
covering all child-devices.  It would be great if there was a way in
which we could make an assumption that the entire register address
space for a 'tagged' (MFD) device is to be shared (via Regmap) between
each of the devices described by its child-nodes.  Probably by picking
up on the 'simple-mfd' compatible string in the first instance.

Rob, is the above something you would contemplate?

Michael, do your register addresses overlap i.e. are they intermingled
with one another?  Do multiple child devices need access to the same
registers i.e. are they shared?

> > > But, there is more in my driver:
> > >  (1) there is a version check

If we can rid the Regmap dependency, then creating an entire driver to
conduct a version check is unjustifiable.  This could become an inline
function which is called by each of the sub-devices instead, for
example.

> > >  (2) there is another function for which there is no suitable linux
> > >      subsystem I'm aware of and thus which I'd like to us sysfs
> > >      attributes for: This controller supports 16 non-volatile
> > >      configuration bits. (this is still TBD)

There is a place for everything in Linux.

What do these bits configure?

> > TBH I'd also say that the enumeration of the subdevices for this
> > device should be in the device rather than the DT, they don't
> > seem to be things that exist outside of this one device.
> 
> We're going circles here, formerly they were enumerated in the MFD.
> Yes, they are devices which aren't likely be used outside a
> "sl28cpld", but there might there might be other versions of the
> sl28cpld with other components on different base addresses. I
> don't care if they are enumerated in DT or MFD, actually, I'd
> prefer the latter. _But_ I would like to have the device tree
> properties for its subdevices, e.g. the ones for the watchdog or
> whatever components there might be in the future.

[...]

> MFD core can
> match a device tree node today; but only one per unique compatible
> string. So what should I use to differentiate the different
> subdevices?

Right.  I have been aware of this issue.  The only suitable solution
to this would be to match on 'reg'.

FYI: I plan to fix this.

If your register map needs to change, then I suggest that this is
either a new device or at least a different version of the device and
would also have to be represented as different (sub-)mfd_cell.

> Rob suggested the internal offset, which I did here.

FWIW, I don't like this idea.  DTs should not have to be modified
(either in the first instance or subsequently) or specifically
designed to patch inadequacies in any given OS.

> But then, there is less use in duplicating the offsets in the MFD
> just to have the MFD enumerate the subdevices and then match
> the device tree nodes against it. I can just use
> of_platform_populate() to enumerate the children and I won't
> have to duplicate the base addresses.

Which is fine.  However this causes a different issue for you.  By
stripping out the MFD code you render the MFD portion seemingly
superfluous.  Another issue driver authors commonly contend with.

> So here we are, any ideas appreciated.

Working on it!

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-08  8:28             ` Lee Jones
@ 2020-06-08 10:02               ` Andy Shevchenko
  2020-06-08 15:41                 ` Michael Walle
  2020-06-08 18:20                 ` Lee Jones
  2020-06-09 16:54               ` Rob Herring
  1 sibling, 2 replies; 74+ messages in thread
From: Andy Shevchenko @ 2020-06-08 10:02 UTC (permalink / raw)
  To: Lee Jones, Ranjani Sridharan, david.m.ertman, shiraz.saleem
  Cc: Michael Walle, Rob Herring, Mark Brown, open list:GPIO SUBSYSTEM,
	devicetree, Linux Kernel Mailing List, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm Mailing List, Linus Walleij,
	Bartosz Golaszewski, Jean Delvare, Guenter Roeck, Thierry Reding,
	Uwe Kleine-König, Wim Van Sebroeck, Shawn Guo, Li Yang,
	Thomas Gleixner, Jason Cooper, Marc Zyngier, Greg Kroah-Hartman,
	Andy Shevchenko

+Cc: some Intel people WRT our internal discussion about similar
problem and solutions.

On Mon, Jun 8, 2020 at 11:30 AM Lee Jones <lee.jones@linaro.org> wrote:
> On Sat, 06 Jun 2020, Michael Walle wrote:
> > Am 2020-06-06 13:46, schrieb Mark Brown:
> > > On Fri, Jun 05, 2020 at 10:07:36PM +0200, Michael Walle wrote:
> > > > Am 2020-06-05 12:50, schrieb Mark Brown:

...

> Right.  I'm suggesting a means to extrapolate complex shared and
> sometimes intertwined batches of register sets to be consumed by
> multiple (sub-)devices spanning different subsystems.
>
> Actually scrap that.  The most common case I see is a single Regmap
> covering all child-devices.

Yes, because often we need a synchronization across the entire address
space of the (parent) device in question.

>  It would be great if there was a way in
> which we could make an assumption that the entire register address
> space for a 'tagged' (MFD) device is to be shared (via Regmap) between
> each of the devices described by its child-nodes.  Probably by picking
> up on the 'simple-mfd' compatible string in the first instance.
>
> Rob, is the above something you would contemplate?
>
> Michael, do your register addresses overlap i.e. are they intermingled
> with one another?  Do multiple child devices need access to the same
> registers i.e. are they shared?
>
> > > > But, there is more in my driver:
> > > >  (1) there is a version check
>
> If we can rid the Regmap dependency, then creating an entire driver to
> conduct a version check is unjustifiable.  This could become an inline
> function which is called by each of the sub-devices instead, for
> example.
>
> > > >  (2) there is another function for which there is no suitable linux
> > > >      subsystem I'm aware of and thus which I'd like to us sysfs
> > > >      attributes for: This controller supports 16 non-volatile
> > > >      configuration bits. (this is still TBD)
>
> There is a place for everything in Linux.
>
> What do these bits configure?
>
> > > TBH I'd also say that the enumeration of the subdevices for this
> > > device should be in the device rather than the DT, they don't
> > > seem to be things that exist outside of this one device.
> >
> > We're going circles here, formerly they were enumerated in the MFD.
> > Yes, they are devices which aren't likely be used outside a
> > "sl28cpld", but there might there might be other versions of the
> > sl28cpld with other components on different base addresses. I
> > don't care if they are enumerated in DT or MFD, actually, I'd
> > prefer the latter. _But_ I would like to have the device tree
> > properties for its subdevices, e.g. the ones for the watchdog or
> > whatever components there might be in the future.
>
> [...]
>
> > MFD core can
> > match a device tree node today; but only one per unique compatible
> > string. So what should I use to differentiate the different
> > subdevices?
>
> Right.  I have been aware of this issue.  The only suitable solution
> to this would be to match on 'reg'.
>
> FYI: I plan to fix this.
>
> If your register map needs to change, then I suggest that this is
> either a new device or at least a different version of the device and
> would also have to be represented as different (sub-)mfd_cell.
>
> > Rob suggested the internal offset, which I did here.
>
> FWIW, I don't like this idea.  DTs should not have to be modified
> (either in the first instance or subsequently) or specifically
> designed to patch inadequacies in any given OS.
>
> > But then, there is less use in duplicating the offsets in the MFD
> > just to have the MFD enumerate the subdevices and then match
> > the device tree nodes against it. I can just use
> > of_platform_populate() to enumerate the children and I won't
> > have to duplicate the base addresses.
>
> Which is fine.  However this causes a different issue for you.  By
> stripping out the MFD code you render the MFD portion seemingly
> superfluous.  Another issue driver authors commonly contend with.

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 03/11] irqchip: add sl28cpld interrupt controller support
  2020-06-04 21:10 ` [PATCH v4 03/11] irqchip: add sl28cpld interrupt controller support Michael Walle
  2020-06-05  1:26   ` kernel test robot
  2020-06-05  8:07   ` Andy Shevchenko
@ 2020-06-08 15:12   ` kernel test robot
  2 siblings, 0 replies; 74+ messages in thread
From: kernel test robot @ 2020-06-08 15:12 UTC (permalink / raw)
  To: Michael Walle, linux-gpio, devicetree, linux-kernel, linux-hwmon,
	linux-pwm, linux-watchdog, linux-arm-kernel
  Cc: kbuild-all, Linus Walleij, Bartosz Golaszewski, Rob Herring

Hi Michael,

I love your patch! Perhaps something to improve:

[auto build test WARNING on next-20200604]
[cannot apply to gpio/for-next hwmon/hwmon-next ljones-mfd/for-mfd-next shawnguo/for-next v5.7 v5.7-rc7 v5.7-rc6 v5.7]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:    https://github.com/0day-ci/linux/commits/Michael-Walle/Add-support-for-Kontron-sl28cpld/20200605-051333
base:    d4899e5542c15062cc55cac0ca99025bb64edc61
:::::: branch date: 26 hours ago
:::::: commit date: 26 hours ago
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>


cppcheck warnings: (new ones prefixed by >>)

>> drivers/irqchip/irq-sl28cpld.c:56:10: warning: Checking if unsigned variable 'irq' is less than zero. [unsignedLessThanZero]
    if (irq < 0)
            ^

# https://github.com/0day-ci/linux/commit/b13743c1f1a52746beaa071e5d008c84d59fbd7f
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout b13743c1f1a52746beaa071e5d008c84d59fbd7f
vim +/irq +56 drivers/irqchip/irq-sl28cpld.c

b13743c1f1a527 Michael Walle 2020-06-04  35  
b13743c1f1a527 Michael Walle 2020-06-04  36  static int sl28cpld_intc_probe(struct platform_device *pdev)
b13743c1f1a527 Michael Walle 2020-06-04  37  {
b13743c1f1a527 Michael Walle 2020-06-04  38  	struct device *dev = &pdev->dev;
b13743c1f1a527 Michael Walle 2020-06-04  39  	struct sl28cpld_intc *irqchip;
b13743c1f1a527 Michael Walle 2020-06-04  40  	unsigned int irq;
b13743c1f1a527 Michael Walle 2020-06-04  41  	u32 base;
b13743c1f1a527 Michael Walle 2020-06-04  42  	int ret;
b13743c1f1a527 Michael Walle 2020-06-04  43  
b13743c1f1a527 Michael Walle 2020-06-04  44  	if (!dev->parent)
b13743c1f1a527 Michael Walle 2020-06-04  45  		return -ENODEV;
b13743c1f1a527 Michael Walle 2020-06-04  46  
b13743c1f1a527 Michael Walle 2020-06-04  47  	irqchip = devm_kzalloc(dev, sizeof(*irqchip), GFP_KERNEL);
b13743c1f1a527 Michael Walle 2020-06-04  48  	if (!irqchip)
b13743c1f1a527 Michael Walle 2020-06-04  49  		return -ENOMEM;
b13743c1f1a527 Michael Walle 2020-06-04  50  
b13743c1f1a527 Michael Walle 2020-06-04  51  	irqchip->regmap = dev_get_regmap(dev->parent, NULL);
b13743c1f1a527 Michael Walle 2020-06-04  52  	if (!irqchip->regmap)
b13743c1f1a527 Michael Walle 2020-06-04  53  		return -ENODEV;
b13743c1f1a527 Michael Walle 2020-06-04  54  
b13743c1f1a527 Michael Walle 2020-06-04  55  	irq = platform_get_irq(pdev, 0);
b13743c1f1a527 Michael Walle 2020-06-04 @56  	if (irq < 0)
b13743c1f1a527 Michael Walle 2020-06-04  57  		return irq;
b13743c1f1a527 Michael Walle 2020-06-04  58  
b13743c1f1a527 Michael Walle 2020-06-04  59  	ret = device_property_read_u32(&pdev->dev, "reg", &base);
b13743c1f1a527 Michael Walle 2020-06-04  60  	if (ret)
b13743c1f1a527 Michael Walle 2020-06-04  61  		return -EINVAL;
b13743c1f1a527 Michael Walle 2020-06-04  62  
b13743c1f1a527 Michael Walle 2020-06-04  63  	irqchip->chip.name = "sl28cpld-intc";
b13743c1f1a527 Michael Walle 2020-06-04  64  	irqchip->chip.irqs = sl28cpld_irqs;
b13743c1f1a527 Michael Walle 2020-06-04  65  	irqchip->chip.num_irqs = ARRAY_SIZE(sl28cpld_irqs);
b13743c1f1a527 Michael Walle 2020-06-04  66  	irqchip->chip.num_regs = 1;
b13743c1f1a527 Michael Walle 2020-06-04  67  	irqchip->chip.status_base = base + INTC_IP;
b13743c1f1a527 Michael Walle 2020-06-04  68  	irqchip->chip.mask_base = base + INTC_IE;
b13743c1f1a527 Michael Walle 2020-06-04  69  	irqchip->chip.mask_invert = true,
b13743c1f1a527 Michael Walle 2020-06-04  70  	irqchip->chip.ack_base = base + INTC_IP;
b13743c1f1a527 Michael Walle 2020-06-04  71  
b13743c1f1a527 Michael Walle 2020-06-04  72  	return devm_regmap_add_irq_chip_np(&pdev->dev, dev->of_node,
b13743c1f1a527 Michael Walle 2020-06-04  73  					   irqchip->regmap, irq,
b13743c1f1a527 Michael Walle 2020-06-04  74  					   IRQF_SHARED | IRQF_ONESHOT, 0,
b13743c1f1a527 Michael Walle 2020-06-04  75  					   &irqchip->chip, &irqchip->irq_data);
b13743c1f1a527 Michael Walle 2020-06-04  76  }
b13743c1f1a527 Michael Walle 2020-06-04  77  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org


^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-08 10:02               ` Andy Shevchenko
@ 2020-06-08 15:41                 ` Michael Walle
  2020-06-08 18:56                   ` Lee Jones
  2020-06-08 18:20                 ` Lee Jones
  1 sibling, 1 reply; 74+ messages in thread
From: Michael Walle @ 2020-06-08 15:41 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Lee Jones, Ranjani Sridharan, david.m.ertman, shiraz.saleem,
	Rob Herring, Mark Brown, open list:GPIO SUBSYSTEM, devicetree,
	Linux Kernel Mailing List, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm Mailing List, Linus Walleij,
	Bartosz Golaszewski, Jean Delvare, Guenter Roeck, Thierry Reding,
	Uwe Kleine-König, Wim Van Sebroeck, Shawn Guo, Li Yang,
	Thomas Gleixner, Jason Cooper, Marc Zyngier, Greg Kroah-Hartman,
	Andy Shevchenko

Am 2020-06-08 12:02, schrieb Andy Shevchenko:
> +Cc: some Intel people WRT our internal discussion about similar
> problem and solutions.
> 
> On Mon, Jun 8, 2020 at 11:30 AM Lee Jones <lee.jones@linaro.org> wrote:
>> On Sat, 06 Jun 2020, Michael Walle wrote:
>> > Am 2020-06-06 13:46, schrieb Mark Brown:
>> > > On Fri, Jun 05, 2020 at 10:07:36PM +0200, Michael Walle wrote:
>> > > > Am 2020-06-05 12:50, schrieb Mark Brown:
> 
> ...
> 
>> Right.  I'm suggesting a means to extrapolate complex shared and
>> sometimes intertwined batches of register sets to be consumed by
>> multiple (sub-)devices spanning different subsystems.
>> 
>> Actually scrap that.  The most common case I see is a single Regmap
>> covering all child-devices.
> 
> Yes, because often we need a synchronization across the entire address
> space of the (parent) device in question.
> 
>>  It would be great if there was a way in
>> which we could make an assumption that the entire register address
>> space for a 'tagged' (MFD) device is to be shared (via Regmap) between
>> each of the devices described by its child-nodes.  Probably by picking
>> up on the 'simple-mfd' compatible string in the first instance.
>> 
>> Rob, is the above something you would contemplate?
>> 
>> Michael, do your register addresses overlap i.e. are they intermingled
>> with one another?  Do multiple child devices need access to the same
>> registers i.e. are they shared?

No they don't overlap, expect for maybe the version register, which is
just there once and not per function block.

>> 
>> > > > But, there is more in my driver:
>> > > >  (1) there is a version check
>> 
>> If we can rid the Regmap dependency, then creating an entire driver to
>> conduct a version check is unjustifiable.  This could become an inline
>> function which is called by each of the sub-devices instead, for
>> example.

sounds good to me. (although there would then be a probe fail per 
sub-device
if the version is not supported)

>> > > >  (2) there is another function for which there is no suitable linux
>> > > >      subsystem I'm aware of and thus which I'd like to us sysfs
>> > > >      attributes for: This controller supports 16 non-volatile
>> > > >      configuration bits. (this is still TBD)
>> 
>> There is a place for everything in Linux.
>> 
>> What do these bits configure?

- hardware strappings which have to be there before the board powers up,
   like clocking mode for different SerDes settings
- "keep-in-reset" bits for onboard peripherals if you want to save power
- disable watchdog bits (there is a watchdog which is active right from
   the start and supervises the bootloader start and switches to failsafe
   mode if it wasn't successfully started)
- special boot modes, like eMMC, etc.

Think of it as a 16bit configuration word.

>> > > TBH I'd also say that the enumeration of the subdevices for this
>> > > device should be in the device rather than the DT, they don't
>> > > seem to be things that exist outside of this one device.
>> >
>> > We're going circles here, formerly they were enumerated in the MFD.
>> > Yes, they are devices which aren't likely be used outside a
>> > "sl28cpld", but there might there might be other versions of the
>> > sl28cpld with other components on different base addresses. I
>> > don't care if they are enumerated in DT or MFD, actually, I'd
>> > prefer the latter. _But_ I would like to have the device tree
>> > properties for its subdevices, e.g. the ones for the watchdog or
>> > whatever components there might be in the future.
>> 
>> [...]
>> 
>> > MFD core can
>> > match a device tree node today; but only one per unique compatible
>> > string. So what should I use to differentiate the different
>> > subdevices?
>> 
>> Right.  I have been aware of this issue.  The only suitable solution
>> to this would be to match on 'reg'.

see below (1)

>> 
>> FYI: I plan to fix this.
>> 
>> If your register map needs to change, then I suggest that this is
>> either a new device or at least a different version of the device and
>> would also have to be represented as different (sub-)mfd_cell.
>> 
>> > Rob suggested the internal offset, which I did here.
>> 
>> FWIW, I don't like this idea.  DTs should not have to be modified
>> (either in the first instance or subsequently) or specifically
>> designed to patch inadequacies in any given OS.

How does (1) play together with this? What do you propose the "reg"
property should contain?

>> 
>> > But then, there is less use in duplicating the offsets in the MFD
>> > just to have the MFD enumerate the subdevices and then match
>> > the device tree nodes against it. I can just use
>> > of_platform_populate() to enumerate the children and I won't
>> > have to duplicate the base addresses.
>> 
>> Which is fine.  However this causes a different issue for you.  By
>> stripping out the MFD code you render the MFD portion seemingly
>> superfluous.  Another issue driver authors commonly contend with.

Yeah, I agree.

-michael

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-08 10:02               ` Andy Shevchenko
  2020-06-08 15:41                 ` Michael Walle
@ 2020-06-08 18:20                 ` Lee Jones
  1 sibling, 0 replies; 74+ messages in thread
From: Lee Jones @ 2020-06-08 18:20 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Ranjani Sridharan, david.m.ertman, shiraz.saleem, Michael Walle,
	Rob Herring, Mark Brown, open list:GPIO SUBSYSTEM, devicetree,
	Linux Kernel Mailing List, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm Mailing List, Linus Walleij,
	Bartosz Golaszewski, Jean Delvare, Guenter Roeck, Thierry Reding,
	Uwe Kleine-König, Wim Van Sebroeck, Shawn Guo, Li Yang,
	Thomas Gleixner, Jason Cooper, Marc Zyngier, Greg Kroah-Hartman,
	Andy Shevchenko

On Mon, 08 Jun 2020, Andy Shevchenko wrote:

> +Cc: some Intel people WRT our internal discussion about similar
> problem and solutions.
> 
> On Mon, Jun 8, 2020 at 11:30 AM Lee Jones <lee.jones@linaro.org> wrote:
> > On Sat, 06 Jun 2020, Michael Walle wrote:
> > > Am 2020-06-06 13:46, schrieb Mark Brown:
> > > > On Fri, Jun 05, 2020 at 10:07:36PM +0200, Michael Walle wrote:
> > > > > Am 2020-06-05 12:50, schrieb Mark Brown:
> 
> ...
> 
> > Right.  I'm suggesting a means to extrapolate complex shared and
> > sometimes intertwined batches of register sets to be consumed by
> > multiple (sub-)devices spanning different subsystems.
> >
> > Actually scrap that.  The most common case I see is a single Regmap
> > covering all child-devices.
> 
> Yes, because often we need a synchronization across the entire address
> space of the (parent) device in question.

Exactly.

Because of the reasons in the paragraph above:

 "complex shared and sometimes intertwined batches of register sets to
  be consumed by multiple (sub-)devices spanning different subsystems"

> >  It would be great if there was a way in
> > which we could make an assumption that the entire register address
> > space for a 'tagged' (MFD) device is to be shared (via Regmap) between
> > each of the devices described by its child-nodes.  Probably by picking
> > up on the 'simple-mfd' compatible string in the first instance.
> >
> > Rob, is the above something you would contemplate?
> >
> > Michael, do your register addresses overlap i.e. are they intermingled
> > with one another?  Do multiple child devices need access to the same
> > registers i.e. are they shared?
> >
> > > > > But, there is more in my driver:
> > > > >  (1) there is a version check
> >
> > If we can rid the Regmap dependency, then creating an entire driver to
> > conduct a version check is unjustifiable.  This could become an inline
> > function which is called by each of the sub-devices instead, for
> > example.
> >
> > > > >  (2) there is another function for which there is no suitable linux
> > > > >      subsystem I'm aware of and thus which I'd like to us sysfs
> > > > >      attributes for: This controller supports 16 non-volatile
> > > > >      configuration bits. (this is still TBD)
> >
> > There is a place for everything in Linux.
> >
> > What do these bits configure?
> >
> > > > TBH I'd also say that the enumeration of the subdevices for this
> > > > device should be in the device rather than the DT, they don't
> > > > seem to be things that exist outside of this one device.
> > >
> > > We're going circles here, formerly they were enumerated in the MFD.
> > > Yes, they are devices which aren't likely be used outside a
> > > "sl28cpld", but there might there might be other versions of the
> > > sl28cpld with other components on different base addresses. I
> > > don't care if they are enumerated in DT or MFD, actually, I'd
> > > prefer the latter. _But_ I would like to have the device tree
> > > properties for its subdevices, e.g. the ones for the watchdog or
> > > whatever components there might be in the future.
> >
> > [...]
> >
> > > MFD core can
> > > match a device tree node today; but only one per unique compatible
> > > string. So what should I use to differentiate the different
> > > subdevices?
> >
> > Right.  I have been aware of this issue.  The only suitable solution
> > to this would be to match on 'reg'.
> >
> > FYI: I plan to fix this.
> >
> > If your register map needs to change, then I suggest that this is
> > either a new device or at least a different version of the device and
> > would also have to be represented as different (sub-)mfd_cell.
> >
> > > Rob suggested the internal offset, which I did here.
> >
> > FWIW, I don't like this idea.  DTs should not have to be modified
> > (either in the first instance or subsequently) or specifically
> > designed to patch inadequacies in any given OS.
> >
> > > But then, there is less use in duplicating the offsets in the MFD
> > > just to have the MFD enumerate the subdevices and then match
> > > the device tree nodes against it. I can just use
> > > of_platform_populate() to enumerate the children and I won't
> > > have to duplicate the base addresses.
> >
> > Which is fine.  However this causes a different issue for you.  By
> > stripping out the MFD code you render the MFD portion seemingly
> > superfluous.  Another issue driver authors commonly contend with.
> 

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-08 15:41                 ` Michael Walle
@ 2020-06-08 18:56                   ` Lee Jones
  2020-06-08 21:09                     ` Michael Walle
  0 siblings, 1 reply; 74+ messages in thread
From: Lee Jones @ 2020-06-08 18:56 UTC (permalink / raw)
  To: Michael Walle
  Cc: Andy Shevchenko, Ranjani Sridharan, david.m.ertman,
	shiraz.saleem, Rob Herring, Mark Brown, open list:GPIO SUBSYSTEM,
	devicetree, Linux Kernel Mailing List, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm Mailing List, Linus Walleij,
	Bartosz Golaszewski, Jean Delvare, Guenter Roeck, Thierry Reding,
	Uwe Kleine-König, Wim Van Sebroeck, Shawn Guo, Li Yang,
	Thomas Gleixner, Jason Cooper, Marc Zyngier, Greg Kroah-Hartman,
	Andy Shevchenko

On Mon, 08 Jun 2020, Michael Walle wrote:

> Am 2020-06-08 12:02, schrieb Andy Shevchenko:
> > +Cc: some Intel people WRT our internal discussion about similar
> > problem and solutions.
> > 
> > On Mon, Jun 8, 2020 at 11:30 AM Lee Jones <lee.jones@linaro.org> wrote:
> > > On Sat, 06 Jun 2020, Michael Walle wrote:
> > > > Am 2020-06-06 13:46, schrieb Mark Brown:
> > > > > On Fri, Jun 05, 2020 at 10:07:36PM +0200, Michael Walle wrote:
> > > > > > Am 2020-06-05 12:50, schrieb Mark Brown:
> > 
> > ...
> > 
> > > Right.  I'm suggesting a means to extrapolate complex shared and
> > > sometimes intertwined batches of register sets to be consumed by
> > > multiple (sub-)devices spanning different subsystems.
> > > 
> > > Actually scrap that.  The most common case I see is a single Regmap
> > > covering all child-devices.
> > 
> > Yes, because often we need a synchronization across the entire address
> > space of the (parent) device in question.
> > 
> > >  It would be great if there was a way in
> > > which we could make an assumption that the entire register address
> > > space for a 'tagged' (MFD) device is to be shared (via Regmap) between
> > > each of the devices described by its child-nodes.  Probably by picking
> > > up on the 'simple-mfd' compatible string in the first instance.
> > > 
> > > Rob, is the above something you would contemplate?
> > > 
> > > Michael, do your register addresses overlap i.e. are they intermingled
> > > with one another?  Do multiple child devices need access to the same
> > > registers i.e. are they shared?
> 
> No they don't overlap, expect for maybe the version register, which is
> just there once and not per function block.

Then what's stopping you having each device Regmap their own space?

The issues I wish to resolve using 'simple-mfd' are when sub-devices
register maps overlap and intertwine.

> > > > > > But, there is more in my driver:
> > > > > >  (1) there is a version check
> > > 
> > > If we can rid the Regmap dependency, then creating an entire driver to
> > > conduct a version check is unjustifiable.  This could become an inline
> > > function which is called by each of the sub-devices instead, for
> > > example.
> 
> sounds good to me. (although there would then be a probe fail per sub-device
> if the version is not supported)

I don't see an issue with that.  I would put that check inside a
shared call though, complete with support for locking.

> > > > > >  (2) there is another function for which there is no suitable linux
> > > > > >      subsystem I'm aware of and thus which I'd like to us sysfs
> > > > > >      attributes for: This controller supports 16 non-volatile
> > > > > >      configuration bits. (this is still TBD)
> > > 
> > > There is a place for everything in Linux.
> > > 
> > > What do these bits configure?
> 
> - hardware strappings which have to be there before the board powers up,
>   like clocking mode for different SerDes settings
> - "keep-in-reset" bits for onboard peripherals if you want to save power
> - disable watchdog bits (there is a watchdog which is active right from
>   the start and supervises the bootloader start and switches to failsafe
>   mode if it wasn't successfully started)
> - special boot modes, like eMMC, etc.
> 
> Think of it as a 16bit configuration word.

And you wish for users to be able to view these at run-time?

Can they adapt any of them on-the-fly or will the be RO?

> > > > > TBH I'd also say that the enumeration of the subdevices for this
> > > > > device should be in the device rather than the DT, they don't
> > > > > seem to be things that exist outside of this one device.
> > > >
> > > > We're going circles here, formerly they were enumerated in the MFD.
> > > > Yes, they are devices which aren't likely be used outside a
> > > > "sl28cpld", but there might there might be other versions of the
> > > > sl28cpld with other components on different base addresses. I
> > > > don't care if they are enumerated in DT or MFD, actually, I'd
> > > > prefer the latter. _But_ I would like to have the device tree
> > > > properties for its subdevices, e.g. the ones for the watchdog or
> > > > whatever components there might be in the future.
> > > 
> > > [...]
> > > 
> > > > MFD core can
> > > > match a device tree node today; but only one per unique compatible
> > > > string. So what should I use to differentiate the different
> > > > subdevices?
> > > 
> > > Right.  I have been aware of this issue.  The only suitable solution
> > > to this would be to match on 'reg'.
> 
> see below (1)
> 
> > > 
> > > FYI: I plan to fix this.
> > > 
> > > If your register map needs to change, then I suggest that this is
> > > either a new device or at least a different version of the device and
> > > would also have to be represented as different (sub-)mfd_cell.
> > > 
> > > > Rob suggested the internal offset, which I did here.
> > > 
> > > FWIW, I don't like this idea.  DTs should not have to be modified
> > > (either in the first instance or subsequently) or specifically
> > > designed to patch inadequacies in any given OS.
> 
> How does (1) play together with this? What do you propose the "reg"
> property should contain?

Whatever is in the 'reg' property contained in the Device Tree node.
Either the full address or an offset would be suitable.

Caveat: All this thinking has been done on-the-fly.  I would need to
look at some examples of existing devices and start coding before I
could really think the solution through.

Happy to discuss and/or take recommendations though.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-08 18:56                   ` Lee Jones
@ 2020-06-08 21:09                     ` Michael Walle
  2020-06-09  6:47                       ` Lee Jones
  0 siblings, 1 reply; 74+ messages in thread
From: Michael Walle @ 2020-06-08 21:09 UTC (permalink / raw)
  To: Lee Jones
  Cc: Andy Shevchenko, Ranjani Sridharan, david.m.ertman,
	shiraz.saleem, Rob Herring, Mark Brown, open list:GPIO SUBSYSTEM,
	devicetree, Linux Kernel Mailing List, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm Mailing List, Linus Walleij,
	Bartosz Golaszewski, Jean Delvare, Guenter Roeck, Thierry Reding,
	Uwe Kleine-König, Wim Van Sebroeck, Shawn Guo, Li Yang,
	Thomas Gleixner, Jason Cooper, Marc Zyngier, Greg Kroah-Hartman,
	Andy Shevchenko

Am 2020-06-08 20:56, schrieb Lee Jones:
> On Mon, 08 Jun 2020, Michael Walle wrote:
> 
>> Am 2020-06-08 12:02, schrieb Andy Shevchenko:
>> > +Cc: some Intel people WRT our internal discussion about similar
>> > problem and solutions.
>> >
>> > On Mon, Jun 8, 2020 at 11:30 AM Lee Jones <lee.jones@linaro.org> wrote:
>> > > On Sat, 06 Jun 2020, Michael Walle wrote:
>> > > > Am 2020-06-06 13:46, schrieb Mark Brown:
>> > > > > On Fri, Jun 05, 2020 at 10:07:36PM +0200, Michael Walle wrote:
>> > > > > > Am 2020-06-05 12:50, schrieb Mark Brown:
>> >
>> > ...
>> >
>> > > Right.  I'm suggesting a means to extrapolate complex shared and
>> > > sometimes intertwined batches of register sets to be consumed by
>> > > multiple (sub-)devices spanning different subsystems.
>> > >
>> > > Actually scrap that.  The most common case I see is a single Regmap
>> > > covering all child-devices.
>> >
>> > Yes, because often we need a synchronization across the entire address
>> > space of the (parent) device in question.
>> >
>> > >  It would be great if there was a way in
>> > > which we could make an assumption that the entire register address
>> > > space for a 'tagged' (MFD) device is to be shared (via Regmap) between
>> > > each of the devices described by its child-nodes.  Probably by picking
>> > > up on the 'simple-mfd' compatible string in the first instance.
>> > >
>> > > Rob, is the above something you would contemplate?
>> > >
>> > > Michael, do your register addresses overlap i.e. are they intermingled
>> > > with one another?  Do multiple child devices need access to the same
>> > > registers i.e. are they shared?
>> 
>> No they don't overlap, expect for maybe the version register, which is
>> just there once and not per function block.
> 
> Then what's stopping you having each device Regmap their own space?

Because its just one I2C device, AFAIK thats not possible, right?

> The issues I wish to resolve using 'simple-mfd' are when sub-devices
> register maps overlap and intertwine.
> 
>> > > > > > But, there is more in my driver:
>> > > > > >  (1) there is a version check
>> > >
>> > > If we can rid the Regmap dependency, then creating an entire driver to
>> > > conduct a version check is unjustifiable.  This could become an inline
>> > > function which is called by each of the sub-devices instead, for
>> > > example.
>> 
>> sounds good to me. (although there would then be a probe fail per 
>> sub-device
>> if the version is not supported)
> 
> I don't see an issue with that.  I would put that check inside a
> shared call though, complete with support for locking.
> 
>> > > > > >  (2) there is another function for which there is no suitable linux
>> > > > > >      subsystem I'm aware of and thus which I'd like to us sysfs
>> > > > > >      attributes for: This controller supports 16 non-volatile
>> > > > > >      configuration bits. (this is still TBD)
>> > >
>> > > There is a place for everything in Linux.
>> > >
>> > > What do these bits configure?
>> 
>> - hardware strappings which have to be there before the board powers 
>> up,
>>   like clocking mode for different SerDes settings
>> - "keep-in-reset" bits for onboard peripherals if you want to save 
>> power
>> - disable watchdog bits (there is a watchdog which is active right 
>> from
>>   the start and supervises the bootloader start and switches to 
>> failsafe
>>   mode if it wasn't successfully started)
>> - special boot modes, like eMMC, etc.
>> 
>> Think of it as a 16bit configuration word.
> 
> And you wish for users to be able to view these at run-time?

And esp. change them.

> Can they adapt any of them on-the-fly or will the be RO?

They are R/W but only will only affect the board behavior after a reset.

-michael

> 
>> > > > > TBH I'd also say that the enumeration of the subdevices for this
>> > > > > device should be in the device rather than the DT, they don't
>> > > > > seem to be things that exist outside of this one device.
>> > > >
>> > > > We're going circles here, formerly they were enumerated in the MFD.
>> > > > Yes, they are devices which aren't likely be used outside a
>> > > > "sl28cpld", but there might there might be other versions of the
>> > > > sl28cpld with other components on different base addresses. I
>> > > > don't care if they are enumerated in DT or MFD, actually, I'd
>> > > > prefer the latter. _But_ I would like to have the device tree
>> > > > properties for its subdevices, e.g. the ones for the watchdog or
>> > > > whatever components there might be in the future.
>> > >
>> > > [...]
>> > >
>> > > > MFD core can
>> > > > match a device tree node today; but only one per unique compatible
>> > > > string. So what should I use to differentiate the different
>> > > > subdevices?
>> > >
>> > > Right.  I have been aware of this issue.  The only suitable solution
>> > > to this would be to match on 'reg'.
>> 
>> see below (1)
>> 
>> > >
>> > > FYI: I plan to fix this.
>> > >
>> > > If your register map needs to change, then I suggest that this is
>> > > either a new device or at least a different version of the device and
>> > > would also have to be represented as different (sub-)mfd_cell.
>> > >
>> > > > Rob suggested the internal offset, which I did here.
>> > >
>> > > FWIW, I don't like this idea.  DTs should not have to be modified
>> > > (either in the first instance or subsequently) or specifically
>> > > designed to patch inadequacies in any given OS.
>> 
>> How does (1) play together with this? What do you propose the "reg"
>> property should contain?
> 
> Whatever is in the 'reg' property contained in the Device Tree node.
> Either the full address or an offset would be suitable.
> 
> Caveat: All this thinking has been done on-the-fly.  I would need to
> look at some examples of existing devices and start coding before I
> could really think the solution through.
> 
> Happy to discuss and/or take recommendations though.

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-08 21:09                     ` Michael Walle
@ 2020-06-09  6:47                       ` Lee Jones
  2020-06-09 14:38                         ` Michael Walle
  0 siblings, 1 reply; 74+ messages in thread
From: Lee Jones @ 2020-06-09  6:47 UTC (permalink / raw)
  To: Michael Walle
  Cc: Andy Shevchenko, Ranjani Sridharan, david.m.ertman,
	shiraz.saleem, Rob Herring, Mark Brown, open list:GPIO SUBSYSTEM,
	devicetree, Linux Kernel Mailing List, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm Mailing List, Linus Walleij,
	Bartosz Golaszewski, Jean Delvare, Guenter Roeck, Thierry Reding,
	Uwe Kleine-König, Wim Van Sebroeck, Shawn Guo, Li Yang,
	Thomas Gleixner, Jason Cooper, Marc Zyngier, Greg Kroah-Hartman,
	Andy Shevchenko

On Mon, 08 Jun 2020, Michael Walle wrote:

> Am 2020-06-08 20:56, schrieb Lee Jones:
> > On Mon, 08 Jun 2020, Michael Walle wrote:
> > 
> > > Am 2020-06-08 12:02, schrieb Andy Shevchenko:
> > > > +Cc: some Intel people WRT our internal discussion about similar
> > > > problem and solutions.
> > > >
> > > > On Mon, Jun 8, 2020 at 11:30 AM Lee Jones <lee.jones@linaro.org> wrote:
> > > > > On Sat, 06 Jun 2020, Michael Walle wrote:
> > > > > > Am 2020-06-06 13:46, schrieb Mark Brown:
> > > > > > > On Fri, Jun 05, 2020 at 10:07:36PM +0200, Michael Walle wrote:
> > > > > > > > Am 2020-06-05 12:50, schrieb Mark Brown:
> > > >
> > > > ...
> > > >
> > > > > Right.  I'm suggesting a means to extrapolate complex shared and
> > > > > sometimes intertwined batches of register sets to be consumed by
> > > > > multiple (sub-)devices spanning different subsystems.
> > > > >
> > > > > Actually scrap that.  The most common case I see is a single Regmap
> > > > > covering all child-devices.
> > > >
> > > > Yes, because often we need a synchronization across the entire address
> > > > space of the (parent) device in question.
> > > >
> > > > >  It would be great if there was a way in
> > > > > which we could make an assumption that the entire register address
> > > > > space for a 'tagged' (MFD) device is to be shared (via Regmap) between
> > > > > each of the devices described by its child-nodes.  Probably by picking
> > > > > up on the 'simple-mfd' compatible string in the first instance.
> > > > >
> > > > > Rob, is the above something you would contemplate?
> > > > >
> > > > > Michael, do your register addresses overlap i.e. are they intermingled
> > > > > with one another?  Do multiple child devices need access to the same
> > > > > registers i.e. are they shared?
> > > 
> > > No they don't overlap, expect for maybe the version register, which is
> > > just there once and not per function block.
> > 
> > Then what's stopping you having each device Regmap their own space?
> 
> Because its just one I2C device, AFAIK thats not possible, right?

Not sure what (if any) the restrictions are.

I can't think of any reasons why not, off the top of my head.

Does Regmap only deal with shared accesses from multiple devices
accessing a single register map, or can it also handle multiple
devices communicating over a single I2C channel?

One for Mark perhaps.

> > The issues I wish to resolve using 'simple-mfd' are when sub-devices
> > register maps overlap and intertwine.

[...]

> > > > > What do these bits configure?
> > > 
> > > - hardware strappings which have to be there before the board powers
> > > up,
> > >   like clocking mode for different SerDes settings
> > > - "keep-in-reset" bits for onboard peripherals if you want to save
> > > power
> > > - disable watchdog bits (there is a watchdog which is active right
> > > from
> > >   the start and supervises the bootloader start and switches to
> > > failsafe
> > >   mode if it wasn't successfully started)
> > > - special boot modes, like eMMC, etc.
> > > 
> > > Think of it as a 16bit configuration word.
> > 
> > And you wish for users to be able to view these at run-time?
> 
> And esp. change them.
> 
> > Can they adapt any of them on-the-fly or will the be RO?
> 
> They are R/W but only will only affect the board behavior after a reset.

I see.  Makes sense.  This is board controller territory.  Perhaps
suitable for inclusion into drivers/soc or drivers/platform.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-09  6:47                       ` Lee Jones
@ 2020-06-09 14:38                         ` Michael Walle
  2020-06-09 14:42                           ` Mark Brown
  2020-06-09 15:19                           ` Lee Jones
  0 siblings, 2 replies; 74+ messages in thread
From: Michael Walle @ 2020-06-09 14:38 UTC (permalink / raw)
  To: Lee Jones
  Cc: Andy Shevchenko, Ranjani Sridharan, david.m.ertman,
	shiraz.saleem, Rob Herring, Mark Brown, open list:GPIO SUBSYSTEM,
	devicetree, Linux Kernel Mailing List, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm Mailing List, Linus Walleij,
	Bartosz Golaszewski, Jean Delvare, Guenter Roeck, Thierry Reding,
	Uwe Kleine-König, Wim Van Sebroeck, Shawn Guo, Li Yang,
	Thomas Gleixner, Jason Cooper, Marc Zyngier, Greg Kroah-Hartman,
	Andy Shevchenko

Am 2020-06-09 08:47, schrieb Lee Jones:
> On Mon, 08 Jun 2020, Michael Walle wrote:
> 
>> Am 2020-06-08 20:56, schrieb Lee Jones:
>> > On Mon, 08 Jun 2020, Michael Walle wrote:
>> >
>> > > Am 2020-06-08 12:02, schrieb Andy Shevchenko:
>> > > > +Cc: some Intel people WRT our internal discussion about similar
>> > > > problem and solutions.
>> > > >
>> > > > On Mon, Jun 8, 2020 at 11:30 AM Lee Jones <lee.jones@linaro.org> wrote:
>> > > > > On Sat, 06 Jun 2020, Michael Walle wrote:
>> > > > > > Am 2020-06-06 13:46, schrieb Mark Brown:
>> > > > > > > On Fri, Jun 05, 2020 at 10:07:36PM +0200, Michael Walle wrote:
>> > > > > > > > Am 2020-06-05 12:50, schrieb Mark Brown:
>> > > >
>> > > > ...
>> > > >
>> > > > > Right.  I'm suggesting a means to extrapolate complex shared and
>> > > > > sometimes intertwined batches of register sets to be consumed by
>> > > > > multiple (sub-)devices spanning different subsystems.
>> > > > >
>> > > > > Actually scrap that.  The most common case I see is a single Regmap
>> > > > > covering all child-devices.
>> > > >
>> > > > Yes, because often we need a synchronization across the entire address
>> > > > space of the (parent) device in question.
>> > > >
>> > > > >  It would be great if there was a way in
>> > > > > which we could make an assumption that the entire register address
>> > > > > space for a 'tagged' (MFD) device is to be shared (via Regmap) between
>> > > > > each of the devices described by its child-nodes.  Probably by picking
>> > > > > up on the 'simple-mfd' compatible string in the first instance.
>> > > > >
>> > > > > Rob, is the above something you would contemplate?
>> > > > >
>> > > > > Michael, do your register addresses overlap i.e. are they intermingled
>> > > > > with one another?  Do multiple child devices need access to the same
>> > > > > registers i.e. are they shared?
>> > >
>> > > No they don't overlap, expect for maybe the version register, which is
>> > > just there once and not per function block.
>> >
>> > Then what's stopping you having each device Regmap their own space?
>> 
>> Because its just one I2C device, AFAIK thats not possible, right?
> 
> Not sure what (if any) the restrictions are.

You can only have one device per I2C address. Therefore, I need one 
device
which is enumerated by the I2C bus, which then enumerates its 
sub-devices.
I thought this was one of the use cases for MFD. (Regardless of how a
sub-device access its registers). So even in the "simple-regmap" case 
this
would need to be an i2c device.

E.g.

&i2cbus {
   mfd-device@10 {
     compatible = "simple-regmap", "simple-mfd";
     reg = <10>;
     regmap,reg-bits = <8>;
     regmap,val-bits = <8>;
     sub-device@0 {
       compatible = "vendor,sub-device0";
       reg = <0>;
     };
     ...
};

Or if you just want the regmap:

&soc {
   regmap: regmap@fff0000 {
     compatible = "simple-regmap";
     reg = <0xfff0000>;
     regmap,reg-bits = <16>;
     regmap,val-bits = <32>;
   };

   enet-which-needs-syscon-too@1000000 {
     vendor,ctrl-regmap = <&regmap>;
   };
};

Similar to the current syscon (which is MMIO only..).

-michael

> 
> I can't think of any reasons why not, off the top of my head.
> 
> Does Regmap only deal with shared accesses from multiple devices
> accessing a single register map, or can it also handle multiple
> devices communicating over a single I2C channel?
> 
> One for Mark perhaps.
> 
>> > The issues I wish to resolve using 'simple-mfd' are when sub-devices
>> > register maps overlap and intertwine.
> 
> [...]
> 
>> > > > > What do these bits configure?
>> > >
>> > > - hardware strappings which have to be there before the board powers
>> > > up,
>> > >   like clocking mode for different SerDes settings
>> > > - "keep-in-reset" bits for onboard peripherals if you want to save
>> > > power
>> > > - disable watchdog bits (there is a watchdog which is active right
>> > > from
>> > >   the start and supervises the bootloader start and switches to
>> > > failsafe
>> > >   mode if it wasn't successfully started)
>> > > - special boot modes, like eMMC, etc.
>> > >
>> > > Think of it as a 16bit configuration word.
>> >
>> > And you wish for users to be able to view these at run-time?
>> 
>> And esp. change them.
>> 
>> > Can they adapt any of them on-the-fly or will the be RO?
>> 
>> They are R/W but only will only affect the board behavior after a 
>> reset.
> 
> I see.  Makes sense.  This is board controller territory.  Perhaps
> suitable for inclusion into drivers/soc or drivers/platform.

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-09 14:38                         ` Michael Walle
@ 2020-06-09 14:42                           ` Mark Brown
  2020-06-09 15:01                             ` Michael Walle
  2020-06-09 15:19                           ` Lee Jones
  1 sibling, 1 reply; 74+ messages in thread
From: Mark Brown @ 2020-06-09 14:42 UTC (permalink / raw)
  To: Michael Walle
  Cc: Lee Jones, Andy Shevchenko, Ranjani Sridharan, david.m.ertman,
	shiraz.saleem, Rob Herring, open list:GPIO SUBSYSTEM, devicetree,
	Linux Kernel Mailing List, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm Mailing List, Linus Walleij,
	Bartosz Golaszewski, Jean Delvare, Guenter Roeck, Thierry Reding,
	Uwe Kleine-König, Wim Van Sebroeck, Shawn Guo, Li Yang,
	Thomas Gleixner, Jason Cooper, Marc Zyngier, Greg Kroah-Hartman,
	Andy Shevchenko

[-- Attachment #1: Type: text/plain, Size: 2617 bytes --]

On Tue, Jun 09, 2020 at 04:38:31PM +0200, Michael Walle wrote:

>   mfd-device@10 {
>     compatible = "simple-regmap", "simple-mfd";
>     reg = <10>;
>     regmap,reg-bits = <8>;
>     regmap,val-bits = <8>;
>     sub-device@0 {
>       compatible = "vendor,sub-device0";
>       reg = <0>;
>     };

A DT binding like this is not a good idea, encoding the details of the
register map into the DT binding makes it an ABI which is begging for
trouble.  I'd also suggest that any device using a generic driver like
this should have a specific compatible string for the device so we can
go back and add quirks later if we need them.

>     ...
> };
> 
> Or if you just want the regmap:
> 
> &soc {
>   regmap: regmap@fff0000 {
>     compatible = "simple-regmap";
>     reg = <0xfff0000>;
>     regmap,reg-bits = <16>;
>     regmap,val-bits = <32>;
>   };
> 
>   enet-which-needs-syscon-too@1000000 {
>     vendor,ctrl-regmap = <&regmap>;
>   };
> };
> 
> Similar to the current syscon (which is MMIO only..).
> 
> -michael
> 
> > 
> > I can't think of any reasons why not, off the top of my head.
> > 
> > Does Regmap only deal with shared accesses from multiple devices
> > accessing a single register map, or can it also handle multiple
> > devices communicating over a single I2C channel?
> > 
> > One for Mark perhaps.
> > 
> > > > The issues I wish to resolve using 'simple-mfd' are when sub-devices
> > > > register maps overlap and intertwine.
> > 
> > [...]
> > 
> > > > > > > What do these bits configure?
> > > > >
> > > > > - hardware strappings which have to be there before the board powers
> > > > > up,
> > > > >   like clocking mode for different SerDes settings
> > > > > - "keep-in-reset" bits for onboard peripherals if you want to save
> > > > > power
> > > > > - disable watchdog bits (there is a watchdog which is active right
> > > > > from
> > > > >   the start and supervises the bootloader start and switches to
> > > > > failsafe
> > > > >   mode if it wasn't successfully started)
> > > > > - special boot modes, like eMMC, etc.
> > > > >
> > > > > Think of it as a 16bit configuration word.
> > > >
> > > > And you wish for users to be able to view these at run-time?
> > > 
> > > And esp. change them.
> > > 
> > > > Can they adapt any of them on-the-fly or will the be RO?
> > > 
> > > They are R/W but only will only affect the board behavior after a
> > > reset.
> > 
> > I see.  Makes sense.  This is board controller territory.  Perhaps
> > suitable for inclusion into drivers/soc or drivers/platform.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-09 14:42                           ` Mark Brown
@ 2020-06-09 15:01                             ` Michael Walle
  2020-06-09 17:15                               ` Rob Herring
  0 siblings, 1 reply; 74+ messages in thread
From: Michael Walle @ 2020-06-09 15:01 UTC (permalink / raw)
  To: Mark Brown
  Cc: Lee Jones, Andy Shevchenko, Ranjani Sridharan, david.m.ertman,
	shiraz.saleem, Rob Herring, open list:GPIO SUBSYSTEM, devicetree,
	Linux Kernel Mailing List, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm Mailing List, Linus Walleij,
	Bartosz Golaszewski, Jean Delvare, Guenter Roeck, Thierry Reding,
	Uwe Kleine-König, Wim Van Sebroeck, Shawn Guo, Li Yang,
	Thomas Gleixner, Jason Cooper, Marc Zyngier, Greg Kroah-Hartman,
	Andy Shevchenko

Am 2020-06-09 16:42, schrieb Mark Brown:
> On Tue, Jun 09, 2020 at 04:38:31PM +0200, Michael Walle wrote:
> 
>>   mfd-device@10 {
>>     compatible = "simple-regmap", "simple-mfd";
>>     reg = <10>;
>>     regmap,reg-bits = <8>;
>>     regmap,val-bits = <8>;
>>     sub-device@0 {
>>       compatible = "vendor,sub-device0";
>>       reg = <0>;
>>     };
> 
> A DT binding like this is not a good idea, encoding the details of the
> register map into the DT binding makes it an ABI which is begging for
> trouble.  I'd also suggest that any device using a generic driver like
> this should have a specific compatible string for the device so we can
> go back and add quirks later if we need them.

Like in the spidev case, yes. But OTOH if I _just_ encode the parameters
for the regmap a MFD, Lee don't agree because its just a shim. So either
way I seem to be stuck here.

Where should I put the code to create an i2c driver, init a regmap and
populate its childen?

-michael

> 
>>     ...
>> };
>> 
>> Or if you just want the regmap:
>> 
>> &soc {
>>   regmap: regmap@fff0000 {
>>     compatible = "simple-regmap";
>>     reg = <0xfff0000>;
>>     regmap,reg-bits = <16>;
>>     regmap,val-bits = <32>;
>>   };
>> 
>>   enet-which-needs-syscon-too@1000000 {
>>     vendor,ctrl-regmap = <&regmap>;
>>   };
>> };
>> 
>> Similar to the current syscon (which is MMIO only..).
>> 
>> -michael
>> 
>> >
>> > I can't think of any reasons why not, off the top of my head.
>> >
>> > Does Regmap only deal with shared accesses from multiple devices
>> > accessing a single register map, or can it also handle multiple
>> > devices communicating over a single I2C channel?
>> >
>> > One for Mark perhaps.
>> >
>> > > > The issues I wish to resolve using 'simple-mfd' are when sub-devices
>> > > > register maps overlap and intertwine.
>> >
>> > [...]
>> >
>> > > > > > > What do these bits configure?
>> > > > >
>> > > > > - hardware strappings which have to be there before the board powers
>> > > > > up,
>> > > > >   like clocking mode for different SerDes settings
>> > > > > - "keep-in-reset" bits for onboard peripherals if you want to save
>> > > > > power
>> > > > > - disable watchdog bits (there is a watchdog which is active right
>> > > > > from
>> > > > >   the start and supervises the bootloader start and switches to
>> > > > > failsafe
>> > > > >   mode if it wasn't successfully started)
>> > > > > - special boot modes, like eMMC, etc.
>> > > > >
>> > > > > Think of it as a 16bit configuration word.
>> > > >
>> > > > And you wish for users to be able to view these at run-time?
>> > >
>> > > And esp. change them.
>> > >
>> > > > Can they adapt any of them on-the-fly or will the be RO?
>> > >
>> > > They are R/W but only will only affect the board behavior after a
>> > > reset.
>> >
>> > I see.  Makes sense.  This is board controller territory.  Perhaps
>> > suitable for inclusion into drivers/soc or drivers/platform.

-- 
-michael

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-09 14:38                         ` Michael Walle
  2020-06-09 14:42                           ` Mark Brown
@ 2020-06-09 15:19                           ` Lee Jones
  2020-06-09 15:30                             ` Michael Walle
  1 sibling, 1 reply; 74+ messages in thread
From: Lee Jones @ 2020-06-09 15:19 UTC (permalink / raw)
  To: Michael Walle
  Cc: Andy Shevchenko, Ranjani Sridharan, david.m.ertman,
	shiraz.saleem, Rob Herring, Mark Brown, open list:GPIO SUBSYSTEM,
	devicetree, Linux Kernel Mailing List, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm Mailing List, Linus Walleij,
	Bartosz Golaszewski, Jean Delvare, Guenter Roeck, Thierry Reding,
	Uwe Kleine-König, Wim Van Sebroeck, Shawn Guo, Li Yang,
	Thomas Gleixner, Jason Cooper, Marc Zyngier, Greg Kroah-Hartman,
	Andy Shevchenko

On Tue, 09 Jun 2020, Michael Walle wrote:

> Am 2020-06-09 08:47, schrieb Lee Jones:
> > On Mon, 08 Jun 2020, Michael Walle wrote:
> > 
> > > Am 2020-06-08 20:56, schrieb Lee Jones:
> > > > On Mon, 08 Jun 2020, Michael Walle wrote:
> > > >
> > > > > Am 2020-06-08 12:02, schrieb Andy Shevchenko:
> > > > > > +Cc: some Intel people WRT our internal discussion about similar
> > > > > > problem and solutions.
> > > > > >
> > > > > > On Mon, Jun 8, 2020 at 11:30 AM Lee Jones <lee.jones@linaro.org> wrote:
> > > > > > > On Sat, 06 Jun 2020, Michael Walle wrote:
> > > > > > > > Am 2020-06-06 13:46, schrieb Mark Brown:
> > > > > > > > > On Fri, Jun 05, 2020 at 10:07:36PM +0200, Michael Walle wrote:
> > > > > > > > > > Am 2020-06-05 12:50, schrieb Mark Brown:
> > > > > >
> > > > > > ...
> > > > > >
> > > > > > > Right.  I'm suggesting a means to extrapolate complex shared and
> > > > > > > sometimes intertwined batches of register sets to be consumed by
> > > > > > > multiple (sub-)devices spanning different subsystems.
> > > > > > >
> > > > > > > Actually scrap that.  The most common case I see is a single Regmap
> > > > > > > covering all child-devices.
> > > > > >
> > > > > > Yes, because often we need a synchronization across the entire address
> > > > > > space of the (parent) device in question.
> > > > > >
> > > > > > >  It would be great if there was a way in
> > > > > > > which we could make an assumption that the entire register address
> > > > > > > space for a 'tagged' (MFD) device is to be shared (via Regmap) between
> > > > > > > each of the devices described by its child-nodes.  Probably by picking
> > > > > > > up on the 'simple-mfd' compatible string in the first instance.
> > > > > > >
> > > > > > > Rob, is the above something you would contemplate?
> > > > > > >
> > > > > > > Michael, do your register addresses overlap i.e. are they intermingled
> > > > > > > with one another?  Do multiple child devices need access to the same
> > > > > > > registers i.e. are they shared?
> > > > >
> > > > > No they don't overlap, expect for maybe the version register, which is
> > > > > just there once and not per function block.
> > > >
> > > > Then what's stopping you having each device Regmap their own space?
> > > 
> > > Because its just one I2C device, AFAIK thats not possible, right?
> > 
> > Not sure what (if any) the restrictions are.
> 
> You can only have one device per I2C address. Therefore, I need one device
> which is enumerated by the I2C bus, which then enumerates its sub-devices.
> I thought this was one of the use cases for MFD. (Regardless of how a
> sub-device access its registers). So even in the "simple-regmap" case this
> would need to be an i2c device.
> 
> E.g.
> 
> &i2cbus {
>   mfd-device@10 {
>     compatible = "simple-regmap", "simple-mfd";
>     reg = <10>;
>     regmap,reg-bits = <8>;
>     regmap,val-bits = <8>;
>     sub-device@0 {
>       compatible = "vendor,sub-device0";
>       reg = <0>;
>     };
>     ...
> };
> 
> Or if you just want the regmap:
> 
> &soc {
>   regmap: regmap@fff0000 {
>     compatible = "simple-regmap";
>     reg = <0xfff0000>;
>     regmap,reg-bits = <16>;
>     regmap,val-bits = <32>;
>   };
> 
>   enet-which-needs-syscon-too@1000000 {
>     vendor,ctrl-regmap = <&regmap>;
>   };
> };
> 
> Similar to the current syscon (which is MMIO only..).

We do not need a 'simple-regmap' solution for your use-case.

Since your device's registers are segregated, just split up the
register map and allocate each sub-device with it's own slice.

> > I can't think of any reasons why not, off the top of my head.
> > 
> > Does Regmap only deal with shared accesses from multiple devices
> > accessing a single register map, or can it also handle multiple
> > devices communicating over a single I2C channel?
> > 
> > One for Mark perhaps.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-09 15:19                           ` Lee Jones
@ 2020-06-09 15:30                             ` Michael Walle
  2020-06-09 19:45                               ` Lee Jones
  0 siblings, 1 reply; 74+ messages in thread
From: Michael Walle @ 2020-06-09 15:30 UTC (permalink / raw)
  To: Lee Jones
  Cc: Andy Shevchenko, Ranjani Sridharan, david.m.ertman,
	shiraz.saleem, Rob Herring, Mark Brown, open list:GPIO SUBSYSTEM,
	devicetree, Linux Kernel Mailing List, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm Mailing List, Linus Walleij,
	Bartosz Golaszewski, Jean Delvare, Guenter Roeck, Thierry Reding,
	Uwe Kleine-König, Wim Van Sebroeck, Shawn Guo, Li Yang,
	Thomas Gleixner, Jason Cooper, Marc Zyngier, Greg Kroah-Hartman,
	Andy Shevchenko

Am 2020-06-09 17:19, schrieb Lee Jones:
> On Tue, 09 Jun 2020, Michael Walle wrote:
> 
>> Am 2020-06-09 08:47, schrieb Lee Jones:
>> > On Mon, 08 Jun 2020, Michael Walle wrote:
>> >
>> > > Am 2020-06-08 20:56, schrieb Lee Jones:
>> > > > On Mon, 08 Jun 2020, Michael Walle wrote:
>> > > >
>> > > > > Am 2020-06-08 12:02, schrieb Andy Shevchenko:
>> > > > > > +Cc: some Intel people WRT our internal discussion about similar
>> > > > > > problem and solutions.
>> > > > > >
>> > > > > > On Mon, Jun 8, 2020 at 11:30 AM Lee Jones <lee.jones@linaro.org> wrote:
>> > > > > > > On Sat, 06 Jun 2020, Michael Walle wrote:
>> > > > > > > > Am 2020-06-06 13:46, schrieb Mark Brown:
>> > > > > > > > > On Fri, Jun 05, 2020 at 10:07:36PM +0200, Michael Walle wrote:
>> > > > > > > > > > Am 2020-06-05 12:50, schrieb Mark Brown:
>> > > > > >
>> > > > > > ...
>> > > > > >
>> > > > > > > Right.  I'm suggesting a means to extrapolate complex shared and
>> > > > > > > sometimes intertwined batches of register sets to be consumed by
>> > > > > > > multiple (sub-)devices spanning different subsystems.
>> > > > > > >
>> > > > > > > Actually scrap that.  The most common case I see is a single Regmap
>> > > > > > > covering all child-devices.
>> > > > > >
>> > > > > > Yes, because often we need a synchronization across the entire address
>> > > > > > space of the (parent) device in question.
>> > > > > >
>> > > > > > >  It would be great if there was a way in
>> > > > > > > which we could make an assumption that the entire register address
>> > > > > > > space for a 'tagged' (MFD) device is to be shared (via Regmap) between
>> > > > > > > each of the devices described by its child-nodes.  Probably by picking
>> > > > > > > up on the 'simple-mfd' compatible string in the first instance.
>> > > > > > >
>> > > > > > > Rob, is the above something you would contemplate?
>> > > > > > >
>> > > > > > > Michael, do your register addresses overlap i.e. are they intermingled
>> > > > > > > with one another?  Do multiple child devices need access to the same
>> > > > > > > registers i.e. are they shared?
>> > > > >
>> > > > > No they don't overlap, expect for maybe the version register, which is
>> > > > > just there once and not per function block.
>> > > >
>> > > > Then what's stopping you having each device Regmap their own space?
>> > >
>> > > Because its just one I2C device, AFAIK thats not possible, right?
>> >
>> > Not sure what (if any) the restrictions are.
>> 
>> You can only have one device per I2C address. Therefore, I need one 
>> device
>> which is enumerated by the I2C bus, which then enumerates its 
>> sub-devices.
>> I thought this was one of the use cases for MFD. (Regardless of how a
>> sub-device access its registers). So even in the "simple-regmap" case 
>> this
>> would need to be an i2c device.

Here (see below)

>> 
>> E.g.
>> 
>> &i2cbus {
>>   mfd-device@10 {
>>     compatible = "simple-regmap", "simple-mfd";
>>     reg = <10>;
>>     regmap,reg-bits = <8>;
>>     regmap,val-bits = <8>;
>>     sub-device@0 {
>>       compatible = "vendor,sub-device0";
>>       reg = <0>;
>>     };
>>     ...
>> };
>> 
>> Or if you just want the regmap:
>> 
>> &soc {
>>   regmap: regmap@fff0000 {
>>     compatible = "simple-regmap";
>>     reg = <0xfff0000>;
>>     regmap,reg-bits = <16>;
>>     regmap,val-bits = <32>;
>>   };
>> 
>>   enet-which-needs-syscon-too@1000000 {
>>     vendor,ctrl-regmap = <&regmap>;
>>   };
>> };
>> 
>> Similar to the current syscon (which is MMIO only..).
> 
> We do not need a 'simple-regmap' solution for your use-case.
> 
> Since your device's registers are segregated, just split up the
> register map and allocate each sub-device with it's own slice.

I don't get it, could you make a device tree example for my
use-case? (see also above)

-michael

> 
>> > I can't think of any reasons why not, off the top of my head.
>> >
>> > Does Regmap only deal with shared accesses from multiple devices
>> > accessing a single register map, or can it also handle multiple
>> > devices communicating over a single I2C channel?
>> >
>> > One for Mark perhaps.

-- 
-michael

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 01/11] dt-bindings: mfd: Add bindings for sl28cpld
  2020-06-04 21:10 ` [PATCH v4 01/11] dt-bindings: mfd: Add bindings for sl28cpld Michael Walle
@ 2020-06-09 16:28   ` Rob Herring
  0 siblings, 0 replies; 74+ messages in thread
From: Rob Herring @ 2020-06-09 16:28 UTC (permalink / raw)
  To: Michael Walle
  Cc: Mark Brown, linux-watchdog, Shawn Guo, Linus Walleij,
	linux-hwmon, Jean Delvare, Thierry Reding, Greg Kroah-Hartman,
	Rob Herring, linux-pwm, linux-arm-kernel, Jason Cooper,
	Lee Jones, Li Yang, linux-gpio, Uwe Kleine-König,
	linux-kernel, Wim Van Sebroeck, Marc Zyngier, Andy Shevchenko,
	Bartosz Golaszewski, Guenter Roeck, Thomas Gleixner, devicetree

On Thu, 04 Jun 2020 23:10:29 +0200, Michael Walle wrote:
> Add a device tree bindings for the board management controller found on
> the Kontron SMARC-sAL28 board.
> 
> Signed-off-by: Michael Walle <michael@walle.cc>
> ---
>  .../bindings/gpio/kontron,sl28cpld-gpio.yaml  |  54 +++++++
>  .../hwmon/kontron,sl28cpld-hwmon.yaml         |  27 ++++
>  .../kontron,sl28cpld-intc.yaml                |  54 +++++++
>  .../bindings/mfd/kontron,sl28cpld.yaml        | 153 ++++++++++++++++++
>  .../bindings/pwm/kontron,sl28cpld-pwm.yaml    |  35 ++++
>  .../watchdog/kontron,sl28cpld-wdt.yaml        |  35 ++++
>  6 files changed, 358 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/gpio/kontron,sl28cpld-gpio.yaml
>  create mode 100644 Documentation/devicetree/bindings/hwmon/kontron,sl28cpld-hwmon.yaml
>  create mode 100644 Documentation/devicetree/bindings/interrupt-controller/kontron,sl28cpld-intc.yaml
>  create mode 100644 Documentation/devicetree/bindings/mfd/kontron,sl28cpld.yaml
>  create mode 100644 Documentation/devicetree/bindings/pwm/kontron,sl28cpld-pwm.yaml
>  create mode 100644 Documentation/devicetree/bindings/watchdog/kontron,sl28cpld-wdt.yaml
> 


My bot found errors running 'make dt_binding_check' on your patch:

/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mfd/kontron,sl28cpld.example.dt.yaml: sl28cpld@4a: 'gpio@1a', 'gpio@1b', 'hwmon@b', 'interrupt-controller@1c', 'pwm@c', 'pwm@e' do not match any of the regexes: '^gpio(@[0-9]+)?$', '^hwmon(@[0-9]+)?$', '^interrupt-controller(@[0-9]+)?$', '^pwm(@[0-9]+)?$', '^watchdog(@[0-9]+)?$', 'pinctrl-[0-9]+'

See https://patchwork.ozlabs.org/patch/1303780

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:

pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade

Please check and re-submit.


^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-08  8:28             ` Lee Jones
  2020-06-08 10:02               ` Andy Shevchenko
@ 2020-06-09 16:54               ` Rob Herring
  2020-06-09 18:52                 ` Lee Jones
  1 sibling, 1 reply; 74+ messages in thread
From: Rob Herring @ 2020-06-09 16:54 UTC (permalink / raw)
  To: Lee Jones
  Cc: Michael Walle, Mark Brown, linux-gpio, devicetree, linux-kernel,
	linux-hwmon, linux-pwm, linux-watchdog, linux-arm-kernel,
	Linus Walleij, Bartosz Golaszewski, Jean Delvare, Guenter Roeck,
	Thierry Reding, Uwe Kleine-König, Wim Van Sebroeck,
	Shawn Guo, Li Yang, Thomas Gleixner, Jason Cooper, Marc Zyngier,
	Greg Kroah-Hartman, Andy Shevchenko

On Mon, Jun 08, 2020 at 09:28:27AM +0100, Lee Jones wrote:
> Rob, something for you below.
> 
> On Sat, 06 Jun 2020, Michael Walle wrote:
> > Am 2020-06-06 13:46, schrieb Mark Brown:
> > > On Fri, Jun 05, 2020 at 10:07:36PM +0200, Michael Walle wrote:
> > > > Am 2020-06-05 12:50, schrieb Mark Brown:
> > > 
> > > > > I have no idea what you are thinking of when you say "simple-regmap" so
> > > > > it is difficult to comment.
> > > 
> > > > I guess, Lee is suggesting to be able to create a regmap instance via
> > > > device tree (and populate its child nodes?). Like
> > > >   compatible = "syscon", "simple-mfd";
> > > > but for any regmap, not just MMIO.
> 
> Bingo!
> 
> > > I don't understand why this would be anything separate to
> > > simple-mfd.
> > 
> > Don't just simple-mfd tells the of core, to probe the children this
> > node? Where does the regmap then come from?
> 
> Right.  I'm suggesting a means to extrapolate complex shared and
> sometimes intertwined batches of register sets to be consumed by
> multiple (sub-)devices spanning different subsystems.
> 
> Actually scrap that.  The most common case I see is a single Regmap
> covering all child-devices.  It would be great if there was a way in
> which we could make an assumption that the entire register address
> space for a 'tagged' (MFD) device is to be shared (via Regmap) between
> each of the devices described by its child-nodes.  Probably by picking
> up on the 'simple-mfd' compatible string in the first instance.
> 
> Rob, is the above something you would contemplate?

No. I'd like to just kill off syscon and simple-mfd really. Those are 
just hints meaning a specific compatible is still needed, but I see them 
all the time alone (or combined like above). 'syscon' just serves to 
create a regmap. This could be accomplished just with a list of 
compatibles to register a regmap for. That might be a longish list, but 
wanting a regmap is really a kernel implementation detail and decision.

> Michael, do your register addresses overlap i.e. are they intermingled
> with one another?  Do multiple child devices need access to the same
> registers i.e. are they shared?
> 
> > > > But, there is more in my driver:
> > > >  (1) there is a version check
> 
> If we can rid the Regmap dependency, then creating an entire driver to
> conduct a version check is unjustifiable.  This could become an inline
> function which is called by each of the sub-devices instead, for
> example.
> 
> > > >  (2) there is another function for which there is no suitable linux
> > > >      subsystem I'm aware of and thus which I'd like to us sysfs
> > > >      attributes for: This controller supports 16 non-volatile
> > > >      configuration bits. (this is still TBD)
> 
> There is a place for everything in Linux.
> 
> What do these bits configure?
> 
> > > TBH I'd also say that the enumeration of the subdevices for this
> > > device should be in the device rather than the DT, they don't
> > > seem to be things that exist outside of this one device.
> > 
> > We're going circles here, formerly they were enumerated in the MFD.
> > Yes, they are devices which aren't likely be used outside a
> > "sl28cpld", but there might there might be other versions of the
> > sl28cpld with other components on different base addresses. I
> > don't care if they are enumerated in DT or MFD, actually, I'd
> > prefer the latter. _But_ I would like to have the device tree
> > properties for its subdevices, e.g. the ones for the watchdog or
> > whatever components there might be in the future.
> 
> [...]
> 
> > MFD core can
> > match a device tree node today; but only one per unique compatible
> > string. So what should I use to differentiate the different
> > subdevices?
> 
> Right.  I have been aware of this issue.  The only suitable solution
> to this would be to match on 'reg'.
> 
> FYI: I plan to fix this.
> 
> If your register map needs to change, then I suggest that this is
> either a new device or at least a different version of the device and
> would also have to be represented as different (sub-)mfd_cell.

The same register set at a different offset is the same (sub)device.

> 
> > Rob suggested the internal offset, which I did here.
> 
> FWIW, I don't like this idea.  DTs should not have to be modified
> (either in the first instance or subsequently) or specifically
> designed to patch inadequacies in any given OS.

My understanding is there can be differing combinations or number of 
instances of sub devices for this device. That's when having DT sub 
devices makes sense. If the h/w changes, then the DT should change.

Multiple instances of devices require an address to identify them and we 
don't make up numbering if we can avoid it. The earlier revisions just 
had made up indices for addresses.

Rob

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-09 15:01                             ` Michael Walle
@ 2020-06-09 17:15                               ` Rob Herring
  2020-06-09 17:29                                 ` Mark Brown
  2020-06-09 18:41                                 ` Lee Jones
  0 siblings, 2 replies; 74+ messages in thread
From: Rob Herring @ 2020-06-09 17:15 UTC (permalink / raw)
  To: Michael Walle
  Cc: Mark Brown, Lee Jones, Andy Shevchenko, Ranjani Sridharan,
	david.m.ertman, shiraz.saleem, open list:GPIO SUBSYSTEM,
	devicetree, Linux Kernel Mailing List, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm Mailing List, Linus Walleij,
	Bartosz Golaszewski, Jean Delvare, Guenter Roeck, Thierry Reding,
	Uwe Kleine-König, Wim Van Sebroeck, Shawn Guo, Li Yang,
	Thomas Gleixner, Jason Cooper, Marc Zyngier, Greg Kroah-Hartman,
	Andy Shevchenko

On Tue, Jun 09, 2020 at 05:01:17PM +0200, Michael Walle wrote:
> Am 2020-06-09 16:42, schrieb Mark Brown:
> > On Tue, Jun 09, 2020 at 04:38:31PM +0200, Michael Walle wrote:
> > 
> > >   mfd-device@10 {
> > >     compatible = "simple-regmap", "simple-mfd";
> > >     reg = <10>;
> > >     regmap,reg-bits = <8>;
> > >     regmap,val-bits = <8>;
> > >     sub-device@0 {
> > >       compatible = "vendor,sub-device0";
> > >       reg = <0>;
> > >     };
> > 
> > A DT binding like this is not a good idea, encoding the details of the
> > register map into the DT binding makes it an ABI which is begging for
> > trouble.  I'd also suggest that any device using a generic driver like
> > this should have a specific compatible string for the device so we can
> > go back and add quirks later if we need them.
> 
> Like in the spidev case, yes. But OTOH if I _just_ encode the parameters
> for the regmap a MFD, Lee don't agree because its just a shim. So either
> way I seem to be stuck here.
> 
> Where should I put the code to create an i2c driver, init a regmap and
> populate its childen?

Find another driver doing this already and rename it 'simple-mfd' (no 
relation to the DT binding) and add your compatible string to it. 
'Generic' or 'simple' drivers don't require generic/simple DT bindings.

Or extend the existing syscon driver to look up the bus_type and create 
the regmap based on the bus type?

Rob

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-09 17:15                               ` Rob Herring
@ 2020-06-09 17:29                                 ` Mark Brown
  2020-06-09 18:41                                 ` Lee Jones
  1 sibling, 0 replies; 74+ messages in thread
From: Mark Brown @ 2020-06-09 17:29 UTC (permalink / raw)
  To: Rob Herring
  Cc: Michael Walle, Lee Jones, Andy Shevchenko, Ranjani Sridharan,
	david.m.ertman, shiraz.saleem, open list:GPIO SUBSYSTEM,
	devicetree, Linux Kernel Mailing List, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm Mailing List, Linus Walleij,
	Bartosz Golaszewski, Jean Delvare, Guenter Roeck, Thierry Reding,
	Uwe Kleine-König, Wim Van Sebroeck, Shawn Guo, Li Yang,
	Thomas Gleixner, Jason Cooper, Marc Zyngier, Greg Kroah-Hartman,
	Andy Shevchenko

[-- Attachment #1: Type: text/plain, Size: 639 bytes --]

On Tue, Jun 09, 2020 at 11:15:20AM -0600, Rob Herring wrote:

> Find another driver doing this already and rename it 'simple-mfd' (no 
> relation to the DT binding) and add your compatible string to it. 
> 'Generic' or 'simple' drivers don't require generic/simple DT bindings.

> Or extend the existing syscon driver to look up the bus_type and create 
> the regmap based on the bus type?

You'd need a particular bus driver to instantiate for a given bus (or
I'm misunderstanding your proposal) so it wouldn't even need a lookup,
just per-bus ID tables (and ideally also data tables with the regmap
and child descriptions).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-09 17:15                               ` Rob Herring
  2020-06-09 17:29                                 ` Mark Brown
@ 2020-06-09 18:41                                 ` Lee Jones
  1 sibling, 0 replies; 74+ messages in thread
From: Lee Jones @ 2020-06-09 18:41 UTC (permalink / raw)
  To: Rob Herring
  Cc: Michael Walle, Mark Brown, Andy Shevchenko, Ranjani Sridharan,
	david.m.ertman, shiraz.saleem, open list:GPIO SUBSYSTEM,
	devicetree, Linux Kernel Mailing List, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm Mailing List, Linus Walleij,
	Bartosz Golaszewski, Jean Delvare, Guenter Roeck, Thierry Reding,
	Uwe Kleine-König, Wim Van Sebroeck, Shawn Guo, Li Yang,
	Thomas Gleixner, Jason Cooper, Marc Zyngier, Greg Kroah-Hartman,
	Andy Shevchenko

On Tue, 09 Jun 2020, Rob Herring wrote:

> On Tue, Jun 09, 2020 at 05:01:17PM +0200, Michael Walle wrote:
> > Am 2020-06-09 16:42, schrieb Mark Brown:
> > > On Tue, Jun 09, 2020 at 04:38:31PM +0200, Michael Walle wrote:
> > > 
> > > >   mfd-device@10 {
> > > >     compatible = "simple-regmap", "simple-mfd";
> > > >     reg = <10>;
> > > >     regmap,reg-bits = <8>;
> > > >     regmap,val-bits = <8>;
> > > >     sub-device@0 {
> > > >       compatible = "vendor,sub-device0";
> > > >       reg = <0>;
> > > >     };
> > > 
> > > A DT binding like this is not a good idea, encoding the details of the
> > > register map into the DT binding makes it an ABI which is begging for
> > > trouble.  I'd also suggest that any device using a generic driver like
> > > this should have a specific compatible string for the device so we can
> > > go back and add quirks later if we need them.
> > 
> > Like in the spidev case, yes. But OTOH if I _just_ encode the parameters
> > for the regmap a MFD, Lee don't agree because its just a shim. So either
> > way I seem to be stuck here.
> > 
> > Where should I put the code to create an i2c driver, init a regmap and
> > populate its childen?
> 
> Find another driver doing this already and rename it 'simple-mfd' (no 
> relation to the DT binding) and add your compatible string to it. 
> 'Generic' or 'simple' drivers don't require generic/simple DT bindings.

Creating a generic driver is one of the options spinning around in my
head.  If nothing better comes of these discussions, I'll turn my hand
to it soon.

> Or extend the existing syscon driver to look up the bus_type and create 
> the regmap based on the bus type?

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-09 16:54               ` Rob Herring
@ 2020-06-09 18:52                 ` Lee Jones
  0 siblings, 0 replies; 74+ messages in thread
From: Lee Jones @ 2020-06-09 18:52 UTC (permalink / raw)
  To: Rob Herring
  Cc: Michael Walle, Mark Brown, linux-gpio, devicetree, linux-kernel,
	linux-hwmon, linux-pwm, linux-watchdog, linux-arm-kernel,
	Linus Walleij, Bartosz Golaszewski, Jean Delvare, Guenter Roeck,
	Thierry Reding, Uwe Kleine-König, Wim Van Sebroeck,
	Shawn Guo, Li Yang, Thomas Gleixner, Jason Cooper, Marc Zyngier,
	Greg Kroah-Hartman, Andy Shevchenko

On Tue, 09 Jun 2020, Rob Herring wrote:

> On Mon, Jun 08, 2020 at 09:28:27AM +0100, Lee Jones wrote:
> > Rob, something for you below.
> > 
> > On Sat, 06 Jun 2020, Michael Walle wrote:
> > > Am 2020-06-06 13:46, schrieb Mark Brown:
> > > > On Fri, Jun 05, 2020 at 10:07:36PM +0200, Michael Walle wrote:
> > > > > Am 2020-06-05 12:50, schrieb Mark Brown:
> > > > 
> > > > > > I have no idea what you are thinking of when you say "simple-regmap" so
> > > > > > it is difficult to comment.
> > > > 
> > > > > I guess, Lee is suggesting to be able to create a regmap instance via
> > > > > device tree (and populate its child nodes?). Like
> > > > >   compatible = "syscon", "simple-mfd";
> > > > > but for any regmap, not just MMIO.
> > 
> > Bingo!
> > 
> > > > I don't understand why this would be anything separate to
> > > > simple-mfd.
> > > 
> > > Don't just simple-mfd tells the of core, to probe the children this
> > > node? Where does the regmap then come from?
> > 
> > Right.  I'm suggesting a means to extrapolate complex shared and
> > sometimes intertwined batches of register sets to be consumed by
> > multiple (sub-)devices spanning different subsystems.
> > 
> > Actually scrap that.  The most common case I see is a single Regmap
> > covering all child-devices.  It would be great if there was a way in
> > which we could make an assumption that the entire register address
> > space for a 'tagged' (MFD) device is to be shared (via Regmap) between
> > each of the devices described by its child-nodes.  Probably by picking
> > up on the 'simple-mfd' compatible string in the first instance.
> > 
> > Rob, is the above something you would contemplate?
> 
> No. I'd like to just kill off syscon and simple-mfd really. Those are 
> just hints meaning a specific compatible is still needed, but I see them 
> all the time alone (or combined like above). 'syscon' just serves to 
> create a regmap. This could be accomplished just with a list of 
> compatibles to register a regmap for. That might be a longish list, but 
> wanting a regmap is really a kernel implementation detail and decision.

Exactly.  Syscon is a real tangible thing and Regmap is a Linux
subsystem.  So swapping out the former for the latter sounds like the
opposite of what you'd want to do.

> > > MFD core can
> > > match a device tree node today; but only one per unique compatible
> > > string. So what should I use to differentiate the different
> > > subdevices?
> > 
> > Right.  I have been aware of this issue.  The only suitable solution
> > to this would be to match on 'reg'.
> > 
> > FYI: I plan to fix this.
> > 
> > If your register map needs to change, then I suggest that this is
> > either a new device or at least a different version of the device and
> > would also have to be represented as different (sub-)mfd_cell.
> 
> The same register set at a different offset is the same (sub)device.

See below.

> > > Rob suggested the internal offset, which I did here.
> > 
> > FWIW, I don't like this idea.  DTs should not have to be modified
> > (either in the first instance or subsequently) or specifically
> > designed to patch inadequacies in any given OS.
> 
> My understanding is there can be differing combinations or number of 
> instances of sub devices for this device. That's when having DT sub 
> devices makes sense. If the h/w changes, then the DT should change.

This is the same point I was making above.

> Multiple instances of devices require an address to identify them and we 
> don't make up numbering if we can avoid it. The earlier revisions just 
> had made up indices for addresses.

Right.  Which I'm against.

Placing "internal offsets" into the 'reg' property is a hack.

The issue is, if we need to configure the devices differently, then
how do we identify them in order to ensure the correct OF node pointer
is allocated to the correct platform device?

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-09 15:30                             ` Michael Walle
@ 2020-06-09 19:45                               ` Lee Jones
  2020-06-10  7:10                                 ` Michael Walle
  0 siblings, 1 reply; 74+ messages in thread
From: Lee Jones @ 2020-06-09 19:45 UTC (permalink / raw)
  To: Michael Walle
  Cc: Andy Shevchenko, Ranjani Sridharan, david.m.ertman,
	shiraz.saleem, Rob Herring, Mark Brown, open list:GPIO SUBSYSTEM,
	devicetree, Linux Kernel Mailing List, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm Mailing List, Linus Walleij,
	Bartosz Golaszewski, Jean Delvare, Guenter Roeck, Thierry Reding,
	Uwe Kleine-König, Wim Van Sebroeck, Shawn Guo, Li Yang,
	Thomas Gleixner, Jason Cooper, Marc Zyngier, Greg Kroah-Hartman,
	Andy Shevchenko

On Tue, 09 Jun 2020, Michael Walle wrote:

> Am 2020-06-09 17:19, schrieb Lee Jones:
> > On Tue, 09 Jun 2020, Michael Walle wrote:
> > 
> > > Am 2020-06-09 08:47, schrieb Lee Jones:
> > > > On Mon, 08 Jun 2020, Michael Walle wrote:
> > > >
> > > > > Am 2020-06-08 20:56, schrieb Lee Jones:
> > > > > > On Mon, 08 Jun 2020, Michael Walle wrote:
> > > > > >
> > > > > > > Am 2020-06-08 12:02, schrieb Andy Shevchenko:
> > > > > > > > +Cc: some Intel people WRT our internal discussion about similar
> > > > > > > > problem and solutions.
> > > > > > > >
> > > > > > > > On Mon, Jun 8, 2020 at 11:30 AM Lee Jones <lee.jones@linaro.org> wrote:
> > > > > > > > > On Sat, 06 Jun 2020, Michael Walle wrote:
> > > > > > > > > > Am 2020-06-06 13:46, schrieb Mark Brown:
> > > > > > > > > > > On Fri, Jun 05, 2020 at 10:07:36PM +0200, Michael Walle wrote:
> > > > > > > > > > > > Am 2020-06-05 12:50, schrieb Mark Brown:
> > > > > > > >
> > > > > > > > ...
> > > > > > > >
> > > > > > > > > Right.  I'm suggesting a means to extrapolate complex shared and
> > > > > > > > > sometimes intertwined batches of register sets to be consumed by
> > > > > > > > > multiple (sub-)devices spanning different subsystems.
> > > > > > > > >
> > > > > > > > > Actually scrap that.  The most common case I see is a single Regmap
> > > > > > > > > covering all child-devices.
> > > > > > > >
> > > > > > > > Yes, because often we need a synchronization across the entire address
> > > > > > > > space of the (parent) device in question.
> > > > > > > >
> > > > > > > > >  It would be great if there was a way in
> > > > > > > > > which we could make an assumption that the entire register address
> > > > > > > > > space for a 'tagged' (MFD) device is to be shared (via Regmap) between
> > > > > > > > > each of the devices described by its child-nodes.  Probably by picking
> > > > > > > > > up on the 'simple-mfd' compatible string in the first instance.
> > > > > > > > >
> > > > > > > > > Rob, is the above something you would contemplate?
> > > > > > > > >
> > > > > > > > > Michael, do your register addresses overlap i.e. are they intermingled
> > > > > > > > > with one another?  Do multiple child devices need access to the same
> > > > > > > > > registers i.e. are they shared?
> > > > > > >
> > > > > > > No they don't overlap, expect for maybe the version register, which is
> > > > > > > just there once and not per function block.
> > > > > >
> > > > > > Then what's stopping you having each device Regmap their own space?
> > > > >
> > > > > Because its just one I2C device, AFAIK thats not possible, right?
> > > >
> > > > Not sure what (if any) the restrictions are.
> > > 
> > > You can only have one device per I2C address. Therefore, I need one
> > > device
> > > which is enumerated by the I2C bus, which then enumerates its
> > > sub-devices.
> > > I thought this was one of the use cases for MFD. (Regardless of how a
> > > sub-device access its registers). So even in the "simple-regmap"
> > > case this
> > > would need to be an i2c device.
> 
> Here (see below)

Yes, it should still be an I2C device.

> > > 
> > > E.g.
> > > 
> > > &i2cbus {
> > >   mfd-device@10 {
> > >     compatible = "simple-regmap", "simple-mfd";
> > >     reg = <10>;
> > >     regmap,reg-bits = <8>;
> > >     regmap,val-bits = <8>;
> > >     sub-device@0 {
> > >       compatible = "vendor,sub-device0";
> > >       reg = <0>;
> > >     };
> > >     ...
> > > };
> > > 
> > > Or if you just want the regmap:
> > > 
> > > &soc {
> > >   regmap: regmap@fff0000 {
> > >     compatible = "simple-regmap";
> > >     reg = <0xfff0000>;
> > >     regmap,reg-bits = <16>;
> > >     regmap,val-bits = <32>;
> > >   };
> > > 
> > >   enet-which-needs-syscon-too@1000000 {
> > >     vendor,ctrl-regmap = <&regmap>;
> > >   };
> > > };
> > > 
> > > Similar to the current syscon (which is MMIO only..).
> > 
> > We do not need a 'simple-regmap' solution for your use-case.
> > 
> > Since your device's registers are segregated, just split up the
> > register map and allocate each sub-device with it's own slice.
> 
> I don't get it, could you make a device tree example for my
> use-case? (see also above)

    &i2cbus {
        mfd-device@10 {
            compatible = "simple-mfd";
            reg = <10>;

            sub-device@10 {
                compatible = "vendor,sub-device";
                reg = <10>;
            };
   };

The Regmap config would be present in each of the child devices.

Each child device would call devm_regmap_init_i2c() in .probe().

> > > > I can't think of any reasons why not, off the top of my head.
> > > >
> > > > Does Regmap only deal with shared accesses from multiple devices
> > > > accessing a single register map, or can it also handle multiple
> > > > devices communicating over a single I2C channel?
> > > >
> > > > One for Mark perhaps.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-09 19:45                               ` Lee Jones
@ 2020-06-10  7:10                                 ` Michael Walle
  2020-06-10  7:19                                   ` Lee Jones
  0 siblings, 1 reply; 74+ messages in thread
From: Michael Walle @ 2020-06-10  7:10 UTC (permalink / raw)
  To: Lee Jones
  Cc: Andy Shevchenko, Ranjani Sridharan, david.m.ertman,
	shiraz.saleem, Rob Herring, Mark Brown, open list:GPIO SUBSYSTEM,
	devicetree, Linux Kernel Mailing List, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm Mailing List, Linus Walleij,
	Bartosz Golaszewski, Jean Delvare, Guenter Roeck, Thierry Reding,
	Uwe Kleine-König, Wim Van Sebroeck, Shawn Guo, Li Yang,
	Thomas Gleixner, Jason Cooper, Marc Zyngier, Greg Kroah-Hartman,
	Andy Shevchenko

Am 2020-06-09 21:45, schrieb Lee Jones:
> On Tue, 09 Jun 2020, Michael Walle wrote:
> 
>> Am 2020-06-09 17:19, schrieb Lee Jones:
>> > On Tue, 09 Jun 2020, Michael Walle wrote:
>> >
>> > > Am 2020-06-09 08:47, schrieb Lee Jones:
>> > > > On Mon, 08 Jun 2020, Michael Walle wrote:
>> > > >
>> > > > > Am 2020-06-08 20:56, schrieb Lee Jones:
>> > > > > > On Mon, 08 Jun 2020, Michael Walle wrote:
>> > > > > >
>> > > > > > > Am 2020-06-08 12:02, schrieb Andy Shevchenko:
>> > > > > > > > +Cc: some Intel people WRT our internal discussion about similar
>> > > > > > > > problem and solutions.
>> > > > > > > >
>> > > > > > > > On Mon, Jun 8, 2020 at 11:30 AM Lee Jones <lee.jones@linaro.org> wrote:
>> > > > > > > > > On Sat, 06 Jun 2020, Michael Walle wrote:
>> > > > > > > > > > Am 2020-06-06 13:46, schrieb Mark Brown:
>> > > > > > > > > > > On Fri, Jun 05, 2020 at 10:07:36PM +0200, Michael Walle wrote:
>> > > > > > > > > > > > Am 2020-06-05 12:50, schrieb Mark Brown:
>> > > > > > > >
>> > > > > > > > ...
>> > > > > > > >
>> > > > > > > > > Right.  I'm suggesting a means to extrapolate complex shared and
>> > > > > > > > > sometimes intertwined batches of register sets to be consumed by
>> > > > > > > > > multiple (sub-)devices spanning different subsystems.
>> > > > > > > > >
>> > > > > > > > > Actually scrap that.  The most common case I see is a single Regmap
>> > > > > > > > > covering all child-devices.
>> > > > > > > >
>> > > > > > > > Yes, because often we need a synchronization across the entire address
>> > > > > > > > space of the (parent) device in question.
>> > > > > > > >
>> > > > > > > > >  It would be great if there was a way in
>> > > > > > > > > which we could make an assumption that the entire register address
>> > > > > > > > > space for a 'tagged' (MFD) device is to be shared (via Regmap) between
>> > > > > > > > > each of the devices described by its child-nodes.  Probably by picking
>> > > > > > > > > up on the 'simple-mfd' compatible string in the first instance.
>> > > > > > > > >
>> > > > > > > > > Rob, is the above something you would contemplate?
>> > > > > > > > >
>> > > > > > > > > Michael, do your register addresses overlap i.e. are they intermingled
>> > > > > > > > > with one another?  Do multiple child devices need access to the same
>> > > > > > > > > registers i.e. are they shared?
>> > > > > > >
>> > > > > > > No they don't overlap, expect for maybe the version register, which is
>> > > > > > > just there once and not per function block.
>> > > > > >
>> > > > > > Then what's stopping you having each device Regmap their own space?
>> > > > >
>> > > > > Because its just one I2C device, AFAIK thats not possible, right?
>> > > >
>> > > > Not sure what (if any) the restrictions are.
>> > >
>> > > You can only have one device per I2C address. Therefore, I need one
>> > > device
>> > > which is enumerated by the I2C bus, which then enumerates its
>> > > sub-devices.
>> > > I thought this was one of the use cases for MFD. (Regardless of how a
>> > > sub-device access its registers). So even in the "simple-regmap"
>> > > case this
>> > > would need to be an i2c device.
>> 
>> Here (see below)
> 
> Yes, it should still be an I2C device.
> 
>> > >
>> > > E.g.
>> > >
>> > > &i2cbus {
>> > >   mfd-device@10 {
>> > >     compatible = "simple-regmap", "simple-mfd";
>> > >     reg = <10>;
>> > >     regmap,reg-bits = <8>;
>> > >     regmap,val-bits = <8>;
>> > >     sub-device@0 {
>> > >       compatible = "vendor,sub-device0";
>> > >       reg = <0>;
>> > >     };
>> > >     ...
>> > > };
>> > >
>> > > Or if you just want the regmap:
>> > >
>> > > &soc {
>> > >   regmap: regmap@fff0000 {
>> > >     compatible = "simple-regmap";
>> > >     reg = <0xfff0000>;
>> > >     regmap,reg-bits = <16>;
>> > >     regmap,val-bits = <32>;
>> > >   };
>> > >
>> > >   enet-which-needs-syscon-too@1000000 {
>> > >     vendor,ctrl-regmap = <&regmap>;
>> > >   };
>> > > };
>> > >
>> > > Similar to the current syscon (which is MMIO only..).
>> >
>> > We do not need a 'simple-regmap' solution for your use-case.
>> >
>> > Since your device's registers are segregated, just split up the
>> > register map and allocate each sub-device with it's own slice.
>> 
>> I don't get it, could you make a device tree example for my
>> use-case? (see also above)
> 
>     &i2cbus {
>         mfd-device@10 {
>             compatible = "simple-mfd";
>             reg = <10>;
> 
>             sub-device@10 {
>                 compatible = "vendor,sub-device";
>                 reg = <10>;
>             };
>    };
> 
> The Regmap config would be present in each of the child devices.
> 
> Each child device would call devm_regmap_init_i2c() in .probe().

Ah, I see. If I'm not wrong, this still means to create an i2c
device driver with the name "simple-mfd".

Besides that, I don't like this, because:
  - Rob already expressed its concerns with "simple-mfd" and so on.
  - you need to duplicate the config in each sub device
  - which also means you are restricting the sub devices to be
    i2c only (unless you implement and duplicate other regmap configs,
    too). For this driver, SPI and MMIO may be viable options.

Thus, I'd rather implement a simple-mfd.c which implement a common
I2C driver for now and populate its children using
devm_of_platform_populate(). This could be extended to support other
type of regmaps like SPI in the future.

Also some MFD drivers could be moved to this, a likely candidate is
the smsc-ece1099.c. Although I don't really understand its purpose,
if don't have CONFIG_OF.

Judging from the existing code, this simple-mfd.c wouldn't just be
"a list of compatible" strings but also additional quirks and tweaks
for particular devices in this list.

-michael

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-10  7:10                                 ` Michael Walle
@ 2020-06-10  7:19                                   ` Lee Jones
  2020-06-10  7:49                                     ` Michael Walle
  2020-06-10 17:16                                     ` Rob Herring
  0 siblings, 2 replies; 74+ messages in thread
From: Lee Jones @ 2020-06-10  7:19 UTC (permalink / raw)
  To: Michael Walle
  Cc: Andy Shevchenko, Ranjani Sridharan, david.m.ertman,
	shiraz.saleem, Rob Herring, Mark Brown, open list:GPIO SUBSYSTEM,
	devicetree, Linux Kernel Mailing List, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm Mailing List, Linus Walleij,
	Bartosz Golaszewski, Jean Delvare, Guenter Roeck, Thierry Reding,
	Uwe Kleine-König, Wim Van Sebroeck, Shawn Guo, Li Yang,
	Thomas Gleixner, Jason Cooper, Marc Zyngier, Greg Kroah-Hartman,
	Andy Shevchenko

On Wed, 10 Jun 2020, Michael Walle wrote:
> Am 2020-06-09 21:45, schrieb Lee Jones:
> > On Tue, 09 Jun 2020, Michael Walle wrote:
> > > > We do not need a 'simple-regmap' solution for your use-case.
> > > >
> > > > Since your device's registers are segregated, just split up the
> > > > register map and allocate each sub-device with it's own slice.
> > > 
> > > I don't get it, could you make a device tree example for my
> > > use-case? (see also above)
> > 
> >     &i2cbus {
> >         mfd-device@10 {
> >             compatible = "simple-mfd";
> >             reg = <10>;
> > 
> >             sub-device@10 {
> >                 compatible = "vendor,sub-device";
> >                 reg = <10>;
> >             };
> >    };
> > 
> > The Regmap config would be present in each of the child devices.
> > 
> > Each child device would call devm_regmap_init_i2c() in .probe().
> 
> Ah, I see. If I'm not wrong, this still means to create an i2c
> device driver with the name "simple-mfd".

Yes, it does.

> Besides that, I don't like this, because:
>  - Rob already expressed its concerns with "simple-mfd" and so on.

Where did this take place?  I'd like to read up on this.

>  - you need to duplicate the config in each sub device

You can have a share a single config.

>  - which also means you are restricting the sub devices to be
>    i2c only (unless you implement and duplicate other regmap configs,
>    too). For this driver, SPI and MMIO may be viable options.

You could also have a shared implementation to choose between different
busses.

> Thus, I'd rather implement a simple-mfd.c which implement a common
> I2C driver for now and populate its children using
> devm_of_platform_populate(). This could be extended to support other
> type of regmaps like SPI in the future.
> 
> Also some MFD drivers could be moved to this, a likely candidate is
> the smsc-ece1099.c. Although I don't really understand its purpose,
> if don't have CONFIG_OF.
> 
> Judging from the existing code, this simple-mfd.c wouldn't just be
> "a list of compatible" strings but also additional quirks and tweaks
> for particular devices in this list.

Hold off on the simple-mfd.c idea, as I'm not taken by it yet and
wouldn't want you to waste your time.  I have another idea which would
help.  Give me a few days to put something together.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-10  7:19                                   ` Lee Jones
@ 2020-06-10  7:49                                     ` Michael Walle
  2020-06-10  7:56                                       ` Lee Jones
  2020-06-10 17:16                                     ` Rob Herring
  1 sibling, 1 reply; 74+ messages in thread
From: Michael Walle @ 2020-06-10  7:49 UTC (permalink / raw)
  To: Lee Jones
  Cc: Andy Shevchenko, Ranjani Sridharan, david.m.ertman,
	shiraz.saleem, Rob Herring, Mark Brown, open list:GPIO SUBSYSTEM,
	devicetree, Linux Kernel Mailing List, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm Mailing List, Linus Walleij,
	Bartosz Golaszewski, Jean Delvare, Guenter Roeck, Thierry Reding,
	Uwe Kleine-König, Wim Van Sebroeck, Shawn Guo, Li Yang,
	Thomas Gleixner, Jason Cooper, Marc Zyngier, Greg Kroah-Hartman,
	Andy Shevchenko

Am 2020-06-10 09:19, schrieb Lee Jones:
> On Wed, 10 Jun 2020, Michael Walle wrote:
>> Am 2020-06-09 21:45, schrieb Lee Jones:
>> > On Tue, 09 Jun 2020, Michael Walle wrote:
>> > > > We do not need a 'simple-regmap' solution for your use-case.
>> > > >
>> > > > Since your device's registers are segregated, just split up the
>> > > > register map and allocate each sub-device with it's own slice.
>> > >
>> > > I don't get it, could you make a device tree example for my
>> > > use-case? (see also above)
>> >
>> >     &i2cbus {
>> >         mfd-device@10 {
>> >             compatible = "simple-mfd";
>> >             reg = <10>;
>> >
>> >             sub-device@10 {
>> >                 compatible = "vendor,sub-device";
>> >                 reg = <10>;
>> >             };
>> >    };
>> >
>> > The Regmap config would be present in each of the child devices.
>> >
>> > Each child device would call devm_regmap_init_i2c() in .probe().
>> 
>> Ah, I see. If I'm not wrong, this still means to create an i2c
>> device driver with the name "simple-mfd".
> 
> Yes, it does.
> 
>> Besides that, I don't like this, because:
>>  - Rob already expressed its concerns with "simple-mfd" and so on.
> 
> Where did this take place?  I'd like to read up on this.

In this thread:
https://lore.kernel.org/linux-devicetree/20200604211039.12689-1-michael@walle.cc/T/#m16fdba5962069e7cd4aa817582ee358c9fe2ecbf

> 
>>  - you need to duplicate the config in each sub device
> 
> You can have a share a single config.
> 
>>  - which also means you are restricting the sub devices to be
>>    i2c only (unless you implement and duplicate other regmap configs,
>>    too). For this driver, SPI and MMIO may be viable options.
> 
> You could also have a shared implementation to choose between different
> busses.

Then what is the difference between to have this shared config in the
parent driver only and use the functions which are already there, i.e.
dev_get_regmap(parent). But see, below, I'll wait with what you're
coming up.

> 
>> Thus, I'd rather implement a simple-mfd.c which implement a common
>> I2C driver for now and populate its children using
>> devm_of_platform_populate(). This could be extended to support other
>> type of regmaps like SPI in the future.
>> 
>> Also some MFD drivers could be moved to this, a likely candidate is
>> the smsc-ece1099.c. Although I don't really understand its purpose,
>> if don't have CONFIG_OF.
>> 
>> Judging from the existing code, this simple-mfd.c wouldn't just be
>> "a list of compatible" strings but also additional quirks and tweaks
>> for particular devices in this list.
> 
> Hold off on the simple-mfd.c idea, as I'm not taken by it yet and
> wouldn't want you to waste your time.  I have another idea which would
> help.  Give me a few days to put something together.

Sure. I'm just glad there is now a discussion about this issue.

-michael

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-10  7:49                                     ` Michael Walle
@ 2020-06-10  7:56                                       ` Lee Jones
  2020-06-10  9:27                                         ` Michael Walle
  0 siblings, 1 reply; 74+ messages in thread
From: Lee Jones @ 2020-06-10  7:56 UTC (permalink / raw)
  To: Michael Walle
  Cc: Andy Shevchenko, Ranjani Sridharan, david.m.ertman,
	shiraz.saleem, Rob Herring, Mark Brown, open list:GPIO SUBSYSTEM,
	devicetree, Linux Kernel Mailing List, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm Mailing List, Linus Walleij,
	Bartosz Golaszewski, Jean Delvare, Guenter Roeck, Thierry Reding,
	Uwe Kleine-König, Wim Van Sebroeck, Shawn Guo, Li Yang,
	Thomas Gleixner, Jason Cooper, Marc Zyngier, Greg Kroah-Hartman,
	Andy Shevchenko

On Wed, 10 Jun 2020, Michael Walle wrote:

> Am 2020-06-10 09:19, schrieb Lee Jones:
> > On Wed, 10 Jun 2020, Michael Walle wrote:
> > > Am 2020-06-09 21:45, schrieb Lee Jones:
> > > > On Tue, 09 Jun 2020, Michael Walle wrote:
> > > > > > We do not need a 'simple-regmap' solution for your use-case.
> > > > > >
> > > > > > Since your device's registers are segregated, just split up the
> > > > > > register map and allocate each sub-device with it's own slice.
> > > > >
> > > > > I don't get it, could you make a device tree example for my
> > > > > use-case? (see also above)
> > > >
> > > >     &i2cbus {
> > > >         mfd-device@10 {
> > > >             compatible = "simple-mfd";
> > > >             reg = <10>;
> > > >
> > > >             sub-device@10 {
> > > >                 compatible = "vendor,sub-device";
> > > >                 reg = <10>;
> > > >             };
> > > >    };
> > > >
> > > > The Regmap config would be present in each of the child devices.
> > > >
> > > > Each child device would call devm_regmap_init_i2c() in .probe().
> > > 
> > > Ah, I see. If I'm not wrong, this still means to create an i2c
> > > device driver with the name "simple-mfd".
> > 
> > Yes, it does.
> > 
> > > Besides that, I don't like this, because:
> > >  - Rob already expressed its concerns with "simple-mfd" and so on.
> > 
> > Where did this take place?  I'd like to read up on this.
> 
> In this thread:
> https://lore.kernel.org/linux-devicetree/20200604211039.12689-1-michael@walle.cc/T/#m16fdba5962069e7cd4aa817582ee358c9fe2ecbf
> 
> > 
> > >  - you need to duplicate the config in each sub device
> > 
> > You can have a share a single config.
> > 
> > >  - which also means you are restricting the sub devices to be
> > >    i2c only (unless you implement and duplicate other regmap configs,
> > >    too). For this driver, SPI and MMIO may be viable options.
> > 
> > You could also have a shared implementation to choose between different
> > busses.
> 
> Then what is the difference between to have this shared config in the
> parent driver only and use the functions which are already there, i.e.
> dev_get_regmap(parent). But see, below, I'll wait with what you're
> coming up.

The difference is the omission of an otherwise pointless/superfluous
driver.  Actually, it's the difference between the omission of 10
pointless drivers!

> > > Thus, I'd rather implement a simple-mfd.c which implement a common
> > > I2C driver for now and populate its children using
> > > devm_of_platform_populate(). This could be extended to support other
> > > type of regmaps like SPI in the future.
> > > 
> > > Also some MFD drivers could be moved to this, a likely candidate is
> > > the smsc-ece1099.c. Although I don't really understand its purpose,
> > > if don't have CONFIG_OF.
> > > 
> > > Judging from the existing code, this simple-mfd.c wouldn't just be
> > > "a list of compatible" strings but also additional quirks and tweaks
> > > for particular devices in this list.
> > 
> > Hold off on the simple-mfd.c idea, as I'm not taken by it yet and
> > wouldn't want you to waste your time.  I have another idea which would
> > help.  Give me a few days to put something together.
> 
> Sure. I'm just glad there is now a discussion about this issue.

It's very much in my mind.

I've been meaning to do something about it for quite some time.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-10  7:56                                       ` Lee Jones
@ 2020-06-10  9:27                                         ` Michael Walle
  2020-06-10 18:30                                           ` Lee Jones
  0 siblings, 1 reply; 74+ messages in thread
From: Michael Walle @ 2020-06-10  9:27 UTC (permalink / raw)
  To: Lee Jones
  Cc: Andy Shevchenko, Ranjani Sridharan, david.m.ertman,
	shiraz.saleem, Rob Herring, Mark Brown, open list:GPIO SUBSYSTEM,
	devicetree, Linux Kernel Mailing List, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm Mailing List, Linus Walleij,
	Bartosz Golaszewski, Jean Delvare, Guenter Roeck, Thierry Reding,
	Uwe Kleine-König, Wim Van Sebroeck, Shawn Guo, Li Yang,
	Thomas Gleixner, Jason Cooper, Marc Zyngier, Greg Kroah-Hartman,
	Andy Shevchenko

Am 2020-06-10 09:56, schrieb Lee Jones:
> On Wed, 10 Jun 2020, Michael Walle wrote:
> 
>> Am 2020-06-10 09:19, schrieb Lee Jones:
>> > On Wed, 10 Jun 2020, Michael Walle wrote:
>> > > Am 2020-06-09 21:45, schrieb Lee Jones:
>> > > > On Tue, 09 Jun 2020, Michael Walle wrote:
>> > > > > > We do not need a 'simple-regmap' solution for your use-case.
>> > > > > >
>> > > > > > Since your device's registers are segregated, just split up the
>> > > > > > register map and allocate each sub-device with it's own slice.
>> > > > >
>> > > > > I don't get it, could you make a device tree example for my
>> > > > > use-case? (see also above)
>> > > >
>> > > >     &i2cbus {
>> > > >         mfd-device@10 {
>> > > >             compatible = "simple-mfd";
>> > > >             reg = <10>;
>> > > >
>> > > >             sub-device@10 {
>> > > >                 compatible = "vendor,sub-device";
>> > > >                 reg = <10>;
>> > > >             };
>> > > >    };
>> > > >
>> > > > The Regmap config would be present in each of the child devices.
>> > > >
>> > > > Each child device would call devm_regmap_init_i2c() in .probe().
>> > >
>> > > Ah, I see. If I'm not wrong, this still means to create an i2c
>> > > device driver with the name "simple-mfd".
>> >
>> > Yes, it does.
>> >
>> > > Besides that, I don't like this, because:
>> > >  - Rob already expressed its concerns with "simple-mfd" and so on.
>> >
>> > Where did this take place?  I'd like to read up on this.
>> 
>> In this thread:
>> https://lore.kernel.org/linux-devicetree/20200604211039.12689-1-michael@walle.cc/T/#m16fdba5962069e7cd4aa817582ee358c9fe2ecbf
>> 
>> >
>> > >  - you need to duplicate the config in each sub device
>> >
>> > You can have a share a single config.
>> >
>> > >  - which also means you are restricting the sub devices to be
>> > >    i2c only (unless you implement and duplicate other regmap configs,
>> > >    too). For this driver, SPI and MMIO may be viable options.
>> >
>> > You could also have a shared implementation to choose between different
>> > busses.
>> 
>> Then what is the difference between to have this shared config in the
>> parent driver only and use the functions which are already there, i.e.
>> dev_get_regmap(parent). But see, below, I'll wait with what you're
>> coming up.
> 
> The difference is the omission of an otherwise pointless/superfluous
> driver.  Actually, it's the difference between the omission of 10
> pointless drivers!

If you want to omit anything generic in the device tree - and as far as
I understand it - that should be the way to go, the specific compatible
string of the parent device has to go somewhere. Thus I'd appreciate
a consolidated (MFD) driver which holds all these, as you say it
pointless drivers. Because IMHO they are not pointless, rather they are
the actual drivers for the MFD. Its sub nodes are just an implementation
detail to be able to use the OF bindings (like your clock example or
a phandle to a PWM controller). Just because it is almost nothing there
except the regmap instantiation doesn't mean it is not a valid MFD 
driver.
And there is also additional stuff, like clock enable, version checks, 
etc.

-michael

>> > > Thus, I'd rather implement a simple-mfd.c which implement a common
>> > > I2C driver for now and populate its children using
>> > > devm_of_platform_populate(). This could be extended to support other
>> > > type of regmaps like SPI in the future.
>> > >
>> > > Also some MFD drivers could be moved to this, a likely candidate is
>> > > the smsc-ece1099.c. Although I don't really understand its purpose,
>> > > if don't have CONFIG_OF.
>> > >
>> > > Judging from the existing code, this simple-mfd.c wouldn't just be
>> > > "a list of compatible" strings but also additional quirks and tweaks
>> > > for particular devices in this list.
>> >
>> > Hold off on the simple-mfd.c idea, as I'm not taken by it yet and
>> > wouldn't want you to waste your time.  I have another idea which would
>> > help.  Give me a few days to put something together.
>> 
>> Sure. I'm just glad there is now a discussion about this issue.
> 
> It's very much in my mind.
> 
> I've been meaning to do something about it for quite some time.

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-10  7:19                                   ` Lee Jones
  2020-06-10  7:49                                     ` Michael Walle
@ 2020-06-10 17:16                                     ` Rob Herring
  2020-06-10 18:02                                       ` Lee Jones
  1 sibling, 1 reply; 74+ messages in thread
From: Rob Herring @ 2020-06-10 17:16 UTC (permalink / raw)
  To: Lee Jones
  Cc: Michael Walle, Andy Shevchenko, Ranjani Sridharan,
	david.m.ertman, shiraz.saleem, Mark Brown,
	open list:GPIO SUBSYSTEM, devicetree, Linux Kernel Mailing List,
	Linux HWMON List, Linux PWM List, LINUX-WATCHDOG,
	linux-arm Mailing List, Linus Walleij, Bartosz Golaszewski,
	Jean Delvare, Guenter Roeck, Thierry Reding,
	Uwe Kleine-König, Wim Van Sebroeck, Shawn Guo, Li Yang,
	Thomas Gleixner, Jason Cooper, Marc Zyngier, Greg Kroah-Hartman,
	Andy Shevchenko

On Wed, Jun 10, 2020 at 1:19 AM Lee Jones <lee.jones@linaro.org> wrote:
>
> On Wed, 10 Jun 2020, Michael Walle wrote:
> > Am 2020-06-09 21:45, schrieb Lee Jones:
> > > On Tue, 09 Jun 2020, Michael Walle wrote:
> > > > > We do not need a 'simple-regmap' solution for your use-case.
> > > > >
> > > > > Since your device's registers are segregated, just split up the
> > > > > register map and allocate each sub-device with it's own slice.
> > > >
> > > > I don't get it, could you make a device tree example for my
> > > > use-case? (see also above)
> > >
> > >     &i2cbus {
> > >         mfd-device@10 {
> > >             compatible = "simple-mfd";
> > >             reg = <10>;
> > >
> > >             sub-device@10 {
> > >                 compatible = "vendor,sub-device";
> > >                 reg = <10>;
> > >             };
> > >    };
> > >
> > > The Regmap config would be present in each of the child devices.
> > >
> > > Each child device would call devm_regmap_init_i2c() in .probe().
> >
> > Ah, I see. If I'm not wrong, this still means to create an i2c
> > device driver with the name "simple-mfd".
>
> Yes, it does.

TBC, while fine for a driver to bind on 'simple-mfd', a DT compatible
with that alone is not fine.

> > Besides that, I don't like this, because:
> >  - Rob already expressed its concerns with "simple-mfd" and so on.
>
> Where did this take place?  I'd like to read up on this.
>
> >  - you need to duplicate the config in each sub device
>
> You can have a share a single config.
>
> >  - which also means you are restricting the sub devices to be
> >    i2c only (unless you implement and duplicate other regmap configs,
> >    too). For this driver, SPI and MMIO may be viable options.
>
> You could also have a shared implementation to choose between different
> busses.

I think it is really the syscon mfd driver you want to generalize to
other buses. Though with a quick look at it, there's not really a
whole lot to share. The regmap lookup would be the main thing. You are
going to need a driver instance for each bus type.

> > Thus, I'd rather implement a simple-mfd.c which implement a common
> > I2C driver for now and populate its children using
> > devm_of_platform_populate(). This could be extended to support other
> > type of regmaps like SPI in the future.
> >
> > Also some MFD drivers could be moved to this, a likely candidate is
> > the smsc-ece1099.c. Although I don't really understand its purpose,
> > if don't have CONFIG_OF.
> >
> > Judging from the existing code, this simple-mfd.c wouldn't just be
> > "a list of compatible" strings but also additional quirks and tweaks
> > for particular devices in this list.

Yes, this is why specific compatible strings are required.

> Hold off on the simple-mfd.c idea, as I'm not taken by it yet and
> wouldn't want you to waste your time.  I have another idea which would
> help.  Give me a few days to put something together.
>
> --
> Lee Jones [李琼斯]
> Senior Technical Lead - Developer Services
> Linaro.org │ Open source software for Arm SoCs
> Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-10 17:16                                     ` Rob Herring
@ 2020-06-10 18:02                                       ` Lee Jones
  0 siblings, 0 replies; 74+ messages in thread
From: Lee Jones @ 2020-06-10 18:02 UTC (permalink / raw)
  To: Rob Herring
  Cc: Michael Walle, Andy Shevchenko, Ranjani Sridharan,
	david.m.ertman, shiraz.saleem, Mark Brown,
	open list:GPIO SUBSYSTEM, devicetree, Linux Kernel Mailing List,
	Linux HWMON List, Linux PWM List, LINUX-WATCHDOG,
	linux-arm Mailing List, Linus Walleij, Bartosz Golaszewski,
	Jean Delvare, Guenter Roeck, Thierry Reding,
	Uwe Kleine-König, Wim Van Sebroeck, Shawn Guo, Li Yang,
	Thomas Gleixner, Jason Cooper, Marc Zyngier, Greg Kroah-Hartman,
	Andy Shevchenko

On Wed, 10 Jun 2020, Rob Herring wrote:

> On Wed, Jun 10, 2020 at 1:19 AM Lee Jones <lee.jones@linaro.org> wrote:
> >
> > On Wed, 10 Jun 2020, Michael Walle wrote:
> > > Am 2020-06-09 21:45, schrieb Lee Jones:
> > > > On Tue, 09 Jun 2020, Michael Walle wrote:
> > > > > > We do not need a 'simple-regmap' solution for your use-case.
> > > > > >
> > > > > > Since your device's registers are segregated, just split up the
> > > > > > register map and allocate each sub-device with it's own slice.
> > > > >
> > > > > I don't get it, could you make a device tree example for my
> > > > > use-case? (see also above)
> > > >
> > > >     &i2cbus {
> > > >         mfd-device@10 {
> > > >             compatible = "simple-mfd";
> > > >             reg = <10>;
> > > >
> > > >             sub-device@10 {
> > > >                 compatible = "vendor,sub-device";
> > > >                 reg = <10>;
> > > >             };
> > > >    };
> > > >
> > > > The Regmap config would be present in each of the child devices.
> > > >
> > > > Each child device would call devm_regmap_init_i2c() in .probe().
> > >
> > > Ah, I see. If I'm not wrong, this still means to create an i2c
> > > device driver with the name "simple-mfd".
> >
> > Yes, it does.
> 
> TBC, while fine for a driver to bind on 'simple-mfd', a DT compatible
> with that alone is not fine.

'simple-mfd' essentially means:

  "This device doesn't do anything useful, but the children do."

When used with 'syscon' it means:

  "Memory for this device is shared between all children"

Adding more specific/descriptive compatible strings is conceptually
fine, but they should not be forced to bind to a real driver using
them.  Else we're creating drivers for the sake of creating drivers.

This is especially true with 'simple-mfd' is used without 'syscon'.

> > > Besides that, I don't like this, because:
> > >  - Rob already expressed its concerns with "simple-mfd" and so on.
> >
> > Where did this take place?  I'd like to read up on this.
> >
> > >  - you need to duplicate the config in each sub device
> >
> > You can have a share a single config.
> >
> > >  - which also means you are restricting the sub devices to be
> > >    i2c only (unless you implement and duplicate other regmap configs,
> > >    too). For this driver, SPI and MMIO may be viable options.
> >
> > You could also have a shared implementation to choose between different
> > busses.
> 
> I think it is really the syscon mfd driver you want to generalize to
> other buses. Though with a quick look at it, there's not really a
> whole lot to share. The regmap lookup would be the main thing. You are
> going to need a driver instance for each bus type.

On it.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply	[flat|nested] 74+ messages in thread

* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
  2020-06-10  9:27                                         ` Michael Walle
@ 2020-06-10 18:30                                           ` Lee Jones
  0 siblings, 0 replies; 74+ messages in thread
From: Lee Jones @ 2020-06-10 18:30 UTC (permalink / raw)
  To: Michael Walle
  Cc: Andy Shevchenko, Ranjani Sridharan, david.m.ertman,
	shiraz.saleem, Rob Herring, Mark Brown, open list:GPIO SUBSYSTEM,
	devicetree, Linux Kernel Mailing List, linux-hwmon, linux-pwm,
	linux-watchdog, linux-arm Mailing List, Linus Walleij,
	Bartosz Golaszewski, Jean Delvare, Guenter Roeck, Thierry Reding,
	Uwe Kleine-König, Wim Van Sebroeck, Shawn Guo, Li Yang,
	Thomas Gleixner, Jason Cooper, Marc Zyngier, Greg Kroah-Hartman,
	Andy Shevchenko

On Wed, 10 Jun 2020, Michael Walle wrote:

> Am 2020-06-10 09:56, schrieb Lee Jones:
> > On Wed, 10 Jun 2020, Michael Walle wrote:
> > 
> > > Am 2020-06-10 09:19, schrieb Lee Jones:
> > > > On Wed, 10 Jun 2020, Michael Walle wrote:
> > > > > Am 2020-06-09 21:45, schrieb Lee Jones:
> > > > > > On Tue, 09 Jun 2020, Michael Walle wrote:
> > > > > > > > We do not need a 'simple-regmap' solution for your use-case.
> > > > > > > >
> > > > > > > > Since your device's registers are segregated, just split up the
> > > > > > > > register map and allocate each sub-device with it's own slice.
> > > > > > >
> > > > > > > I don't get it, could you make a device tree example for my
> > > > > > > use-case? (see also above)
> > > > > >
> > > > > >     &i2cbus {
> > > > > >         mfd-device@10 {
> > > > > >             compatible = "simple-mfd";
> > > > > >             reg = <10>;
> > > > > >
> > > > > >             sub-device@10 {
> > > > > >                 compatible = "vendor,sub-device";
> > > > > >                 reg = <10>;
> > > > > >             };
> > > > > >    };
> > > > > >
> > > > > > The Regmap config would be present in each of the child devices.
> > > > > >
> > > > > > Each child device would call devm_regmap_init_i2c() in .probe().
> > > > >
> > > > > Ah, I see. If I'm not wrong, this still means to create an i2c
> > > > > device driver with the name "simple-mfd".
> > > >
> > > > Yes, it does.
> > > >
> > > > > Besides that, I don't like this, because:
> > > > >  - Rob already expressed its concerns with "simple-mfd" and so on.
> > > >
> > > > Where did this take place?  I'd like to read up on this.
> > > 
> > > In this thread:
> > > https://lore.kernel.org/linux-devicetree/20200604211039.12689-1-michael@walle.cc/T/#m16fdba5962069e7cd4aa817582ee358c9fe2ecbf
> > > 
> > > >
> > > > >  - you need to duplicate the config in each sub device
> > > >
> > > > You can have a share a single config.
> > > >
> > > > >  - which also means you are restricting the sub devices to be
> > > > >    i2c only (unless you implement and duplicate other regmap configs,
> > > > >    too). For this driver, SPI and MMIO may be viable options.
> > > >
> > > > You could also have a shared implementation to choose between different
> > > > busses.
> > > 
> > > Then what is the difference between to have this shared config in the
> > > parent driver only and use the functions which are already there, i.e.
> > > dev_get_regmap(parent). But see, below, I'll wait with what you're
> > > coming up.
> > 
> > The difference is the omission of an otherwise pointless/superfluous
> > driver.  Actually, it's the difference between the omission of 10
> > pointless drivers!
> 
> If you want to omit anything generic in the device tree - and as far as
> I understand it - that should be the way to go, the specific compatible
> string of the parent device has to go somewhere. Thus I'd appreciate
> a consolidated (MFD) driver which holds all these, as you say it
> pointless drivers.
> Because IMHO they are not pointless, rather they are
> the actual drivers for the MFD. Its sub nodes are just an implementation
> detail to be able to use the OF bindings
> (like your clock example or
> a phandle to a PWM controller). Just because it is almost nothing there
> except the regmap instantiation doesn't mean it is not a valid MFD driver.

A valid MFD driver is whatever we (the Linux community at large)
define it to be.  An MFD is not a real thing.  We made it up.  It's
MFD which is the implementation detail, not the child devices.  If a
driver a) does very little, and b) the very little it does do can be
resolved in a different way, is not a valid driver.  It's a waste of
disk space.

> And there is also additional stuff, like clock enable, version checks, etc.

As more functionality is added *then* we can justify a driver.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply	[flat|nested] 74+ messages in thread

end of thread, other threads:[~2020-06-10 18:31 UTC | newest]

Thread overview: 74+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-04 21:10 [PATCH v4 00/11] Add support for Kontron sl28cpld Michael Walle
2020-06-04 21:10 ` [PATCH v4 01/11] dt-bindings: mfd: Add bindings for sl28cpld Michael Walle
2020-06-09 16:28   ` Rob Herring
2020-06-04 21:10 ` [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller Michael Walle
2020-06-05  6:57   ` Lee Jones
2020-06-05  9:51     ` Michael Walle
2020-06-05 10:50     ` Mark Brown
2020-06-05 20:07       ` Michael Walle
2020-06-06 11:46         ` Mark Brown
2020-06-06 12:45           ` Michael Walle
2020-06-08  8:28             ` Lee Jones
2020-06-08 10:02               ` Andy Shevchenko
2020-06-08 15:41                 ` Michael Walle
2020-06-08 18:56                   ` Lee Jones
2020-06-08 21:09                     ` Michael Walle
2020-06-09  6:47                       ` Lee Jones
2020-06-09 14:38                         ` Michael Walle
2020-06-09 14:42                           ` Mark Brown
2020-06-09 15:01                             ` Michael Walle
2020-06-09 17:15                               ` Rob Herring
2020-06-09 17:29                                 ` Mark Brown
2020-06-09 18:41                                 ` Lee Jones
2020-06-09 15:19                           ` Lee Jones
2020-06-09 15:30                             ` Michael Walle
2020-06-09 19:45                               ` Lee Jones
2020-06-10  7:10                                 ` Michael Walle
2020-06-10  7:19                                   ` Lee Jones
2020-06-10  7:49                                     ` Michael Walle
2020-06-10  7:56                                       ` Lee Jones
2020-06-10  9:27                                         ` Michael Walle
2020-06-10 18:30                                           ` Lee Jones
2020-06-10 17:16                                     ` Rob Herring
2020-06-10 18:02                                       ` Lee Jones
2020-06-08 18:20                 ` Lee Jones
2020-06-09 16:54               ` Rob Herring
2020-06-09 18:52                 ` Lee Jones
2020-06-05  8:01   ` Andy Shevchenko
2020-06-05  8:02     ` Andy Shevchenko
2020-06-05 10:09     ` Michael Walle
2020-06-05 10:48       ` Andy Shevchenko
2020-06-05 11:51         ` Michael Walle
2020-06-04 21:10 ` [PATCH v4 03/11] irqchip: add sl28cpld interrupt controller support Michael Walle
2020-06-05  1:26   ` kernel test robot
2020-06-05  8:07   ` Andy Shevchenko
2020-06-08 15:12   ` kernel test robot
2020-06-04 21:10 ` [PATCH v4 04/11] watchdog: add support for sl28cpld watchdog Michael Walle
2020-06-05  8:14   ` Andy Shevchenko
2020-06-05 10:24     ` Michael Walle
2020-06-05 10:50       ` Andy Shevchenko
2020-06-05 13:52         ` Guenter Roeck
2020-06-05 14:09           ` Andy Shevchenko
2020-06-05 15:05             ` Guenter Roeck
2020-06-05 16:04               ` Andy Shevchenko
2020-06-05 16:34                 ` Guenter Roeck
2020-06-04 21:10 ` [PATCH v4 05/11] pwm: add support for sl28cpld PWM controller Michael Walle
2020-06-05  8:15   ` Andy Shevchenko
2020-06-05  8:49   ` Lee Jones
2020-06-05  9:33     ` Andy Shevchenko
2020-06-05 11:39     ` Michael Walle
2020-06-05 18:17     ` Michael Walle
2020-06-08  7:46       ` Lee Jones
2020-06-04 21:10 ` [PATCH v4 06/11] gpio: add support for the sl28cpld GPIO controller Michael Walle
2020-06-05 12:00   ` Andy Shevchenko
2020-06-05 12:42     ` Michael Walle
2020-06-05 13:15       ` Andy Shevchenko
2020-06-05 18:44         ` Michael Walle
2020-06-05 21:19           ` Andy Shevchenko
2020-06-04 21:10 ` [PATCH v4 07/11] hwmon: add support for the sl28cpld hardware monitoring controller Michael Walle
2020-06-05 12:06   ` Andy Shevchenko
2020-06-04 21:10 ` [PATCH v4 08/11] arm64: dts: freescale: sl28: enable sl28cpld Michael Walle
2020-06-04 21:10 ` [PATCH v4 09/11] arm64: dts: freescale: sl28: map GPIOs to input events Michael Walle
2020-06-04 21:10 ` [PATCH v4 10/11] arm64: dts: freescale: sl28: enable LED support Michael Walle
2020-06-04 21:10 ` [PATCH v4 11/11] arm64: dts: freescale: sl28: enable fan support Michael Walle
2020-06-05  6:13 ` [PATCH v4 00/11] Add support for Kontron sl28cpld Lee Jones

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).