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 <[email protected]>
----------------------------------------------------------------
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
On Mon, Apr 29, 2013 at 9:21 AM, Greg KH <[email protected]> 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
On Mon, Apr 29, 2013 at 11:28:40AM -0700, Linus Torvalds wrote:
> On Mon, Apr 29, 2013 at 9:21 AM, Greg KH <[email protected]> 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
On Mon, Apr 29, 2013 at 11:38 AM, Greg KH <[email protected]> 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
On Mon, Apr 29, 2013 at 11:55 AM, Linus Torvalds
<[email protected]> wrote:
> On Mon, Apr 29, 2013 at 11:38 AM, Greg KH <[email protected]> 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
On Mon, Apr 29, 2013 at 11:55 AM, Linus Torvalds
<[email protected]> 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
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
On Mon, Apr 29, 2013 at 12:54 PM, Arnd Bergmann <[email protected]> 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
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
On Monday 29 April 2013, Linus Torvalds wrote:
> On Mon, Apr 29, 2013 at 12:54 PM, Arnd Bergmann <[email protected]> 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
Linus Torvalds <[email protected]> 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
On Mon, Apr 29, 2013 at 1:50 PM, Arnd Bergmann <[email protected]> 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
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
On Mon, Apr 29, 2013 at 2:08 PM, David Brown <[email protected]> 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
On Monday 29 April 2013, Linus Torvalds wrote:
> On Mon, Apr 29, 2013 at 1:50 PM, Arnd Bergmann <[email protected]> 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
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
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 <[email protected]>
Cc: Samuel Ortiz <[email protected]>
---
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
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 <[email protected]>
> Cc: Samuel Ortiz <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
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 <[email protected]>
> Cc: Samuel Ortiz <[email protected]>
Acked-by: Nicolas Pitre <[email protected]>
> ---
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Arnd Bergmann <[email protected]> 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 <[email protected]>
> Cc: Samuel Ortiz <[email protected]>
Acked-by: David Brown <[email protected]>
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,
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 <[email protected]>
> Cc: Samuel Ortiz <[email protected]>
> ---
> 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/
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
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.
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.
Mark Brown <[email protected]> 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
On Thu, May 02, 2013 at 01:53:03PM -0700, David Brown wrote:
> Mark Brown <[email protected]> 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.
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 <[email protected]>
> Cc: Samuel Ortiz <[email protected]>
> ---
> 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/