The usage of gpiochip_find(&gg_data, of_gpiochip_and_xlate) is odd.
Usually gpiochip_find() is used to find a gpio_chip. Here, however,
the return value from gpiochip_find() is just discarded. Instead,
gpiochip_find(&gg_data, of_gpiochip_and_xlate) is called for the
side-effect of the match function.
The match function, of_gpiochip_find_and_xlate(), fills the given
struct gg_data, but a match function should be simply called to
judge the matching.
This commit fixes this distortion and makes the code more readable.
Remove of_gpiochip_find_and_xlate() and struct gg_data. Instead,
this adds a very simple helper function of_find_gpiochip_by_node().
Now, of_get_named_gpiod_flags() is implemented more straight-forward.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Do this sanity check only once when the gpio_chip is added
rather than every time gpio-hog is handled.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This function is doing more complicated than needed. The caller of
this function, of_gpiochip_scan_gpios() already knows the pointer to
the gpio_chip. It can pass it to of_parse_own_gpio() instead of
looking up the gpio_chip by gpiochip_find().
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Call of_property_read_u32_array() only once rather than iterating
of_property_read_u32_index().
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The generic IRQ helper library just checks if the IRQ line is
set as input before activating it for interrupts. As we
recently started to check things better with .get_dir() it
turns out that it's good to try to convince the line to become
an input before attempting to lock it as IRQ.
Reviewed-by: Björn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The lineevent_irq_thread is not exported, so make it static
to fix the following warning:
drivers/gpio/gpiolib.c:654:13: warning: symbol 'lineevent_irq_thread' was not declared. Should it be static?
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When initializing the GPIO handles, we use the iterator (i)
to back off if something goes wrong. But since the iterator
is also used after we pass the loop, we must decrement by
one after exiting the loop so that we point at the last
element in the array.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Walter Harms <wharms@bfs.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gcc reports a theoretical case for returning uninitialized data in
the kfifo when a GPIO interrupt happens and neither
GPIOEVENT_REQUEST_RISING_EDGE nor GPIOEVENT_REQUEST_FALLING_EDGE
are set:
drivers/gpio/gpiolib.c: In function 'lineevent_irq_thread':
drivers/gpio/gpiolib.c:683:87: error: 'ge.id' may be used uninitialized in this function [-Werror=maybe-uninitialized]
This case should not happen, but to be on the safe side, let's
return from the irq handler without adding data to the FIFO
to ensure we can never leak stack data to user space.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 61f922db72 ("gpio: userspace ABI for reading GPIO line events")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The gpio-event-mon is used from userspace as an example of how
to monitor GPIO line events. It will latch on to a certain
GPIO line on a certain gpiochip and print timestamped events
as they arrive.
Example output:
$ gpio-event-mon -n gpiochip2 -o 0 -r -f
Monitoring line 0 on gpiochip2
Initial line value: 1
GPIO EVENT 946685798487609863: falling edge
GPIO EVENT 946685798732482910: rising edge
GPIO EVENT 946685799115997314: falling edge
GPIO EVENT 946685799381469726: rising edge
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This adds an ABI for listening to events on GPIO lines.
The mechanism returns an anonymous file handle to a request
to listen to a specific offset on a specific gpiochip.
To fetch the stream of events from the file handle, userspace
simply reads an event.
- Events can be requested with the same flags as ordinary
handles, i.e. open drain or open source. An ioctl() call
GPIO_GET_LINEEVENT_IOCTL is issued indicating the desired
line.
- Events can be requested for falling edge events, rising
edge events, or both.
- All events are timestamped using the kernel real time
nanosecond timestamp (the same as is used by IIO).
- The supplied consumer label will appear in "lsgpio"
listings of the lines, and in /proc/interrupts as the
mechanism will request an interrupt from the gpio chip.
- Events are not supported on gpiochips that do not serve
interrupts (no legal .to_irq() call). The event interrupt
is threaded to avoid any realtime problems.
- It is possible to also directly read the current value
of the registered GPIO line by issuing the same
GPIOHANDLE_GET_LINE_VALUES_IOCTL as used by the
line handles. Setting the value is not supported: we
do not listen to events on output lines.
This ABI is strongly influenced by Industrial I/O and surpasses
the old sysfs ABI by providing proper precision timestamps,
making it possible to set flags like open drain, and put
consumer names on the GPIO lines.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The gpio-hammer is used from userspace as an example of how
to retrieve a GPIO handle for one or several GPIO lines and
hammer the outputs from low to high and back again. It will
pulse the selected lines once per second for a specified
number of times or indefinitely if no loop count is
supplied.
Example output:
$ gpio-hammer -n gpiochip0 -o5 -o6 -o7
Hammer lines [5, 6, 7] on gpiochip0, initial states: [1, 1, 1]
[-] [5: 0, 6: 0, 7: 0]
Tested-by: Michael Welling <mwelling@ieee.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This adds a userspace ABI for reading and writing GPIO lines.
The mechanism returns an anonymous file handle to a request
to read/write n offsets from a gpiochip. This file handle
in turn accepts two ioctl()s: one that reads and one that
writes values to the selected lines.
- Handles can be requested as input/output, active low,
open drain, open source, however when you issue a request
for n lines with GPIO_GET_LINEHANDLE_IOCTL, they must all
have the same flags, i.e. all inputs or all outputs, all
open drain etc. If a granular control of the flags for
each line is desired, they need to be requested
individually, not in a batch.
- The GPIOHANDLE_GET_LINE_VALUES_IOCTL read ioctl() can be
issued also to output lines to verify that the hardware
is in the expected state.
- It reads and writes up to GPIOHANDLES_MAX lines at once,
utilizing the .set_multiple() call in the driver if
possible, making the call efficient if several lines
can be written with a single register update.
The limitation of GPIOHANDLES_MAX to 64 lines is done under
the assumption that we may expect hardware that can issue a
transaction updating 64 bits at an instant but unlikely
anything larger than that.
ChangeLog v2->v3:
- Use gpiod_get_value_cansleep() so we support also slowpath
GPIO drivers.
- Fix up the UAPI docs kerneldoc.
- Allocate the anonymous fd last, so that the release
function don't get called until that point of something
fails. After this point, skip the errorpath.
ChangeLog v1->v2:
- Handle ioctl_compat() properly based on a similar patch
to the other ioctl() handling code.
- Use _IOWR() as we pass pointers both in and out of the
ioctl()
- Use kmalloc() and kfree() for the linehandled, do not
try to be fancy with devm_* it doesn't work the way I
thought.
- Fix const-correctness on the linehandle name field.
Acked-by: Michael Welling <mwelling@ieee.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Intel Edison board has 4 GPIO expanders PCA9555a connected to I2C bus. Add an
ID to support them.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
On Acer One 10, the ACPI battery driver can not be probed because
it depends on the GPIO controller as well as the I2C controller to work,
Device (BATC)
{
Name (_HID, EisaId ("PNP0C0A") /* Control Method Battery */)
...
Name (_DEP, Package (0x03) // _DEP: Dependencies
{
I2C1,
GPO2,
GPO0
})
...
}
The I2C dependency also exists on other platforms and has been fixed by commit
40e7fcb192 ("ACPI: Add _DEP support to fix battery issue on Asus T100TA"),
this patch resolves the GPIO dependency for Acer One 10.
Link:https://bugzilla.kernel.org/show_bug.cgi?id=115191
Tested-by: Stace A. Zacharov <stace75@gmail.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When CONFIG_GPIOLIB is not set make will still descend into the gpio
directory but nothing will be built. This produces unneeded build
artifacts and messages in addition to slowing the build. Fix this here.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
NBANK() macro assumes that ngpios is a multiple of 8(BANK_SZ) and
hence results in 0 banks for PCA9536 which has just 4 gpios. This is
wrong as PCA9356 has 1 bank with 4 gpios. This results in uninitialized
PCA953X_INVERT register. Fix this by using DIV_ROUND_UP macro in
NBANK().
Cc: stable@vger.kernel.org
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch adds support for the Western Digital's
MyBook Live memory-mapped GPIO controllers.
The GPIOs will be supported by the generic driver
for memory-mapped GPIO controllers.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch adds support for defining memory-mapped GPIOs which
are compatible with the existing gpio-mmio interface. The generic
library provides support for many memory-mapped GPIO controllers
that are found in various on-board FPGA and ASIC solutions that
are used to control board's switches, LEDs, chip-selects,
Ethernet/USB PHY power, etc.
For setting GPIOs there are three configurations:
1. single input/output register resource (named "dat"),
2. set/clear pair (named "set" and "clr"),
3. single output register resource and single input resource
("set" and dat").
The configuration is detected by which resources are present.
For the single output register, this drives a 1 by setting a bit
and a zero by clearing a bit. For the set clr pair, this drives
a 1 by setting a bit in the set register and clears it by setting
a bit in the clear register.
For setting the GPIO direction, there are three configurations:
a. simple bidirectional GPIOs that requires no configuration.
b. an output direction register (named "dirout")
where a 1 bit indicates the GPIO is an output.
c. an input direction register (named "dirin")
where a 1 bit indicates the GPIO is an input.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Kconfig currently controlling compilation of this code is:
config GPIO_LPC18XX
bool "NXP LPC18XX/43XX GPIO support"
...meaning that it currently is not being built as a module by anyone.
When targeting orphaned modular code in non-modular drivers, this
came up. Joachim indicated that the driver was actually meant to
be tristate but ended up bool by accident. So here we make it
tristate instead of removing the modular code that was essentially
orphaned.
Cc: Joachim Eastwood <manabian@gmail.com>
Acked-by: Joachim Eastwood <manabian@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Add ACPI support for GPIO controller on Broadcom Vulcan ARM64.
ACPI ID for this device is BRCM9006.
Signed-off-by: Kamlakant Patel <kamlakant.patel@broadcom.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
irq_alloc_descs need not be called in case of Vulcan, where we use
a dynamic IRQ range for GPIO interrupt numbers.
Update code not to call irq_alloc_descs and pass 0 as irq_base in
case of Vulcan.
Signed-off-by: Kamlakant Patel <kamlakant.patel@broadcom.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Since board support for the CLPS711X platform was removed,
remove the board support from the driver.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch changes the compatibility string to match with the smallest
supported chip (EP7209). Since the DT-support for this CPU is not yet
announced, this change is safe.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch changes the compatibility string to match with the smallest
supported chip (EP7209). Since the DT-support for this CPU is not yet
announced, this change is safe.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Add function to set multiple GPIO of the same chip at the same time
and register it
Signed-off-by: Iban Rodriguez <irodriguez@cemitec.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The commit 9b8e3ec343 ("gpio: pca953x: Use correct u16 value for register
word write") fixed regression in pca953x_write_regs(). At the same time the
solution introduced a sparse warning:
drivers/gpio/gpio-pca953x.c:168:39: warning: incorrect type in argument 3 (different base types)
drivers/gpio/gpio-pca953x.c:168:39: expected unsigned short [unsigned] [usertype] value
drivers/gpio/gpio-pca953x.c:168:39: got restricted __le16 [usertype] <noident>
Fix the code by enforcing the type of i2c_smbus_write_word_data() parameter.
Cc: Yong Li <sdliyong@gmail.com>
Cc: Phil Reid <preid@electromag.com.au>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This symbols is not needed to get access to selecting the
GPIOLIB anymore: any arch can select GPIOLIB.
Cc: Michael Büsch <m@bues.ch>
Cc: Michal Simek <monstr@monstr.eu>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This symbols is not needed to get access to selecting the
GPIOLIB anymore: any arch can select GPIOLIB.
Cc: Michael Büsch <m@bues.ch>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: linux-ia64@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Replace "select ARCH_REQUIRE_GPIOLIB" with "select GPIOLIB"
as this can now be selected directly.
Cc: Michael Büsch <m@bues.ch>
Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This replaces:
- "select ARCH_REQUIRE_GPIOLIB" with "select GPIOLIB" as this can
now be selected directly.
- "select ARCH_WANT_OPTIONAL_GPIOLIB" with no dependency: GPIOLIB
is now selectable by everyone, so we need not declare our
intent to select it.
When ordering the symbols the following rationale was used:
if the selects were in alphabetical order, I moved select GPIOLIB
to be in alphabetical order, but if the selects were not
maintained in alphabetical order, I just replaced
"select ARCH_REQUIRE_GPIOLIB" with "select GPIOLIB".
Cc: Michael Büsch <m@bues.ch>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Rich Felker <dalias@libc.org>
Cc: linux-sh@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This replaces:
- "select ARCH_REQUIRE_GPIOLIB" with "select GPIOLIB" as this can
now be selected directly.
- "select ARCH_WANT_OPTIONAL_GPIOLIB" with no dependency: GPIOLIB
is now selectable by everyone, so we need not declare our
intent to select it.
When ordering the symbols the following rationale was used:
if the selects were in alphabetical order, I moved select GPIOLIB
to be in alphabetical order, but if the selects were not
maintained in alphabetical order, I just replaced
"select ARCH_REQUIRE_GPIOLIB" with "select GPIOLIB".
Cc: Michael Büsch <m@bues.ch>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Replace "select ARCH_REQUIRE_GPIOLIB" with "select GPIOLIB"
as this can now be selected directly.
Cc: Michael Büsch <m@bues.ch>
Cc: Jonas Bonn <jonas@southpole.se>
Cc: linux@lists.openrisc.net
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Avoid a gpiochip_free() and use standard functions.
Cc: John Crispin <blogic@openwrt.org>
Cc: Pramod Gurav <pramod.gurav@smartplayin.com>
Cc: Martin Schiller <mschiller@tdt.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
There are few redundant assignments of ret variable which is updated anyway.
Remove them for good.
While here, correct indentation of the constant definition and remove one empty
line.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The symbol that will be selected when GPIO is implemented
for Hexagon will be GPIOLIB, we have removed
ARCH_REQUIRE_GPIOLIB and ARCH_WANT_OPTIONAL_GPIOLIB.
Cc: Michael Büsch <m@bues.ch>
Cc: Richard Kuo <rkuo@codeaurora.org>
Cc: linux-hexagon@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The reset values for all the PCF lines are high and hence on
shutdown we should drive all the lines high in order to
bring it to the reset state.
This is actually required since PCF doesn't have a reset
line and even after warm reset (by invoking "reboot" in
prompt) the PCF lines maintains it's previous programmed
state. This becomes a problem if the boards are designed to
work with the default initial state.
DRA7XX_evm uses PCF8575 and one of the PCF output lines
feeds to MMC/SD VDD and this line should be driven high in order
for the MMC/SD to be detected. This line is modelled as
regulator and the hsmmc driver takes care of enabling and
disabling it. In the case of 'reboot', during shutdown path
as part of it's cleanup process the hsmmc driver disables
this regulator. This makes MMC *boot* not functional.
Fix it by driving all the pcf lines high.
This patch was sent long back
(https://patchwork.ozlabs.org/patch/420382/)
But there was a concern that contention might occur if the
PCF shutdown handler is invoked before the shutdown handler
of the PCF's consumers. In that case PCF shutdown handler can't
drive all the pcf lines high without knowing if the PCF
consumers are still active.
However commit 52cdbdd498 ("driver core: correct device's
shutdown order") will make sure shutdown handler of PCF's
consumers are invoked before invoking the shutdown
handler of PCF. So it should be safe to merge this now.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
A platform_driver need not set an owner since it will be populated
by platform_driver_register().
Likewise for mcb_driver (gpio-menz127.c).
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
As the comment block of of_parse_phandle_with_fixed_args() says,
the caller is responsible to call of_node_put() on the returned
node when done.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The MAX77620 have a GPIO pins which can act as open drain or
push pull mode. Implement support for controlling this from GPIO
descriptor tables or other hardware descriptions such as
device tree by implementing the .set_single_ended() callback.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The GPIO sub modules of MAX77620 offers to configure the GPIO
interrupt trigger level as RISING and FALLING edge.
Pass this information to regmap-irg when registering for GPIO
interrupts.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This implements the .get_direction() callback for the STMPE
expander GPIO.
Cc: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
TI PCA9536 is 4-Bit I2C GPIO expander without interrupt support[1].
Add support for the same.
[1] TRM: http://www.ti.com/lit/ds/symlink/pca9536.pdf
Signed-off-by: Vignesh R <vigneshr@ti.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
MAXIM Semiconductor's PMIC, MAX77620/MAX20024 has 8 GPIO
pins. It also supports interrupts from these pins.
Add GPIO driver for these pins to control via GPIO APIs.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Maxim Semiconductor's PMIC MAX77620/MAX20024 has 8 GPIO pins
which act as GPIO as well as special function mode.
Add DT binding document to support these pins in GPIO
mode via GPIO framework.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Pull parisc fixes from Helge Deller:
- Fix printk time stamps on SMP systems which got wrong due to a patch
which was added during the merge window
- Fix two bugs in the stack backtrace code: Races in module unloading
and possible invalid accesses to memory due to wrong instruction
decoding (Mikulas Patocka)
- Fix userspace crash when syscalls access invalid unaligned userspace
addresses. Those syscalls will now return EFAULT as expected.
(tagged for stable kernel series)
* 'parisc-4.7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
parisc: Move die_if_kernel() prototype into traps.h header
parisc: Fix pagefault crash in unaligned __get_user() call
parisc: Fix printk time during boot
parisc: Fix backtrace on PA-RISC
Pull key handling update from James Morris:
"This alters a new keyctl function added in the current merge window to
allow for a future extension planned for the next merge window"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security:
KEYS: Add placeholder for KDF usage with DH
The /dev/ptmx device node is changed to lookup the directory entry "pts"
in the same directory as the /dev/ptmx device node was opened in. If
there is a "pts" entry and that entry is a devpts filesystem /dev/ptmx
uses that filesystem. Otherwise the open of /dev/ptmx fails.
The DEVPTS_MULTIPLE_INSTANCES configuration option is removed, so that
userspace can now safely depend on each mount of devpts creating a new
instance of the filesystem.
Each mount of devpts is now a separate and equal filesystem.
Reserved ttys are now available to all instances of devpts where the
mounter is in the initial mount namespace.
A new vfs helper path_pts is introduced that finds a directory entry
named "pts" in the directory of the passed in path, and changes the
passed in path to point to it. The helper path_pts uses a function
path_parent_directory that was factored out of follow_dotdot.
In the implementation of devpts:
- devpts_mnt is killed as it is no longer meaningful if all mounts of
devpts are equal.
- pts_sb_from_inode is replaced by just inode->i_sb as all cached
inodes in the tty layer are now from the devpts filesystem.
- devpts_add_ref is rolled into the new function devpts_ptmx. And the
unnecessary inode hold is removed.
- devpts_del_ref is renamed devpts_release and reduced to just a
deacrivate_super.
- The newinstance mount option continues to be accepted but is now
ignored.
In devpts_fs.h definitions for when !CONFIG_UNIX98_PTYS are removed as
they are never used.
Documentation/filesystems/devices.txt is updated to describe the current
situation.
This has been verified to work properly on openwrt-15.05, centos5,
centos6, centos7, debian-6.0.2, debian-7.9, debian-8.2, ubuntu-14.04.3,
ubuntu-15.10, fedora23, magia-5, mint-17.3, opensuse-42.1,
slackware-14.1, gentoo-20151225 (13.0?), archlinux-2015-12-01. With the
caveat that on centos6 and on slackware-14.1 that there wind up being
two instances of the devpts filesystem mounted on /dev/pts, the lower
copy does not end up getting used.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Greg KH <greg@kroah.com>
Cc: Peter Hurley <peter@hurleysoftware.com>
Cc: Peter Anvin <hpa@zytor.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Serge Hallyn <serge.hallyn@ubuntu.com>
Cc: Willy Tarreau <w@1wt.eu>
Cc: Aurelien Jarno <aurelien@aurel32.net>
Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Cc: Jann Horn <jann@thejh.net>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Florian Weimer <fw@deneb.enyo.de>
Cc: Konstantin Khlebnikov <koct9i@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
