[GIT PULL] MFD for v4.13

[GIT PULL] MFD for v4.13

[Lee Jones]

Morning Linus,

Enjoy!

The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6:

  Linux 4.12-rc1 (2017-05-13 13:19:49 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git tags/mfd-next-4.13

for you to fetch changes up to d1f99b97478e248353588da0de07be5a265601cf:

  mfd: madera: Add register definitions for Cirrus Logic Madera codecs (2017-07-06 08:29:13 +0100)

----------------------------------------------------------------
 - New Drivers
   - Intel Cherry Trail Whiskey Cove PMIC
   - TI LP87565 PMIC

 - New Device Support
   - Add support for Cannonlake to intel-lpss-pci
   - Add support for Simatic IOT2000 to intel_quark_i2c_gpio
   - Add register definitions for Cirrus Logic Madera codecs

 - New Functionality
   - Add Regulator support; axp20x

 - Fix-ups
   - Rework IRQ handling; intel_soc_pmic_bxtwc, rtsx_pcr, cros_ec
   - Remove unused/unwelcome code; ipaq-micro, wm831x-core, da9062-core
   - Provide deregistration on unbind; rn5t618
   - Rework DT code/documentation; arizona
   - Constify things; fsl-imx25-tsadc
   - MAINTAINERS updates; DA9062/61
   - Kconfig configuration adaptions; INTEL_SOC_PMIC, MFD_AXP20X_I2C
   - Switch to DMI matching; intel_quark_i2c_gpio
   - Provide an appropriate level of error checking;
                                  wm831x-{i2c,spi}, twl4030-irq, tc6393xb
   - Make use of devm_* (resource handling) calls;
                                  intel_soc_pmic_bxtwc, stm32-timers,
                                  atmel-flexcom, cros_ec, fsl-imx25-tsadc,
                                  exynos-lpass, palmas, qcom-spmi-pmic,
                                  smsc-ece1099, motorola-cpcap
----------------------------------------------------------------
Andy Shevchenko (1):
      mfd: intel-lpss: Add Intel Cannonlake PCI IDs

Arvind Yadav (1):
      mfd: tc6393xb: Handle return value of clk_prepare_enable

Benjamin Gaignard (9):
      mfd: stm32-timers: Use devm_of_platform_populate()
      mfd: atmel: Use devm_of_platform_populate()
      mfd: cros_ec: Use devm_of_platform_populate()
      mfd: fsl-imx25: Use devm_of_platform_populate()
      mfd: exynos: Use devm_of_platform_populate()
      mfd: palmas: Use devm_of_platform_populate()
      mfd: qcom-spmi-pmic: Use devm_of_platform_populate()
      mfd: smsc-ece: Use devm_of_platform_populate()
      mfd: motorola-cpcap: Use devm_of_platform_populate()

Charles Keepax (2):
      mfd: wm831x: Remove redundant !pdata checks
      mfd: arizona: Update GPIO binding for newly supported specifiers

Gustavo A. R. Silva (2):
      mfd: wm831x-i2c: Add NULL check before pointer dereference
      mfd: wm831x-spi: Add NULL check before pointer dereference

Hans de Goede (3):
      mfd: intel_soc_pmic: Select designware i2c-bus driver
      mfd: Add Cherry Trail Whiskey Cove PMIC driver
      mfd: axp20x-i2c: Document that this must be builtin on x86

Icenowy Zheng (1):
      mfd: axp20x: Add axp20x-regulator cell for AXP803

Jan Kiszka (2):
      mfd: intel_quark_i2c_gpio: Use dmi_system_id table for retrieving frequency
      mfd: intel_quark_i2c_gpio: Add support for SIMATIC IOT2000 platform

Jeffy Chen (1):
      mfd: cros_ec: Free IRQ on exit

Keerthy (1):
      mfd: Add LP87565 PMIC support

Kuppuswamy Sathyanarayanan (6):
      mfd: intel_soc_pmic_bxtwc: Fix TMU interrupt index
      mfd: intel_soc_pmic_bxtwc: Remove thermal second level IRQs
      mfd: intel_soc_pmic_bxtwc: Remove second level IRQ for gpio device
      mfd: intel_soc_pmic_bxtwc: Utilize devm_* functions in driver probe
      mfd: intel_soc_pmic_bxtwc: Use chained IRQs for second level IRQ chips
      platform/x86: intel_bxtwc_tmu: Remove first level IRQ unmask

Linus Walleij (1):
      mfd: ipaq-micro: Dump debugging hexdumps

Olimpiu Dejeu (1):
      dt-bindings: vendor-prefixes: Add arctic to vendor prefix

Richard Fitzgerald (1):
      mfd: madera: Add register definitions for Cirrus Logic Madera codecs

Stefan Agner (1):
      mfd: rn5t618: Unregister restart handler on remove

Steve Twiss (3):
      MAINTAINERS: da9062/61 updates to the Dialog Semiconductor search terms
      mfd: da9061: Fix to remove BBAT_CONT register from chip model
      mfd: da9061: Fix to remove BBAT_CONT register from chip model

Steven Feng (1):
      mfd: rtsx: Do retry when DMA transfer error

Tobias Klauser (1):
      mfd: fsl-imx25-tsadc: Constify irq_domain_ops

Uwe Kleine-König (1):
      mfd: twl4030-irq: Log an error in twl4030_sih_setup if the module cannot be found

 Documentation/devicetree/bindings/mfd/arizona.txt  |    3 +-
 Documentation/devicetree/bindings/mfd/lp87565.txt  |   43 +
 .../devicetree/bindings/vendor-prefixes.txt        |    1 +
 MAINTAINERS                                        |   14 +
 drivers/gpio/gpio-wcove.c                          |   14 +-
 drivers/mfd/Kconfig                                |   44 +-
 drivers/mfd/Makefile                               |    2 +
 drivers/mfd/atmel-flexcom.c                        |    2 +-
 drivers/mfd/axp20x.c                               |    3 +-
 drivers/mfd/cros_ec.c                              |    5 +-
 drivers/mfd/da9062-core.c                          |   12 -
 drivers/mfd/exynos-lpass.c                         |    2 +-
 drivers/mfd/fsl-imx25-tsadc.c                      |    7 +-
 drivers/mfd/intel-lpss-pci.c                       |   24 +
 drivers/mfd/intel_quark_i2c_gpio.c                 |   49 +-
 drivers/mfd/intel_soc_pmic_bxtwc.c                 |  232 +-
 drivers/mfd/intel_soc_pmic_chtwc.c                 |  230 +
 drivers/mfd/ipaq-micro.c                           |    5 -
 drivers/mfd/lp87565.c                              |  100 +
 drivers/mfd/motorola-cpcap.c                       |   13 +-
 drivers/mfd/palmas.c                               |    2 +-
 drivers/mfd/qcom-spmi-pmic.c                       |    9 +-
 drivers/mfd/rn5t618.c                              |    2 +
 drivers/mfd/rtsx_pcr.c                             |   17 +-
 drivers/mfd/smsc-ece1099.c                         |    3 +-
 drivers/mfd/stm32-timers.c                         |   10 +-
 drivers/mfd/tc6393xb.c                             |    4 +-
 drivers/mfd/twl4030-irq.c                          |    4 +-
 drivers/mfd/wm831x-core.c                          |   26 +-
 drivers/mfd/wm831x-i2c.c                           |    4 +
 drivers/mfd/wm831x-spi.c                           |    4 +
 drivers/platform/x86/intel_bxtwc_tmu.c             |    4 -
 drivers/thermal/intel_bxt_pmic_thermal.c           |    2 +-
 drivers/usb/typec/typec_wcove.c                    |    2 +-
 include/linux/mfd/intel_soc_pmic.h                 |    5 +-
 include/linux/mfd/lp87565.h                        |  270 +
 include/linux/mfd/madera/registers.h               | 8832 ++++++++++++++++++++
 include/linux/mfd/rtsx_pci.h                       |    5 +
 38 files changed, 9827 insertions(+), 183 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mfd/lp87565.txt
 create mode 100644 drivers/mfd/intel_soc_pmic_chtwc.c
 create mode 100644 drivers/mfd/lp87565.c
 create mode 100644 include/linux/mfd/lp87565.h
 create mode 100644 include/linux/mfd/madera/registers.h

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [GIT PULL] MFD for v4.13

[Linus Torvalds]

On Fri, Jul 7, 2017 at 2:50 AM, Lee Jones <lee.jones@linaro.org> wrote:
>
>  include/linux/mfd/madera/registers.h               | 8832 ++++++++++++++++++++

So I've pulled everything but this, because honestly, that file looks
like utter garbage.

Why are there all those _hundreds_ of odd defines for

  MADERA_WSEQ_SEQUENCE_xx

when it looks like you could just do one single one:

  // The sequence is one-based because somebody doesn't
  // know that indices start at 0. Thus the "-2".
  #define MADERA_WSEQ_SEQUENCE(x) (0x3000 + (x)*2 - 2)

and similar things go for for pretty much EVERY SINGLE LINE in that
8-thousand line piece of nasty horrible crud.

Being auto-generated doesn't really make this kind of thing any
better. In fact, it makes it worse, because those stupid hardcoded
names are often *harder* to use, because you cannot use a variable to
index into things (which you may often want).

So we have eight thousand lines of garbage that is

 (a) probably closer to 200x too many lines
 (b) less flexible than doing it right

Honestly, tell me why would I want to merge something monstrous like that?

                Linus

Re: [GIT PULL] MFD for v4.13

[Lee Jones]

On Fri, 07 Jul 2017, Linus Torvalds wrote:

> On Fri, Jul 7, 2017 at 2:50 AM, Lee Jones <lee.jones@linaro.org> wrote:
> >
> >  include/linux/mfd/madera/registers.h               | 8832 ++++++++++++++++++++
> 
> So I've pulled everything but this, because honestly, that file looks
> like utter garbage.
> 
> Why are there all those _hundreds_ of odd defines for
> 
>   MADERA_WSEQ_SEQUENCE_xx
> 
> when it looks like you could just do one single one:
> 
>   // The sequence is one-based because somebody doesn't
>   // know that indices start at 0. Thus the "-2".
>   #define MADERA_WSEQ_SEQUENCE(x) (0x3000 + (x)*2 - 2)
> 
> and similar things go for for pretty much EVERY SINGLE LINE in that
> 8-thousand line piece of nasty horrible crud.
> 
> Being auto-generated doesn't really make this kind of thing any
> better. In fact, it makes it worse, because those stupid hardcoded
> names are often *harder* to use, because you cannot use a variable to
> index into things (which you may often want).
> 
> So we have eight thousand lines of garbage that is
> 
>  (a) probably closer to 200x too many lines
>  (b) less flexible than doing it right
> 
> Honestly, tell me why would I want to merge something monstrous like that?

I'm inclined to agree and had my reservations.  However based on
a previous conversation [0], I was convinced that it's actually the
right thing to do. 

https://lkml.org/lkml/2017/4/7/229

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [GIT PULL] MFD for v4.13

[Charles Keepax]

On Fri, Jul 07, 2017 at 11:50:14PM +0100, Lee Jones wrote:
> On Fri, 07 Jul 2017, Linus Torvalds wrote:
> 
> > On Fri, Jul 7, 2017 at 2:50 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > >
> > >  include/linux/mfd/madera/registers.h               | 8832 ++++++++++++++++++++
> > 
> > So I've pulled everything but this, because honestly, that file looks
> > like utter garbage.
> > 
> > Why are there all those _hundreds_ of odd defines for
> > 
> >   MADERA_WSEQ_SEQUENCE_xx
> > 
> > when it looks like you could just do one single one:
> > 
> >   // The sequence is one-based because somebody doesn't
> >   // know that indices start at 0. Thus the "-2".
> >   #define MADERA_WSEQ_SEQUENCE(x) (0x3000 + (x)*2 - 2)
> > 
> > and similar things go for for pretty much EVERY SINGLE LINE in that
> > 8-thousand line piece of nasty horrible crud.
> > 
> > Being auto-generated doesn't really make this kind of thing any
> > better. In fact, it makes it worse, because those stupid hardcoded
> > names are often *harder* to use, because you cannot use a variable to
> > index into things (which you may often want).
> > 
> > So we have eight thousand lines of garbage that is
> > 
> >  (a) probably closer to 200x too many lines
> >  (b) less flexible than doing it right
> > 
> > Honestly, tell me why would I want to merge something monstrous like that?
> 
> I'm inclined to agree and had my reservations.  However based on
> a previous conversation [0], I was convinced that it's actually the
> right thing to do. 
> 
> https://lkml.org/lkml/2017/4/7/229

We are happy to look at other ways to implement the file but
there are a few reasons it looks the way it does, although
admittedly the write sequencer defines should probably go.

Copying in Richard's reply from the other thread below, as he
doesn't subscribe to LKML, so missed this thread.

Thanks,
Charles


But for others on this thread interested in why our registers.h
is the way it is...

We really quite like to keep all the registers defined because it
makes the source highly greppable, which is extremely useful. A
type of question which is often asked is "what does the driver
do with register bits XYZ" or "where does it use register
bits XYZ". Eliminating definitions into generator macros or
block-indexing code makes these questions more difficult to
answer. Another convenience is that it makes it easier for people
to translate raw hardware configurations (which are a list
of register values) into ALSA and pdata settings if they can
easily grep the source for those registers to see how they are
controlled. It also helps when adapting the driver for another
similar codec.

We do use block-indexing code where it's clearly the only
sensible way to implement a feature. But a lot of the source
that uses repetitive-looking definitions is ASoC tables,
not functions, so there's no code to do block-indexing, and
macroing out the register definitions just makes the table
definitions more clunky and less readable but has no effect on
its "quality". I did already strip a lot out of the file to
remove stuff we don't need or we implement as repeated blocks
(the original file is >44000 lines).

As for the naming and the 1-indexed counting, these are the
datasheet names of the registers and we want to use the same name
in the source as is in the datasheet and the hardware design,
otherwise it gets confusing. In fact, the majority are the names
of actual wires and blocks in the hardware design, generated
directly from it.  Renaming them is a big deal for the hardware
engineers because it's a design change and you can't patch
silicon if it introduces a bug. The 0-indexed counting is a very
C-centric view, hardware designers have other considerations, as
well as avoiding the risk of unnecessary changes.

The WSEQ registers can go but I was hoping to avoid manually
stripping too much more because when there are updated register
maps for new chips or new revisions of existing silicon it must
be possible to see what's changed. As we strip more and more
it gets harder work for people to see in a diff the difference
between genuinely removed register bits and spurious changes from
manual edits. However, I can strip out definitions of bits that
we aren't using _right now_ to reduce file size and patch them
back later when we need to use them, though that does mean anyone
debugging (via regmap debugfs for example) has to go to the
datasheet to look for the definitions of all those bits because
they are missing from the source.

Re: [GIT PULL] MFD for v4.13

[Pavel Machek]

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

Hi!

> > > >  include/linux/mfd/madera/registers.h               | 8832 ++++++++++++++++++++
> > > 
> > > So I've pulled everything but this, because honestly, that file looks
> > > like utter garbage.
> > > 
> > > Why are there all those _hundreds_ of odd defines for
> > > 
> > >   MADERA_WSEQ_SEQUENCE_xx
> > > 
> > > when it looks like you could just do one single one:
> > > 
> > >   // The sequence is one-based because somebody doesn't
> > >   // know that indices start at 0. Thus the "-2".
> > >   #define MADERA_WSEQ_SEQUENCE(x) (0x3000 + (x)*2 - 2)
...
> > >  (a) probably closer to 200x too many lines
> > >  (b) less flexible than doing it right
> > > 
> > > Honestly, tell me why would I want to merge something monstrous like that?
> > 
> > I'm inclined to agree and had my reservations.  However based on
> > a previous conversation [0], I was convinced that it's actually the
> > right thing to do. 
> > 
> > https://lkml.org/lkml/2017/4/7/229
...
> We really quite like to keep all the registers defined because it
> makes the source highly greppable, which is extremely useful. A
> type of question which is often asked is "what does the driver
> do with register bits XYZ" or "where does it use register
> bits XYZ". Eliminating definitions into generator macros or
> block-indexing code makes these questions more difficult to
> answer. Another convenience is that it makes it easier for people
> to translate raw hardware configurations (which are a list
> of register values) into ALSA and pdata settings if they can

Well, easy grep is a nice thing, but not worth the cost of 8000 lines
vs. 40 lines. I'm sure you can write the required regexps in less than
7960 lines.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]