[GIT PATCH] char/misc patches for 3.10-rc1

[GIT PATCH] char/misc patches for 3.10-rc1

[Greg KH]

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

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

----------------------------------------------------------------
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

Re: [GIT PATCH] char/misc patches for 3.10-rc1

[Linus Torvalds]

On Mon, Apr 29, 2013 at 9:21 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> Here's the big char / misc driver update for 3.10-rc1

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

>  drivers/ssbi/Kconfig                               |  16 +
>  drivers/ssbi/Makefile                              |   1 +
>  drivers/ssbi/ssbi.c                                | 379 ++++++++++++++

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

Re: [GIT PATCH] char/misc patches for 3.10-rc1

[Greg KH]

On Mon, Apr 29, 2013 at 11:28:40AM -0700, Linus Torvalds wrote:
> On Mon, Apr 29, 2013 at 9:21 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > Here's the big char / misc driver update for 3.10-rc1
> 
> Ugh. What the f*ck is up with stuff like this:
> 
> >  drivers/ssbi/Kconfig                               |  16 +
> >  drivers/ssbi/Makefile                              |   1 +
> >  drivers/ssbi/ssbi.c                                | 379 ++++++++++++++
> 
> 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".

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

Re: [GIT PATCH] char/misc patches for 3.10-rc1

[Linus Torvalds]

On Mon, Apr 29, 2013 at 11:38 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> It's a "bus" type, that has individual drivers connecting to it.

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

Re: [GIT PATCH] char/misc patches for 3.10-rc1

[Linus Torvalds]

On Mon, Apr 29, 2013 at 11:55 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> But right now it smells like somethign that should not be at
> the top level.

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

Re: [GIT PATCH] char/misc patches for 3.10-rc1

[Linus Torvalds]

On Mon, Apr 29, 2013 at 11:55 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, Apr 29, 2013 at 11:38 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
>>
>> It's a "bus" type, that has individual drivers connecting to it.
>
> No it isn't, and no it doesn't.

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:

On Tue, Feb 22 2011, Daniel Walker wrote:
> On Tue, 2011-02-22 at 12:47 -0800, Dima Zavin wrote:
>
>> What is the problem leaving it under arch/arm/mach-msm?
>
> Because it's a driver.

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

Re: [GIT PATCH] char/misc patches for 3.10-rc1

[Arnd Bergmann]

On Monday 29 April 2013, Linus Torvalds wrote:
> 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.

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

Re: [GIT PATCH] char/misc patches for 3.10-rc1

[Linus Torvalds]

On Mon, Apr 29, 2013 at 12:54 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> 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:

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

Re: [GIT PATCH] char/misc patches for 3.10-rc1

[Nicolas Pitre]

On Mon, 29 Apr 2013, Linus Torvalds wrote:

> The "explanations" for why it should be in drivers/ is this mindless drivel:
> 
> On Tue, Feb 22 2011, Daniel Walker wrote:
> > On Tue, 2011-02-22 at 12:47 -0800, Dima Zavin wrote:
> >
> >> What is the problem leaving it under arch/arm/mach-msm?
> >
> > Because it's a driver.
> 
> Seriously. That's the *ONLY* explanation given.

This certainly sucks as an answer.

> WTF? That's a singularly *bad* reason for moving things to "drivers".

Agreed.

> 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.

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

Re: [GIT PATCH] char/misc patches for 3.10-rc1

[Arnd Bergmann]

On Monday 29 April 2013, Linus Torvalds wrote:
> On Mon, Apr 29, 2013 at 12:54 PM, Arnd Bergmann <arnd@arndb.de> wrote:

> 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.

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.

>  - 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.

Agreed.

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

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

Re: [GIT PATCH] char/misc patches for 3.10-rc1

[David Brown]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> 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.

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.

>  - 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.

Agreed

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

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 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.

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

Re: [GIT PATCH] char/misc patches for 3.10-rc1

[Linus Torvalds]

On Mon, Apr 29, 2013 at 1:50 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> Fair enough. Of course the distinction here is not based on what it
> does, but how it gets used.

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

Re: [GIT PATCH] char/misc patches for 3.10-rc1

[Arnd Bergmann]

On Monday 29 April 2013, David Brown wrote:
> 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.

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

Re: [GIT PATCH] char/misc patches for 3.10-rc1

[Linus Torvalds]

On Mon, Apr 29, 2013 at 2:08 PM, David Brown <davidb@codeaurora.org> wrote:
>
> 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.

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

Re: [GIT PATCH] char/misc patches for 3.10-rc1

[Arnd Bergmann]

On Monday 29 April 2013, Linus Torvalds wrote:
> On Mon, Apr 29, 2013 at 1:50 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > Fair enough. Of course the distinction here is not based on what it
> > does, but how it gets used.
> 
> 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.

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.

> 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.

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

Re: [GIT PATCH] char/misc patches for 3.10-rc1

[Arnd Bergmann]

On Monday 29 April 2013, Linus Torvalds wrote:
> 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.

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

MFD: move ssbi driver into drivers/mfd

[Arnd Bergmann]

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.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Samuel Ortiz <sameo@linux.intel.com>
---
 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(-)

diff --git a/drivers/Kconfig b/drivers/Kconfig
index 78a956e..202fa6d 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -52,8 +52,6 @@ source "drivers/i2c/Kconfig"
 
 source "drivers/spi/Kconfig"
 
-source "drivers/ssbi/Kconfig"
-
 source "drivers/hsi/Kconfig"
 
 source "drivers/pps/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index 33360de..3c200a2 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -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
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index ca86581..5150833 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -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
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index b90409c..3b95b47 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -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
diff --git a/drivers/ssbi/ssbi.c b/drivers/mfd/ssbi.c
similarity index 100%
rename from drivers/ssbi/ssbi.c
rename to drivers/mfd/ssbi.c
diff --git a/drivers/ssbi/Kconfig b/drivers/ssbi/Kconfig
deleted file mode 100644
index 1ae4040a..0000000
--- a/drivers/ssbi/Kconfig
+++ /dev/null
@@ -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
diff --git a/drivers/ssbi/Makefile b/drivers/ssbi/Makefile
deleted file mode 100644
index 38fb70c..0000000
--- a/drivers/ssbi/Makefile
+++ /dev/null
@@ -1 +0,0 @@
-obj-$(CONFIG_SSBI) += ssbi.o

Re: MFD: move ssbi driver into drivers/mfd

[Greg KH]

On Tue, Apr 30, 2013 at 12:00:19AM +0200, Arnd Bergmann wrote:
> 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.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Samuel Ortiz <sameo@linux.intel.com>

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Re: MFD: move ssbi driver into drivers/mfd

[Nicolas Pitre]

On Tue, 30 Apr 2013, Arnd Bergmann wrote:

> 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.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Samuel Ortiz <sameo@linux.intel.com>

Acked-by: Nicolas Pitre <nico@linaro.org>


> ---
>  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(-)
> 
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index 78a956e..202fa6d 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -52,8 +52,6 @@ source "drivers/i2c/Kconfig"
>  
>  source "drivers/spi/Kconfig"
>  
> -source "drivers/ssbi/Kconfig"
> -
>  source "drivers/hsi/Kconfig"
>  
>  source "drivers/pps/Kconfig"
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 33360de..3c200a2 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -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
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index ca86581..5150833 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -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
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index b90409c..3b95b47 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -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
> diff --git a/drivers/ssbi/ssbi.c b/drivers/mfd/ssbi.c
> similarity index 100%
> rename from drivers/ssbi/ssbi.c
> rename to drivers/mfd/ssbi.c
> diff --git a/drivers/ssbi/Kconfig b/drivers/ssbi/Kconfig
> deleted file mode 100644
> index 1ae4040a..0000000
> --- a/drivers/ssbi/Kconfig
> +++ /dev/null
> @@ -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
> diff --git a/drivers/ssbi/Makefile b/drivers/ssbi/Makefile
> deleted file mode 100644
> index 38fb70c..0000000
> --- a/drivers/ssbi/Makefile
> +++ /dev/null
> @@ -1 +0,0 @@
> -obj-$(CONFIG_SSBI) += ssbi.o
> --
> 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/
> 

Re: MFD: move ssbi driver into drivers/mfd

[David Brown]

Arnd Bergmann <arnd@arndb.de> writes:

> 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.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Samuel Ortiz <sameo@linux.intel.com>

Acked-by: David Brown <davidb@codeaurora.org>

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

Re: MFD: move ssbi driver into drivers/mfd

[Samuel Ortiz]

Hi Arnd,

On Tue, Apr 30, 2013 at 12:00:19AM +0200, Arnd Bergmann wrote:
> 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.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Samuel Ortiz <sameo@linux.intel.com>
> ---
>  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(-)
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/

Re: MFD: move ssbi driver into drivers/mfd

[Arnd Bergmann]

On Tuesday 30 April 2013, Samuel Ortiz wrote:
> I suppose we don't expect any non MFD drivers to use this interface ?

Yes, that is correct.

> If that's so, I'll take it through mfd-next.

Ok, thanks!

	Arnd

Re: [GIT PATCH] char/misc patches for 3.10-rc1

[Mark Brown]

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

On Mon, Apr 29, 2013 at 10:50:47PM +0200, Arnd Bergmann wrote:
> On Monday 29 April 2013, Linus Torvalds wrote:

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

> 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.

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.

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

Re: [GIT PATCH] char/misc patches for 3.10-rc1

[Mark Brown]

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

On Mon, Apr 29, 2013 at 11:16:28PM +0200, Arnd Bergmann wrote:

> 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.

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.

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

Re: [GIT PATCH] char/misc patches for 3.10-rc1

[David Brown]

Mark Brown <broonie@kernel.org> writes:

> On Mon, Apr 29, 2013 at 11:16:28PM +0200, Arnd Bergmann wrote:
>
>> 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.
>
> 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

Re: [GIT PATCH] char/misc patches for 3.10-rc1

[Mark Brown]

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

On Thu, May 02, 2013 at 01:53:03PM -0700, David Brown wrote:
> Mark Brown <broonie@kernel.org> writes:

> > 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.

Yes, quite.

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

Re: MFD: move ssbi driver into drivers/mfd

[Samuel Ortiz]

Hi Arnd,

On Tue, Apr 30, 2013 at 12:00:19AM +0200, Arnd Bergmann wrote:
> 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.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Samuel Ortiz <sameo@linux.intel.com>
> ---
>  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(-)
Applied to my mfd-next tree, thanks.

Cheers,
Samuel.

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