On Tue, Mar 18, 2014 at 10:58:51AM +0000, Lee Jones wrote:

quoted

quoted

quoted

quoted

This patch add support for the Power Enable Key found on MFD AXP202 and
AXP209. Besides the basic support for the button, the driver adds two
entries in sysfs to configure the time delay for power on/off.

Signed-off-by: Carlo Caione <redacted>
---
 drivers/input/misc/Kconfig      |  11 ++
 drivers/input/misc/Makefile     |   1 +
 drivers/input/misc/axp20x-pek.c | 267 ++++++++++++++++++++++++++++++++++++++++
 3 files changed, 279 insertions(+)
 create mode 100644 drivers/input/misc/axp20x-pek.c

From what I understood of the MFD framework, you usually have a MFD
core driver that gets loaded from the DT and instantiate its various
functions through sub-devices, that are registered through
mfd_add_devices, and the drivers for these sub-devices are supported
in sub-drivers that are located in the driver/mfd, alongside the core
driver.

I believe that such a pattern allows for two interesting things:
  - You don't have to search around the whole kernel tree to find
    where a given sub-feature is supported.
  - You don't have to cripple your DT with instantiation of all the
    subcomponents, while you only really have one device.

Do you have a reason for not following this pattern?

Sorry Maxime, this is not the case.

If an MFD contains Regulators and USB & GPIO Controllers, I'd expect
to see the device represented in the following way:

  drivers/mfd/<id>.c
  drivers/{gpio,pinctrl}/{gpio,pinctrl}-<id>.c
  drivers/regulator/<id>-regulator.c
  drivers/usb/host/<id>.c

Oh, ok. Nevermind then :)

Just out of curiosity, some drivers at least seem to follow that trend
in drivers/mfd, is there any reason for this (other than historical) ?

Would you mind providing an example?

I was under this impression given the naming scheme that they were
using. Looking into it just proved me how wrong I was :)

Sorry for the noise.

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140318/7395cd2d/attachment.sig>