char/misc patches for 3.10-rc1

The following changes since commit 41ef2d5678d83af030125550329b6ae8b74618fa:

Linux 3.9-rc7 (2013-04-14 17:45:16 -0700)

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ tags/char-misc-3.10-rc1

for you to fetch changes up to 0e27263926699fcbbd574cff4dd6920007a50e8a:

Tools: hv: Fix a checkpatch warning (2013-04-24 09:02:36 -0700)

----------------------------------------------------------------
Char / Misc driver update for 3.10-rc1

Here's the big char / misc driver update for 3.10-rc1

A number of various driver updates, the majority being new functionality in the MEI driver subsystem (it's now a subsystem, it started out just a single driver), extcon updates, memory updates, hyper-v updates, and a bunch of other small stuff that doesn't fit in any other tree.

All of these have been in linux-next for a while

----------------------------------------------------------------
Alexandru Gheorghiu (1):
drivers: char: Use PTR_RET function

Ambresh K (1):
memory: emif: setup LP settings on freq update

Arnd Bergmann (1):
misc: mark spear13xx-pcie-gadget as broken

Bill Nottingham (1):

      mei: reseting -> resetting

Charles Keepax (1):
extcon: arizona: Check we report a valid impedance

Chen Gang (1):

      drivers/misc: beautify code: chip->lux_calib is u16 which will never more than APDS_RANGE

Damian Hobson-Garcia (1):
drivers: uio: Fix UIO device registration failure

Dan Carpenter (1):
applicom: use correct array offset

David Brown (10):
fix: Use EXPORT_SYMBOL_GPL
ssbi: Fix exit mismatch in remove function
ssbi: Allow compilation as a module
SSBI: Convert SSBI to device tree
ssbi: Comment the use of udelay()
ssbi: Use regular init level
ssbi: Remove extraneous logging
SSBI: Remove MSM_ prefix from SSBI drivers
MAINTAINERS: add ssbi
mfd: pm8921: Disable driver until it gets fixed

Fabio Estevam (1):
w1: mxc_w1: Convert to devm_ioremap_resource()

Fabio Porcedda (3):
drivers: memory: use module_platform_driver_probe()
drivers: char: use module_platform_driver_probe()
parport: amiga: use module_platform_driver_probe()

Greg Kroah-Hartman (8):
Merge tag 'arizona-extcon-asoc' of git://git.kernel.org/.../broonie/misc into char-misc-next Merge branch 'char-misc-linus' into char-misc-next
Merge v3.9-rc5 into char-misc-next
Merge tag 'extcon-arizona-v3.10' of git://git.kernel.org/.../broonie/misc into char-misc-next Merge tag 'extcon-for-3.10' of git://git.kernel.org/.../chanwoo/extcon into char-misc-next Merge 3.9-rc7 into char-misc-next
Revert "scsi: pcmcia: nsp_cs: remove module init/exit function prototypes" Revert "drivers/scsi: use module_pcmcia_driver() in pcmcia drivers"

Grygorii Strashko (1):
memory: emif: errata i743: Prohibit usage of Power-Down mode

Guenter Roeck (1):
misc/vmw_vmci: Add dependency on CONFIG_NET

H Hartley Sweeten (12):
pcmcia/ds.h: introduce helper for pcmcia_driver module boilerplate drivers/ata: use module_pcmcia_driver() in pcmcia drivers drivers/bluetooth: use module_pcmcia_driver() in pcmcia drivers drivers/isdn: use module_pcmcia_driver() in pcmcia drivers drivers/mmc: use module_pcmcia_driver() in pcmcia drivers drivers/parport: use module_pcmcia_driver() in pcmcia drivers drivers/scsi: use module_pcmcia_driver() in pcmcia drivers drivers/tty: use module_pcmcia_driver() in pcmcia drivers drivers/usb: use module_pcmcia_driver() in pcmcia drivers sound/pcmcia: use module_pcmcia_driver() in pcmcia drivers drivers/net: use module_pcmcia_driver() in pcmcia drivers
scsi: pcmcia: nsp_cs: remove module init/exit function prototypes

Hiroshi Doyu (1):
memory: tegra30: Fix build error w/o PM

Jean-Francois Dagenais (2):
w1: ds2408: make value read-back check a Kconfig option
w1: ds2408: use ARRAY_SIZE instead of hard-coded number

Jingoo Han (10):
misc: arm-charlcd: use module_platform_driver_probe()
misc: atmel_pwm: use module_platform_driver_probe()
misc: ep93xx_pwm: use module_platform_driver_probe()
misc: bh1780gli: add CONFIG_PM_SLEEP to suspend/resume functions
misc: bh1770glc: add CONFIG_PM_SLEEP to suspend/resume functions
misc: apds990x: add CONFIG_PM_SLEEP to suspend/resume functions
misc: at25: use spi_get_drvdata() and spi_set_drvdata()
misc: eeprom_93xx46: use spi_get_drvdata() and spi_set_drvdata()
misc: lattice-ecp3-config: use spi_get_drvdata()
extcon: max8997: use dev_err() instead of pr_err()

Jiri Kosina (1):
dummy-irq: introduce a dummy IRQ handler driver

K. Y. Srinivasan (14):
Drivers: hv: balloon: Do not request completion notification
Drivers: hv: balloon: Execute balloon inflation in a separate context
Drivers: hv: balloon: Execute hot-add code in a separate context
Drivers: hv: balloon: Make the balloon driver not unloadable
Drivers: hv: balloon: Implement hot-add functionality
Drivers: hv: vmbus: Handle channel rescind message correctly
Drivers: hv: Add a new driver to support host initiated backup
Drivers: hv: balloon: Permit Linux to specify hot-add alignment requirements
mm: export split_page()
Drivers: hv: balloon: Support 2M page allocations for ballooning
Drivers: hv: Notify the host of permanent hot-add failures
Drivers: hv: vmbus: Fix a bug in hv_need_to_signal()
Tools: hv: Fix a checkpatch warning
Tools: hv: Fix a checkpatch warning

Kenneth Heitke (1):
add single-wire serial bus interface (SSBI) driver

Kurt Van Dijck (3):
softingcs: initialize spinlock with macro
softingcs: use module_pcmcia_driver
FIX: softingcs conversion to module_pcmcia_driver macro

Lars-Peter Clausen (4):

      misc: apds9802als: Fix suspend/resume
      misc: fsa8480: Use dev_pm_ops
      misc: isl29003: Use dev_pm_ops
      misc: tsl2550: Use dev_pm_ops

Lokesh Vutla (2):
memory: emif: Fix the lpmode timeout calculation
memory: emif: Load the correct custom config values from dt

Mark Brown (18):
extcon: arizona: Factor out magic application
ASoC: arizona: Fix interaction between headphone outputs and identification
extcon: arizona: Fix interaction between headphone outputs and identification
mfd: wm5102: Add registers for microphone detection level configuration
extcon: arizona: Attempt more microphone measurements
extcon: arizona: Allow configuration of button detection
extcon: arizona: Don't pulse MICBIAS for HPDET identification
extcon: arizona: Allow pull to be disabled on GPIO5 when used for JACKET
extcon: arizona: Raise minimum microphone impedance for HPDET method
extcon: arizona: Suppress duplicate JACKDET reports
extcon: arizona: Tune up HPDET debounce
extcon: arizona: Retry HPDET identification for high impedance
extcon: arizona: Don't ground flip when using HPDET identification
extcon: arizona: Simplify HPDET based identification
extcon: arizona: Time out if MICDET fails to report
extcon: arizona: Clear existing button reports before reporting new one
extcon: arizona: Allow additional debounce during microphone detection
extcon: arizona: Make mic detection timeout configurable

Nishanth Menon (3):
memory: emif: handle overflow for timing for LP mode
memory: emif: Handle devices which are not rated for >85C
memory: emif: use restart if power_off not present when out of spec

Olaf Hering (5):
Tools: hv: fix warnings in hv_vss_daemon
tools: hv: fix checks for origin of netlink message in hv_vss_daemon
tools: hv: use getmntent in hv_vss_daemon
tools: hv: use FIFREEZE/FITHAW in hv_vss_daemon
tools: hv: skip iso9660 mounts in hv_vss_daemon

Oleksandr Dmytryshyn (1):
memory: emif: Fix the incorrect 'size' parameter in memcpy

Paul Bolle (1):
misc: Remove max8997-muic.o Makefile line again

Richard Weinberger (2):
cs5535-mfgpt: Add another reset method
cs5535-mfgpt: Fix quotation marks

Sachin Kamat (3):
extcon: max77693: Staticize default_init_data
extcon: max77693: Fix return value
extcon: max8997: Fix return value

Samuel Iglesias Gonsalvez (2):
ipack: add ipack_get_device() ipack_put_device()
ipack: split ipack_device_register() in several functions

Samuel Ortiz (11):
mei: bus: Initial MEI Client bus type implementation
mei: bus: Implement driver registration
mei: bus: Initial implementation for I/O routines
mei: bus: Add bus related structures to mei_cl
mei: bus: Call bus routines from the core code
mei: bus: Synchronous API for the data transmission
mei: bus: Implement bus driver data setter/getter
mei: bus: Add device enabling and disabling API
mei: nfc: Initial nfc implementation
mei: nfc: Add NFC device to the MEI bus
mei: nfc: Implement MEI bus ops

Silviu-Mihai Popescu (1):
parport: use kmemdup instead of kmalloc + memcpy

Tomas Hozza (3):
tools: hv: daemon should subscribe only to CN_KVP_IDX group
tools: hv: daemon setsockopt should use options macros
tools: hv: daemon should check type of received Netlink msg

Tomas Winkler (18):
mei: revamp mei_data2slots
mei: add hw start callback
mei: add mei_irq_compl_handler function
mei: drop RECOVERING_FROM_RESET device state
mei: unregister watchdog from mei_stop function
mei: ME structures should be initialized in mei_device_init
mei: rename function mei_hw_init to mei_start
mei: prefix me hardware specific functions with mei_me_
mei: move mei-me to separate module
mei: add debugfs hooks
mei: add mei_cl_write function
mei: notify about the reset in error level
mei: wd: fix line over 80 characters
mei: revamp hbm state machine
mei: revamp mei_amthif_irq_read_message
mei: revamp mei_irq_read_client_message function
mei: fix reading large reposnes
mei: reduce flow control only for completed messages

Wei Yongjun (3):
Drivers: hv: balloon: make local functions static
mei: convert to use simple_open()
mei: fix krealloc() misuse in in mei_cl_irq_read_msg()

Zhang Yanfei (1):
driver: hv: remove cast for kmalloc return value

 Documentation/ABI/testing/sysfs-bus-mei            |   7 +
 Documentation/devicetree/bindings/arm/msm/ssbi.txt |  18 +
 Documentation/misc-devices/mei/mei-client-bus.txt  | 138 +++++
 MAINTAINERS                                        |   1 +
 arch/arm/boot/dts/msm8660-surf.dts                 |   6 +
 arch/arm/boot/dts/msm8960-cdp.dts                  |   6 +
 drivers/Kconfig                                    |   2 +
 drivers/Makefile                                   |   1 +
 drivers/ata/pata_pcmcia.c                          |  14 +-
 drivers/bluetooth/bluecard_cs.c                    |  15 +-
 drivers/bluetooth/bt3c_cs.c                        |  15 +-
 drivers/bluetooth/btuart_cs.c                      |  15 +-
 drivers/bluetooth/dtl1_cs.c                        |  15 +-
 drivers/char/applicom.c                            |   4 +-
 drivers/char/hw_random/mxc-rnga.c                  |  13 +-
 drivers/char/hw_random/tx4939-rng.c                |  13 +-
 drivers/char/tile-srom.c                           |   2 +-
 drivers/extcon/extcon-arizona.c                    | 498 ++++++++++++------
 drivers/extcon/extcon-max77693.c                   |  10 +-
 drivers/extcon/extcon-max8997.c                    |  12 +-
 drivers/hv/Makefile                                |   2 +-
 drivers/hv/channel_mgmt.c                          |  11 +
 drivers/hv/hv.c                                    |   5 +-
 drivers/hv/hv_balloon.c                            | 544 +++++++++++++++++---
 drivers/hv/hv_snapshot.c                           | 287 +++++++++++
 drivers/hv/hv_util.c                               |  10 +
 drivers/hv/ring_buffer.c                           |   1 +
 drivers/ipack/carriers/tpci200.c                   |  14 +-
 drivers/ipack/ipack.c                              |  36 +-
 drivers/isdn/hardware/avm/avm_cs.c                 |  14 +-
 drivers/isdn/hisax/avma1_cs.c                      |  14 +-
 drivers/isdn/hisax/elsa_cs.c                       |  14 +-
 drivers/isdn/hisax/sedlbauer_cs.c                  |  14 +-
 drivers/isdn/hisax/teles_cs.c                      |  14 +-
 drivers/memory/emif.c                              | 141 +++++-
 drivers/memory/tegra30-mc.c                        |   2 +
 drivers/mfd/Kconfig                                |   2 +-
 drivers/mfd/pm8921-core.c                          |  14 +-
 drivers/mfd/wm5102-tables.c                        |   8 +
 drivers/misc/Kconfig                               |  10 +-
 drivers/misc/Makefile                              |   2 +-
 drivers/misc/apds9802als.c                         |  25 +-
 drivers/misc/apds990x.c                            |   9 +-
 drivers/misc/arm-charlcd.c                         |  13 +-
 drivers/misc/atmel_pwm.c                           |  12 +-
 drivers/misc/bh1770glc.c                           |   7 +-
 drivers/misc/bh1780gli.c                           |  10 +-
 drivers/misc/cs5535-mfgpt.c                        |  41 +-
 drivers/misc/dummy-irq.c                           |  59 +++
 drivers/misc/eeprom/at25.c                         |   4 +-
 drivers/misc/eeprom/eeprom_93xx46.c                |   6 +-
 drivers/misc/ep93xx_pwm.c                          |  13 +-
 drivers/misc/fsa9480.c                             |  19 +-
 drivers/misc/isl29003.c                            |  19 +-
 drivers/misc/lattice-ecp3-config.c                 |   2 +-
 drivers/misc/mei/Kconfig                           |   5 +-
 drivers/misc/mei/Makefile                          |   9 +-
 drivers/misc/mei/amthif.c                          |  21 +-
 drivers/misc/mei/bus.c                             | 528 ++++++++++++++++++++
 drivers/misc/mei/client.c                          | 116 ++++-
 drivers/misc/mei/client.h                          |   7 +-
 drivers/misc/mei/debugfs.c                         | 143 ++++++
 drivers/misc/mei/hbm.c                             |  82 +--
 drivers/misc/mei/hbm.h                             |  25 +-
 drivers/misc/mei/hw-me.c                           | 124 +++--
 drivers/misc/mei/hw-me.h                           |   6 -
 drivers/misc/mei/init.c                            |  70 +--
 drivers/misc/mei/interrupt.c                       | 242 +++++----
 drivers/misc/mei/main.c                            | 127 ++---
 drivers/misc/mei/mei_dev.h                         | 166 +++++-
 drivers/misc/mei/nfc.c                             | 554 +++++++++++++++++++++
 drivers/misc/mei/pci-me.c                          |  46 +-
 drivers/misc/mei/wd.c                              |   3 +-
 drivers/misc/tsl2550.c                             |  21 +-
 drivers/mmc/host/sdricoh_cs.c                      |  20 +-
 drivers/net/arcnet/com20020_cs.c                   |  14 +-
 drivers/net/can/sja1000/ems_pcmcia.c               |  13 +-
 drivers/net/can/sja1000/peak_pcmcia.c              |  13 +-
 drivers/net/can/softing/softing_cs.c               |  16 +-
 drivers/net/ethernet/3com/3c574_cs.c               |  14 +-
 drivers/net/ethernet/3com/3c589_cs.c               |  14 +-
 drivers/net/ethernet/8390/axnet_cs.c               |  14 +-
 drivers/net/ethernet/8390/pcnet_cs.c               |  14 +-
 drivers/net/ethernet/amd/nmclan_cs.c               |  14 +-
 drivers/net/ethernet/fujitsu/fmvj18x_cs.c          |  14 +-
 drivers/net/ethernet/smsc/smc91c92_cs.c            |  14 +-
 drivers/net/ethernet/xircom/xirc2ps_cs.c           |  16 +-
 drivers/net/wireless/airo_cs.c                     |  14 +-
 drivers/net/wireless/atmel_cs.c                    |  14 +-
 drivers/net/wireless/b43/pcmcia.c                  |   4 +
 drivers/net/wireless/hostap/hostap_cs.c            |  15 +-
 drivers/net/wireless/libertas/if_cs.c              |  25 +-
 drivers/net/wireless/orinoco/orinoco_cs.c          |  16 +-
 drivers/net/wireless/orinoco/spectrum_cs.c         |  16 +-
 drivers/net/wireless/wl3501_cs.c                   |  14 +-
 drivers/parport/parport_amiga.c                    |  15 +-
 drivers/parport/parport_cs.c                       |  14 +-
 drivers/parport/parport_gsc.c                      |   4 +-
 drivers/parport/parport_sunbpp.c                   |   5 +-
 drivers/parport/procfs.c                           |   6 +-
 drivers/ssbi/Kconfig                               |  16 +
 drivers/ssbi/Makefile                              |   1 +
 drivers/ssbi/ssbi.c                                | 379 ++++++++++++++
 drivers/tty/serial/8250/serial_cs.c                |  14 +-
 drivers/uio/uio.c                                  |   1 +
 drivers/usb/host/sl811_cs.c                        |  15 +-
 drivers/w1/masters/mxc_w1.c                        |   6 +-
 drivers/w1/slaves/Kconfig                          |  10 +
 drivers/w1/slaves/w1_ds2408.c                      |  25 +-
 include/linux/hyperv.h                             |  69 +++
 include/linux/ipack.h                              |  42 +-
 include/linux/mei_cl_bus.h                         |  44 ++
 include/linux/mfd/arizona/core.h                   |   3 +
 include/linux/mfd/arizona/pdata.h                  |  21 +
 include/linux/mfd/arizona/registers.h              |   4 +
 include/linux/mod_devicetable.h                    |   9 +
 include/linux/platform_data/emif_plat.h            |   1 +
 include/linux/ssbi.h                               |  38 ++
 include/pcmcia/ds.h                                |  12 +
 include/uapi/linux/connector.h                     |   5 +-
 mm/page_alloc.c                                    |   1 +
 scripts/mod/devicetable-offsets.c                  |   3 +
 scripts/mod/file2alias.c                           |  12 +
 sound/pcmcia/pdaudiocf/pdaudiocf.c                 |  15 +-
 sound/pcmcia/vx/vxpocket.c                         |  14 +-
 sound/soc/codecs/arizona.c                         |  33 ++
 sound/soc/codecs/arizona.h                         |   3 +
 sound/soc/codecs/wm5102.c                          |   8 +-
 sound/soc/codecs/wm5110.c                          |   8 +-
 tools/hv/hv_kvp_daemon.c                           |  16 +-
 tools/hv/hv_vss_daemon.c                           | 249 +++++++++
 131 files changed, 4596 insertions(+), 1331 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-mei
 create mode 100644 Documentation/devicetree/bindings/arm/msm/ssbi.txt
 create mode 100644 Documentation/misc-devices/mei/mei-client-bus.txt
 create mode 100644 drivers/hv/hv_snapshot.c
 create mode 100644 drivers/misc/dummy-irq.c
 create mode 100644 drivers/misc/mei/bus.c
 create mode 100644 drivers/misc/mei/debugfs.c
 create mode 100644 drivers/misc/mei/nfc.c
 create mode 100644 drivers/ssbi/Kconfig
 create mode 100644 drivers/ssbi/Makefile
 create mode 100644 drivers/ssbi/ssbi.c
 create mode 100644 include/linux/mei_cl_bus.h
 create mode 100644 include/linux/ssbi.h
 create mode 100644 tools/hv/hv_vss_daemon.c

Ugh. What the f*ck is up with stuff like this:

Seriously? "ssbi" is such a major driver subsystem that it needs its own subdirectory at the top level?

We can't just go adding random single drivers at the top level. Now, giving it a subdirectory of its own is certainly fine (there should be more drivers that decide "I'll put my files away from others", but it should be under drivers/misc/ or something. There's no way this is at the same level as "networking" or "pci".

Linus

It's a "bus" type, that has individual drivers connecting to it. I'm pretty sure that David (now on to:) has a bunch more drivers queued up for this directory, right David?

Now if we want to have a drivers/buses/ where we put these things, that's fine with me, but so far, we seem to put new bus types directly in drivers/

thanks,

greg k-h

No it isn't, and no it doesn't.

It's a "bus" exactly the same way the PS2 driver is a "bus", and it has individual devices connecting to it exactly the same way we have keyboards and mice connecting to the PS2 driver.

Except at least the PS2 driver is documented somewhere, and has been done by multiple different vendors. Afaik, ssbi is a single implementation by qualcomm or something.

Yes, we could have "drivers/ps2" too. Except we don't. It's actually hidden down in drivers/input/serio/.

Now, maybe I'm wrong, and maybe SSBI is some next-gen super-bus that just hides all the information about itself from me better than most hardware tends to. And hey, maybe it will eventually grow to replace something like i2c entirely. Maybe David can explain why it's such a big deal. But right now it smells like somethign that should not be at the top level.

Linus

Ok, searching more, I find this discussion on lkml:

Dima Zavin reasonably wrote

"SSBI is a Qualcomm proprietary protocol that will only ever have one
ssbi "host" driver in it. The slave is always the PMIC .."

arguing that it should stay in arch/arm/mach-msm/ where it got developed by the Android guys.

The "explanations" for why it should be in drivers/ is this mindless drivel:

Seriously. That's the *ONLY* explanation given.

WTF? That's a singularly *bad* reason for moving things to "drivers". If it's specific to some particular machine board, it should damn well stay as specific as possible, instead of being moved to "drivers/" "just because".

This seems to be nothing but a continuation of the same old ARM story:
people were embarrassed by the fact that ARM looked bad in the diffstats, so they for many moons now have actively tried to spread out the arm-specific manure in other places. Not because it makes sense anywhere else, but because it makes ARM look less proprietary, and less filled with ad-hoc hacks.

I object. If it's a single-platform driver, it shouldn't be in "drivers". It should be under the one single platform that supports it. Seriously.

Then, *if* it ever becomes anything more than that, go right ahead and make it more generic. But don't move it to drivers "just because it's a driver".

And you seem to have fallen for the lipstick-on-a-pig explanation, hook line and sinker.

And I'm calling the ARM people out on this idiocy. Arnd and Nico - stop encouraging this kind of crap. Move things to drivers only once there is actual reason for it. If it's some proprierary single-SoC thing, it can damn well stay away from other people. And it definitely shouldn't mess up autocomplete in some core location.

Linus

First of all, I have to admit that I did not notice ssbi getting submitted, otherwise I would have suggested adding it to the drivers/bus directory that we created a while ago for bus drivers.

I think there are good reasons for most of the drivers we have moved out of arch/arm to stay out of there: we have added subdirectories for a lot of drivers that are alike:

* drivers/irqchip
* drivers/clocksource
* drivers/cpufreq
* drivers/pinctrl
* drivers/pci/host
* drivers/pwm

All of these (and probably a couple I missed) now have a subsystem maintainer who can look at the bigger picture across multiple platforms, create common infrastructure to avoid code duplication and point out when people create new drivers for hardware that already has an existing driver in the same subsystem (this happens more than you'd think).

Moreoever, a lot of ARM platforms in share even the most basic building blocks with platforms on other architectures: powerpc, mips, hexagon, c6x, sh, and even x86. I think it's much better to consistently move those drivers into on directory per subsystem rather than having only half the irqchip drivers in one directory when they are shared across two architectures, and the rest hidden away in some platform. In the end, it's not much different from having a platform specific network driver sit under drivers/net/ethernet rather than arch/arm/mach-foo even if we know it's never going to be used elsewhere.
In case of SSBI, I assume it's also being used by arch/hexagon, which is the other CPU core on many Qualcomm SoCs, but I'm sure that David can comment better on that one, maybe it's only used exclusively on SoCs that are ARM-only.

I think about two years ago, I tried to move a lot of simple "bus" drivers into a common drivers/bus/ directory: amba, bcma, dio, eisa, hsi, nubus, vlynq, vme, zorro out of their own top-level drivers directory. That idea was almost universally rejected.

I did ask people submitting new bus infrastructure to use drivers/bus though, and at least three of them were subsequently merged that way (or are queued up for this merge window). If you like, we can try to find a different place for those along with ssbi.

Arnd

Maybe. But this one is NOT such a case, and I saw Nico making excuses for it on lkml.

There are other things wrong with that whole SSBI driver crap that you seem to be ignoring:

- it's not a bus, it's just a driver. Just because some people call
it "serial bus" doesn't make it magically about a "bus". I can call an ethernet driver an "ethernet bus driver", and it may be technically correct, but it is still bullshit. And ethernet is damn more a real bus than that SSBI driver is. That's just a pure serial driver for a very specific piece of embedded hardware. Stop calling it a bus.

- The whole Kconfig thing is complete and utter garbage. There is no
excuse what-so-ever for ever asking the user about it. Not on x86, not on ARM. The drivers that actually *use* that magical serial line driver should just have selected it.

- I'm not seeing what commonalities this thing can have with anything
else. Did anybody look at the code? There's nothing generic there.

So move it to a saner place, fix the kconfig idiocy, and don't make noises as if it's some generic driver, much less some generic bus. It's not.

Linus

Fair enough. Of course the distinction here is not based on what it does, but how it gets used. I've looked at the driver now and it seems to do exactly the same as i2c and spi, which we certainly need to treat as buses here. The only difference here is that this hardware only has a single use in linux-next, which in an MFD driver. If we had a lot of different ones, it could reasonably be called a bus and use the bus_type and device_driver infrastructure.

Agreed.

It's a simple bus that has addressable registers. We have a generic infrastructure for these things in drivers/base/regmap, currently handling I2C, SPI and MMIO based buses, which are often used as different methods to address the same device endpoints. I think it would be sensible to add another one-off type here and convert the user(s) to be based on the regmap interface rather than its own set of exported symbols.
Alternatively, it could just be moved next to the pm8921 driver in drivers/mfd, which is currently its only user, but the Qualcomm people might have a better idea on whether other devices connected to ssbi follow the same pattern or whether they are going to live elsewhere outside of drivers/mfd.

Arnd

Even technically, a "bus" generally has a topology. It has addresses, and it has a protocol.

i2c is a bus. PCI is a bus. And something like SSB is a bus. There is a protocol, there's device with identity on the bus, there's stuff going on.

The SBBI driver has neither addresses nor a protocol. It's literally just an embedded on-chip serial device as far as I can tell. There's nothing "bus" about it. It's just a hose.

Yeah, yeah, at some point you can call "anything" a bus. I could call my little two-seater car a "school bus", because it has wheels, it's even yellow exactly like the school buses around here. And I can put a child in it. So my little yellow two-seater must be a bus too. It's all just how you define your words.

But it's a damn big reach. I didn't use to call the serial line connecting my computer to the modem a "bus". Even if it connected two devices.

Linus

Right. I was looking at it from the linux driver model perspective, where we already call a lot of things a bus that are not at all one in the engineering sense.

It seems I looked too briefly. As you point out and David already confirmed, there is only one device on the other side, which is indeed a major difference to e.g. SPI, which seems rather similar otherwise but can use chip-select pins to multiplex between different endpoints. Certainly this hardware could do the same, but you are right that it's not relevant because it doesn't do that in practice.

Arnd

No need for a special bus type, the regmap core now has support for supplying read and write callbacks so drivers for devices that look nothing like a bytestream can use the cache and other infrastructure. This is a good idea anyway for a PMIC since the regulator API has a large set of regmap based helpers for the standard operations so we'd probably save a bunch of code in the regulator driver too.

Correct. Despite having "bus" in the name, it isn't really a bus. It's a point-to-point serial interface to a non-addressible device.

Agreed

This driver has one purpose, and will only ever have this one purpose:
to connect the MSM SOC to a small family of power management chips. It is theoretically possible to connect it to other things, and I think there have been some obscure designs that do this, but not anything that is going to be supported in the kernel.

So, what is this saner place? The hardware is theoretically shared between ARM and Hexagon, but I don't know the hexagon plans to support it, I've added them to the CC.

I'm not sure why this shouldn't be in the drivers/mfd directory alongside the various pm*.c drivers that use it. It isn't going to be used for anything else.

Given the bikeshedding that happened when Ken pushed the driver out last time, though, I'm sure this will create a firestorm of disagreement over its location.

David

sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

Well, the only reason I see against putting it into drivers/mfd is that this place is becoming a dumping ground for stuff that doesn't have a real home anywhere else. On the other hand, this one would fit better than a lot of drivers that are already there, and it would actually remove the need for a global include/linux/*.h header file as the interface.

Arnd

Well, this device should have a bunch of function drivers hanging off it shouldn't it? That's pretty much the definition of a MFD.

Perhaps it's better to think of it as the library that other mfd devices use to talk to their device. ssbi is not itself an MFD device, it is part of the other drivers.

David

sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

Yes, quite.

So I actually wouldn't have complained about it in drivers/misc/ssbi/ or something like that. I don't think that's necessarily the best place for it, and maybe somebody can come up with better places. But even just in drivers/misc, at least you've moved it away to the point that it doesn't potentially compete with the pathname auto-completion of the fifty million other drivers we have under drivers/.

Or maybe "drivers/platform/something-or-other" if there are possible other things that get shared together with this thing? I don't care that deeply, as long as it's just off in a little corner of the universe, rather than smack-dab in the middle.

Linus

I usually try to prevent ARM platform specific code to go into drivers/platform, because of fear that this might become the place that people use to sneak in code we would not allow them to add to arch/arm/ for one reason or another. Based on David's explanation, I think drivers/mfd makes the most sense. I'll follow up with a patch.

Arnd

There is no reason for ssbi to have its own top-level driver directory when the only users of this interface are all MFD drivers. The only mainline driver using it at the moment (PM8921) is marked broken and in fact does not compile. I have verified that fixing the trivial build breakage in pm8921 links in the new ssbi code just fine, but that can be a separate patch.

---
 drivers/Kconfig              |  2 --
 drivers/Makefile             |  1 -
 drivers/mfd/Kconfig          |  3 ++-
 drivers/mfd/Makefile         |  2 +-
 drivers/{ssbi => mfd}/ssbi.c |  0
 drivers/ssbi/Kconfig         | 16 ----------------
 drivers/ssbi/Makefile        |  1 -
 7 files changed, 3 insertions(+), 22 deletions(-)

index 78a956e..202fa6d 100644
@@ -52,8 +52,6 @@ source "drivers/i2c/Kconfig"
 
 source "drivers/spi/Kconfig"
 
-source "drivers/ssbi/Kconfig"
-
 source "drivers/hsi/Kconfig"
 
 source "drivers/pps/Kconfig"

index 33360de..3c200a2 100644
@@ -114,7 +114,6 @@ obj-y				+= firmware/
 obj-$(CONFIG_CRYPTO)		+= crypto/
 obj-$(CONFIG_SUPERH)		+= sh/
 obj-$(CONFIG_ARCH_SHMOBILE)	+= sh/
-obj-$(CONFIG_SSBI)		+= ssbi/
 ifndef CONFIG_ARCH_USES_GETTIMEOFFSET
 obj-y				+= clocksource/
 endif

index ca86581..5150833 100644
@@ -991,7 +991,8 @@ config MFD_PM8XXX
 
 config MFD_PM8921_CORE
 	tristate "Qualcomm PM8921 PMIC chip"
-	depends on SSBI && BROKEN
+	depends on (ARCH_MSM || HEXAGON)
+	depends on BROKEN
 	select MFD_CORE
 	select MFD_PM8XXX
 	help

index b90409c..3b95b47 100644
@@ -133,7 +133,7 @@ obj-$(CONFIG_MFD_VX855)		+= vx855.o
 obj-$(CONFIG_MFD_WL1273_CORE)	+= wl1273-core.o
 obj-$(CONFIG_MFD_CS5535)	+= cs5535-mfd.o
 obj-$(CONFIG_MFD_OMAP_USB_HOST)	+= omap-usb-host.o omap-usb-tll.o
-obj-$(CONFIG_MFD_PM8921_CORE) 	+= pm8921-core.o
+obj-$(CONFIG_MFD_PM8921_CORE) 	+= pm8921-core.o ssbi.o
 obj-$(CONFIG_MFD_PM8XXX_IRQ) 	+= pm8xxx-irq.o
 obj-$(CONFIG_TPS65911_COMPARATOR)	+= tps65911-comparator.o
 obj-$(CONFIG_MFD_TPS65090)	+= tps65090.o

similarity index 100%
rename from drivers/ssbi/ssbi.c
rename to drivers/mfd/ssbi.c

deleted file mode 100644
index 1ae4040a..0000000
@@ -1,16 +0,0 @@
-#
-# SSBI bus support
-#
-
-menu "Qualcomm MSM SSBI bus support"
-
-config SSBI
-	tristate "Qualcomm Single-wire Serial Bus Interface (SSBI)"
-	help
-	  If you say yes to this option, support will be included for the
-	  built-in SSBI interface on Qualcomm MSM family processors.
-
-	  This is required for communicating with Qualcomm PMICs and
-	  other devices that have the SSBI interface.
-
-endmenu

deleted file mode 100644
index 38fb70c..0000000
@@ -1 +0,0 @@
-obj-$(CONFIG_SSBI) += ssbi.o

Coming soon, I hope, are going to be the DT conversion of the 8921 driver, and possibly drivers for a few of the other pmic chips.

And, thanks for moving this.

David

sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

Hi Arnd,

I suppose we don't expect any non MFD drivers to use this interface ? If that's so, I'll take it through mfd-next.

Cheers,
Samuel.

Intel Open Source Technology Centre
http://oss.intel.com/

Yes, that is correct.

Ok, thanks!

Arnd

Hi Arnd,

Applied to my mfd-next tree, thanks.

Cheers,
Samuel.

Intel Open Source Technology Centre
http://oss.intel.com/

This certainly sucks as an answer.

Agreed.

All I wish to add to what Arnd already stated is this:

We ought to gather drivers together according to their _purpose_. Especially if they provide some generic functionality via a common API to be used by the rest of the kernel. In some cases that API just begs to be created and commonalities factored out from individual drivers, which also warrants a move to drivers/.

Of course the cpufreq drivers, or even the cpuidle drivers, are awfully platform specific, or even proprietary single-SoC in many cases. But the interface they register into and the services they provide are common, and it is far easier for someone maintaining the cpuidle infrastructure to improve the interface and avoid conflicts by having all the related drivers at the same place. . It even helps next driver author look for better examples than only the last SoC they worked with.

However this is a design goal, not a hard rule. If a piece of code has no interface commonality with anything else then it is indeed not worth the hassle.

Nicolas

Btw, I pulled and pushed out, because I don't think this is the end of the world, but it's part of my constant fight against people who think that *their* subsystem is oh-so-magically important that it needs to show up as "default y" or otherwise be shown as the center of the universe. But for everybody else, it makes things like autocomplete much harder when there are tons of random subdirectories in central places.

Linus