* [GIT PULL] GPIO bulk changes for kernel v4.6
@ 2016-03-17 8:59 Linus Walleij
2016-03-18 6:07 ` Linus Torvalds
0 siblings, 1 reply; 16+ messages in thread
From: Linus Walleij @ 2016-03-17 8:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linux-gpio, Laxman Dewangan
Hi Linus,
here is the big bulk of changes for kernel v4.6. There is quite a lot
of interesting stuff going on.
NOTE: tree was a bit dirty and I realized it too late: Laxmans
devm_gpiochip_add() branch was based on my for-next branch rather
than my devel branch, making some commits appear twice and
a file named README.md "Share upstreaming patches" appear and
then get reverted out by me.
The end result should be clean but the history is a bit messy.
If you prefer that I rebase the tree and remove the noise, just tell me
and I'll do that and send an updated pull request. I didn't want to
unnecessarily disturb the tested tree at this point. Maybe I'm doing
the wrong thing, tell me.
On top of this I pulled an immutable branch from Lee Jones, so
an MFD and regulator driver may first appear through this tree
or already be in your tree, a bit of race to the line as usual with
these cross-subsystem things. I guess it would need to be
re-pulled if I rebase, etc, sigh.
The patches to other subsystems and arch-wide are ACKed as far
as possible, though I consider things like per-arch <asm/gpio.h> as
essentially a part of the GPIO subsystem so it should not be needed.
The meat of the new stuff is in the signed tag.
Greg gave a nod to the new device/chardev code:
http://marc.info/?l=linux-gpio&m=144564661321472&w=2
Please pull it in, or tell me to go rebase my stuff.
Yours,
Linus Walleij
The following changes since commit 36f90b0a2ddd60823fe193a85e60ff1906c2a9b3:
Linux 4.5-rc2 (2016-01-31 18:12:16 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
tags/gpio-v4.6-1
for you to fetch changes up to ccbd805aa934dd1b863ef115a9c55f119b2388cf:
Revert "Share upstreaming patches" (2016-03-17 09:36:09 +0100)
----------------------------------------------------------------
This is the bulk of GPIO changes for kernel v4.6:
Core changes:
- The gpio_chip is now a *real device*. Until now the gpio chips
were just piggybacking the parent device or (gasp) floating in
space outside of the device model. We now finally make GPIO chips
devices. The gpio_chip will create a gpio_device which contains
a struct device, and this gpio_device struct is kept private.
Anything that needs to be kept private from the rest of the kernel
will gradually be moved over to the gpio_device.
- As a result of making the gpio_device a real device, we have added
resource management, so devm_gpiochip_add_data() will cut down on
overhead and reduce code lines. A huge slew of patches convert
almost all drivers in the subsystem to use this.
- Building on making the GPIO a real device, we add the first step
of a new userspace ABI: the GPIO character device. We take small
steps here, so we first add a pure *information* ABI and the tool
"lsgpio" that will list all GPIO devices on the system and all
lines on these devices. We can now discover GPIOs properly from
userspace. We still have not come up with a way to actually *use*
GPIOs from userspace.
- To encourage people to use the character device for the future,
we have it always-enabled when using GPIO. The old sysfs ABI is
still opt-in (and can be used in parallel), but is marked as
deprecated. We will keep it around for the foreseeable future,
but it will not be extended to cover ever more use cases.
Cleanup:
- Bjorn Helgaas removed a whole slew of per-architecture <asm/gpio.h>
includes. This dates back to when GPIO was an opt-in feature and
no shared library even existed: just a header file with proper
prototypes was provided and all semantics were up to the arch to
implement. These patches make the GPIO chip even more a proper
device and cleans out leftovers of the old in-kernel API here
and there. Still some cruft is left but it's very little now.
- There is still some clamping of return values for .get() going
on, but we now return sane values in the vast majority of drivers
and the errorpath is sanitized. Some patches for powerpc, blackfin
and unicore still drop in.
- We continue to switch the ARM, MIPS, blackfin, m68k local GPIO
implementations to use gpiochip_add_data() and cut down on code
lines.
- MPC8xxx is converted to use the generic GPIO helpers.
- ATH79 is converted to use the generic GPIO helpers.
New drivers:
- WinSystems WS16C48
- Acces 104-DIO-48E
- F81866 (a F7188x variant)
- Qoric (a MPC8xxx variant)
- TS-4800
- SPI serializers (pisosr): simple 74xx shift registers connected
to SPI to obtain a dirt-cheap output-only GPIO expander.
- Texas Instruments TPIC2810
- Texas Instruments TPS65218
- Texas Instruments TPS65912
- X-Gene (ARM64) standby GPIO controller
----------------------------------------------------------------
Alban Bedel (5):
gpio: ath79: Move to the generic GPIO driver
gpio: ath79: Allow building in compile tests
gpio: ath79: Make the driver removable
gpio: ath79: Add support for the interrupt controller
gpio: ath79: Update the copyright notice
Amitoj Kaur Chawla (1):
gpio: timberdale: Switch to devm_ioremap_resource()
Andreas Werner (1):
gpio: add driver for MEN 16Z127 GPIO controller
Andrew F. Davis (8):
gpio: Add driver for SPI serializers
gpio: Add driver for TI TPIC2810
Documentation: tps65912: Add DT bindings for the TPS65912 PMIC
mfd: tps65912: Remove old driver in preparation for new driver
mfd: tps65912: Add driver for the TPS65912 PMIC
regulator: tps65912: Add regulator driver for the TPS65912 PMIC
gpio: tps65912: Add GPIO driver for the TPS65912 PMIC
gpio: Add generic serializer DT binding
Andrzej Hajda (2):
gpio: xgene: fix type of variable containing error codes
gpio: xgene: fix type of variable containing error codes
Arnd Bergmann (3):
gpio: remove broken irq_to_gpio() interface
gpio: ks8695: remove irq_to_gpio function
gpio: allow setting ARCH_NR_GPIOS from Kconfig
Axel Lin (18):
gpio: tpic2810: Make tpic2810_direction_output set proper output level
gpio: tps65218: Make tps65218_gpio_output set proper output level
gpio: ath79: Check valid gpio count for both DT and non-DT cases
gpio: brcmstb: Use list_for_each_entry at appropriate places
gpio: ts4800: Drop redundant code to set already initialized
gpio_chip fields
gpio: pisosr: Use devm_gpiod_get_optional for gpio->load_gpio
gpio: ath79: Check valid gpio count for both DT and non-DT cases
gpio: brcmstb: Use list_for_each_entry at appropriate places
gpio: ts4800: Drop redundant code to set already initialized
gpio_chip fields
gpio: pisosr: Use devm_gpiod_get_optional for gpio->load_gpio
gpio: pisosr: Use gpiod_set_value_cansleep in pisosr_gpio_refresh()
gpio: mb86s7x: Allow compile test build
gpio: moxart: Drop redundant code to set already initialized
gpio_chip fields
gpio: moxart: Allow compile test build
gpio: lp3943: Drop pin_used and lp3943_gpio_request/lp3943_gpio_free
gpio: mpc8xxx: Fixup setting gpio direction output
gpio: mpc8xxx: Remove *read_reg and *write_reg from struct
mpc8xxx_gpio_chip
gpio: mpc8xxx: Slightly update the code for better readability
Bamvor Jian Zhang (3):
gpiolib: fix crash when gpiochip removed
gpio: fix abi regression in sysfs
gpiolib: rewrite gpiodev_add_to_list
Bjorn Helgaas (2):
gpio: Include linux/gpio.h instead of asm/gpio.h
gpio: Remove unused asm/gpio.h files
Gabor Juhos (1):
gpio: documenatation: fix GPIO_LOOKUP{,_IDX} documentation
Geert Uytterhoeven (4):
gpio: Propagate all errors in devm_get_gpiod_from_child()
gpio: rcar: Add Runtime PM handling for interrupts
gpio: pca953x: Fix pca953x_gpio_set_multiple() on 64-bit
gpiolib: Fix comment referring to gpio_*() in gpiod_*()
Geliang Tang (1):
gpio: davinci: use irq_data_get_chip_type
Grygorii Strashko (1):
gpio: omap: drop dev field from gpio_bank structure
Insu Yun (1):
gpio-mcp23s08: correctly handling failed allocation
Josh Cartwright (1):
gpio: use kzalloc to allocate gpio_device
Julien Grossholtz (4):
gpio: add bindings for TS-4800 gpio controller
gpio: add TS-4800 fpga GPIO support
gpio: TS-4800: remove useless bgpio_init flags
gpio: ts4800: Add IMX51 dependency
Keerthy (1):
gpio: davinci: Add the missing of-node pointer
Laxman Dewangan (60):
Merge remote-tracking branch 'linusw-gpio/for-next' into devm_gpiochip
gpio: Add devm_ apis for gpiochip_add_data and gpiochip_remove
gpio: Add resource management devm_gpio_chip_{add_data,remove}
gpio: Add missing devm_gpio_ wrapper in devres.txt
gpio: 74xx-mmio: Use devm_gpiochip_add_data() for gpio registration
gpio: adnp: Use devm_gpiochip_add_data() for gpio registration
gpio: adp5520: Use devm_gpiochip_add_data() for gpio registration
gpio: adp5588: Use devm_gpiochip_add_data() for gpio registration
gpio: arizona: Use devm_gpiochip_add_data() for gpio registration
gpio: bcm-kona: Use devm_gpiochip_add_data() for gpio registration
gpio: clps711x: Use devm_gpiochip_add_data() for gpio registration
gpio: crystalcove: Use devm_gpiochip_add_data() for gpio registration
gpio: cs5535: Use devm_gpiochip_add_data() for gpio registration
gpio: da9052: Use devm_gpiochip_add_data() for gpio registration
gpio: da9055: Use devm_gpiochip_add_data() for gpio registration
gpio: dln2: Use devm_gpiochip_add_data() for gpio registration
gpio: ep93xx: Use devm_gpiochip_add_data() for gpio registration
gpio: f7188x: Use devm_gpiochip_add_data() for gpio registration
gpio: ge: Use devm_gpiochip_add_data() for gpio registration
gpio: generic: Use devm_gpiochip_add_data() for gpio registration
gpio: iop: Use devm_gpiochip_add_data() for gpio registration
gpio: janz-ttl: Use devm_gpiochip_add_data() for gpio registration
gpio: kempld: Use devm_gpiochip_add_data() for gpio registration
gpio: lp3943: Use devm_gpiochip_add_data() for gpio registration
gpio: lpc32xx: Use devm_gpiochip_add_data() for gpio registration
gpio: lynxpoint: Use devm_gpiochip_add_data() for gpio registration
gpio: mc9s08dz60: Use devm_gpiochip_add_data() for gpio registration
gpio: moxart: Use devm_gpiochip_add_data() for gpio registration
gpio: mvebu: Use devm_gpiochip_add_data() for gpio registration
gpio: mxc: Use devm_gpiochip_add_data() for gpio registration
gpio: octeon: Use devm_gpiochip_add_data() for gpio registration
gpio: pca953x: Use devm_gpiochip_add_data() for gpio registration
gpio: pcf857x: Use devm_gpiochip_add_data() for gpio registration
gpio: palmas: Use devm_gpiochip_add_data() for gpio registration
gpio: rc5t583: Use devm_gpiochip_add_data() for gpio registration
gpio: rdc321x: Use devm_gpiochip_add_data() for gpio registration
gpio: sch: Use devm_gpiochip_add_data() for gpio registration
gpio: spear-spics: Use devm_gpiochip_add_data() for gpio registration
gpio: sta2x11: Use devm_gpiochip_add_data() for gpio registration
gpio: stp-xway: Use devm_gpiochip_add_data() for gpio registration
gpio: sx150x: Use devm_gpiochip_add_data() for gpio registration
gpio: syscon: Use devm_gpiochip_add_data() for gpio registration
gpio: tb10x: Use devm_gpiochip_add_data() for gpio registration
gpio: tc3589x: Use devm_gpiochip_add_data() for gpio registration
gpio: tegra: Use devm_gpiochip_add_data() for gpio registration
gpio: timberdale Use devm_gpiochip_add_data() for gpio registration
gpio: tps6586x: Use devm_gpiochip_add_data() for gpio registration
gpio: tps65910: Use devm_gpiochip_add_data() for gpio registration
gpio: tps65912: Use devm_gpiochip_add_data() for gpio registration
gpio: ts4800: Use devm_gpiochip_add_data() for gpio registration
gpio: ts5500: Use devm_gpiochip_add_data() for gpio registration
gpio: twl6040: Use devm_gpiochip_add_data() for gpio registration
gpio: ucb1400: Use devm_gpiochip_add_data() for gpio registration
gpio: viperboard: Use devm_gpiochip_add_data() for gpio registration
gpio: vx855: Use devm_gpiochip_add_data() for gpio registration
gpio: wm8350: Use devm_gpiochip_add_data() for gpio registration
gpio: wm8350: Use devm_gpiochip_add_data() for gpio registration
gpio: wm8994: Use devm_gpiochip_add_data() for gpio registration
gpio: xgene-sb: Use devm_gpiochip_add_data() for gpio registration
gpio: xgene: Use devm_gpiochip_add_data() for gpio registration
Linus Walleij (57):
blackfin: gpio: Be sure to clamp return value
powerpc: ppc4cc/gpio: Be sure to clamp return value
powerpc: qe_lib/gpio: Be sure to clamp return value
powerpc: simple_gpio: Be sure to clamp return value
unicore: gpio: Be sure to clamp return value
Merge branch 'error-return-from-get' into devel
gpio: make the gpiochip a real device
gpio: refer to gpio device in prints and debugfs
gpio: add a userspace chardev ABI for GPIOs
tools/gpio: create GPIO tools
gpio: add a userspace character device ABI
gpio: ABI: mark the sysfs ABI as obsolete
Merge branch 'chardev' into devel
gpio: remember to finally free gpio_device
gpio: move sysfs mock device to the gpio_device
gpio: move descriptors into gpio_device
gpio/pinctrl: sunxi: stop poking around in private vars
gpio: reflect base and ngpio into gpio_device
gpio: reference count the gpio device for each desc
pinctrl: sirf/atlas7: stop poking around in GPIO internals
gpio: move the pin ranges into gpio_device
gpio: move the subdriver data pointer into gpio_device
gpio: create an API to detect open drain/source on lines
gpio: tps65218: remove unused #include
gpio: store reflect the label to userspace
gpio: add userspace ABI for GPIO line information
pinctrl: cygnus-gpio: use gpiochip data pointer
ARM: scoop: use gpiochip data pointer
ARM: gemini: switch to gpiochip_add_data()
ARM: imx: switch to gpiochip_add_data()
ARM: ixp4xx: switch to gpiochip_add_data()
ARM: s3c24xx: switch to gpiochip_add_data()
ARM: simpad: switch to gpiochip_add_data()
ARM: w90x900: use gpiochip data pointer
ARM: plat-orion: use gpiochip data pointer
blackfin: gpio: switch to gpiochip_add_data()
blackfin: extgpio: switch to gpiochip_add_data()
m68k: gpio: switch to gpiochip_add_data()
MIPS: alchemy: switch to gpiochip_add_data()
MIPS: ar7: use gpiochip data pointer
MIPS: bcm63xx: switch to gpiochip_add_data()
MIPS: jz4740: use gpiochip data pointer
MIPS: txx9: switch to gpiochip_add_data()
MIPS: rb532: use gpiochip data pointer
MIPS: txx9: iocled: use gpiochip data pointer
MIPS: txx9: rbtx4938: switch to gpiochip_add_data()
Revert "gpio: remove broken irq_to_gpio() interface"
gpio: fixup line flags for userspace ABI
Merge branch 'devel' into for-next
Merge branch 'devm_gpiochip' of
https://github.com/ldewangan/linux-upstream into
devm-gpiochip-add-data
gpio: present the consumer of a line to userspace
Merge branch 'devm-gpiochip-add-data' into devel
Merge branch 'ib-mfd-regulator-gpio-4.6' of
git://git.kernel.org/.../lee/mfd into devel
Revert "gpio: lp3943: Drop pin_used and
lp3943_gpio_request/lp3943_gpio_free"
gpio: tps65912: fix bad merge
gpio: uapi: use 0xB4 as ioctl() major
Revert "Share upstreaming patches"
Liu Gang (2):
gpio/qoriq: Add qoriq platforms support
drivers/gpio: Switch gpio-mpc8xxx to use gpio-generic
Lokesh Vutla (1):
gpio: davinci: Fix the number of controllers allocated
Marek Vasut (1):
dt-bindings: gpio: altera: Fix altr,interrupt-type property
Markus Pargmann (1):
tools: gpio: Small updates for output format
Matthias Brugger (1):
gpio: xgene: Fix kconfig for standby GIPO contoller
Nicholas Krause (1):
gpio: davinci: Fix possible NULL pointer deference
Nicolas Saenz Julienne (1):
gpio: add tps65218 gpio
Peter Hung (1):
gpio-f7188x: Add F81866 GPIO supports
Phil Reid (3):
gpio: gpio-altera: Remove gpiochip on probe failure.
gpio: mcp23s08: Add support for mcp23s18
gpio: mcp23s08: Fix clearing of interrupt.
Quan Nguyen (2):
gpio: xgene: Enable X-Gene standby GPIO as interrupt controller
gpio: X-Gene standby GPIO controller DTS binding
Ralf Baechle (1):
MIPS: jz4740: Fix surviving instance of irq_to_gpio()
Simon Horman (2):
gpio: rcar: Use ARCH_RENESAS
gpio: rcar: Use ARCH_RENESAS
Sudip Mukherjee (1):
gpio: pisosr: add missing unlock
William Breathitt Gray (11):
gpio: 104-idi-48: Allow IRQ sharing
gpio: Add GPIO support for the WinSystems WS16C48
gpio: Add GPIO support for the ACCES 104-DIO-48E
gpio: misc: Pass correct license string to MODULE_LICENSE
gpio: 104-dio-48e: Use devm_request_region
gpio: 104-idi-48: Use devm_request_region
gpio: 104-idio-16: Use devm_request_region
gpio: amd8111: Use devm_request_region
gpio: ich: Use devm_request_region
gpio: sch311x: Use devm_request_region
gpio: ws16c48: Use devm_request_region
ldewangan (1):
Share upstreaming patches
Documentation/ABI/{testing => obsolete}/sysfs-gpio | 4 +-
Documentation/ABI/testing/gpio-cdev | 26 +
.../devicetree/bindings/gpio/gpio-altera.txt | 4 +-
.../devicetree/bindings/gpio/gpio-mcp23s08.txt | 4 +-
.../devicetree/bindings/gpio/gpio-pisosr.txt | 34 +
.../devicetree/bindings/gpio/gpio-ts4800.txt | 20 +
.../devicetree/bindings/gpio/gpio-xgene-sb.txt | 47 +-
Documentation/devicetree/bindings/mfd/tps65912.txt | 50 ++
Documentation/driver-model/devres.txt | 5 +
Documentation/gpio/board.txt | 11 +-
Documentation/ioctl/ioctl-number.txt | 1 +
MAINTAINERS | 16 +
arch/alpha/include/asm/gpio.h | 4 -
arch/arm/common/scoop.c | 10 +-
arch/arm/mach-gemini/gpio.c | 4 +-
arch/arm/mach-imx/mach-mx27ads.c | 4 +-
arch/arm/mach-ixp4xx/common.c | 4 +-
arch/arm/mach-s3c24xx/mach-h1940.c | 2 +-
arch/arm/mach-sa1100/simpad.c | 4 +-
arch/arm/mach-w90x900/gpio.c | 13 +-
arch/arm/plat-orion/gpio.c | 24 +-
arch/avr32/boards/merisc/setup.c | 1 -
arch/avr32/mach-at32ap/pio.c | 2 +-
arch/blackfin/kernel/bfin_gpio.c | 6 +-
arch/blackfin/kernel/debug-mmrs.c | 2 +-
arch/blackfin/mach-bf538/boards/ezkit.c | 2 +-
arch/blackfin/mach-bf538/ext-gpio.c | 8 +-
arch/blackfin/mach-bf548/boards/cm_bf548.c | 2 +-
arch/blackfin/mach-bf548/boards/ezkit.c | 2 +-
arch/blackfin/mach-bf609/boards/ezkit.c | 2 +-
arch/blackfin/mach-common/ints-priority.c | 2 +-
arch/blackfin/mach-common/pm.c | 2 +-
arch/ia64/include/asm/gpio.h | 4 -
arch/m68k/coldfire/gpio.c | 2 +-
arch/metag/include/asm/gpio.h | 4 -
arch/microblaze/include/asm/gpio.h | 4 -
arch/mips/alchemy/common/gpiolib.c | 8 +-
arch/mips/ar7/gpio.c | 26 +-
arch/mips/bcm63xx/gpio.c | 4 +-
arch/mips/jz4740/gpio.c | 12 +-
arch/mips/kernel/gpio_txx9.c | 4 +-
arch/mips/rb532/gpio.c | 12 +-
arch/mips/txx9/generic/setup.c | 10 +-
arch/mips/txx9/rbtx4938/setup.c | 3 +-
arch/openrisc/include/asm/gpio.h | 4 -
arch/powerpc/include/asm/gpio.h | 4 -
arch/powerpc/sysdev/ppc4xx_gpio.c | 2 +-
arch/powerpc/sysdev/simple_gpio.c | 2 +-
arch/sh/include/mach-common/mach/magicpanelr2.h | 2 +-
arch/sparc/include/asm/gpio.h | 4 -
arch/unicore32/kernel/gpio.c | 2 +-
arch/x86/include/asm/gpio.h | 4 -
arch/xtensa/include/asm/gpio.h | 4 -
drivers/ata/pata_at91.c | 3 +-
drivers/ata/pata_bf54x.c | 2 +-
drivers/gpio/Kconfig | 85 ++-
drivers/gpio/Makefile | 9 +-
drivers/gpio/devres.c | 2 +-
drivers/gpio/gpio-104-dio-48e.c | 430 +++++++++++
drivers/gpio/gpio-104-idi-48.c | 30 +-
drivers/gpio/gpio-104-idio-16.c | 27 +-
drivers/gpio/gpio-74xx-mmio.c | 11 +-
drivers/gpio/gpio-adnp.c | 11 +-
drivers/gpio/gpio-adp5520.c | 13 +-
drivers/gpio/gpio-adp5588.c | 4 +-
drivers/gpio/gpio-altera.c | 5 +-
drivers/gpio/gpio-amd8111.c | 7 +-
drivers/gpio/gpio-arizona.c | 12 +-
drivers/gpio/gpio-ath79.c | 264 +++++--
drivers/gpio/gpio-bcm-kona.c | 2 +-
drivers/gpio/gpio-brcmstb.c | 13 +-
drivers/gpio/gpio-clps711x.c | 11 +-
drivers/gpio/gpio-crystalcove.c | 9 +-
drivers/gpio/gpio-cs5535.c | 20 +-
drivers/gpio/gpio-da9052.c | 11 +-
drivers/gpio/gpio-da9055.c | 16 +-
drivers/gpio/gpio-davinci.c | 12 +-
drivers/gpio/gpio-dln2.c | 16 +-
drivers/gpio/gpio-ep93xx.c | 2 +-
drivers/gpio/gpio-f7188x.c | 53 +-
drivers/gpio/gpio-ge.c | 2 +-
drivers/gpio/gpio-generic.c | 11 +-
drivers/gpio/gpio-ich.c | 51 +-
drivers/gpio/gpio-iop.c | 2 +-
drivers/gpio/gpio-janz-ttl.c | 12 +-
drivers/gpio/gpio-kempld.c | 11 +-
drivers/gpio/gpio-ks8695.c | 12 -
drivers/gpio/gpio-lp3943.c | 12 +-
drivers/gpio/gpio-lpc32xx.c | 2 +-
drivers/gpio/gpio-lynxpoint.c | 4 +-
drivers/gpio/gpio-mc9s08dz60.c | 13 +-
drivers/gpio/gpio-mcp23s08.c | 25 +-
drivers/gpio/gpio-menz127.c | 200 +++++
drivers/gpio/gpio-moxart.c | 5 +-
drivers/gpio/gpio-mpc5200.c | 1 -
drivers/gpio/gpio-mpc8xxx.c | 255 +++----
drivers/gpio/gpio-mvebu.c | 11 +-
drivers/gpio/gpio-mxc.c | 6 +-
drivers/gpio/gpio-octeon.c | 10 +-
drivers/gpio/gpio-omap.c | 57 +-
drivers/gpio/gpio-palmas.c | 12 +-
drivers/gpio/gpio-pca953x.c | 10 +-
drivers/gpio/gpio-pcf857x.c | 10 +-
drivers/gpio/gpio-pisosr.c | 183 +++++
drivers/gpio/gpio-rc5t583.c | 12 +-
drivers/gpio/gpio-rcar.c | 42 ++
drivers/gpio/gpio-rdc321x.c | 13 +-
drivers/gpio/gpio-sch.c | 11 +-
drivers/gpio/gpio-sch311x.c | 8 +-
drivers/gpio/gpio-spear-spics.c | 2 +-
drivers/gpio/gpio-sta2x11.c | 2 +-
drivers/gpio/gpio-stp-xway.c | 2 +-
drivers/gpio/gpio-sx150x.c | 18 +-
drivers/gpio/gpio-syscon.c | 11 +-
drivers/gpio/gpio-tb10x.c | 22 +-
drivers/gpio/gpio-tc3589x.c | 13 +-
drivers/gpio/gpio-tegra.c | 2 +-
drivers/gpio/gpio-timberdale.c | 25 +-
drivers/gpio/gpio-tpic2810.c | 170 +++++
drivers/gpio/gpio-tps65218.c | 222 ++++++
drivers/gpio/gpio-tps6586x.c | 12 +-
drivers/gpio/gpio-tps65910.c | 12 +-
drivers/gpio/gpio-tps65912.c | 174 +++--
drivers/gpio/gpio-ts4800.c | 81 ++
drivers/gpio/gpio-ts5500.c | 9 +-
drivers/gpio/gpio-twl6040.c | 9 +-
drivers/gpio/gpio-ucb1400.c | 3 +-
drivers/gpio/gpio-viperboard.c | 24 +-
drivers/gpio/gpio-vx855.c | 12 +-
drivers/gpio/gpio-wm831x.c | 12 +-
drivers/gpio/gpio-wm8350.c | 12 +-
drivers/gpio/gpio-wm8994.c | 17 +-
drivers/gpio/gpio-ws16c48.c | 427 +++++++++++
drivers/gpio/gpio-xgene-sb.c | 266 ++++++-
drivers/gpio/gpio-xgene.c | 11 +-
drivers/gpio/gpiolib-acpi.c | 18 +-
drivers/gpio/gpiolib-sysfs.c | 51 +-
drivers/gpio/gpiolib.c | 822 +++++++++++++++------
drivers/gpio/gpiolib.h | 79 +-
drivers/mfd/Kconfig | 20 +-
drivers/mfd/Makefile | 3 +-
drivers/mfd/menelaus.c | 2 +-
drivers/mfd/tps65912-core.c | 240 +++---
drivers/mfd/tps65912-i2c.c | 162 ++--
drivers/mfd/tps65912-irq.c | 217 ------
drivers/mfd/tps65912-spi.c | 160 ++--
drivers/mtd/onenand/omap2.c | 2 +-
drivers/pcmcia/bfin_cf_pcmcia.c | 2 +-
drivers/pcmcia/pxa2xx_vpac270.c | 1 -
drivers/pinctrl/bcm/pinctrl-iproc-gpio.c | 33 +-
drivers/pinctrl/sirf/pinctrl-atlas7.c | 18 -
drivers/pinctrl/sunxi/pinctrl-sunxi.c | 4 +-
drivers/regulator/Kconfig | 2 +-
drivers/regulator/tps65912-regulator.c | 613 +++------------
drivers/soc/fsl/qe/gpio.c | 2 +-
drivers/usb/gadget/udc/atmel_usba_udc.c | 2 -
drivers/usb/host/ohci-at91.c | 2 -
drivers/video/fbdev/atmel_lcdfb.c | 2 -
drivers/video/fbdev/omap/lcd_h3.c | 2 +-
drivers/video/fbdev/omap/lcd_osk.c | 3 +-
drivers/video/fbdev/omap/lcd_palmtt.c | 2 +-
include/asm-generic/gpio.h | 4 +
include/linux/gpio/driver.h | 39 +-
include/linux/mfd/tps65912.h | 209 +++---
include/uapi/linux/Kbuild | 1 +
include/uapi/linux/gpio.h | 58 ++
tools/Makefile | 8 +-
tools/gpio/Makefile | 12 +
tools/gpio/gpio-utils.c | 11 +
tools/gpio/gpio-utils.h | 27 +
tools/gpio/lsgpio.c | 195 +++++
171 files changed, 4455 insertions(+), 2669 deletions(-)
rename Documentation/ABI/{testing => obsolete}/sysfs-gpio (88%)
create mode 100644 Documentation/ABI/testing/gpio-cdev
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-pisosr.txt
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-ts4800.txt
create mode 100644 Documentation/devicetree/bindings/mfd/tps65912.txt
delete mode 100644 arch/alpha/include/asm/gpio.h
delete mode 100644 arch/ia64/include/asm/gpio.h
delete mode 100644 arch/metag/include/asm/gpio.h
delete mode 100644 arch/microblaze/include/asm/gpio.h
delete mode 100644 arch/openrisc/include/asm/gpio.h
delete mode 100644 arch/powerpc/include/asm/gpio.h
delete mode 100644 arch/sparc/include/asm/gpio.h
delete mode 100644 arch/x86/include/asm/gpio.h
delete mode 100644 arch/xtensa/include/asm/gpio.h
create mode 100644 drivers/gpio/gpio-104-dio-48e.c
create mode 100644 drivers/gpio/gpio-menz127.c
create mode 100644 drivers/gpio/gpio-pisosr.c
create mode 100644 drivers/gpio/gpio-tpic2810.c
create mode 100644 drivers/gpio/gpio-tps65218.c
create mode 100644 drivers/gpio/gpio-ts4800.c
create mode 100644 drivers/gpio/gpio-ws16c48.c
delete mode 100644 drivers/mfd/tps65912-irq.c
create mode 100644 include/uapi/linux/gpio.h
create mode 100644 tools/gpio/Makefile
create mode 100644 tools/gpio/gpio-utils.c
create mode 100644 tools/gpio/gpio-utils.h
create mode 100644 tools/gpio/lsgpio.c
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [GIT PULL] GPIO bulk changes for kernel v4.6
2016-03-18 6:07 ` Linus Torvalds
@ 2016-03-18 6:07 ` Laxman Dewangan
2016-03-18 7:15 ` Linus Torvalds
2016-03-18 9:01 ` Linus Walleij
1 sibling, 1 reply; 16+ messages in thread
From: Laxman Dewangan @ 2016-03-18 6:07 UTC (permalink / raw)
To: Linus Torvalds, Linus Walleij; +Cc: linux-kernel, linux-gpio
On Friday 18 March 2016 11:37 AM, Linus Torvalds wrote:
> On Thu, Mar 17, 2016 at 1:59 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
>> NOTE: tree was a bit dirty and I realized it too late: Laxmans
>> devm_gpiochip_add() branch was based on my for-next branch rather
>> than my devel branch, making some commits appear twice and
>> a file named README.md "Share upstreaming patches" appear and
>> then get reverted out by me.
>>
>> The end result should be clean but the history is a bit messy.
> Gaah. I took the tree, but I didn't realize just *how* messy it was. I
> doubt you did either.
>
> Dammit, had I realized just how screwed up that branch was, I'd have
> made you re-do it.
>
> Because that branch is crap.
>
> And the real reason is is crap isn't a "README.md" file that comes and
> goes. The real reason it is crap is that it has a new root commit, and
> Laxman has done something TOTALLY INSANE.
>
> I'm not even sure what insane tool was used to do this, but there's a
> new root commit at
>
> a101ad945113be3d7f283a181810d76897f0a0d6
>
> that has no parenthood, and that is only used for a completely bogus
> merge (merge commit e5451c8f8330e03ad3cfa16048b4daf961af434f). That's
> where the README.md file comes from.
>
> Git does support the notion of having multiple roots, and it is a
> useful thing to have when you merge two different projects with
> separate history. In fact, git itself has that, for 'gitk' that was
> merged into the main git history.
>
> We have that in the kernel for the initial btrfs merge too, actually.
> btrfs started out outside the full kernel, and had a root of its own
> with its own development history, and then it was merged into the
> kernel tree under fs/btrfs.
>
> But this is *not* that. That commit
> a101ad945113be3d7f283a181810d76897f0a0d6 is just pure garbage, and the
> merge that introduces it is pure shit.
>
> Dammit, I noticed too late, so now it's out there. How the hell did
> that even happen? Why did Laxman do that insane merge? Why did it get
> pulled back?
>
> You actually have to *work* at making shit like this, so I wonder what
> workflow you guys had to make that bad merge. It's easy enough to do
> with git manually, but it's hard to do by _mistake_. Is there some
> broken tool that Laxman uses?
>
> I'm very annoyed, because while the multi-root situation can be
> useful, it can also be confusing as hell. It can cause bisection
> problems, and it can just cause people to go "WTF?"
>
> I need to know what happened and make sure it doesn't happen again. If
> this is some intentional workflow by nvidia, it needs to stop *now*.
> It's broken shit.
>
For creating the repo and branch, I just followed the instruction from wiki
https://help.github.com/articles/create-a-repo/
and for pushing changes
https://help.github.com/articles/fork-a-repo/
I jut use git (git version 2.1.4) for pushing the changes in github repo.
There is no other tools used.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [GIT PULL] GPIO bulk changes for kernel v4.6
2016-03-17 8:59 [GIT PULL] GPIO bulk changes for kernel v4.6 Linus Walleij
@ 2016-03-18 6:07 ` Linus Torvalds
2016-03-18 6:07 ` Laxman Dewangan
2016-03-18 9:01 ` Linus Walleij
0 siblings, 2 replies; 16+ messages in thread
From: Linus Torvalds @ 2016-03-18 6:07 UTC (permalink / raw)
To: Linus Walleij; +Cc: linux-kernel, linux-gpio, Laxman Dewangan
On Thu, Mar 17, 2016 at 1:59 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> NOTE: tree was a bit dirty and I realized it too late: Laxmans
> devm_gpiochip_add() branch was based on my for-next branch rather
> than my devel branch, making some commits appear twice and
> a file named README.md "Share upstreaming patches" appear and
> then get reverted out by me.
>
> The end result should be clean but the history is a bit messy.
Gaah. I took the tree, but I didn't realize just *how* messy it was. I
doubt you did either.
Dammit, had I realized just how screwed up that branch was, I'd have
made you re-do it.
Because that branch is crap.
And the real reason is is crap isn't a "README.md" file that comes and
goes. The real reason it is crap is that it has a new root commit, and
Laxman has done something TOTALLY INSANE.
I'm not even sure what insane tool was used to do this, but there's a
new root commit at
a101ad945113be3d7f283a181810d76897f0a0d6
that has no parenthood, and that is only used for a completely bogus
merge (merge commit e5451c8f8330e03ad3cfa16048b4daf961af434f). That's
where the README.md file comes from.
Git does support the notion of having multiple roots, and it is a
useful thing to have when you merge two different projects with
separate history. In fact, git itself has that, for 'gitk' that was
merged into the main git history.
We have that in the kernel for the initial btrfs merge too, actually.
btrfs started out outside the full kernel, and had a root of its own
with its own development history, and then it was merged into the
kernel tree under fs/btrfs.
But this is *not* that. That commit
a101ad945113be3d7f283a181810d76897f0a0d6 is just pure garbage, and the
merge that introduces it is pure shit.
Dammit, I noticed too late, so now it's out there. How the hell did
that even happen? Why did Laxman do that insane merge? Why did it get
pulled back?
You actually have to *work* at making shit like this, so I wonder what
workflow you guys had to make that bad merge. It's easy enough to do
with git manually, but it's hard to do by _mistake_. Is there some
broken tool that Laxman uses?
I'm very annoyed, because while the multi-root situation can be
useful, it can also be confusing as hell. It can cause bisection
problems, and it can just cause people to go "WTF?"
I need to know what happened and make sure it doesn't happen again. If
this is some intentional workflow by nvidia, it needs to stop *now*.
It's broken shit.
Linus
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [GIT PULL] GPIO bulk changes for kernel v4.6
2016-03-18 6:07 ` Laxman Dewangan
@ 2016-03-18 7:15 ` Linus Torvalds
2016-03-18 14:32 ` Johannes Schindelin
0 siblings, 1 reply; 16+ messages in thread
From: Linus Torvalds @ 2016-03-18 7:15 UTC (permalink / raw)
To: Laxman Dewangan, Junio C Hamano
Cc: Linus Walleij, linux-kernel, linux-gpio, Git Mailing List
On Thu, Mar 17, 2016 at 11:07 PM, Laxman Dewangan <ldewangan@nvidia.com> wrote:
>
> For creating the repo and branch, I just followed the instruction from wiki
> https://help.github.com/articles/create-a-repo/
So you shouldn't have created a new repo at all, you should just have
cloned an existing one (that gets you a repo, of course).
You basically ended up starting a new project.
But I guess the github connection explains why there was a crazy
README.md file there, and I can see why that documentation would make
you think it's the right thing to do.
Oh well.
Just a "git init" wouldn't have done that kind of damage, the github
documentation is just misleading in this respect.
We may have to make it really really really clear for the kernel that
people should not use github in any way except purely for hosting..
> I jut use git (git version 2.1.4) for pushing the changes in github repo.
>
> There is no other tools used.
I thought git didn't merge two branches that have no common base by
default, but it seems it will happily do so.
So once you made the mistake of starting a new project, git merge
ended up "helpfully" allowing you to merge the remote tracking branch
into that new project, and we ended up with a silly new root.
"git pull-request" will complain about not having a commit in common,
but "git merge" apparently does not even warn.
Adding Junio and the git list. This seems like much too easy a way to screw up.
Junio (and git people), the problem is that github seems to have
caused Laxman to think he should start a new project, and then git
happily merged the new root just because nobody knew better. And
sadly, I didn't notice the history screw-up until too late, so now we
in the kernel have a third root commit (the first two are
intentional): commit a101ad945113 was merged by commit e5451c8f8330.
So how about a patch something like this:
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -1398,7 +1398,7 @@ int cmd_merge(int argc, const char **argv,
const char *prefix)
NULL, 0, UPDATE_REFS_DIE_ON_ERR);
if (remoteheads && !common)
- ; /* No common ancestors found. We need a real merge. */
+ die(_("No common ancestor - not merging"));
else if (!remoteheads ||
(!remoteheads->next && !common->next &&
common->item == remoteheads->item)) {
(the above is explicitly whitespace-damaged on purpose - it's not
meant as a serious patch, because we do want the *ability* to merge
different projects across different roots, and there are even git
tests for it, it's just that I think it's too easy to make this
mistake and not even realize).
So the real thing having a special option required to merge
non-related projects? Or at least a humongous warning?
You can recreate (for testing only!) this by doing this in a kernel repo:
git checkout a101ad945113
git merge 3cf42efc3479
and you'll see how it happily ends up creating a merge commit with no
common ancestors and no warning that anything might be wrong. It will
take a while - walking all the way up to the root to not find the
common object - but it will happily merge those two totally unrelated
branches without complaining at all.
Now I'm starting to wonder just how many github projects have lots of
separate root commits..
Linus
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [GIT PULL] GPIO bulk changes for kernel v4.6
2016-03-18 6:07 ` Linus Torvalds
2016-03-18 6:07 ` Laxman Dewangan
@ 2016-03-18 9:01 ` Linus Walleij
2016-03-18 9:39 ` Laxman Dewangan
1 sibling, 1 reply; 16+ messages in thread
From: Linus Walleij @ 2016-03-18 9:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linux-gpio, Laxman Dewangan
On Fri, Mar 18, 2016 at 7:07 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, Mar 17, 2016 at 1:59 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
>>
>> The end result should be clean but the history is a bit messy.
>
> Gaah. I took the tree, but I didn't realize just *how* messy it was. I
> doubt you did either.
Certainly not. I wasn't even aware that things could be screwed up so
much and still look OK on the surface. I'll certainly be more cautious
about pulling branches in the future.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [GIT PULL] GPIO bulk changes for kernel v4.6
2016-03-18 9:01 ` Linus Walleij
@ 2016-03-18 9:39 ` Laxman Dewangan
2016-03-18 15:56 ` Linus Torvalds
0 siblings, 1 reply; 16+ messages in thread
From: Laxman Dewangan @ 2016-03-18 9:39 UTC (permalink / raw)
To: Linus Walleij, Linus Torvalds; +Cc: linux-kernel, linux-gpio
On Friday 18 March 2016 02:31 PM, Linus Walleij wrote:
> On Fri, Mar 18, 2016 at 7:07 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>> On Thu, Mar 17, 2016 at 1:59 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
>>> The end result should be clean but the history is a bit messy.
>> Gaah. I took the tree, but I didn't realize just *how* messy it was. I
>> doubt you did either.
> Certainly not. I wasn't even aware that things could be screwed up so
> much and still look OK on the surface. I'll certainly be more cautious
> about pulling branches in the future.
>
Apologizing for the trouble created by me. I understand from other mail
that It seems I have misguided by the step mentioned in github document
and so created the issue. I will not use github as mentioned by Linus T.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [GIT PULL] GPIO bulk changes for kernel v4.6
2016-03-18 7:15 ` Linus Torvalds
@ 2016-03-18 14:32 ` Johannes Schindelin
2016-03-18 15:43 ` Junio C Hamano
2016-03-18 15:47 ` Linus Torvalds
0 siblings, 2 replies; 16+ messages in thread
From: Johannes Schindelin @ 2016-03-18 14:32 UTC (permalink / raw)
To: Linus Torvalds
Cc: Laxman Dewangan, Junio C Hamano, Linus Walleij, linux-kernel,
linux-gpio, Git Mailing List
Hi Linus,
On Fri, 18 Mar 2016, Linus Torvalds wrote:
> I thought git didn't merge two branches that have no common base by
> default, but it seems it will happily do so.
What happened to "The coolest merge EVER!"?
http://thread.gmane.org/gmane.comp.version-control.git/5126/
Ciao,
Dscho
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [GIT PULL] GPIO bulk changes for kernel v4.6
2016-03-18 14:32 ` Johannes Schindelin
@ 2016-03-18 15:43 ` Junio C Hamano
2016-03-18 15:47 ` Linus Torvalds
1 sibling, 0 replies; 16+ messages in thread
From: Junio C Hamano @ 2016-03-18 15:43 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Linus Torvalds, Laxman Dewangan, Linus Walleij, linux-kernel,
linux-gpio, Git Mailing List
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi Linus,
>
> On Fri, 18 Mar 2016, Linus Torvalds wrote:
>
>> I thought git didn't merge two branches that have no common base by
>> default, but it seems it will happily do so.
>
> What happened to "The coolest merge EVER!"?
>
> http://thread.gmane.org/gmane.comp.version-control.git/5126/
>
> Ciao,
> Dscho
An obvious response to the above, "What about it?", is something you
would have already anticipated when you wrote the above, and I wish
I saw that in the message I am responding to, but I didn't, so here
is my attempt ;-)
The old article shows two interesting things. One is that there are
cases where it makes perfect sense to bind two unrelated histories
when the two roots are totally unrelated.
I am not Linus, but I think the proposal is to make it harder to do
this unusual merge by mistake, while keeping it possible to do so
when the user really wants to. And the "deliberately whitespace
damaged patch" in the message you are responding to was primarily to
point out where the "making it harder" logic should go by showing
how to make it impossible, leaving it to readers to adjust it to
"harder but still possible".
Now, the second thing that the old article you pointed shows is that
it is possible to create such a merge without using "git merge" even
though it is more involved and takes conscious effort by the user.
In that sense, you could argue that, with the "make it impossible"
change in Linus's message to "git merge", there is no more change
needed (I do not know if that is what you meant to imply, though).
I think it makes sense to teach "git merge" to error out like Linus
did unless the user explicitly says "I know what I am doing" with an
explicit option (e.g. --force or --merge-unrelated-histories).
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [GIT PULL] GPIO bulk changes for kernel v4.6
@ 2016-03-18 15:43 ` Junio C Hamano
0 siblings, 0 replies; 16+ messages in thread
From: Junio C Hamano @ 2016-03-18 15:43 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Linus Torvalds, Laxman Dewangan, Linus Walleij, linux-kernel,
linux-gpio, Git Mailing List
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi Linus,
>
> On Fri, 18 Mar 2016, Linus Torvalds wrote:
>
>> I thought git didn't merge two branches that have no common base by
>> default, but it seems it will happily do so.
>
> What happened to "The coolest merge EVER!"?
>
> http://thread.gmane.org/gmane.comp.version-control.git/5126/
>
> Ciao,
> Dscho
An obvious response to the above, "What about it?", is something you
would have already anticipated when you wrote the above, and I wish
I saw that in the message I am responding to, but I didn't, so here
is my attempt ;-)
The old article shows two interesting things. One is that there are
cases where it makes perfect sense to bind two unrelated histories
when the two roots are totally unrelated.
I am not Linus, but I think the proposal is to make it harder to do
this unusual merge by mistake, while keeping it possible to do so
when the user really wants to. And the "deliberately whitespace
damaged patch" in the message you are responding to was primarily to
point out where the "making it harder" logic should go by showing
how to make it impossible, leaving it to readers to adjust it to
"harder but still possible".
Now, the second thing that the old article you pointed shows is that
it is possible to create such a merge without using "git merge" even
though it is more involved and takes conscious effort by the user.
In that sense, you could argue that, with the "make it impossible"
change in Linus's message to "git merge", there is no more change
needed (I do not know if that is what you meant to imply, though).
I think it makes sense to teach "git merge" to error out like Linus
did unless the user explicitly says "I know what I am doing" with an
explicit option (e.g. --force or --merge-unrelated-histories).
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [GIT PULL] GPIO bulk changes for kernel v4.6
2016-03-18 14:32 ` Johannes Schindelin
2016-03-18 15:43 ` Junio C Hamano
@ 2016-03-18 15:47 ` Linus Torvalds
2016-03-18 16:37 ` Junio C Hamano
1 sibling, 1 reply; 16+ messages in thread
From: Linus Torvalds @ 2016-03-18 15:47 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Laxman Dewangan, Junio C Hamano, Linus Walleij, linux-kernel,
linux-gpio, Git Mailing List
On Fri, Mar 18, 2016 at 7:32 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> On Fri, 18 Mar 2016, Linus Torvalds wrote:
>
>> I thought git didn't merge two branches that have no common base by
>> default, but it seems it will happily do so.
>
> What happened to "The coolest merge EVER!"?
>
> http://thread.gmane.org/gmane.comp.version-control.git/5126/
I'm not complaining about multi-root capability in general - it's
still cool. In the kernel, we have aef8755711a2 ("Merge Btrfs into
fs/btrfs") that does something slightly similar.
It's literally just the fact that "git merge" does it with no extra
flags or checks. I'd like people to have to be aware of what they are
doing when they merge two different projects, not do it by mistake.
So making it conditional on a flag like "--no-common-root" is what I'd look for.
Or just make it about the merge stategy. For example, "subtree" makes
sense exactly for merging one project into a subdirectory of another.
But the default merge shouldn't do it.
I don't think the original "resolve" did it, for example. You can't do
a three-way merge without a base.
Note how that above "coolest merge" definitely wasn't done by just
"git merge gitk". I had to play around with the git internals. Now, it
shouldn't be _that_ hard, but at the same time it really shouldn't be
as easy as "I didn't know, so I merged two independent projects".
Linus
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [GIT PULL] GPIO bulk changes for kernel v4.6
2016-03-18 9:39 ` Laxman Dewangan
@ 2016-03-18 15:56 ` Linus Torvalds
0 siblings, 0 replies; 16+ messages in thread
From: Linus Torvalds @ 2016-03-18 15:56 UTC (permalink / raw)
To: Laxman Dewangan; +Cc: Linus Walleij, linux-kernel, linux-gpio
On Fri, Mar 18, 2016 at 2:39 AM, Laxman Dewangan <ldewangan@nvidia.com> wrote:
>
> Apologizing for the trouble created by me.
Don't worry about it, we'll just have to make sure it doesn't happen again.
I thought you must have had done something special to do this, and
that made me upset.
But the fact that it was just a trivial and explainable mistake makes
it slightly sad, but "mistakes happen".
I'll push to get it harder to make this mistake in git, and that will
be part of the "let's make sure it doesn't happen again".
We have other ugly history issues. I don't like it, and I wish I had
caught this earlier (or better yet, somebody else had), but it's water
under the bridge.
Linus
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [GIT PULL] GPIO bulk changes for kernel v4.6
2016-03-18 15:47 ` Linus Torvalds
@ 2016-03-18 16:37 ` Junio C Hamano
0 siblings, 0 replies; 16+ messages in thread
From: Junio C Hamano @ 2016-03-18 16:37 UTC (permalink / raw)
To: Linus Torvalds
Cc: Johannes Schindelin, Laxman Dewangan, Linus Walleij,
linux-kernel, linux-gpio, Git Mailing List
Linus Torvalds <torvalds@linux-foundation.org> writes:
> It's literally just the fact that "git merge" does it with no extra
> flags or checks. I'd like people to have to be aware of what they are
> doing when they merge two different projects, not do it by mistake.
>
> So making it conditional on a flag like "--no-common-root" is what I'd look for.
I think I said essentially the same thing in a separate message; I
am not sure "--no-common-root" is a good name, but I think it is
better to be more explicit than tying this to a strategy.
> I don't think the original "resolve" did it, for example. You can't do
> a three-way merge without a base.
Yes, and that continues to this day:
# Give up if we are given two or more remotes -- not handling octopus.
case "$remotes" in
?*' '?*)
exit 2 ;;
esac
# Give up if this is a baseless merge.
if test '' = "$bases"
then
exit 2
fi
This is a tangent but I wonder if we should say why we refuse to
the standard error before calling these two "exit"s.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [GIT PULL] GPIO bulk changes for kernel v4.6
@ 2016-03-18 16:37 ` Junio C Hamano
0 siblings, 0 replies; 16+ messages in thread
From: Junio C Hamano @ 2016-03-18 16:37 UTC (permalink / raw)
To: Linus Torvalds
Cc: Johannes Schindelin, Laxman Dewangan, Linus Walleij,
linux-kernel, linux-gpio, Git Mailing List
Linus Torvalds <torvalds@linux-foundation.org> writes:
> It's literally just the fact that "git merge" does it with no extra
> flags or checks. I'd like people to have to be aware of what they are
> doing when they merge two different projects, not do it by mistake.
>
> So making it conditional on a flag like "--no-common-root" is what I'd look for.
I think I said essentially the same thing in a separate message; I
am not sure "--no-common-root" is a good name, but I think it is
better to be more explicit than tying this to a strategy.
> I don't think the original "resolve" did it, for example. You can't do
> a three-way merge without a base.
Yes, and that continues to this day:
# Give up if we are given two or more remotes -- not handling octopus.
case "$remotes" in
?*' '?*)
exit 2 ;;
esac
# Give up if this is a baseless merge.
if test '' = "$bases"
then
exit 2
fi
This is a tangent but I wonder if we should say why we refuse to
the standard error before calling these two "exit"s.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [GIT PULL] GPIO bulk changes for kernel v4.6
2016-03-18 16:37 ` Junio C Hamano
(?)
@ 2016-03-18 17:01 ` Linus Torvalds
2016-03-18 17:16 ` Junio C Hamano
-1 siblings, 1 reply; 16+ messages in thread
From: Linus Torvalds @ 2016-03-18 17:01 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Laxman Dewangan, Linus Walleij,
linux-kernel, linux-gpio, Git Mailing List
On Fri, Mar 18, 2016 at 9:37 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
>> I don't think the original "resolve" did it, for example. You can't do
>> a three-way merge without a base.
>
> Yes, and that continues to this day:
Yeah, "octopus" also refuses it cleanly:
common=$(git merge-base --all $SHA1 $MRC) ||
die "Unable to find common commit with $pretty_name"
The code in the recursive merge that allows this to happen is this:
if (merged_common_ancestors == NULL) {
/* if there is no common ancestor, use an empty tree */
struct tree *tree;
tree = lookup_tree(EMPTY_TREE_SHA1_BIN);
merged_common_ancestors = make_virtual_commit(tree, "ancestor");
}
so the "no common ancestors" is just considered to be an empty merge base.
And I do think that's right, and I think it's clever, and it goes back to 2006:
934d9a24078e merge-recur: if there is no common ancestor, fake empty one
but I think there should be an option there.
> This is a tangent but I wonder if we should say why we refuse to
> the standard error before calling these two "exit"s.
As mentioned, Octopus does.
That said, there's probably no reason to ever use the old three-way
merge, so I'm not even sure it's worth fixing the old
git-merge-resolve.
Linus
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [GIT PULL] GPIO bulk changes for kernel v4.6
2016-03-18 17:01 ` Linus Torvalds
@ 2016-03-18 17:16 ` Junio C Hamano
0 siblings, 0 replies; 16+ messages in thread
From: Junio C Hamano @ 2016-03-18 17:16 UTC (permalink / raw)
To: Linus Torvalds
Cc: Johannes Schindelin, Laxman Dewangan, Linus Walleij,
linux-kernel, linux-gpio, Git Mailing List
Linus Torvalds <torvalds@linux-foundation.org> writes:
> The code in the recursive merge that allows this to happen is this:
> ...
> And I do think that's right, and I think it's clever, and it goes back to 2006:
>
> 934d9a24078e merge-recur: if there is no common ancestor, fake empty one
>
> but I think there should be an option there.
Oh, I think everybody understands that and agrees by now.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [GIT PULL] GPIO bulk changes for kernel v4.6
@ 2016-03-18 17:16 ` Junio C Hamano
0 siblings, 0 replies; 16+ messages in thread
From: Junio C Hamano @ 2016-03-18 17:16 UTC (permalink / raw)
To: Linus Torvalds
Cc: Johannes Schindelin, Laxman Dewangan, Linus Walleij,
linux-kernel, linux-gpio, Git Mailing List
Linus Torvalds <torvalds@linux-foundation.org> writes:
> The code in the recursive merge that allows this to happen is this:
> ...
> And I do think that's right, and I think it's clever, and it goes back to 2006:
>
> 934d9a24078e merge-recur: if there is no common ancestor, fake empty one
>
> but I think there should be an option there.
Oh, I think everybody understands that and agrees by now.
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2016-03-18 17:17 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-03-17 8:59 [GIT PULL] GPIO bulk changes for kernel v4.6 Linus Walleij
2016-03-18 6:07 ` Linus Torvalds
2016-03-18 6:07 ` Laxman Dewangan
2016-03-18 7:15 ` Linus Torvalds
2016-03-18 14:32 ` Johannes Schindelin
2016-03-18 15:43 ` Junio C Hamano
2016-03-18 15:43 ` Junio C Hamano
2016-03-18 15:47 ` Linus Torvalds
2016-03-18 16:37 ` Junio C Hamano
2016-03-18 16:37 ` Junio C Hamano
2016-03-18 17:01 ` Linus Torvalds
2016-03-18 17:16 ` Junio C Hamano
2016-03-18 17:16 ` Junio C Hamano
2016-03-18 9:01 ` Linus Walleij
2016-03-18 9:39 ` Laxman Dewangan
2016-03-18 15:56 ` Linus Torvalds
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.