[GIT] [3.1] MFD pull request

July 31st, 2011 - 06:40 pm ET by Samuel Ortiz | Report spam

Hi Linus,

This is the MFD pull request for the 3.1 merge window. This is a relatively
quiet one, with a few new MFD drivers: AnalogicTech's AAT2870 and TI's
tps65912 and tps65921.
The rest of the update is made of a big chunk of Wolfson's WM83xx fixes and
improvements, and a few fixes for the ST-Ericsson ABxxxx support.

Thanks in advance for pulling those in.

The following changes since commit 24c3047095fa3954f114bfff2e37b8fcbb216396:

Merge branch 'nfs-for-3.1' of git://git.linux-nfs.org/projects/trondmy/linux-nfs (2011-07-31 06:26:50 -1000)

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/...fd-2.6.git for-next

Alexander Stein (1):
mfd: Add tunnelcreek watchdog to lpc_sch devices

Axel Lin (2):
mfd: Remove comp{1,2}_threshold sysfs entries in tps65911_comparator_remove
mfd: Fix off-by-one value range checking for tps65912_i2c_write

Dan Carpenter (1):
regulator: Storing tps65912 error codes in u8

Dimitris Papastamos (1):
mfd: Fix off by one in WM831x IRQ code

Jesper Juhl (3):
mfd: Remove dead code from max8997-irq
mfd: Don't leak init_data in tps65910_i2c_probe
mfd: Avoid two assignments if failures happen in tps65910_i2c_probe

Jin Park (3):
mfd: Add AAT2870 mfd driver
backlight: Add AAT2870 backlight driver
regulator: aat2870: Add AAT2870 regulator driver

Keshava Munegowda (1):
mfd: Fix the omap-usb-host clock API usage on usbhs_disable()

Lars-Peter Clausen (1):
mfd: Use generic irq chip for jz4740-adc

Linus Walleij (3):
mfd: Update ab8500 subdevice list
mfd: Clean-up ab8500 register file
mfd: Move TPS55910 Kconfig option

Margarita Olaya (4):
mfd: tps65912: Add new mfd device
tps65912: irq: add interrupt controller
tps65912: gpio: add gpio driver
tps65912: add regulator driver

Mark Brown (18):
mfd: Fix bus lock interaction for WM831x IRQ set_type() operation
mfd: Implement support for multiple WM831x devices
mfd: Allow touchscreen to be disabled on wm831x devices
mfd: Only register wm831x RTC device if the 32.768kHz crystal is enabled
mfd: Support dynamic allocation of IRQ range for wm831x
mfd: Read wm831x AUXADC conversion results before acknowledging interrupt
mfd: Refactor wm831x AUXADC handling into a separate file
mfd: Restructure wm8994-core device revision handling
mfd: Support multiple active WM831x AUXADC conversions
mfd: Fix WM8994 IRQ register cache restore on resume
mfd: Fix error handling if BUG() isn't enabled in WM8994
mfd: Implement tps65910 IRQ cleanup
mfd: Ensure value written by wm831x_set_bits() is within the mask
mfd: Add WM831x clock control register definitions
mfd: Don't ask about the TPS65912 core driver in Kconfig
mfd: Add devices for WM831x clocking module
mfd: Acknowlege all WM831x IRQs before we handle them
mfd: Acknowledge WM8994 IRQs before reporting

Oleg Drokin (1):
mfd: Add tps65921 support from twl-core

Om Prakash (1):
mfd: Fix missing stmpe kerneldoc

Peter Huewe (2):
mfd: Use kstrtoul_from_user in ab3550
mfd: Use kstrtoul_from_user in ab8500

Randy Dunlap (1):
mfd: twl6030-pwm.c needs MODULE_LICENSE

Robert Rosengren (1):
mfd: ab8500-core MFD devices marked as initdata

Sanjeev Premi (1):
mfd: Fix mismatch in twl4030 mutex lock-unlock

Sascha Hauer (1):
mfd: Allocate wm835x irq descs dynamically

drivers/gpio/Kconfig | 6 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-tps65912.c | 156 +++++++
drivers/mfd/Kconfig | 53 ++-
drivers/mfd/Makefile | 8 +-
drivers/mfd/aat2870-core.c | 535 +++++++++++++++++++++
drivers/mfd/ab3550-core.c | 41 +--
drivers/mfd/ab8500-core.c | 231 +++++++
drivers/mfd/ab8500-debugfs.c | 41 +--
drivers/mfd/jz4740-adc.c | 90 ++
drivers/mfd/lpc_sch.c | 49 ++-
drivers/mfd/max8997-irq.c | 2 -
drivers/mfd/omap-usb-host.c | 4 +-
drivers/mfd/stmpe.c | 2 +-
drivers/mfd/stmpe.h | 1 +
drivers/mfd/tps65910.c | 13 +-
drivers/mfd/tps65911-comparator.c | 2 +
drivers/mfd/tps65912-core.c | 177 +++++++
drivers/mfd/tps65912-i2c.c | 139 ++++++
drivers/mfd/tps65912-irq.c | 224 +++++++++
drivers/mfd/tps65912-spi.c | 142 ++++++
drivers/mfd/twl-core.c | 2 +
drivers/mfd/twl4030-madc.c | 8 +-
drivers/mfd/twl6030-pwm.c | 2 +
drivers/mfd/wm831x-auxadc.c | 299 ++++++++++++
drivers/mfd/wm831x-core.c | 259 +++--
drivers/mfd/wm831x-irq.c | 77 ++--
drivers/mfd/wm8350-irq.c | 18 +-
drivers/mfd/wm8994-core.c | 33 +-
drivers/mfd/wm8994-irq.c | 12 +-
drivers/regulator/Kconfig | 13 +
drivers/regulator/Makefile | 2 +
drivers/regulator/aat2870-regulator.c | 232 +++++++++
drivers/regulator/tps65912-regulator.c | 800 ++++++++++++++++++++++++++++++++
drivers/video/backlight/Kconfig | 7 +
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/aat2870_bl.c | 246 ++++++++++
include/linux/mfd/aat2870.h | 181 +++++++
include/linux/mfd/ab8500.h | 8 +-
include/linux/mfd/stmpe.h | 3 +
include/linux/mfd/tps65910.h | 1 +
include/linux/mfd/tps65912.h | 327 +++++++++++++
include/linux/mfd/wm831x/core.h | 119 +++++-
include/linux/mfd/wm831x/pdata.h | 3 +
44 files changed, 4118 insertions(+), 452 deletions(-)
create mode 100644 drivers/gpio/gpio-tps65912.c
create mode 100644 drivers/mfd/aat2870-core.c
create mode 100644 drivers/mfd/tps65912-core.c
create mode 100644 drivers/mfd/tps65912-i2c.c
create mode 100644 drivers/mfd/tps65912-irq.c
create mode 100644 drivers/mfd/tps65912-spi.c
create mode 100644 drivers/mfd/wm831x-auxadc.c
create mode 100644 drivers/regulator/aat2870-regulator.c
create mode 100644 drivers/regulator/tps65912-regulator.c
create mode 100644 drivers/video/backlight/aat2870_bl.c
create mode 100644 include/linux/mfd/aat2870.h
create mode 100644 include/linux/mfd/tps65912.h

Intel Open Source Technology Centre
http://oss.intel.com/
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Follow the discussion Replies

1 reply

Make a reply

Replies

#1 Linus Torvalds

July 31st, 2011 - 08:50 pm ET | Report spam

On Sun, Jul 31, 2011 at 12:37 PM, Samuel Ortiz wrote:

This is the MFD pull request for the 3.1 merge window.

Guys, I'm getting *really* fed up with these kinds of trees.

This -git tree clearly had no testing at all, and cannot possibly have
been in -next.

How do I know? It's based on something I pushed out this morning, so
all the commits are really recent.

DO NOT DO THIS. It annoys the hell out of me to pull something and be
able to definitely say immediately that the person who wrote the pull
request clearly gave that particular git tree zero amount of actual
testing.

I pulled this time, because I just cannot find it in myself to care
too much about mfd.

But for the very same reason, next time I notice people rebasing their
trees on top of random points, I will just not pull. If I see that
the tree they based stuff on is from the merge window, I'll just go
"this guy clearly means for this to get more testing, and meant for
this to be pulled in *next* merge window".

And it doesn't matter one whit if you say something like "Oh, but I
use quilt, so it's been tested there, and I just imported a very well
tested tree into -git to push it to you". Dammit, even if you use
quilt or something else to actually maintain your patch series, I KNOW
DAMN WELL THAT YOU DIDN'T TEST THAT SERIES ON TOP OF THE RECENT CRAPPY
NFS PULL!

So if you use quilt or something, then import the patch series on top
of something STABLE AND SANE. Start off with the released 3.0, that at
least doesn't have random pulls that have known compile issues. Use
that for testing, and don't send me a re-based patch-series that
clearly cannot possibly have been tested in that form, and that was
based on a kernel that had ugly problems.

(And during the merge window, pretty much any "Linus' kernel of the
day" tends to have some problem or other. DON'T USE RANDOM KERNELS FOR
YOUR BASE).

Seriously. It really annoys the hell out of me when I get pull
requests that are totally half-assed. And today I got *two* of them
(that NFS pull request that you had based your tree on really was
total crap too, and had clearly not been tested enough)

I'm grumpy. I don't want to know that submaintainers are sending me
untested crap. So if you are too damn lazy to test things, at least
make it not so horribly OBVIOUS to me that it's clearly not tested,
and that it has clearly not been in -next in the form that you sent it
to me. Try to at least spend *some* time trying to make your pull
request look competent, ok?

But best would be if it was actually tested, and had actually been in
-next for a week. That is *especially* true when you send me a pull
request late in the merge window.

There is *NO* excuse for sending me crap this late in the merge
window. If it's not ready at this point, don't send it to me. It's
that simple. And yes, Trond, I'm very much looking at you too.

Linus
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Read all the answers

[GIT] [3.1] MFD pull request

Replies

Similar topics