drivers: mfd: Add support for Moxtet bus
PATCH 1/2 drivers: mfd: Add support for Moxtet bus
On the Turris Mox router there can be connected different modules to the main CPU board, currently a module with a SFP cage, a module with MiniPCIe connector, a 4-port switch module and a 8-port switch module, for example:
[CPU]-[PCIe]-[8-port switch]-[8-port switch]-[SFP]
Each of this modules has an input and output shift register, and these are connected via SPI to CPU board.
Via this SPI connection we are able to discover which modules are connected and we can also read/write some configuration to the modules. Fromi/to each module 8 bits can be read (of which lower 4 bits identify the module) and written.
For example from the module with a SFP cage we can read the LOS, TX-FAULT and MOD-DEF0 signals, while we can write TX-DISABLE and RATE-SELECT signals.
Other modules may support something else.
This driver creates a new bus type, called "moxtet". For each Mox module it finds via SPI, it creates a new device on the moxtet bus so that drivers can be written for them, for example a gpio driver for the module with a SFP cage.
The topology of how Mox modules are connected can then be read by listing /sys/bus/moxtet/devices.
--- Documentation/devicetree/bindings/mfd/moxtet.txt | 36 ++ MAINTAINERS | 7 + drivers/mfd/Kconfig | 10 + drivers/mfd/Makefile | 1 + drivers/mfd/moxtet.c | 501 +++++++++++++++++++++++ include/linux/mfd/moxtet.h | 103 +++++ 6 files changed, 658 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/moxtet.txt create mode 100644 drivers/mfd/moxtet.c create mode 100644 include/linux/mfd/moxtet.h
Documentation/devicetree/bindings/mfd/moxtet.txt new file +36 -0
@@ -0,0 +1,36 @@ +Turris Mox module configuration bus (over SPI) + +Required properties: + - compatible : Should be "cznic,moxtet". + - #address-cells : Has to be 1 + - #size-cells : Has to be 0 +For other required and optional properties of SPI slave +nodes please refer to ../spi/spi-bus.txt. + +Required properties of subnodes: + - reg : Should be position on the Moxtet bus + - moxtet,id : Should be ID of the Moxtet device connected + +The driver finds the devices connected to the bus by itself, but it may be +needed to reference some of them from other parts of the device tree. In that +case the devices can be defined as subnodes of the moxtet node. + +Example: + + moxtet@1 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "cznic,moxtet"; + reg = <1>; + spi-max-frequency = <1000000>; + spi-cpol; + spi-cpha; + + moxtet_sfp: moxtet-sfp@0 { + compatible = "cznic,moxtet-sfp"; + gpio-controller; + #gpio-cells; + reg = <0>; + moxtet,id = <1>; + } + };
MAINTAINERS +7 -0
@@ -1412,6 +1412,13 @@ F: drivers/clocksource/timer-prima2.c F: drivers/clocksource/timer-atlas7.c N: [^a-z]sirf +ARM/CZ.NIC TURRIS MOX SUPPORT +M: Marek Behun <[email protected]> +W: http://mox.turris.cz +S: Maintained +F: include/mfd/moxtet.h +F: drivers/mfd/moxtet.c + ARM/EBSA110 MACHINE SUPPORT M: Russell King <[email protected]> L: [email protected] (moderated for non-subscribers)
drivers/mfd/Kconfig +10 -0
@@ -814,6 +814,16 @@ config MFD_MAX8998 additional drivers must be enabled in order to use the functionality of the device. +config MFD_MOXTET + tristate "CZ.NIC Turris Mox module configuration bus" + depends on SPI_MASTER && OF + help + Say yes here to add support for the module configuration bus found + on CZ.NIC's Turris Mox. This is needed for the ability to read + in what order the modules are connected and to get/set some of + their settings. For example the GPIOs on Mox SFP module are + configured through this bus. + config MFD_MT6397 tristate "MediaTek MT6397 PMIC Support" select MFD_CORE
drivers/mfd/Makefile +1 -0
@@ -159,6 +159,7 @@ max8925-objs := max8925-core.o max8925-i2c.o obj-$(CONFIG_MFD_MAX8925) += max8925.o obj-$(CONFIG_MFD_MAX8997) += max8997.o max8997-irq.o obj-$(CONFIG_MFD_MAX8998) += max8998.o max8998-irq.o +obj-$(CONFIG_MFD_MOXTET) += moxtet.o pcf50633-objs := pcf50633-core.o pcf50633-irq.o obj-$(CONFIG_MFD_PCF50633) += pcf50633.o
drivers/mfd/moxtet.c new file +501 -0
501 lines not on this page · raw message
include/linux/mfd/moxtet.h new file +103 -0
103 lines not on this page · raw message
Signature · 1 line
2.16.4
PATCH 2/2 drivers: gpio: Add support for GPIOs over Moxtet bus
This adds support for interpreting the input and output bits of one device on Moxtet bus as GPIOs.
This is needed for example by the SFP cage module of Turris Mox.
--- .../devicetree/bindings/gpio/gpio-moxtet.txt | 31 +++ MAINTAINERS | 1 + drivers/gpio/Kconfig | 9 + drivers/gpio/Makefile | 1 + drivers/gpio/gpio-moxtet.c | 209 +++++++++++++++++++++ 5 files changed, 251 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-moxtet.txt create mode 100644 drivers/gpio/gpio-moxtet.c
Documentation/devicetree/bindings/gpio/gpio-moxtet.txt new file +31 -0
@@ -0,0 +1,31 @@ +Turris Mox Moxtet GPIO expander + +Required properties: + - compatible : Should be "cznic,moxtet-gpio". + - gpio-controller : Marks the device node as a GPIO controller. + - #gpio-cells : Should be two. For consumer use see gpio.txt. + - moxtet,input-mask : Bitmask. Those bits which correspond to input GPIOs + when read from Moxtet bus should be set here. + For example if bit 0 and bit 3 are input GPIO bits, + this should be set to 0x9. + Since there are only 4 input bits, 0xf is max value. + - moxtet,output-mask : Bitmask. Those bits which correspond to output GPIOs + when written to Moxtet bus should be set here. + For example if bit 1 and bit 6 are output GPIO bits, + this should be set to 0x41. + Since there are at most 8 output bits, 0xff is max + value. +Other properties are required for a moxtet bus device, please refer to +Documentation/devicetree/bindings/mfd/moxtet.txt. + +Example: + + moxtet_sfp: moxtet-sfp@0 { + compatible = "cznic,moxtet-gpio"; + gpio-controller; + #gpio-cells; + reg = <0>; + moxtet,id = <1>; + moxtet,input-mask = <0x7>; + moxtet,output-mask = <0x3>; + }
MAINTAINERS +1 -0
@@ -1417,6 +1417,7 @@ M: Marek Behun <[email protected]> W: http://mox.turris.cz S: Maintained F: include/mfd/moxtet.h +F: drivers/gpio/gpio-moxtet.c F: drivers/mfd/moxtet.c ARM/EBSA110 MACHINE SUPPORT
drivers/gpio/Kconfig +9 -0
@@ -1055,6 +1055,15 @@ config GPIO_MAX77620 driver also provides interrupt support for each of the gpios. Say yes here to enable the max77620 to be used as gpio controller. +config GPIO_MOXTET + tristate "Turris Mox Moxtet bus GPIO expander" + depends on MFD_MOXTET + help + Say yes here if you are building for the Turris Mox router. + This is the driver needed for configuring the GPIOs via the Moxtet + bus. For example the Mox module with SFP cage needs this driver + so that phylink can use corresponding GPIOs. + config GPIO_MSIC bool "Intel MSIC mixed signal gpio support" depends on (X86 || COMPILE_TEST) && MFD_INTEL_MSIC
drivers/gpio/Makefile +1 -0
@@ -85,6 +85,7 @@ obj-$(CONFIG_GPIO_MC9S08DZ60) += gpio-mc9s08dz60.o obj-$(CONFIG_GPIO_ML_IOH) += gpio-ml-ioh.o obj-$(CONFIG_GPIO_MM_LANTIQ) += gpio-mm-lantiq.o obj-$(CONFIG_GPIO_MOCKUP) += gpio-mockup.o +obj-$(CONFIG_GPIO_MOXTET) += gpio-moxtet.o obj-$(CONFIG_GPIO_MPC5200) += gpio-mpc5200.o obj-$(CONFIG_GPIO_MPC8XXX) += gpio-mpc8xxx.o obj-$(CONFIG_GPIO_MSIC) += gpio-msic.o
drivers/gpio/gpio-moxtet.c new file +209 -0
209 lines not on this page · raw message
Signature · 1 line
2.16.4
Re: [PATCH mfd+gpio 2/2] drivers: gpio: Add support for GPIOs over Moxtet bus
Hi Marek!
Your DT bindings patch should ideally be in a separate patch and must be sent to [email protected] as well.
Documentation/devicetree/bindings/gpio/gpio-moxtet.txt line 17
Quoted 11 lines · Marek Behún
+ - moxtet,input-mask : Bitmask. Those bits which correspond to input GPIOs
Documentation/devicetree/bindings/gpio/gpio-moxtet.txt new file +10
-0+ when read from Moxtet bus should be set here. + For example if bit 0 and bit 3 are input GPIO bits, + this should be set to 0x9. + Since there are only 4 input bits, 0xf is max value. + - moxtet,output-mask : Bitmask. Those bits which correspond to output GPIOs + when written to Moxtet bus should be set here. + For example if bit 1 and bit 6 are output GPIO bits, + this should be set to 0x41. + Since there are at most 8 output bits, 0xff is max + value.
Please don't do it like this. Let the consumers decide if they want to use a certain line as input or output.
Enumerate ALL GPIOs from 0 to N and let a consumer pick GPIO x and then decide if it will be used as input or output. Re-enumerating the GPIOs presented from the chip is complicating things by shuffleing around the local offset (HW numbering) space.
For GPIOs that are not usable at all, use the
gpio-reserved-ranges = <> property, see gpio.txt
If you want to indicate that some lines can just be used for input and some can just be used for output and some cannot be used at all, let the .set_direction_output() and .set_direction_input() callbacks fail for these pins with -EINVAL or so.
If these masks cannot be derived from the compatible strings, then create generic bindings to mark lines as input-only or output-only in gpio.txt and use the same syntax as gpio-reserved-ranges, and handle it in the gpiolib just as with gpio-reserved-ranges, not in your local driver.
For example gpio-output-only-ranges and
gpio-input-only-ranges.
But first convince us that you really need that.
drivers/gpio/gpio-moxtet.c line 9
Quoted 2 lines
drivers/gpio/gpio-moxtet.c new file +2
-0+#include <linux/gpio/consumer.h> +#include <linux/gpio.h>
This is a driver so only #include <linux/gpio/driver.h> Skip the two above.
drivers/gpio/gpio-moxtet.c line 12
Quoted 3 lines
drivers/gpio/gpio-moxtet.c new file +3
-0+#include <linux/mfd/moxtet.h> +#include <linux/module.h> +#include <linux/of_gpio.h>
You don't need this either. Delete that include.
drivers/gpio/gpio-moxtet.c line 29
Quoted 9 lines
drivers/gpio/gpio-moxtet.c new file +9
-0+static int moxtet_gpio_dir_mask (struct gpio_chip *gc,unsigned int offset, +int *dir,u8 *mask) +{ +struct moxtet_gpio_chip *chip =gpiochip_get_data (gc); +int i; + + *dir =0 ; +for (i =0 ; i <4 ; ++i) { + *mask =1 << i;
#include <linux/bitops.h>
*mask = BIT(i);
Quoted 8 lines
drivers/gpio/gpio-moxtet.c new file +8
-0+if (*mask & chip->in_mask) { +if (offset ==0 ) +return 0 ; + --offset; + } + } + + *dir =1 ;
drivers/gpio/gpio-moxtet.c line 47
Quoted 10 lines
drivers/gpio/gpio-moxtet.c new file +10
-0+for (i =0 ; i <8 ; ++i) { + *mask =1 << i; +if (*mask & chip->out_mask) { +if (offset ==0 ) +return 0 ; + } + } + +return -EINVAL ; +}
This looks convoluted and I think will go away with my suggestion to cut the masks.
Otherwise use primitives such as for_each_set_bit() etc.
Quoted 19 lines
drivers/gpio/gpio-moxtet.c new file +19
-0+static int moxtet_gpio_get_value (struct gpio_chip *gc,unsigned int offset) +{ +struct moxtet_gpio_chip *chip =gpiochip_get_data (gc); +int ret, dir; +u8 mask; + +if (moxtet_gpio_dir_mask (gc, offset, &dir, &mask) <0 ) +return -EINVAL ; + +if (dir) + ret =moxtet_device_written (chip->dev); +else + ret =moxtet_device_read (chip->dev); + +if (ret <0 ) +return ret; + +return (ret & mask) ?1 :0 ; +}
drivers/gpio/gpio-moxtet.c line 77
Quoted 10 lines
drivers/gpio/gpio-moxtet.c new file +10
-0+ +static void moxtet_gpio_set_value (struct gpio_chip *gc,unsigned int offset, +int val) +{ +struct moxtet_gpio_chip *chip =gpiochip_get_data (gc); +int state, dir; +u8 mask; + +if (moxtet_gpio_dir_mask (gc, offset, &dir, &mask) <0 ) +return ;
So skip this and trust the consumers to ask for the right GPIO and set it up.
Yours,
Linus Walleij
PATCH 1/1 Request (Linus Walleij + Lee Jones)
In reply to Marek BehúnHi Linus and Lee,
these two patches touch two different subsystems (mfd + gpio) and should be applyied one after another (the gpio part is dependant on the mfd part).
The patches are based on mfd-next-4.19. I can send another copy based on gpio/devel.
Could you two, Linus and Lee, work together on applying these patches? I don't know how this is usually solved...
Thanks.
Marek
Re: [PATCH mfd+gpio] Request (Linus Walleij + Lee Jones)
Quoted 8 lines · Marek Behun
Hi Linus and Lee,
these two patches touch two different subsystems (mfd + gpio) and should be applyied one after another (the gpio part is dependant on the mfd part).
The patches are based on mfd-next-4.19. I can send another copy based on gpio/devel.
Could you two, Linus and Lee, work together on applying these patches? I don't know how this is usually solved...
If they need to go into the same merge window this is usually solved by me ACKing the GPIO patches and Lee applying all of it to the MFD tree then providing an immutable git branch to me if I need the same changes in my tree.
Yours,
Linus Walleij
Hi Marek,
Thank you for the patch! Perhaps something to improve:
url: https://github.com/0day-ci/linux/commits/Marek-Beh-n/drivers-mfd-Add-support-for-Moxtet-bus/20180831-031806 base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
smatch warnings:drivers/mfd/moxtet.c:267 of_register_moxtet_device() warn: passing zero to 'ERR_PTR'
# https://github.com/0day-ci/linux/commit/316bda5c94917aa3b0a67c3cf79cca211d08138d
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 316bda5c94917aa3b0a67c3cf79cca211d08138d
vim +/ERR_PTR +267 drivers/mfd/moxtet.c
316bda5c Marek Behún 2018-08-30 213
316bda5c Marek Behún 2018-08-30 214 static struct moxtet_device *
316bda5c Marek Behún 2018-08-30 215 of_register_moxtet_device(struct moxtet *moxtet, struct device_node *nc)
316bda5c Marek Behún 2018-08-30 216 {
316bda5c Marek Behún 2018-08-30 217 struct moxtet_device *dev;
316bda5c Marek Behún 2018-08-30 218 u32 val;
316bda5c Marek Behún 2018-08-30 219 int ret;
316bda5c Marek Behún 2018-08-30 220
316bda5c Marek Behún 2018-08-30 221 dev = moxtet_alloc_device(moxtet);
316bda5c Marek Behún 2018-08-30 222 if (!dev) {
316bda5c Marek Behún 2018-08-30 223 dev_err(moxtet->dev,
316bda5c Marek Behún 2018-08-30 224 "Moxtet device alloc error for %pOF\n", nc);
316bda5c Marek Behún 2018-08-30 225 return ERR_PTR(-ENOMEM);
316bda5c Marek Behún 2018-08-30 226 }
316bda5c Marek Behún 2018-08-30 227
316bda5c Marek Behún 2018-08-30 228 ret = of_property_read_u32(nc, "reg", &val);
316bda5c Marek Behún 2018-08-30 229 if (ret || val >= TURRIS_MOX_MAX_MODULES) {
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^No error code set. It means we return NULL. Presumably it leads to a NULL dereference in the caller?
316bda5c Marek Behún 2018-08-30 230 dev_err(moxtet->dev, "%pOF has no valid 'reg' property (%d)\n",
316bda5c Marek Behún 2018-08-30 231 nc, ret);
316bda5c Marek Behún 2018-08-30 232 goto err_put;
316bda5c Marek Behún 2018-08-30 233 }
316bda5c Marek Behún 2018-08-30 234 dev->idx = val;
316bda5c Marek Behún 2018-08-30 235
316bda5c Marek Behún 2018-08-30 236 ret = of_property_read_u32(nc, "moxtet,id", &val);
316bda5c Marek Behún 2018-08-30 237 if (ret || val > 0xf) {
^^^^^^^^^316bda5c Marek Behún 2018-08-30 238 dev_err(moxtet->dev,
316bda5c Marek Behún 2018-08-30 239 "%pOF has no valid 'moxtet,id' property (%d)\n", nc,
316bda5c Marek Behún 2018-08-30 240 ret);
316bda5c Marek Behún 2018-08-30 241 goto err_put;
316bda5c Marek Behún 2018-08-30 242 }
316bda5c Marek Behún 2018-08-30 243 dev->id = val;
316bda5c Marek Behún 2018-08-30 244
316bda5c Marek Behún 2018-08-30 245 if (moxtet->modules[dev->idx] != dev->id) {
316bda5c Marek Behún 2018-08-30 246 dev_err(moxtet->dev,
316bda5c Marek Behún 2018-08-30 247 "%pOF requested Moxtet device ID 0x%x, 0x%x found\n",
316bda5c Marek Behún 2018-08-30 248 nc, dev->id, moxtet->modules[dev->idx]);
316bda5c Marek Behún 2018-08-30 249 goto err_put;
^^^^^^^^^^^^316bda5c Marek Behún 2018-08-30 250 }
316bda5c Marek Behún 2018-08-30 251
316bda5c Marek Behún 2018-08-30 252 of_node_get(nc);
316bda5c Marek Behún 2018-08-30 253 dev->dev.of_node = nc;
316bda5c Marek Behún 2018-08-30 254
316bda5c Marek Behún 2018-08-30 255 ret = moxtet_add_device(dev);
316bda5c Marek Behún 2018-08-30 256 if (ret) {
316bda5c Marek Behún 2018-08-30 257 dev_err(moxtet->dev,
316bda5c Marek Behún 2018-08-30 258 "Moxtet device register error for %pOF\n", nc);
316bda5c Marek Behún 2018-08-30 259 of_node_put(nc);
316bda5c Marek Behún 2018-08-30 260 goto err_put;
316bda5c Marek Behún 2018-08-30 261 }
316bda5c Marek Behún 2018-08-30 262
316bda5c Marek Behún 2018-08-30 263 return dev;
316bda5c Marek Behún 2018-08-30 264
316bda5c Marek Behún 2018-08-30 265 err_put:
316bda5c Marek Behún 2018-08-30 266 put_device(&dev->dev);316bda5c Marek Behún 2018-08-30 @267 return ERR_PTR(ret);316bda5c Marek Behún 2018-08-30 268 }316bda5c Marek Behún 2018-08-30 269
Quoted 25 lines · Marek Behún
On the Turris Mox router there can be connected different modules to the main CPU board, currently a module with a SFP cage, a module with MiniPCIe connector, a 4-port switch module and a 8-port switch module, for example:
[CPU]-[PCIe]-[8-port switch]-[8-port switch]-[SFP]Each of this modules has an input and output shift register, and these are connected via SPI to CPU board.
Via this SPI connection we are able to discover which modules are connected and we can also read/write some configuration to the modules. Fromi/to each module 8 bits can be read (of which lower 4 bits identify the module) and written.
For example from the module with a SFP cage we can read the LOS, TX-FAULT and MOD-DEF0 signals, while we can write TX-DISABLE and RATE-SELECT signals.
Other modules may support something else.
This driver creates a new bus type, called "moxtet". For each Mox module it finds via SPI, it creates a new device on the moxtet bus so that drivers can be written for them, for example a gpio driver for the module with a SFP cage.
Quoted 6 lines
The topology of how Mox modules are connected can then be read by listing
/sys/bus/moxtet/devices.Signed-off-by Marek Behún <[email protected]>--- Documentation/devicetree/bindings/mfd/moxtet.txt | 36 ++
This should be supplied in a separate patch.
Quoted 1 line
MAINTAINERS | 7 +
As above please.
Quoted 15 lines
drivers/mfd/Kconfig | 10 + drivers/mfd/Makefile | 1 + drivers/mfd/moxtet.c | 501 +++++++++++++++++++++++ include/linux/mfd/moxtet.h | 103 +++++ 6 files changed, 658 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/moxtet.txt create mode 100644 drivers/mfd/moxtet.c create mode 100644 include/linux/mfd/moxtet.hDocumentation/devicetree/bindings/mfd/moxtet.txt new file +0
-0
Documentation/devicetree/bindings/mfd/moxtet.txt line 8
Quoted 8 lines
Documentation/devicetree/bindings/mfd/moxtet.txt new file +8
-0@@ -0,0 +1,36 @@ +Turris Mox module configuration bus (over SPI) + +Required properties: + - compatible : Should be "cznic,moxtet". + - #address-cells : Has to be 1 + - #size-cells : Has to be 0 +For other required and optional properties of SPI slave +nodes please refer to ../spi/spi-bus.txt.
This line is cut unnecessarily short.
Documentation/devicetree/bindings/mfd/moxtet.txt line 12
Quoted 3 lines
Documentation/devicetree/bindings/mfd/moxtet.txt new file +3
-0+Required properties of subnodes: + - reg : Should be position on the Moxtet bus + - moxtet,id : Should be ID of the Moxtet device connected
What is this used for?
Documentation/devicetree/bindings/mfd/moxtet.txt line 20
Quoted 7 lines
Documentation/devicetree/bindings/mfd/moxtet.txt new file +7
-0+The driver finds the devices connected to the bus by itself, but it may be +needed to reference some of them from other parts of the device tree. In that +case the devices can be defined as subnodes of the moxtet node. + +Example: + + moxtet@1 {
Does the device itself have a address, or is it only contactable via SPI?
Quoted 75 lines
Documentation/devicetree/bindings/mfd/moxtet.txt new file +16
-0+ #address-cells = <1>; + #size-cells = <0>; + compatible = "cznic,moxtet"; + reg = <1>; + spi-max-frequency = <1000000>; + spi-cpol; + spi-cpha; + + moxtet_sfp: moxtet-sfp@0 { + compatible = "cznic,moxtet-sfp"; + gpio-controller; + #gpio-cells; + reg = <0>; + moxtet,id = <1>; + } + };MAINTAINERS +7
-0@@ -1412,6 +1412,13 @@ F: drivers/clocksource/timer-prima2.c F: drivers/clocksource/timer-atlas7.c N: [^a-z]sirf +ARM/CZ.NIC TURRIS MOX SUPPORT +M: Marek Behun <[email protected]> +W: http://mox.turris.cz +S: Maintained +F: include/mfd/moxtet.h +F: drivers/mfd/moxtet.c + ARM/EBSA110 MACHINE SUPPORT M: Russell King <[email protected]> L: [email protected] (moderated for non-subscribers)drivers/mfd/Kconfig +10
-0@@ -814,6 +814,16 @@ config MFD_MAX8998 additional drivers must be enabled in order to use the functionality of the device. +config MFD_MOXTET + tristate "CZ.NIC Turris Mox module configuration bus" + depends on SPI_MASTER && OF + help + Say yes here to add support for the module configuration bus found + on CZ.NIC's Turris Mox. This is needed for the ability to read + in what order the modules are connected and to get/set some of + their settings. For example the GPIOs on Mox SFP module are + configured through this bus. + config MFD_MT6397 tristate "MediaTek MT6397 PMIC Support" select MFD_COREdrivers/mfd/Makefile +1
-0@@ -159,6 +159,7 @@ max8925-objs := max8925-core.o max8925-i2c.o obj-$(CONFIG_MFD_MAX8925) += max8925.o obj-$(CONFIG_MFD_MAX8997) += max8997.o max8997-irq.o obj-$(CONFIG_MFD_MAX8998) += max8998.o max8998-irq.o +obj-$(CONFIG_MFD_MOXTET) += moxtet.o pcf50633-objs := pcf50633-core.o pcf50633-irq.o obj-$(CONFIG_MFD_PCF50633) += pcf50633.odrivers/mfd/moxtet.c new file +2
-0@@ -0,0 +1,501 @@ +// SPDX-License-Identifier: GPL-2.0 +/*
drivers/mfd/moxtet.c line 12
Quoted 10 lines
drivers/mfd/moxtet.c new file +10
-0+* Turris Mox module configuration bus driver +* +* Copyright (C) 2018 Marek Behun <[email protected]> +*/ + +#include <linux/module.h> +#include <linux/mutex.h> +#include <linux/of_device.h> +#include <linux/spi/spi.h> +#include <linux/mfd/moxtet.h>
Alphabetical please.
Right, I can probably save us a both a great deal of time here and tell you right off of the bat that this is not an MFD. MFDs will either use the MFD API or something like of_platform_populate().
Glancing over the reminder of the driver, it looks like an alternative of MFD or at least MFD-like. I think drivers/platform would be a better fit.
Signature · 4 lines
Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog