* [GIT PATCH] char/misc patches for 3.10-rc1 @ 2013-04-29 16:21 Greg KH 2013-04-29 18:28 ` Linus Torvalds 0 siblings, 1 reply; 27+ messages in thread From: Greg KH @ 2013-04-29 16:21 UTC (permalink / raw) To: Linus Torvalds, Andrew Morton, Arnd Bergmann; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [GIT PATCH] char/misc patches for 3.10-rc1 2013-04-29 16:21 [GIT PATCH] char/misc patches for 3.10-rc1 Greg KH @ 2013-04-29 18:28 ` Linus Torvalds 2013-04-29 18:38 ` Greg KH 0 siblings, 1 reply; 27+ messages in thread From: Linus Torvalds @ 2013-04-29 18:28 UTC (permalink / raw) To: Greg KH; +Cc: Andrew Morton, Arnd Bergmann, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [GIT PATCH] char/misc patches for 3.10-rc1 2013-04-29 18:28 ` Linus Torvalds @ 2013-04-29 18:38 ` Greg KH 2013-04-29 18:55 ` Linus Torvalds 0 siblings, 1 reply; 27+ messages in thread From: Greg KH @ 2013-04-29 18:38 UTC (permalink / raw) To: Linus Torvalds, David Brown Cc: Andrew Morton, Arnd Bergmann, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [GIT PATCH] char/misc patches for 3.10-rc1 2013-04-29 18:38 ` Greg KH @ 2013-04-29 18:55 ` Linus Torvalds 2013-04-29 19:02 ` Linus Torvalds 2013-04-29 19:15 ` Linus Torvalds 0 siblings, 2 replies; 27+ messages in thread From: Linus Torvalds @ 2013-04-29 18:55 UTC (permalink / raw) To: Greg KH Cc: David Brown, Andrew Morton, Arnd Bergmann, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [GIT PATCH] char/misc patches for 3.10-rc1 2013-04-29 18:55 ` Linus Torvalds @ 2013-04-29 19:02 ` Linus Torvalds 2013-04-29 19:15 ` Linus Torvalds 1 sibling, 0 replies; 27+ messages in thread From: Linus Torvalds @ 2013-04-29 19:02 UTC (permalink / raw) To: Greg KH Cc: David Brown, Andrew Morton, Arnd Bergmann, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [GIT PATCH] char/misc patches for 3.10-rc1 2013-04-29 18:55 ` Linus Torvalds 2013-04-29 19:02 ` Linus Torvalds @ 2013-04-29 19:15 ` Linus Torvalds 2013-04-29 19:54 ` Arnd Bergmann 2013-04-29 20:45 ` [GIT PATCH] char/misc patches for 3.10-rc1 Nicolas Pitre 1 sibling, 2 replies; 27+ messages in thread From: Linus Torvalds @ 2013-04-29 19:15 UTC (permalink / raw) To: Greg KH Cc: David Brown, Andrew Morton, Arnd Bergmann, Linux Kernel Mailing List, Nicolas Pitre 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [GIT PATCH] char/misc patches for 3.10-rc1 2013-04-29 19:15 ` Linus Torvalds @ 2013-04-29 19:54 ` Arnd Bergmann 2013-04-29 20:12 ` Linus Torvalds 2013-04-29 20:45 ` [GIT PATCH] char/misc patches for 3.10-rc1 Nicolas Pitre 1 sibling, 1 reply; 27+ messages in thread From: Arnd Bergmann @ 2013-04-29 19:54 UTC (permalink / raw) To: Linus Torvalds Cc: Greg KH, David Brown, Andrew Morton, Linux Kernel Mailing List, Nicolas Pitre 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [GIT PATCH] char/misc patches for 3.10-rc1 2013-04-29 19:54 ` Arnd Bergmann @ 2013-04-29 20:12 ` Linus Torvalds 2013-04-29 20:50 ` Arnd Bergmann 2013-04-29 21:08 ` David Brown 0 siblings, 2 replies; 27+ messages in thread From: Linus Torvalds @ 2013-04-29 20:12 UTC (permalink / raw) To: Arnd Bergmann Cc: Greg KH, David Brown, Andrew Morton, Linux Kernel Mailing List, Nicolas Pitre 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [GIT PATCH] char/misc patches for 3.10-rc1 2013-04-29 20:12 ` Linus Torvalds @ 2013-04-29 20:50 ` Arnd Bergmann 2013-04-29 21:13 ` Linus Torvalds 2013-05-01 16:12 ` Mark Brown 2013-04-29 21:08 ` David Brown 1 sibling, 2 replies; 27+ messages in thread From: Arnd Bergmann @ 2013-04-29 20:50 UTC (permalink / raw) To: Linus Torvalds Cc: Greg KH, David Brown, Andrew Morton, Linux Kernel Mailing List, Nicolas Pitre 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [GIT PATCH] char/misc patches for 3.10-rc1 2013-04-29 20:50 ` Arnd Bergmann @ 2013-04-29 21:13 ` Linus Torvalds 2013-04-29 21:22 ` Arnd Bergmann 2013-05-01 16:12 ` Mark Brown 1 sibling, 1 reply; 27+ messages in thread From: Linus Torvalds @ 2013-04-29 21:13 UTC (permalink / raw) To: Arnd Bergmann Cc: Greg KH, David Brown, Andrew Morton, Linux Kernel Mailing List, Nicolas Pitre 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [GIT PATCH] char/misc patches for 3.10-rc1 2013-04-29 21:13 ` Linus Torvalds @ 2013-04-29 21:22 ` Arnd Bergmann 0 siblings, 0 replies; 27+ messages in thread From: Arnd Bergmann @ 2013-04-29 21:22 UTC (permalink / raw) To: Linus Torvalds Cc: Greg KH, David Brown, Andrew Morton, Linux Kernel Mailing List, Nicolas Pitre 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [GIT PATCH] char/misc patches for 3.10-rc1 2013-04-29 20:50 ` Arnd Bergmann 2013-04-29 21:13 ` Linus Torvalds @ 2013-05-01 16:12 ` Mark Brown 1 sibling, 0 replies; 27+ messages in thread From: Mark Brown @ 2013-05-01 16:12 UTC (permalink / raw) To: Arnd Bergmann Cc: Linus Torvalds, Greg KH, David Brown, Andrew Morton, Linux Kernel Mailing List, Nicolas Pitre [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [GIT PATCH] char/misc patches for 3.10-rc1 2013-04-29 20:12 ` Linus Torvalds 2013-04-29 20:50 ` Arnd Bergmann @ 2013-04-29 21:08 ` David Brown 2013-04-29 21:16 ` Arnd Bergmann 2013-04-29 21:18 ` Linus Torvalds 1 sibling, 2 replies; 27+ messages in thread From: David Brown @ 2013-04-29 21:08 UTC (permalink / raw) To: Linus Torvalds Cc: Arnd Bergmann, Greg KH, Andrew Morton, Linux Kernel Mailing List, Nicolas Pitre, Richard Kuo, linux-hexagon 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [GIT PATCH] char/misc patches for 3.10-rc1 2013-04-29 21:08 ` David Brown @ 2013-04-29 21:16 ` Arnd Bergmann 2013-05-01 16:13 ` Mark Brown 2013-04-29 21:18 ` Linus Torvalds 1 sibling, 1 reply; 27+ messages in thread From: Arnd Bergmann @ 2013-04-29 21:16 UTC (permalink / raw) To: David Brown Cc: Linus Torvalds, Greg KH, Andrew Morton, Linux Kernel Mailing List, Nicolas Pitre, Richard Kuo, linux-hexagon 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [GIT PATCH] char/misc patches for 3.10-rc1 2013-04-29 21:16 ` Arnd Bergmann @ 2013-05-01 16:13 ` Mark Brown 2013-05-02 20:53 ` David Brown 0 siblings, 1 reply; 27+ messages in thread From: Mark Brown @ 2013-05-01 16:13 UTC (permalink / raw) To: Arnd Bergmann Cc: David Brown, Linus Torvalds, Greg KH, Andrew Morton, Linux Kernel Mailing List, Nicolas Pitre, Richard Kuo, linux-hexagon [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [GIT PATCH] char/misc patches for 3.10-rc1 2013-05-01 16:13 ` Mark Brown @ 2013-05-02 20:53 ` David Brown 2013-05-03 8:06 ` Mark Brown 0 siblings, 1 reply; 27+ messages in thread From: David Brown @ 2013-05-02 20:53 UTC (permalink / raw) To: Mark Brown Cc: Arnd Bergmann, Linus Torvalds, Greg KH, Andrew Morton, Linux Kernel Mailing List, Nicolas Pitre, Richard Kuo, linux-hexagon 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [GIT PATCH] char/misc patches for 3.10-rc1 2013-05-02 20:53 ` David Brown @ 2013-05-03 8:06 ` Mark Brown 0 siblings, 0 replies; 27+ messages in thread From: Mark Brown @ 2013-05-03 8:06 UTC (permalink / raw) To: David Brown Cc: Arnd Bergmann, Linus Torvalds, Greg KH, Andrew Morton, Linux Kernel Mailing List, Nicolas Pitre, Richard Kuo, linux-hexagon [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [GIT PATCH] char/misc patches for 3.10-rc1 2013-04-29 21:08 ` David Brown 2013-04-29 21:16 ` Arnd Bergmann @ 2013-04-29 21:18 ` Linus Torvalds 2013-04-29 21:29 ` Arnd Bergmann 2013-04-29 22:00 ` MFD: move ssbi driver into drivers/mfd Arnd Bergmann 1 sibling, 2 replies; 27+ messages in thread From: Linus Torvalds @ 2013-04-29 21:18 UTC (permalink / raw) To: David Brown Cc: Arnd Bergmann, Greg KH, Andrew Morton, Linux Kernel Mailing List, Nicolas Pitre, Richard Kuo, linux-hexagon 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [GIT PATCH] char/misc patches for 3.10-rc1 2013-04-29 21:18 ` Linus Torvalds @ 2013-04-29 21:29 ` Arnd Bergmann 2013-04-29 22:00 ` MFD: move ssbi driver into drivers/mfd Arnd Bergmann 1 sibling, 0 replies; 27+ messages in thread From: Arnd Bergmann @ 2013-04-29 21:29 UTC (permalink / raw) To: Linus Torvalds Cc: David Brown, Greg KH, Andrew Morton, Linux Kernel Mailing List, Nicolas Pitre, Richard Kuo, linux-hexagon 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* MFD: move ssbi driver into drivers/mfd 2013-04-29 21:18 ` Linus Torvalds 2013-04-29 21:29 ` Arnd Bergmann @ 2013-04-29 22:00 ` Arnd Bergmann 2013-04-29 22:10 ` Greg KH ` (4 more replies) 1 sibling, 5 replies; 27+ messages in thread From: Arnd Bergmann @ 2013-04-29 22:00 UTC (permalink / raw) To: Linus Torvalds, Samuel Ortiz Cc: David Brown, Greg KH, Andrew Morton, Linux Kernel Mailing List, Nicolas Pitre, Richard Kuo, linux-hexagon 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 ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: MFD: move ssbi driver into drivers/mfd 2013-04-29 22:00 ` MFD: move ssbi driver into drivers/mfd Arnd Bergmann @ 2013-04-29 22:10 ` Greg KH 2013-04-29 22:48 ` Nicolas Pitre ` (3 subsequent siblings) 4 siblings, 0 replies; 27+ messages in thread From: Greg KH @ 2013-04-29 22:10 UTC (permalink / raw) To: Arnd Bergmann Cc: Linus Torvalds, Samuel Ortiz, David Brown, Andrew Morton, Linux Kernel Mailing List, Nicolas Pitre, Richard Kuo, linux-hexagon 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> ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: MFD: move ssbi driver into drivers/mfd 2013-04-29 22:00 ` MFD: move ssbi driver into drivers/mfd Arnd Bergmann 2013-04-29 22:10 ` Greg KH @ 2013-04-29 22:48 ` Nicolas Pitre 2013-04-30 0:00 ` David Brown ` (2 subsequent siblings) 4 siblings, 0 replies; 27+ messages in thread From: Nicolas Pitre @ 2013-04-29 22:48 UTC (permalink / raw) To: Arnd Bergmann Cc: Linus Torvalds, Samuel Ortiz, David Brown, Greg KH, Andrew Morton, Linux Kernel Mailing List, Richard Kuo, linux-hexagon 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/ > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: MFD: move ssbi driver into drivers/mfd 2013-04-29 22:00 ` MFD: move ssbi driver into drivers/mfd Arnd Bergmann 2013-04-29 22:10 ` Greg KH 2013-04-29 22:48 ` Nicolas Pitre @ 2013-04-30 0:00 ` David Brown 2013-04-30 10:18 ` Samuel Ortiz 2013-05-16 9:49 ` Samuel Ortiz 4 siblings, 0 replies; 27+ messages in thread From: David Brown @ 2013-04-30 0:00 UTC (permalink / raw) To: Arnd Bergmann Cc: Linus Torvalds, Samuel Ortiz, Greg KH, Andrew Morton, Linux Kernel Mailing List, Nicolas Pitre, Richard Kuo, linux-hexagon 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: MFD: move ssbi driver into drivers/mfd 2013-04-29 22:00 ` MFD: move ssbi driver into drivers/mfd Arnd Bergmann ` (2 preceding siblings ...) 2013-04-30 0:00 ` David Brown @ 2013-04-30 10:18 ` Samuel Ortiz 2013-04-30 10:26 ` Arnd Bergmann 2013-05-16 9:49 ` Samuel Ortiz 4 siblings, 1 reply; 27+ messages in thread From: Samuel Ortiz @ 2013-04-30 10:18 UTC (permalink / raw) To: Arnd Bergmann Cc: Linus Torvalds, David Brown, Greg KH, Andrew Morton, Linux Kernel Mailing List, Nicolas Pitre, Richard Kuo, linux-hexagon 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/ ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: MFD: move ssbi driver into drivers/mfd 2013-04-30 10:18 ` Samuel Ortiz @ 2013-04-30 10:26 ` Arnd Bergmann 0 siblings, 0 replies; 27+ messages in thread From: Arnd Bergmann @ 2013-04-30 10:26 UTC (permalink / raw) To: Samuel Ortiz Cc: Linus Torvalds, David Brown, Greg KH, Andrew Morton, Linux Kernel Mailing List, Nicolas Pitre, Richard Kuo, linux-hexagon 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: MFD: move ssbi driver into drivers/mfd 2013-04-29 22:00 ` MFD: move ssbi driver into drivers/mfd Arnd Bergmann ` (3 preceding siblings ...) 2013-04-30 10:18 ` Samuel Ortiz @ 2013-05-16 9:49 ` Samuel Ortiz 4 siblings, 0 replies; 27+ messages in thread From: Samuel Ortiz @ 2013-05-16 9:49 UTC (permalink / raw) To: Arnd Bergmann Cc: Linus Torvalds, David Brown, Greg KH, Andrew Morton, Linux Kernel Mailing List, Nicolas Pitre, Richard Kuo, linux-hexagon 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/ ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [GIT PATCH] char/misc patches for 3.10-rc1 2013-04-29 19:15 ` Linus Torvalds 2013-04-29 19:54 ` Arnd Bergmann @ 2013-04-29 20:45 ` Nicolas Pitre 1 sibling, 0 replies; 27+ messages in thread From: Nicolas Pitre @ 2013-04-29 20:45 UTC (permalink / raw) To: Linus Torvalds Cc: Greg KH, David Brown, Andrew Morton, Arnd Bergmann, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2013-05-16 9:49 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-04-29 16:21 [GIT PATCH] char/misc patches for 3.10-rc1 Greg KH 2013-04-29 18:28 ` Linus Torvalds 2013-04-29 18:38 ` Greg KH 2013-04-29 18:55 ` Linus Torvalds 2013-04-29 19:02 ` Linus Torvalds 2013-04-29 19:15 ` Linus Torvalds 2013-04-29 19:54 ` Arnd Bergmann 2013-04-29 20:12 ` Linus Torvalds 2013-04-29 20:50 ` Arnd Bergmann 2013-04-29 21:13 ` Linus Torvalds 2013-04-29 21:22 ` Arnd Bergmann 2013-05-01 16:12 ` Mark Brown 2013-04-29 21:08 ` David Brown 2013-04-29 21:16 ` Arnd Bergmann 2013-05-01 16:13 ` Mark Brown 2013-05-02 20:53 ` David Brown 2013-05-03 8:06 ` Mark Brown 2013-04-29 21:18 ` Linus Torvalds 2013-04-29 21:29 ` Arnd Bergmann 2013-04-29 22:00 ` MFD: move ssbi driver into drivers/mfd Arnd Bergmann 2013-04-29 22:10 ` Greg KH 2013-04-29 22:48 ` Nicolas Pitre 2013-04-30 0:00 ` David Brown 2013-04-30 10:18 ` Samuel Ortiz 2013-04-30 10:26 ` Arnd Bergmann 2013-05-16 9:49 ` Samuel Ortiz 2013-04-29 20:45 ` [GIT PATCH] char/misc patches for 3.10-rc1 Nicolas Pitre
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).