[PATCH v14 00/11] mux controller abstraction and iio/i2c muxes

[Peter Rosin]

Hi!

The big change since v13 is that the mux state is now locked with a mutex
instead of an rwsem. Other that that, it is mostly restructuring and doc
changes. There are a few other "real" changes as well, but those changes
feel kind of minor. I guess what I'm trying to say is that although the
list of changes for v14 is longish, it's still basically the same as last
time.

Jonathan, I hope it was OK to keep your Reviewed-by tag on patch 03/11
(mux-core.c plus support) and to also add it to 04/11 (mux-gpio.c) even
if the previously reviewed patch (mux-core.c + mux-gpio.c) was split in
two?

v13 -> v14 changes
- Go back to a mutex instead of a rwsem to protect the mux state. [Greg K-H]
- Add __must_check to the mux_control_select function. [Greg, was this what
  you meant with "sparse markings"? I assume not, but I don't know...]
- Don't return hint on mux state changes when calling mux_control_select. [Greg]
- Add mux_control_try_select function. [Philipp Zabel]
- Split the mux.h #include into mux/driver.h and mux/consumer.h [Philipp]
- Add mux_control_states function to be able to completely hide struct
  mux_control details from mux consumers.
- Include the constants from the DT bindings include, instead of
  redefining them. [Greg]
- Make mux_chip_alloc (and devm_mux_chip_alloc) return ERR_PTR instead
  of NULL on error. [Greg]
- Document why mux_chip_alloc and mux_chip_register are split up, and
  what is supposed to happen between the two calls, [Greg] and...
- ...specifically mention that mux drivers should never clobber
  cached_state [Philipp].
- Support module unloading of the core (and initialize mux_ida on init). [Greg]
- Do not mention link order when commenting on why there is a subsys_initcall
  instead of an ordinare module_init in the mux-core. [Greg]
- Use __func__ instead of spelling out the function name. [Greg]
- Drop cargo cult usage of WARN_ON. [Greg]
- Drop unused forward declaration of struct platform_device.
- Move kernel doc from the function declarations to the definitions. [Greg]
- Use unsigned values for the state in the consumer interface. [Philipp]
- WARN if consumers request an invalid state. [Philipp]
- Split out mux-gpio from the core patch (03/10 -> 03/11 and 04/11). [Greg]
- Drop OF Kconfig dep from mux-gpio. [Greg]
- Fail the adg792a probe if the I2C adapter does not support
  I2C_FUNC_SMBUS_BYTE_DATA.
- For clarity, handle the adg792a active low reset bit in a helper function.
- Make use of the preexisting mux variable in the adg792a driver instead of
  chasing the same pointers a second time.
- Use device_property_read_* instead of of_property_read_* in adg792a.
- Added a "thank you" section to the patch adding the mux core (patch 03/11).


This adds a new mux controller subsystem with an interface for accessing
mux controllers, along with two drivers providing the interface (gpio
and adg792) and two consumers (iio and i2c). This is done in such a way
that several consumers can independently access the same mux controller
if one controller controls several multiplexers, thus allowing sharing.
But sharing is by no means required, of course. It is perfectly fine to
have a single consumer of a dedicated mux controller controlling only
one mux for said consumer.

The prediction is that the typical use case will be for gpio-based muxing
(which is also what drove the development), where the below schematics
show the flexibility with one gpio-based mux controller being shared by
the iio-mux and i2c-mux-gpmux drivers.

..
|GPO0|--.
|GPO1|. |
||| |
|| .---.
|| |dg4052a|
|| |   |
|ADC0|-|XX0| signal X0
|| | X1| signal X1
|| | X2| signal X2
|| | X3| signal X3
|| |   |
|SDA0|-|YY0| i2c segment Y0
|SCL0|--.  | Y1| i2c segment Y1
''  |  | Y2| i2c segment Y2
|  | Y3| i2c segment Y3
|  '---'
|0 1 2 3   (feed SCL0 to each of
|| | | |the 4 muxed segments)
'+-+-+-'

GPO0 and GPO1 may also be fed to further parallel muxers, which is perhaps
desired in a real application to minimize digital noise from the I2C Y
channel leaking into the analog X channel. I.e. it might be a good idea
to separate the analog and digital signals...

And the below hypothetical schematics indicate something similar but using
the I2C-based adg792a multiplexer instead.

..
|SDA0|--.
|SCL0|. |
||| |
|| .---.
|| |adg792a|
|| |   |
|ADC0|-|D1  S1A| signal S1A
|| |S1B| signal S1B
|| |S1C| signal S1C
|| |S1D| signal S1D
|| |   |
|SDA1|---+-|D2  S2A| i2c segment S2A
|SCL1|-. | |S2B

[PATCH v14 02/11] dt-bindings: document devicetree bindings for mux-controllers and gpio-mux

[Peter Rosin]

Allow specifying that a single multiplexer controller can be used to
control several parallel multiplexers, thus enabling sharing of the
multiplexer controller by different consumers.

Add a binding for a first mux controller in the form of a GPIO based mux
controller.

Acked-by: Jonathan Cameron 
Acked-by: Rob Herring 
Signed-off-by: Peter Rosin 
---
 Documentation/devicetree/bindings/mux/gpio-mux.txt |  69 +
 .../devicetree/bindings/mux/mux-controller.txt | 157 +
 MAINTAINERS|   6 +
 include/dt-bindings/mux/mux.h  |  16 +++
 4 files changed, 248 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mux/gpio-mux.txt
 create mode 100644 Documentation/devicetree/bindings/mux/mux-controller.txt
 create mode 100644 include/dt-bindings/mux/mux.h

diff --git a/Documentation/devicetree/bindings/mux/gpio-mux.txt 
b/Documentation/devicetree/bindings/mux/gpio-mux.txt
new file mode 100644
index ..b8f746344d80
--- /dev/null
+++ b/Documentation/devicetree/bindings/mux/gpio-mux.txt
@@ -0,0 +1,69 @@
+GPIO-based multiplexer controller bindings
+
+Define what GPIO pins are used to control a multiplexer. Or several
+multiplexers, if the same pins control more than one multiplexer.
+
+Required properties:
+- compatible : "gpio-mux"
+- mux-gpios : list of gpios used to control the multiplexer, least
+ significant bit first.
+- #mux-control-cells : <0>
+* Standard mux-controller bindings as decribed in mux-controller.txt
+
+Optional properties:
+- idle-state : if present, the state the mux will have when idle. The
+  special state MUX_IDLE_AS_IS is the default.
+
+The multiplexer state is defined as the number represented by the
+multiplexer GPIO pins, where the first pin is the least significant
+bit. An active pin is a binary 1, an inactive pin is a binary 0.
+
+Example:
+
+   mux: mux-controller {
+   compatible = "gpio-mux";
+   #mux-control-cells = <0>;
+
+   mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>,
+   <&pioA 1 GPIO_ACTIVE_HIGH>;
+   };
+
+   adc-mux {
+   compatible = "io-channel-mux";
+   io-channels = <&adc 0>;
+   io-channel-names = "parent";
+
+   mux-controls = <&mux>;
+
+   channels = "sync-1", "in", "out", "sync-2";
+   };
+
+   i2c-mux {
+   compatible = "i2c-mux";
+   i2c-parent = <&i2c1>;
+
+   mux-controls = <&mux>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   i2c@0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ssd1307: oled@3c {
+   /* ... */
+   };
+   };
+
+   i2c@3 {
+   reg = <3>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   pca9555: pca9555@20 {
+   /* ... */
+   };
+   };
+   };
diff --git a/Documentation/devicetree/bindings/mux/mux-controller.txt 
b/Documentation/devicetree/bindings/mux/mux-controller.txt
new file mode 100644
index ..4f47e4bd2fa0
--- /dev/null
+++ b/Documentation/devicetree/bindings/mux/mux-controller.txt
@@ -0,0 +1,157 @@
+Common multiplexer controller bindings
+==
+
+A multiplexer (or mux) controller will have one, or several, consumer devices
+that uses the mux controller. Thus, a mux controller can possibly control
+several parallel multiplexers. Presumably there will be at least one
+multiplexer needed by each consumer, but a single mux controller can of course
+control several multiplexers for a single consumer.
+
+A mux controller provides a number of states to its consumers, and the state
+space is a simple zero-based enumeration. I.e. 0-1 for a 2-way multiplexer,
+0-7 for an 8-way multiplexer, etc.
+
+
+Consumers
+-
+
+Mux controller consumers should specify a list of mux controllers that they
+want to use with a property containing a 'mux-ctrl-list':
+
+   mux-ctrl-list ::=  [mux-ctrl-list]
+   single-mux-ctrl ::=  [mux-ctrl-specifier]
+   mux-ctrl-phandle : phandle to mux controller node
+   mux-ctrl-specifier : array of #mux-control-cells specifying the
+given mux controller (controller specific)
+
+Mux controller properties should be named "mux-controls". The exact meaning of
+each mux controller property must be documented in the device tree binding for
+each consumer. An optional property "mux-control-names" may contain a list of
+strings to label each of the mux controllers listed in the "mux-controls"
+property.
+
+Drivers for devices that use more than a single mux controller can use 

[PATCH v14 01/11] devres: trivial whitespace fix

[Peter Rosin]

Everything else is indented with two spaces, so fix the odd one out.

Acked-by: Jonathan Cameron 
Signed-off-by: Peter Rosin 
---
 Documentation/driver-model/devres.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/driver-model/devres.txt 
b/Documentation/driver-model/devres.txt
index bf34d5b3a733..efb8200819d6 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -335,7 +335,7 @@ MEM
   devm_kzalloc()
 
 MFD
- devm_mfd_add_devices()
+  devm_mfd_add_devices()
 
 PER-CPU MEM
   devm_alloc_percpu()
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v14 03/11] mux: minimal mux subsystem

[Peter Rosin]

Add a new minimalistic subsystem that handles multiplexer controllers.
When multiplexers are used in various places in the kernel, and the
same multiplexer controller can be used for several independent things,
there should be one place to implement support for said multiplexer
controller.

A single multiplexer controller can also be used to control several
parallel multiplexers, that are in turn used by different subsystems
in the kernel, leading to a need to coordinate multiplexer accesses.
The multiplexer subsystem handles this coordination.

Thanks go out to Lars-Peter Clausen, Jonathan Cameron, Rob Herring,
Wolfram Sang, Paul Gortmaker, Dan Carpenter, Colin Ian King, Greg
Kroah-Hartman and last but certainly not least to Philipp Zabel for
helpful comments, reviews, patches and general encouragement!

Reviewed-by: Jonathan Cameron 
Signed-off-by: Peter Rosin 
---
 Documentation/ABI/testing/sysfs-class-mux |  16 +
 Documentation/driver-model/devres.txt |   8 +
 MAINTAINERS   |   3 +
 drivers/Kconfig   |   2 +
 drivers/Makefile  |   1 +
 drivers/mux/Kconfig   |  16 +
 drivers/mux/Makefile  |   5 +
 drivers/mux/mux-core.c| 593 ++
 include/linux/mux/consumer.h  |  33 ++
 include/linux/mux/driver.h| 111 ++
 10 files changed, 788 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-mux
 create mode 100644 drivers/mux/Kconfig
 create mode 100644 drivers/mux/Makefile
 create mode 100644 drivers/mux/mux-core.c
 create mode 100644 include/linux/mux/consumer.h
 create mode 100644 include/linux/mux/driver.h

diff --git a/Documentation/ABI/testing/sysfs-class-mux 
b/Documentation/ABI/testing/sysfs-class-mux
new file mode 100644
index ..8715f9c7bd4f
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-mux
@@ -0,0 +1,16 @@
+What:  /sys/class/mux/
+Date:  April 2017
+KernelVersion: 4.13
+Contact:   Peter Rosin 
+Description:
+   The mux/ class sub-directory belongs to the Generic MUX
+   Framework and provides a sysfs interface for using MUX
+   controllers.
+
+What:  /sys/class/mux/muxchipN/
+Date:  April 2017
+KernelVersion: 4.13
+Contact:   Peter Rosin 
+Description:
+   A /sys/class/mux/muxchipN directory is created for each
+   probed MUX chip where N is a simple enumeration.
diff --git a/Documentation/driver-model/devres.txt 
b/Documentation/driver-model/devres.txt
index efb8200819d6..e2343d9cbec7 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -337,6 +337,14 @@ MEM
 MFD
   devm_mfd_add_devices()
 
+MUX
+  devm_mux_chip_alloc()
+  devm_mux_chip_free()
+  devm_mux_chip_register()
+  devm_mux_chip_unregister()
+  devm_mux_control_get()
+  devm_mux_control_put()
+
 PER-CPU MEM
   devm_alloc_percpu()
   devm_free_percpu()
diff --git a/MAINTAINERS b/MAINTAINERS
index 7fc06739c8ad..4cfa080878e2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8561,8 +8561,11 @@ F:   include/linux/spi/mmc_spi.h
 MULTIPLEXER SUBSYSTEM
 M: Peter Rosin 
 S: Maintained
+F: Documentation/ABI/testing/mux/sysfs-class-mux*
 F: Documentation/devicetree/bindings/mux/
 F: include/linux/dt-bindings/mux/
+F: include/linux/mux/
+F: drivers/mux/
 
 MULTISOUND SOUND DRIVER
 M: Andrew Veliath 
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 117ca14ccf85..a7ea13e1b869 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -204,4 +204,6 @@ source "drivers/fpga/Kconfig"
 
 source "drivers/fsi/Kconfig"
 
+source "drivers/mux/Kconfig"
+
 endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 2eced9afba53..c0436f6dd5a9 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -177,3 +177,4 @@ obj-$(CONFIG_ANDROID)   += android/
 obj-$(CONFIG_NVMEM)+= nvmem/
 obj-$(CONFIG_FPGA) += fpga/
 obj-$(CONFIG_FSI)  += fsi/
+obj-$(CONFIG_MULTIPLEXER)  += mux/
diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
new file mode 100644
index ..23ab2cde83b1
--- /dev/null
+++ b/drivers/mux/Kconfig
@@ -0,0 +1,16 @@
+#
+# Multiplexer devices
+#
+
+menuconfig MULTIPLEXER
+   tristate "Multiplexer subsystem"
+   help
+ Multiplexer controller subsystem. Multiplexers are used in a
+ variety of settings, and this subsystem abstracts their use
+ so that the rest of the kernel sees a common interface. When
+ multiple parallel multiplexers are controlled by one single
+ multiplexer controller, this subsystem also coordinates the
+ multiplexer accesses.
+
+ To compile the subsystem as a module, choose M here: the module will
+ be called mux-core.
diff --git a/drivers/mux/Makefile b/drivers/mux/Makefile
new file mode 100644
index

[PATCH v14 04/11] mux: gpio: add mux controller driver for gpio based multiplexers

[Peter Rosin]

The driver builds a single multiplexer controller using a number
of gpio pins. For N pins, there will be 2^N possible multiplexer
states. The GPIO pins can be connected (by the hardware) to several
multiplexers, which in that case will be operated in parallel.

Reviewed-by: Jonathan Cameron 
Signed-off-by: Peter Rosin 
---
 drivers/mux/Kconfig|  18 
 drivers/mux/Makefile   |   1 +
 drivers/mux/mux-gpio.c | 114 +
 3 files changed, 133 insertions(+)
 create mode 100644 drivers/mux/mux-gpio.c

diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
index 23ab2cde83b1..e580c2d028d2 100644
--- a/drivers/mux/Kconfig
+++ b/drivers/mux/Kconfig
@@ -14,3 +14,21 @@ menuconfig MULTIPLEXER
 
  To compile the subsystem as a module, choose M here: the module will
  be called mux-core.
+
+if MULTIPLEXER
+
+config MUX_GPIO
+   tristate "GPIO-controlled Multiplexer"
+   depends on GPIOLIB
+   help
+ GPIO-controlled Multiplexer controller.
+
+ The driver builds a single multiplexer controller using a number
+ of gpio pins. For N pins, there will be 2^N possible multiplexer
+ states. The GPIO pins can be connected (by the hardware) to several
+ multiplexers, which in that case will be operated in parallel.
+
+ To compile the driver as a module, choose M here: the module will
+ be called mux-gpio.
+
+endif
diff --git a/drivers/mux/Makefile b/drivers/mux/Makefile
index 09f0299e109d..bb16953f6290 100644
--- a/drivers/mux/Makefile
+++ b/drivers/mux/Makefile
@@ -3,3 +3,4 @@
 #
 
 obj-$(CONFIG_MULTIPLEXER)  += mux-core.o
+obj-$(CONFIG_MUX_GPIO) += mux-gpio.o
diff --git a/drivers/mux/mux-gpio.c b/drivers/mux/mux-gpio.c
new file mode 100644
index ..468bf1709606
--- /dev/null
+++ b/drivers/mux/mux-gpio.c
@@ -0,0 +1,114 @@
+/*
+ * GPIO-controlled multiplexer driver
+ *
+ * Copyright (C) 2017 Axentia Technologies AB
+ *
+ * Author: Peter Rosin 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct mux_gpio {
+   struct gpio_descs *gpios;
+   int *val;
+};
+
+static int mux_gpio_set(struct mux_control *mux, int state)
+{
+   struct mux_gpio *mux_gpio = mux_chip_priv(mux->chip);
+   int i;
+
+   for (i = 0; i < mux_gpio->gpios->ndescs; i++)
+   mux_gpio->val[i] = (state >> i) & 1;
+
+   gpiod_set_array_value_cansleep(mux_gpio->gpios->ndescs,
+  mux_gpio->gpios->desc,
+  mux_gpio->val);
+
+   return 0;
+}
+
+static const struct mux_control_ops mux_gpio_ops = {
+   .set = mux_gpio_set,
+};
+
+static const struct of_device_id mux_gpio_dt_ids[] = {
+   { .compatible = "gpio-mux", },
+   { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, mux_gpio_dt_ids);
+
+static int mux_gpio_probe(struct platform_device *pdev)
+{
+   struct device *dev = &pdev->dev;
+   struct mux_chip *mux_chip;
+   struct mux_gpio *mux_gpio;
+   int pins;
+   s32 idle_state;
+   int ret;
+
+   pins = gpiod_count(dev, "mux");
+   if (pins < 0)
+   return pins;
+
+   mux_chip = devm_mux_chip_alloc(dev, 1, sizeof(*mux_gpio) +
+  pins * sizeof(*mux_gpio->val));
+   if (IS_ERR(mux_chip))
+   return PTR_ERR(mux_chip);
+
+   mux_gpio = mux_chip_priv(mux_chip);
+   mux_gpio->val = (int *)(mux_gpio + 1);
+   mux_chip->ops = &mux_gpio_ops;
+
+   mux_gpio->gpios = devm_gpiod_get_array(dev, "mux", GPIOD_OUT_LOW);
+   if (IS_ERR(mux_gpio->gpios)) {
+   ret = PTR_ERR(mux_gpio->gpios);
+   if (ret != -EPROBE_DEFER)
+   dev_err(dev, "failed to get gpios\n");
+   return ret;
+   }
+   WARN_ON(pins != mux_gpio->gpios->ndescs);
+   mux_chip->mux->states = 1 << pins;
+
+   ret = device_property_read_u32(dev, "idle-state", (u32 *)&idle_state);
+   if (ret >= 0 && idle_state != MUX_IDLE_AS_IS) {
+   if (idle_state < 0 || idle_state >= mux_chip->mux->states) {
+   dev_err(dev, "invalid idle-state %u\n", idle_state);
+   return -EINVAL;
+   }
+
+   mux_chip->mux->idle_state = idle_state;
+   }
+
+   ret = devm_mux_chip_register(dev, mux_chip);
+   if (ret < 0)
+   return ret;
+
+   dev_info(dev, "%u-way mux-controller registered\n",
+mux_chip->mux->states);
+
+   return 0;
+}
+
+static struct platform_driver mux_gpio_driver = {
+   .driver = {
+   .name = "gpio-mux",
+   .of_match_table = of_match_ptr(mux_gpio_dt_ids),
+   },
+   .pro

[PATCH v14 05/11] iio: inkern: api for manipulating ext_info of iio channels

[Peter Rosin]

Extend the inkern api with functions for reading and writing ext_info
of iio channels.

Acked-by: Jonathan Cameron 
Signed-off-by: Peter Rosin 
---
 drivers/iio/inkern.c | 60 
 include/linux/iio/consumer.h | 37 +++
 2 files changed, 97 insertions(+)

diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c
index 7a13535dc3e9..8292ad4435ea 100644
--- a/drivers/iio/inkern.c
+++ b/drivers/iio/inkern.c
@@ -869,3 +869,63 @@ int iio_write_channel_raw(struct iio_channel *chan, int 
val)
return ret;
 }
 EXPORT_SYMBOL_GPL(iio_write_channel_raw);
+
+unsigned int iio_get_channel_ext_info_count(struct iio_channel *chan)
+{
+   const struct iio_chan_spec_ext_info *ext_info;
+   unsigned int i = 0;
+
+   if (!chan->channel->ext_info)
+   return i;
+
+   for (ext_info = chan->channel->ext_info; ext_info->name; ext_info++)
+   ++i;
+
+   return i;
+}
+EXPORT_SYMBOL_GPL(iio_get_channel_ext_info_count);
+
+static const struct iio_chan_spec_ext_info *iio_lookup_ext_info(
+   const struct iio_channel *chan,
+   const char *attr)
+{
+   const struct iio_chan_spec_ext_info *ext_info;
+
+   if (!chan->channel->ext_info)
+   return NULL;
+
+   for (ext_info = chan->channel->ext_info; ext_info->name; ++ext_info) {
+   if (!strcmp(attr, ext_info->name))
+   return ext_info;
+   }
+
+   return NULL;
+}
+
+ssize_t iio_read_channel_ext_info(struct iio_channel *chan,
+ const char *attr, char *buf)
+{
+   const struct iio_chan_spec_ext_info *ext_info;
+
+   ext_info = iio_lookup_ext_info(chan, attr);
+   if (!ext_info)
+   return -EINVAL;
+
+   return ext_info->read(chan->indio_dev, ext_info->private,
+ chan->channel, buf);
+}
+EXPORT_SYMBOL_GPL(iio_read_channel_ext_info);
+
+ssize_t iio_write_channel_ext_info(struct iio_channel *chan, const char *attr,
+  const char *buf, size_t len)
+{
+   const struct iio_chan_spec_ext_info *ext_info;
+
+   ext_info = iio_lookup_ext_info(chan, attr);
+   if (!ext_info)
+   return -EINVAL;
+
+   return ext_info->write(chan->indio_dev, ext_info->private,
+  chan->channel, buf, len);
+}
+EXPORT_SYMBOL_GPL(iio_write_channel_ext_info);
diff --git a/include/linux/iio/consumer.h b/include/linux/iio/consumer.h
index 47eeec3218b5..5e347a9805fd 100644
--- a/include/linux/iio/consumer.h
+++ b/include/linux/iio/consumer.h
@@ -312,4 +312,41 @@ int iio_read_channel_scale(struct iio_channel *chan, int 
*val,
 int iio_convert_raw_to_processed(struct iio_channel *chan, int raw,
int *processed, unsigned int scale);
 
+/**
+ * iio_get_channel_ext_info_count() - get number of ext_info attributes
+ *   connected to the channel.
+ * @chan:  The channel being queried
+ *
+ * Returns the number of ext_info attributes
+ */
+unsigned int iio_get_channel_ext_info_count(struct iio_channel *chan);
+
+/**
+ * iio_read_channel_ext_info() - read ext_info attribute from a given channel
+ * @chan:  The channel being queried.
+ * @attr:  The ext_info attribute to read.
+ * @buf:   Where to store the attribute value. Assumed to hold
+ * at least PAGE_SIZE bytes.
+ *
+ * Returns the number of bytes written to buf (perhaps w/o zero termination;
+ * it need not even be a string), or an error code.
+ */
+ssize_t iio_read_channel_ext_info(struct iio_channel *chan,
+ const char *attr, char *buf);
+
+/**
+ * iio_write_channel_ext_info() - write ext_info attribute from a given channel
+ * @chan:  The channel being queried.
+ * @attr:  The ext_info attribute to read.
+ * @buf:   The new attribute value. Strings needs to be zero-
+ * terminated, but the terminator should not be included
+ * in the below len.
+ * @len:   The size of the new attribute value.
+ *
+ * Returns the number of accepted bytes, which should be the same as len.
+ * An error code can also be returned.
+ */
+ssize_t iio_write_channel_ext_info(struct iio_channel *chan, const char *attr,
+  const char *buf, size_t len);
+
 #endif
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v14 07/11] iio: multiplexer: new iio category and iio-mux driver

[Peter Rosin]

When a multiplexer changes how an iio device behaves (for example
by feeding different signals to an ADC), this driver can be used
to create one virtual iio channel for each multiplexer state.

Depends on the generic multiplexer subsystem.

Cache any ext_info values from the parent iio channel, creating a private
copy of the ext_info attributes for each multiplexer state/channel.

Reviewed-by: Jonathan Cameron 
Signed-off-by: Peter Rosin 
---
 MAINTAINERS   |   1 +
 drivers/iio/Kconfig   |   1 +
 drivers/iio/Makefile  |   1 +
 drivers/iio/multiplexer/Kconfig   |  18 ++
 drivers/iio/multiplexer/Makefile  |   6 +
 drivers/iio/multiplexer/iio-mux.c | 459 ++
 6 files changed, 486 insertions(+)
 create mode 100644 drivers/iio/multiplexer/Kconfig
 create mode 100644 drivers/iio/multiplexer/Makefile
 create mode 100644 drivers/iio/multiplexer/iio-mux.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 1cde195bba25..519719069211 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6365,6 +6365,7 @@ M:Peter Rosin 
 L: linux-...@vger.kernel.org
 S: Maintained
 F: Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt
+F: drivers/iio/multiplexer/iio-mux.c
 
 IIO SUBSYSTEM AND DRIVERS
 M: Jonathan Cameron 
diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index a918270d6f54..b3c8c6ef0dff 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -83,6 +83,7 @@ source "drivers/iio/humidity/Kconfig"
 source "drivers/iio/imu/Kconfig"
 source "drivers/iio/light/Kconfig"
 source "drivers/iio/magnetometer/Kconfig"
+source "drivers/iio/multiplexer/Kconfig"
 source "drivers/iio/orientation/Kconfig"
 if IIO_TRIGGER
source "drivers/iio/trigger/Kconfig"
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 33fa4026f92c..93c769cd99bf 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -28,6 +28,7 @@ obj-y += humidity/
 obj-y += imu/
 obj-y += light/
 obj-y += magnetometer/
+obj-y += multiplexer/
 obj-y += orientation/
 obj-y += potentiometer/
 obj-y += potentiostat/
diff --git a/drivers/iio/multiplexer/Kconfig b/drivers/iio/multiplexer/Kconfig
new file mode 100644
index ..70a044510686
--- /dev/null
+++ b/drivers/iio/multiplexer/Kconfig
@@ -0,0 +1,18 @@
+#
+# Multiplexer drivers
+#
+# When adding new entries keep the list in alphabetical order
+
+menu "Multiplexers"
+
+config IIO_MUX
+   tristate "IIO multiplexer driver"
+   select MULTIPLEXER
+   depends on OF
+   help
+ Say yes here to build support for the IIO multiplexer.
+
+ To compile this driver as a module, choose M here: the
+ module will be called iio-mux.
+
+endmenu
diff --git a/drivers/iio/multiplexer/Makefile b/drivers/iio/multiplexer/Makefile
new file mode 100644
index ..68be3c4abd07
--- /dev/null
+++ b/drivers/iio/multiplexer/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for industrial I/O multiplexer drivers
+#
+
+# When adding new entries keep the list in alphabetical order
+obj-$(CONFIG_IIO_MUX) += iio-mux.o
diff --git a/drivers/iio/multiplexer/iio-mux.c 
b/drivers/iio/multiplexer/iio-mux.c
new file mode 100644
index ..37ba007f8dca
--- /dev/null
+++ b/drivers/iio/multiplexer/iio-mux.c
@@ -0,0 +1,459 @@
+/*
+ * IIO multiplexer driver
+ *
+ * Copyright (C) 2017 Axentia Technologies AB
+ *
+ * Author: Peter Rosin 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct mux_ext_info_cache {
+   char *data;
+   ssize_t size;
+};
+
+struct mux_child {
+   struct mux_ext_info_cache *ext_info_cache;
+};
+
+struct mux {
+   int cached_state;
+   struct mux_control *control;
+   struct iio_channel *parent;
+   struct iio_dev *indio_dev;
+   struct iio_chan_spec *chan;
+   struct iio_chan_spec_ext_info *ext_info;
+   struct mux_child *child;
+};
+
+static int iio_mux_select(struct mux *mux, int idx)
+{
+   struct mux_child *child = &mux->child[idx];
+   struct iio_chan_spec const *chan = &mux->chan[idx];
+   int ret;
+   int i;
+
+   ret = mux_control_select(mux->control, chan->channel);
+   if (ret < 0) {
+   mux->cached_state = -1;
+   return ret;
+   }
+
+   if (mux->cached_state == chan->channel)
+   return 0;
+
+   if (chan->ext_info) {
+   for (i = 0; chan->ext_info[i].name; ++i) {
+   const char *attr = chan->ext_info[i].name;
+   struct mux_ext_info_cache *cache;
+
+   cache = &child->ext_info_cache[i];
+
+   if (cache->size < 0)
+   continue;
+
+   ret = iio_write_channel_ext

[PATCH v14 11/11] mux: adg792a: add mux controller driver for ADG792A/G

[Peter Rosin]

Analog Devices ADG792A/G is a triple 4:1 mux.

Reviewed-by: Jonathan Cameron 
Signed-off-by: Peter Rosin 
---
 drivers/mux/Kconfig   |  12 
 drivers/mux/Makefile  |   1 +
 drivers/mux/mux-adg792a.c | 157 ++
 3 files changed, 170 insertions(+)
 create mode 100644 drivers/mux/mux-adg792a.c

diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
index e580c2d028d2..34b8284d6d29 100644
--- a/drivers/mux/Kconfig
+++ b/drivers/mux/Kconfig
@@ -17,6 +17,18 @@ menuconfig MULTIPLEXER
 
 if MULTIPLEXER
 
+config MUX_ADG792A
+   tristate "Analog Devices ADG792A/ADG792G Multiplexers"
+   depends on I2C
+   help
+ ADG792A and ADG792G Wide Bandwidth Triple 4:1 Multiplexers
+
+ The driver supports both operating the three multiplexers in
+ parallel and operating them independently.
+
+ To compile the driver as a module, choose M here: the module will
+ be called mux-adg792a.
+
 config MUX_GPIO
tristate "GPIO-controlled Multiplexer"
depends on GPIOLIB
diff --git a/drivers/mux/Makefile b/drivers/mux/Makefile
index bb16953f6290..b00a7d37d2fb 100644
--- a/drivers/mux/Makefile
+++ b/drivers/mux/Makefile
@@ -3,4 +3,5 @@
 #
 
 obj-$(CONFIG_MULTIPLEXER)  += mux-core.o
+obj-$(CONFIG_MUX_ADG792A)  += mux-adg792a.o
 obj-$(CONFIG_MUX_GPIO) += mux-gpio.o
diff --git a/drivers/mux/mux-adg792a.c b/drivers/mux/mux-adg792a.c
new file mode 100644
index ..12aa221ab90d
--- /dev/null
+++ b/drivers/mux/mux-adg792a.c
@@ -0,0 +1,157 @@
+/*
+ * Multiplexer driver for Analog Devices ADG792A/G Triple 4:1 mux
+ *
+ * Copyright (C) 2017 Axentia Technologies AB
+ *
+ * Author: Peter Rosin 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ADG792A_LDSW   BIT(0)
+#define ADG792A_RESETB BIT(1)
+#define ADG792A_DISABLE(mux)   (0x50 | (mux))
+#define ADG792A_DISABLE_ALL(0x5f)
+#define ADG792A_MUX(mux, state)(0xc0 | (((mux) + 1) << 2) | (state))
+#define ADG792A_MUX_ALL(state) (0xc0 | (state))
+
+static int adg792a_write_cmd(struct i2c_client *i2c, u8 cmd, int reset)
+{
+   u8 data = ADG792A_RESETB | ADG792A_LDSW;
+
+   /* ADG792A_RESETB is active low, the chip resets when it is zero. */
+   if (reset)
+   data &= ~ADG792A_RESETB;
+
+   return i2c_smbus_write_byte_data(i2c, cmd, data);
+}
+
+static int adg792a_set(struct mux_control *mux, int state)
+{
+   struct i2c_client *i2c = to_i2c_client(mux->chip->dev.parent);
+   u8 cmd;
+
+   if (mux->chip->controllers == 1) {
+   /* parallel mux controller operation */
+   if (state == MUX_IDLE_DISCONNECT)
+   cmd = ADG792A_DISABLE_ALL;
+   else
+   cmd = ADG792A_MUX_ALL(state);
+   } else {
+   unsigned int controller = mux_control_get_index(mux);
+
+   if (state == MUX_IDLE_DISCONNECT)
+   cmd = ADG792A_DISABLE(controller);
+   else
+   cmd = ADG792A_MUX(controller, state);
+   }
+
+   return adg792a_write_cmd(i2c, cmd, 0);
+}
+
+static const struct mux_control_ops adg792a_ops = {
+   .set = adg792a_set,
+};
+
+static int adg792a_probe(struct i2c_client *i2c,
+const struct i2c_device_id *id)
+{
+   struct device *dev = &i2c->dev;
+   struct mux_chip *mux_chip;
+   s32 idle_state[3];
+   u32 cells;
+   int ret;
+   int i;
+
+   if (!i2c_check_functionality(i2c->adapter, I2C_FUNC_SMBUS_BYTE_DATA))
+   return -ENODEV;
+
+   ret = device_property_read_u32(dev, "#mux-control-cells", &cells);
+   if (ret < 0)
+   return ret;
+   if (cells >= 2)
+   return -EINVAL;
+
+   mux_chip = devm_mux_chip_alloc(dev, cells ? 3 : 1, 0);
+   if (IS_ERR(mux_chip))
+   return PTR_ERR(mux_chip);
+
+   mux_chip->ops = &adg792a_ops;
+
+   ret = adg792a_write_cmd(i2c, ADG792A_DISABLE_ALL, 1);
+   if (ret < 0)
+   return ret;
+
+   ret = device_property_read_u32_array(dev, "idle-state",
+(u32 *)idle_state,
+mux_chip->controllers);
+   if (ret < 0) {
+   idle_state[0] = MUX_IDLE_AS_IS;
+   idle_state[1] = MUX_IDLE_AS_IS;
+   idle_state[2] = MUX_IDLE_AS_IS;
+   }
+
+   for (i = 0; i < mux_chip->controllers; ++i) {
+   struct mux_control *mux = &mux_chip->mux[i];
+
+   mux->states = 4;
+
+   switch (idle_state[i]) {
+   case MUX_IDLE_DISCONNECT:
+   case MUX_IDLE_AS_IS:
+   case 0 ... 4:
+  

[PATCH v14 09/11] i2c: i2c-mux-gpmux: new driver

[Peter Rosin]

This is a general purpose i2c mux that uses a multiplexer controlled by
the multiplexer subsystem to do the muxing.

The user can select if the mux is to be mux-locked and parent-locked
as described in Documentation/i2c/i2c-topology.

Acked-by: Jonathan Cameron 
Acked-by: Wolfram Sang 
Signed-off-by: Peter Rosin 
---
 drivers/i2c/muxes/Kconfig |  13 +++
 drivers/i2c/muxes/Makefile|   1 +
 drivers/i2c/muxes/i2c-mux-gpmux.c | 173 ++
 3 files changed, 187 insertions(+)
 create mode 100644 drivers/i2c/muxes/i2c-mux-gpmux.c

diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
index 10b3d17ae3ea..5fb34f24 100644
--- a/drivers/i2c/muxes/Kconfig
+++ b/drivers/i2c/muxes/Kconfig
@@ -30,6 +30,19 @@ config I2C_MUX_GPIO
  This driver can also be built as a module.  If so, the module
  will be called i2c-mux-gpio.
 
+config I2C_MUX_GPMUX
+   tristate "General Purpose I2C multiplexer"
+   select MULTIPLEXER
+   depends on OF
+   help
+ If you say yes to this option, support will be included for a
+ general purpose I2C multiplexer. This driver provides access to
+ I2C busses connected through a MUX, which in turn is controlled
+ by a MUX-controller from the MUX subsystem.
+
+ This driver can also be built as a module.  If so, the module
+ will be called i2c-mux-gpmux.
+
 config I2C_MUX_PCA9541
tristate "NXP PCA9541 I2C Master Selector"
help
diff --git a/drivers/i2c/muxes/Makefile b/drivers/i2c/muxes/Makefile
index 9948fa45037f..af43c6c3e861 100644
--- a/drivers/i2c/muxes/Makefile
+++ b/drivers/i2c/muxes/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_I2C_ARB_GPIO_CHALLENGE)+= 
i2c-arb-gpio-challenge.o
 obj-$(CONFIG_I2C_DEMUX_PINCTRL)+= i2c-demux-pinctrl.o
 
 obj-$(CONFIG_I2C_MUX_GPIO) += i2c-mux-gpio.o
+obj-$(CONFIG_I2C_MUX_GPMUX)+= i2c-mux-gpmux.o
 obj-$(CONFIG_I2C_MUX_MLXCPLD)  += i2c-mux-mlxcpld.o
 obj-$(CONFIG_I2C_MUX_PCA9541)  += i2c-mux-pca9541.o
 obj-$(CONFIG_I2C_MUX_PCA954x)  += i2c-mux-pca954x.o
diff --git a/drivers/i2c/muxes/i2c-mux-gpmux.c 
b/drivers/i2c/muxes/i2c-mux-gpmux.c
new file mode 100644
index ..92cf5f48afe6
--- /dev/null
+++ b/drivers/i2c/muxes/i2c-mux-gpmux.c
@@ -0,0 +1,173 @@
+/*
+ * General Purpose I2C multiplexer
+ *
+ * Copyright (C) 2017 Axentia Technologies AB
+ *
+ * Author: Peter Rosin 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct mux {
+   struct mux_control *control;
+
+   bool do_not_deselect;
+};
+
+static int i2c_mux_select(struct i2c_mux_core *muxc, u32 chan)
+{
+   struct mux *mux = i2c_mux_priv(muxc);
+   int ret;
+
+   ret = mux_control_select(mux->control, chan);
+   mux->do_not_deselect = ret < 0;
+
+   return ret;
+}
+
+static int i2c_mux_deselect(struct i2c_mux_core *muxc, u32 chan)
+{
+   struct mux *mux = i2c_mux_priv(muxc);
+
+   if (mux->do_not_deselect)
+   return 0;
+
+   return mux_control_deselect(mux->control);
+}
+
+static struct i2c_adapter *mux_parent_adapter(struct device *dev)
+{
+   struct device_node *np = dev->of_node;
+   struct device_node *parent_np;
+   struct i2c_adapter *parent;
+
+   parent_np = of_parse_phandle(np, "i2c-parent", 0);
+   if (!parent_np) {
+   dev_err(dev, "Cannot parse i2c-parent\n");
+   return ERR_PTR(-ENODEV);
+   }
+   parent = of_find_i2c_adapter_by_node(parent_np);
+   of_node_put(parent_np);
+   if (!parent)
+   return ERR_PTR(-EPROBE_DEFER);
+
+   return parent;
+}
+
+static const struct of_device_id i2c_mux_of_match[] = {
+   { .compatible = "i2c-mux", },
+   {},
+};
+MODULE_DEVICE_TABLE(of, i2c_mux_of_match);
+
+static int i2c_mux_probe(struct platform_device *pdev)
+{
+   struct device *dev = &pdev->dev;
+   struct device_node *np = dev->of_node;
+   struct device_node *child;
+   struct i2c_mux_core *muxc;
+   struct mux *mux;
+   struct i2c_adapter *parent;
+   int children;
+   int ret;
+
+   if (!np)
+   return -ENODEV;
+
+   mux = devm_kzalloc(dev, sizeof(*mux), GFP_KERNEL);
+   if (!mux)
+   return -ENOMEM;
+
+   mux->control = devm_mux_control_get(dev, NULL);
+   if (IS_ERR(mux->control)) {
+   if (PTR_ERR(mux->control) != -EPROBE_DEFER)
+   dev_err(dev, "failed to get control-mux\n");
+   return PTR_ERR(mux->control);
+   }
+
+   parent = mux_parent_adapter(dev);
+   if (IS_ERR(parent)) {
+   if (PTR_ERR(parent) != -EPROBE_DEFER)
+   dev_err(dev, "failed to get i2c-parent adapter\n");
+   retur

[PATCH v14 08/11] dt-bindings: i2c: i2c-mux: document general purpose i2c-mux bindings

[Peter Rosin]

Describe how a general purpose multiplexer controller is used to mux an
i2c bus.

Acked-by: Jonathan Cameron 
Reviewed-by: Rob Herring 
Signed-off-by: Peter Rosin 
---
 .../devicetree/bindings/i2c/i2c-mux-gpmux.txt  | 99 ++
 1 file changed, 99 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.txt

diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.txt 
b/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.txt
new file mode 100644
index ..2907dab56298
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.txt
@@ -0,0 +1,99 @@
+General Purpose I2C Bus Mux
+
+This binding describes an I2C bus multiplexer that uses a mux controller
+from the mux subsystem to route the I2C signals.
+
+  .-.  .-.
+  | dev |  | dev |
+..'-'  '-'
+| SoC|   ||
+||  .+'
+|   .--. |  .--+child bus A, on MUX value set to 0
+|   | I2C  |-|--| Mux  |
+|   '--' |  '--+---+child bus B, on MUX value set to 1
+|   .--. | |'--++.
+|   | MUX- | | |   |||
+|   | Ctrl |-|-+.-.  .-.  .-.
+|   '--' |  | dev |  | dev |  | dev |
+''  '-'  '-'  '-'
+
+Required properties:
+- compatible: i2c-mux
+- i2c-parent: The phandle of the I2C bus that this multiplexer's master-side
+  port is connected to.
+- mux-controls: The phandle of the mux controller to use for operating the
+  mux.
+* Standard I2C mux properties. See i2c-mux.txt in this directory.
+* I2C child bus nodes. See i2c-mux.txt in this directory. The sub-bus number
+  is also the mux-controller state described in ../mux/mux-controller.txt
+
+Optional properties:
+- mux-locked: If present, explicitly allow unrelated I2C transactions on the
+  parent I2C adapter at these times:
+   + during setup of the multiplexer
+   + between setup of the multiplexer and the child bus I2C transaction
+   + between the child bus I2C transaction and releasing of the multiplexer
+   + during releasing of the multiplexer
+  However, I2C transactions to devices behind all I2C multiplexers connected
+  to the same parent adapter that this multiplexer is connected to are blocked
+  for the full duration of the complete multiplexed I2C transaction (i.e.
+  including the times covered by the above list).
+  If mux-locked is not present, the multiplexer is assumed to be parent-locked.
+  This means that no unrelated I2C transactions are allowed on the parent I2C
+  adapter for the complete multiplexed I2C transaction.
+  The properties of mux-locked and parent-locked multiplexers are discussed
+  in more detail in Documentation/i2c/i2c-topology.
+
+For each i2c child node, an I2C child bus will be created. They will
+be numbered based on their order in the device tree.
+
+Whenever an access is made to a device on a child bus, the value set
+in the relevant node's reg property will be set as the state in the
+mux controller.
+
+Example:
+   mux: mux-controller {
+   compatible = "gpio-mux";
+   #mux-control-cells = <0>;
+
+   mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>,
+   <&pioA 1 GPIO_ACTIVE_HIGH>;
+   };
+
+   i2c-mux {
+   compatible = "i2c-mux";
+   mux-locked;
+   i2c-parent = <&i2c1>;
+
+   mux-controls = <&mux>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   i2c@1 {
+   reg = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ssd1307: oled@3c {
+   compatible = "solomon,ssd1307fb-i2c";
+   reg = <0x3c>;
+   pwms = <&pwm 4 3000>;
+   reset-gpios = <&gpio2 7 1>;
+   reset-active-low;
+   };
+   };
+
+   i2c@3 {
+   reg = <3>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   pca9555: pca9555@20 {
+   compatible = "nxp,pca9555";
+   gpio-controller;
+   #gpio-cells = <2>;
+   reg = <0x20>;
+   };
+   };
+   };
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v14 10/11] dt-bindings: mux-adg792a: document devicetree bindings for ADG792A/G mux

[Peter Rosin]

Analog Devices ADG792A/G is a triple 4:1 mux.

Acked-by: Jonathan Cameron 
Reviewed-by: Rob Herring 
Signed-off-by: Peter Rosin 
---
 .../devicetree/bindings/mux/adi,adg792a.txt| 75 ++
 1 file changed, 75 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mux/adi,adg792a.txt

diff --git a/Documentation/devicetree/bindings/mux/adi,adg792a.txt 
b/Documentation/devicetree/bindings/mux/adi,adg792a.txt
new file mode 100644
index ..96b787a69f50
--- /dev/null
+++ b/Documentation/devicetree/bindings/mux/adi,adg792a.txt
@@ -0,0 +1,75 @@
+Bindings for Analog Devices ADG792A/G Triple 4:1 Multiplexers
+
+Required properties:
+- compatible : "adi,adg792a" or "adi,adg792g"
+- #mux-control-cells : <0> if parallel (the three muxes are bound together
+  with a single mux controller controlling all three muxes), or <1> if
+  not (one mux controller for each mux).
+* Standard mux-controller bindings as described in mux-controller.txt
+
+Optional properties for ADG792G:
+- gpio-controller : if present, #gpio-cells below is required.
+- #gpio-cells : should be <2>
+ - First cell is the GPO line number, i.e. 0 or 1
+ - Second cell is used to specify active high (0)
+   or active low (1)
+
+Optional properties:
+- idle-state : if present, array of states that the mux controllers will have
+  when idle. The special state MUX_IDLE_AS_IS is the default and
+  MUX_IDLE_DISCONNECT is also supported.
+
+States 0 through 3 correspond to signals A through D in the datasheet.
+
+Example:
+
+   /*
+* Three independent mux controllers (of which one is used).
+* Mux 0 is disconnected when idle, mux 1 idles in the previously
+* selected state and mux 2 idles with signal B.
+*/
+   &i2c0 {
+   mux: mux-controller@50 {
+   compatible = "adi,adg792a";
+   reg = <0x50>;
+   #mux-control-cells = <1>;
+
+   idle-state = ;
+   };
+   };
+
+   adc-mux {
+   compatible = "io-channel-mux";
+   io-channels = <&adc 0>;
+   io-channel-names = "parent";
+
+   mux-controls = <&mux 2>;
+
+   channels = "sync-1", "", "out";
+   };
+
+
+   /*
+* Three parallel muxes with one mux controller, useful e.g. if
+* the adc is differential, thus needing two signals to be muxed
+* simultaneously for correct operation.
+*/
+   &i2c0 {
+   pmux: mux-controller@50 {
+   compatible = "adi,adg792a";
+   reg = <0x50>;
+   #mux-control-cells = <0>;
+
+   idle-state = <1>;
+   };
+   };
+
+   diff-adc-mux {
+   compatible = "io-channel-mux";
+   io-channels = <&adc 0>;
+   io-channel-names = "parent";
+
+   mux-controls = <&pmux>;
+
+   channels = "sync-1", "", "out";
+   };
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v14 06/11] dt-bindings: iio: io-channel-mux: document io-channel-mux bindings

[Peter Rosin]

Describe how a multiplexer can be used to select which signal is fed to
an io-channel.

Acked-by: Jonathan Cameron 
Acked-by: Rob Herring 
Signed-off-by: Peter Rosin 
---
 .../bindings/iio/multiplexer/io-channel-mux.txt| 39 ++
 MAINTAINERS|  6 
 2 files changed, 45 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt

diff --git 
a/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt 
b/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt
new file mode 100644
index ..c82794002595
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt
@@ -0,0 +1,39 @@
+I/O channel multiplexer bindings
+
+If a multiplexer is used to select which hardware signal is fed to
+e.g. an ADC channel, these bindings describe that situation.
+
+Required properties:
+- compatible : "io-channel-mux"
+- io-channels : Channel node of the parent channel that has multiplexed
+   input.
+- io-channel-names : Should be "parent".
+- #address-cells = <1>;
+- #size-cells = <0>;
+- mux-controls : Mux controller node to use for operating the mux
+- channels : List of strings, labeling the mux controller states.
+
+For each non-empty string in the channels property, an io-channel will
+be created. The number of this io-channel is the same as the index into
+the list of strings in the channels property, and also matches the mux
+controller state. The mux controller state is described in
+../mux/mux-controller.txt
+
+Example:
+   mux: mux-controller {
+   compatible = "mux-gpio";
+   #mux-control-cells = <0>;
+
+   mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>,
+   <&pioA 1 GPIO_ACTIVE_HIGH>;
+   };
+
+   adc-mux {
+   compatible = "io-channel-mux";
+   io-channels = <&adc 0>;
+   io-channel-names = "parent";
+
+   mux-controls = <&mux>;
+
+   channels = "sync", "in", "system-regulator";
+   };
diff --git a/MAINTAINERS b/MAINTAINERS
index 4cfa080878e2..1cde195bba25 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6360,6 +6360,12 @@ F:   
Documentation/ABI/testing/sysfs-bus-iio-adc-envelope-detector
 F: Documentation/devicetree/bindings/iio/adc/envelope-detector.txt
 F: drivers/iio/adc/envelope-detector.c
 
+IIO MULTIPLEXER
+M: Peter Rosin 
+L: linux-...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt
+
 IIO SUBSYSTEM AND DRIVERS
 M: Jonathan Cameron 
 R: Hartmut Knaack 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] KVM: Documentation: remove VM mmap documentation

[Jann Horn]

Since commit 80f5b5e700fa9c ("KVM: remove vm mmap method"), the VM mmap
handler is gone. Remove the corresponding documentation.

Signed-off-by: Jann Horn 
---
 Documentation/virtual/kvm/api.txt | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/Documentation/virtual/kvm/api.txt 
b/Documentation/virtual/kvm/api.txt
index fd106899afd1..e59af374aa86 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -110,11 +110,7 @@ Type: system ioctl
 Parameters: machine type identifier (KVM_VM_*)
 Returns: a VM fd that can be used to control the new virtual machine.
 
-The new VM has no virtual cpus and no memory.  An mmap() of a VM fd
-will access the virtual machine's physical address space; offset zero
-corresponds to guest physical address zero.  Use of mmap() on a VM fd
-is discouraged if userspace memory allocation (KVM_CAP_USER_MEMORY) is
-available.
+The new VM has no virtual cpus and no memory.
 You most certainly want to use 0 as machine type.
 
 In order to create user controlled virtual machines on S390, check
-- 
2.12.2.816.g281164-goog

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] KVM: Documentation: remove VM mmap documentation

[David Hildenbrand]

On 24.04.2017 11:16, Jann Horn wrote:
> as no virtual cpus and no memory.  An mmap() of a VM fd
> -will access the virtual machine's physical address space; offset zero
> -corresponds to guest physical address zero.  Use of mmap() on a VM fd
> -is discouraged if userspace memory allocation (KVM_CAP_USER_MEMORY) is
> -available.
> +The new VM has no virtual cpus and no memory.

Reviewed-by: David Hildenbrand 

-- 

Thanks,

David
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v14 00/11] mux controller abstraction and iio/i2c muxes

[Philipp Zabel]

On Mon, 2017-04-24 at 10:36 +0200, Peter Rosin wrote:
> Hi!
> 
> The big change since v13 is that the mux state is now locked with a mutex
> instead of an rwsem. Other that that, it is mostly restructuring and doc
> changes. There are a few other "real" changes as well, but those changes
> feel kind of minor. I guess what I'm trying to say is that although the
> list of changes for v14 is longish, it's still basically the same as last
> time.

I have hooked this up to the video-multiplexer and now I trigger
the lockdep debug_check_no_locks_held error message when selecting the
mux input from userspace:

$ media-ctl --links "'imx6-mipi-csi2':1->'ipu1_csi0_mux':0[1]"
[   66.258368] 
[   66.259919] =
[   66.265369] [ BUG: media-ctl/258 still has locks held! ]
[   66.270810] 4.11.0-rc8-20170424-1+ #1305 Not tainted
[   66.275863] -
[   66.282158] 1 lock held by media-ctl/258:
[   66.286464]  #0:  (&mux->lock){+.+.+.}, at: [<8074a6c0>] 
mux_control_select+0x24/0x50
[   66.294424] 
[   66.294424] stack backtrace:
[   66.298980] CPU: 0 PID: 258 Comm: media-ctl Not tainted 4.11.0-rc8+ #1305
[   66.306771] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[   66.313334] Backtrace: 
[   66.315858] [<8010e5a4>] (dump_backtrace) from [<8010e8ac>] 
(show_stack+0x20/0x24)
[   66.323473]  r7:80e518d0 r6:80e518d0 r5:600d0013 r4:
[   66.329190] [<8010e88c>] (show_stack) from [<80496cf4>] 
(dump_stack+0xb0/0xdc)
[   66.336470] [<80496c44>] (dump_stack) from [<8017e404>] 
(debug_check_no_locks_held+0xb8/0xbc)
[   66.345043]  r9:ae8566b8 r8:ad88dc84 r7:ad88df58 r6:ad88dc84 r5:ad88df58 
r4:ae856400
[   66.352837] [<8017e34c>] (debug_check_no_locks_held) from [<8012b258>] 
(do_exit+0x79c/0xcc8)
[   66.361321] [<8012aabc>] (do_exit) from [<8012d25c>] 
(do_group_exit+0x4c/0xcc)
[   66.368581]  r7:00f8
[   66.371161] [<8012d210>] (do_group_exit) from [<8012d2fc>] 
(__wake_up_parent+0x0/0x30)
[   66.379120]  r7:00f8 r6:76f71798 r5: r4:0001
[   66.384837] [<8012d2dc>] (SyS_exit_group) from [<80109380>] 
(ret_fast_syscall+0x0/0x1c)

That correctly warns that the media-ctl process caused the mux->lock to
be locked and still held when the process exited. Do we need a usage
counter based mechanism for muxes that are (indirectly) controlled from
userspace?

regards
Philipp


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v14 00/11] mux controller abstraction and iio/i2c muxes

[Peter Rosin]

On 2017-04-24 12:52, Philipp Zabel wrote:
> On Mon, 2017-04-24 at 10:36 +0200, Peter Rosin wrote:
>> Hi!
>>
>> The big change since v13 is that the mux state is now locked with a mutex
>> instead of an rwsem. Other that that, it is mostly restructuring and doc
>> changes. There are a few other "real" changes as well, but those changes
>> feel kind of minor. I guess what I'm trying to say is that although the
>> list of changes for v14 is longish, it's still basically the same as last
>> time.
> 
> I have hooked this up to the video-multiplexer and now I trigger
> the lockdep debug_check_no_locks_held error message when selecting the
> mux input from userspace:
> 
> $ media-ctl --links "'imx6-mipi-csi2':1->'ipu1_csi0_mux':0[1]"
> [   66.258368] 
> [   66.259919] =
> [   66.265369] [ BUG: media-ctl/258 still has locks held! ]
> [   66.270810] 4.11.0-rc8-20170424-1+ #1305 Not tainted
> [   66.275863] -
> [   66.282158] 1 lock held by media-ctl/258:
> [   66.286464]  #0:  (&mux->lock){+.+.+.}, at: [<8074a6c0>] 
> mux_control_select+0x24/0x50
> [   66.294424] 
> [   66.294424] stack backtrace:
> [   66.298980] CPU: 0 PID: 258 Comm: media-ctl Not tainted 4.11.0-rc8+ #1305
> [   66.306771] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> [   66.313334] Backtrace: 
> [   66.315858] [<8010e5a4>] (dump_backtrace) from [<8010e8ac>] 
> (show_stack+0x20/0x24)
> [   66.323473]  r7:80e518d0 r6:80e518d0 r5:600d0013 r4:
> [   66.329190] [<8010e88c>] (show_stack) from [<80496cf4>] 
> (dump_stack+0xb0/0xdc)
> [   66.336470] [<80496c44>] (dump_stack) from [<8017e404>] 
> (debug_check_no_locks_held+0xb8/0xbc)
> [   66.345043]  r9:ae8566b8 r8:ad88dc84 r7:ad88df58 r6:ad88dc84 r5:ad88df58 
> r4:ae856400
> [   66.352837] [<8017e34c>] (debug_check_no_locks_held) from [<8012b258>] 
> (do_exit+0x79c/0xcc8)
> [   66.361321] [<8012aabc>] (do_exit) from [<8012d25c>] 
> (do_group_exit+0x4c/0xcc)
> [   66.368581]  r7:00f8
> [   66.371161] [<8012d210>] (do_group_exit) from [<8012d2fc>] 
> (__wake_up_parent+0x0/0x30)
> [   66.379120]  r7:00f8 r6:76f71798 r5: r4:0001
> [   66.384837] [<8012d2dc>] (SyS_exit_group) from [<80109380>] 
> (ret_fast_syscall+0x0/0x1c)
> 
> That correctly warns that the media-ctl process caused the mux->lock to
> be locked and still held when the process exited. Do we need a usage
> counter based mechanism for muxes that are (indirectly) controlled from
> userspace?

Ok, so the difference is probably that the rwsem locking primitive
don't have any lockdep checking hooked up. Because the rwsem was
definitely held in the same way in v13 as the mutex is now held in
v14, so there's no fundamental difference.

So, yes, we can use some kind of refcount scheme to not hold an actual
mutex for the duration of the mux select/deselect, but that doesn't
really change anything. Userspace is still locking something, and that
seems dangerous. How do you make sure that mux_control_deselect is
called as it should?

What I don't like about abandoning the lock is that there is still a
need to support the multi-consumer case and then you need some way
of keeping track of waiters. A lock does this, and any attempt to open
code that will get messy.

What might be better is to support some kind of exclusive mux, i.e. a
mux that only allows one consumer per mux controller. Then the mux core
could trust that exclusive consumer to not fuck things up for itself and
thus have no lock at all for select/deselect for the exclusive case. Or
perhaps keep a refcount (as you suggested) for the exclusive case so
that mux_control_try_select still makes sense, because you still want
that, right? 

The question then becomes how to best tell the mux core that you want
an exclusive mux. I see two options. Either you declare a mux controller
as exclusive up front somehow (in the device tree presumably), or you
add a mux_control_get_exclusive call that makes further calls to
mux_control_get{,_exclusive} fail with -EBUSY. I think I like the
latter better, if that can be made to work...

Cheers,
peda
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v14 00/11] mux controller abstraction and iio/i2c muxes

[Philipp Zabel]

On Mon, 2017-04-24 at 13:37 +0200, Peter Rosin wrote:
[...]
> Ok, so the difference is probably that the rwsem locking primitive
> don't have any lockdep checking hooked up. Because the rwsem was
> definitely held in the same way in v13 as the mutex is now held in
> v14, so there's no fundamental difference.
>
> So, yes, we can use some kind of refcount scheme to not hold an actual
> mutex for the duration of the mux select/deselect, but that doesn't
> really change anything. Userspace is still locking something, and that
> seems dangerous. How do you make sure that mux_control_deselect is
> called as it should?

My current video_mux link setup implementation looks like this (it is
called from userspace via the MEDIA_IOC_SETUP_LINK ioctl):

--8<--
static int video_mux_link_setup(struct media_entity *entity,
const struct media_pad *local,
const struct media_pad *remote, u32 flags)
{
struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
struct video_mux *video_mux = v4l2_subdev_to_video_mux(sd);
int ret;

/*
 * The mux state is determined by the enabled sink pad link.
 * Enabling or disabling the source pad link has no effect.
 */
if (!is_sink_pad(video_mux, local->index))
return 0;

dev_dbg(sd->dev, "link setup '%s':%d->'%s':%d[%d]", 
remote->entity->name,
remote->index, local->entity->name, local->index,
flags & MEDIA_LNK_FL_ENABLED);

if (flags & MEDIA_LNK_FL_ENABLED) {
if (video_mux->active == local->index)
return 0;

if (video_mux->active >= 0)
return -EBUSY;

dev_dbg(sd->dev, "setting %d active\n", local->index);
ret = mux_control_try_select(video_mux->mux, local->index);
if (ret < 0)
return ret;
video_mux->active = local->index;
} else {
if (video_mux->active != local->index)
return 0;

dev_dbg(sd->dev, "going inactive\n");
mux_control_deselect(video_mux->mux);
video_mux->active = -1;
}

return 0;
}
-->8--

If a mux state was already selected, this should return -EBUSY, until a
call to disable the active link deselects the mux.

> What I don't like about abandoning the lock is that there is still a
> need to support the multi-consumer case and then you need some way
> of keeping track of waiters. A lock does this, and any attempt to open
> code that will get messy.
> 
> What might be better is to support some kind of exclusive mux, i.e. a
> mux that only allows one consumer per mux controller. Then the mux core
> could trust that exclusive consumer to not fuck things up for itself and
> thus have no lock at all for select/deselect for the exclusive case. Or
> perhaps keep a refcount (as you suggested) for the exclusive case so
> that mux_control_try_select still makes sense, because you still want
> that, right? 

In the case of an exclusive mux without lock, I don't see any need for a
try_select call.

> The question then becomes how to best tell the mux core that you want
> an exclusive mux. I see two options. Either you declare a mux controller
> as exclusive up front somehow (in the device tree presumably), or you
> add a mux_control_get_exclusive call that makes further calls to
> mux_control_get{,_exclusive} fail with -EBUSY. I think I like the
> latter better, if that can be made to work...

There is a precedent for the latter in the reset controller framework
(reset_control_get_shared and reset_control_get_exclusive variants).
Since this distinction is a matter of usage, and not a hardware property
of the mux/reset controller itself, I'd also prefer that.

regards
Philipp

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/3] rtmutex: update rt-mutex-design

[Alex Shi]

On 04/21/2017 11:47 PM, Peter Zijlstra wrote:
> On Fri, Apr 21, 2017 at 10:12:53PM +0800, Alex Shi wrote:
>> diff --git a/Documentation/locking/rt-mutex-design.txt 
>> b/Documentation/locking/rt-mutex-design.txt
>> index 8666070..11beb55 100644
>> --- a/Documentation/locking/rt-mutex-design.txt
>> +++ b/Documentation/locking/rt-mutex-design.txt
>> @@ -97,9 +97,9 @@ waiter   - A waiter is a struct that is stored on the 
>> stack of a blocked
>> a process being blocked on the mutex, it is fine to allocate
>> the waiter on the process's stack (local variable).  This
>> structure holds a pointer to the task, as well as the mutex that
>> -   the task is blocked on.  It also has the plist node structures to
>> -   place the task in the waiter_list of a mutex as well as the
>> -   pi_list of a mutex owner task (described below).
>> +   the task is blocked on.  It also has a rbtree node structures to
>> +   place the task in waiters rbtree of a mutex as well as the
>> +   pi_waiters rbtree of a mutex owner task (described below).
> 
> whitespace fail

Keep using the old style. Thanks!

> 
>>  
>> waiter is sometimes used in reference to the task that is waiting
>> on a mutex. This is the same as waiter->task.
>> @@ -179,53 +179,35 @@ again.
>>   |
>> F->L5-+
>>  
>> +If the G process has highest priority in the chain, then all the tasks up
>> +the chain (A and B in this example), must have their priorities increased
>> +to that of G.
> 
> No, only the top task that's actually runnable needs to be modified. The
> rest we don't care about because they're blocked.

As my understand the task B is also changed in function 
rt_mutex_adjust_prio_chain, even it was blocked. Since it should be run and 
then release the lock L2 before task G.

> 
>> +Since the pi_waiters of a task holds an order by priority of all the top 
>> waiters
>> +of all the mutexes that the task owns, rt_mutex_getprio simply needs to 
>> compare
>> +the top pi waiter to its own normal priority, and return the higher priority
>> +back.
> 
> rt_mutex_getprio() doesn't exist.

Thanks. Fixed.

> 
>> +The main operation of this function is summarized by Thomas Gleixner in
>> +rtmutex.c. See the 'Chain walk basics and protection scope' comment for 
>> further
>> +details.
> 
> Since all the useful bits are there anyway, why keep this document
> around at all?
> 

Uh, we already removed much contents of this function. The remain part are not 
simple duplicated, and also give me much help when I try to understand the 
rtmutex. :)

Any comments for 3rd version? :)

Thanks!


>From fab767624f0da0013154c53171cdeb6cec6e74c3 Mon Sep 17 00:00:00 2001
From: Alex Shi 
Date: Tue, 18 Apr 2017 17:40:11 +0800
Subject: [PATCH v3 1/3] rtmutex: update rt-mutex-design

The rt-mutex-design documents didn't gotten meaningful update from its
first version. Even after owner's pending bit was removed in commit 8161239a8bcc
("rtmutex: Simplify PI algorithm and make highest prio task get lock")
and priority list 'plist' changed to rbtree. And Peter Zijlstra did some
clean up and fix for deadline task changes on tip tree.

So update it to latest code and make it meaningful.

Signed-off-by: Alex Shi 
Cc: Steven Rostedt 
Cc: Sebastian Siewior 
To: linux-doc@vger.kernel.org
To: linux-ker...@vger.kernel.org
To: Jonathan Corbet 
To: Ingo Molnar 
To: Peter Zijlstra 
Cc: Thomas Gleixner 
---
 Documentation/locking/rt-mutex-design.txt | 418 +++---
 1 file changed, 97 insertions(+), 321 deletions(-)

diff --git a/Documentation/locking/rt-mutex-design.txt 
b/Documentation/locking/rt-mutex-design.txt
index 8666070..942cf45 100644
--- a/Documentation/locking/rt-mutex-design.txt
+++ b/Documentation/locking/rt-mutex-design.txt
@@ -97,9 +97,9 @@ waiter   - A waiter is a struct that is stored on the stack 
of a blocked
a process being blocked on the mutex, it is fine to allocate
the waiter on the process's stack (local variable).  This
structure holds a pointer to the task, as well as the mutex that
-   the task is blocked on.  It also has the plist node structures to
-   place the task in the waiter_list of a mutex as well as the
-   pi_list of a mutex owner task (described below).
+   the task is blocked on.  It also has a rbtree node structures to
+   place the task in waiters rbtree of a mutex as well as the
+   pi_waiters rbtree of a mutex owner task (described below).
 
waiter is sometimes used in reference to the task that is waiting
on a mutex. This is the same as waiter->task.
@@ -179,53 +179,35 @@ again.
  |
F->L5-+
 
-
-Plist
--
-
-Before I go further and talk about how the PI chain is stored through lists
-on both mutexes and processes, I'll explain the plist.  This is

Re: [PATCH v2 1/3] rtmutex: update rt-mutex-design

[Alex Shi]

  structure holds a pointer to the task, as well as the mutex that
>> -   the task is blocked on.  It also has the plist node structures to
>> -   place the task in the waiter_list of a mutex as well as the
>> -   pi_list of a mutex owner task (described below).
>> +  the task is blocked on.  It also has a rbtree node structures to
> 
> Here I assume we are talking about struct rt_mutex_waiter[1].  If so I
> suggest to replace rbtree with rb_node.

They are the same thing here, rbtree node and rb_node. :)

> 
>> +  place the task in waiters rbtree of a mutex as well as the
>> +  pi_waiters rbtree of a mutex owner task (described below).
> 
> Also following the comment for @pi_tree_entry, s/"a mutex owner
> task"/"a mutex owner waiters tree" .

As my understand, pi_waiters is in task structure. We refer to what's
the pi_tree_entry in.

> 
> [1]. http://lxr.free-electrons.com/source/kernel/locking/rtmutex_common.h#L25
> 
> 
>> -
>> +If the G process has highest priority in the chain, then all the tasks up
> 
> If process G has the highest priority in the chain, ...

Sounds better. Thanks!
>> +mutex (waiter "task" field is not NULL), then we go to sleep (call schedule)
>> +
> 
> This change was likely not done on purpose.

Yes. Thanks.
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/2] tiocsti-restrict : Add owner user namespace to tty_struct

[Serge E. Hallyn]

Quoting Matt Brown (m...@nmatt.com):
> This patch adds struct user_namespace *owner_user_ns to the tty_struct.
> Then it is set to current_user_ns() in the alloc_tty_struct function.
> 
> This is done to facilitate capability checks against the original user
> namespace that allocated the tty.
> 
> E.g. ns_capable(tty->owner_user_ns,CAP_SYS_ADMIN)
> 
> This combined with the use of user namespace's will allow hardening
> protections to be built to mitigate container escapes that utilize TTY
> ioctls such as TIOCSTI.
> 
> See: https://bugzilla.redhat.com/show_bug.cgi?id=1411256
> 
> Signed-off-by: Matt Brown 

Acked-by: Serge Hallyn 

> ---
>  drivers/tty/tty_io.c | 2 ++
>  include/linux/tty.h  | 2 ++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
> index e6d1a65..c276814 100644
> --- a/drivers/tty/tty_io.c
> +++ b/drivers/tty/tty_io.c
> @@ -171,6 +171,7 @@ static void free_tty_struct(struct tty_struct *tty)
>   put_device(tty->dev);
>   kfree(tty->write_buf);
>   tty->magic = 0xDEADDEAD;
> + put_user_ns(tty->owner_user_ns);
>   kfree(tty);
>  }
>  
> @@ -3191,6 +3192,7 @@ struct tty_struct *alloc_tty_struct(struct tty_driver 
> *driver, int idx)
>   tty->index = idx;
>   tty_line_name(driver, idx, tty->name);
>   tty->dev = tty_get_device(tty);
> + tty->owner_user_ns = get_user_ns(current_user_ns());
>  
>   return tty;
>  }
> diff --git a/include/linux/tty.h b/include/linux/tty.h
> index 1017e904..d902d42 100644
> --- a/include/linux/tty.h
> +++ b/include/linux/tty.h
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  
>  /*
> @@ -333,6 +334,7 @@ struct tty_struct {
>   /* If the tty has a pending do_SAK, queue it here - akpm */
>   struct work_struct SAK_work;
>   struct tty_port *port;
> + struct user_namespace *owner_user_ns;
>  };
>  
>  /* Each of a tty's open files has private_data pointing to tty_file_private 
> */
> -- 
> 2.10.2
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/2] tiocsti-restrict : make TIOCSTI ioctl require CAP_SYS_ADMIN

[Serge E. Hallyn]

Quoting Matt Brown (m...@nmatt.com):
> This introduces the tiocsti_restrict sysctl, whose default is controlled via
> CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this control restricts
> all TIOCSTI ioctl calls from non CAP_SYS_ADMIN users.
> 
> This patch depends on patch 1/2
> 
> This patch was inspired from GRKERNSEC_HARDEN_TTY.
> 
> This patch would have prevented
> https://bugzilla.redhat.com/show_bug.cgi?id=1411256 under the following
> conditions:
> * non-privileged container
> * container run inside new user namespace
> 
> Possible effects on userland:
> 
> There could be a few user programs that would be effected by this
> change.
> See: 
> notable programs are: agetty, csh, xemacs and tcsh
> 
> However, I still believe that this change is worth it given that the
> Kconfig defaults to n. This will be a feature that is turned on for the
> same reason that people activate it when using grsecurity. Users of this
> opt-in feature will realize that they are choosing security over some OS
> features like unprivileged TIOCSTI ioctls, as should be clear in the
> Kconfig help message.
> 
> Threat Model/Patch Rational:
> 
> >From grsecurity's config for GRKERNSEC_HARDEN_TTY.
> 
>  | There are very few legitimate uses for this functionality and it
>  | has made vulnerabilities in several 'su'-like programs possible in
>  | the past.  Even without these vulnerabilities, it provides an
>  | attacker with an easy mechanism to move laterally among other
>  | processes within the same user's compromised session.
> 
> So if one process within a tty session becomes compromised it can follow
> that additional processes, that are thought to be in different security
> boundaries, can be compromised as a result. When using a program like su
> or sudo, these additional processes could be in a tty session where TTY file
> descriptors are indeed shared over privilege boundaries.
> 
> This is also an excellent writeup about the issue:
> 
> 
> When user namespaces are in use, the check for the capability
> CAP_SYS_ADMIN is done against the user namespace that originally opened
> the tty.
> 
> Signed-off-by: Matt Brown 

Acked-by: Serge Hallyn 

(typo below)

> ---
>  Documentation/sysctl/kernel.txt | 21 +
>  drivers/tty/tty_io.c|  6 ++
>  include/linux/tty.h |  2 ++
>  kernel/sysctl.c | 12 
>  security/Kconfig| 13 +
>  5 files changed, 54 insertions(+)
> 
> diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
> index bac23c1..c15c660 100644
> --- a/Documentation/sysctl/kernel.txt
> +++ b/Documentation/sysctl/kernel.txt
> @@ -89,6 +89,7 @@ show up in /proc/sys/kernel:
>  - sysctl_writes_strict
>  - tainted
>  - threads-max
> +- tiocsti_restrict
>  - unknown_nmi_panic
>  - watchdog
>  - watchdog_thresh
> @@ -987,6 +988,26 @@ available RAM pages threads-max is reduced accordingly.
>  
>  ==
>  
> +tiocsti_restrict:
> +
> +This toggle indicates whether unprivileged users are prevented
> +from using the TIOCSTI ioctl to inject commands into otherprocesses

space between other processes

> +which share a tty session.
> +
> +When tiocsti_restrict is set to (0) there are no restrictions(accept
> +the default restriction of only being able to injection commands into
> +one's own tty). When tiocsti_restrict is set to (1), users must
> +have CAP_SYS_ADMIN to use the TIOCSTI ioctl.
> +
> +When user namespaces are in use, the check for the capability
> +CAP_SYS_ADMIN is done against the user namespace that originally
> +opened the tty.
> +
> +The kernel config option CONFIG_SECURITY_TIOCSTI_RESTRICT sets the
> +default value of tiocsti_restrict.
> +
> +==
> +
>  unknown_nmi_panic:
>  
>  The value in this file affects behavior of handling NMI. When the
> diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
> index c276814..fe68d14 100644
> --- a/drivers/tty/tty_io.c
> +++ b/drivers/tty/tty_io.c
> @@ -2297,11 +2297,17 @@ static int tty_fasync(int fd, struct file *filp, int 
> on)
>   *   FIXME: may race normal receive processing
>   */
>  
> +int tiocsti_restrict = IS_ENABLED(CONFIG_SECURITY_TIOCSTI_RESTRICT);
> +
>  static int tiocsti(struct tty_struct *tty, char __user *p)
>  {
>   char ch, mbz = 0;
>   struct tty_ldisc *ld;
>  
> + if (tiocsti_restrict && !ns_capable(tty->owner_user_ns,CAP_SYS_ADMIN)) {
> + pr_warn_ratelimited("TIOCSTI ioctl call blocked for 
> non-privileged process\n");
> + return -EPERM;
> + }
>   if ((current->signal->tty != tty) && !capable(CAP_SYS_ADMIN))
>   return -EPERM;
>   if (get_user(ch, p))
> diff --git a/include/linux/tty.h b/include/linux/tty.h
> index d902d42

Re: [PATCH v14 00/11] mux controller abstraction and iio/i2c muxes

[Philipp Zabel]

On Mon, 2017-04-24 at 13:37 +0200, Peter Rosin wrote:
> On 2017-04-24 12:52, Philipp Zabel wrote:
> > On Mon, 2017-04-24 at 10:36 +0200, Peter Rosin wrote:
> >> Hi!
> >>
> >> The big change since v13 is that the mux state is now locked with a mutex
> >> instead of an rwsem. Other that that, it is mostly restructuring and doc
> >> changes. There are a few other "real" changes as well, but those changes
> >> feel kind of minor. I guess what I'm trying to say is that although the
> >> list of changes for v14 is longish, it's still basically the same as last
> >> time.
> > 
> > I have hooked this up to the video-multiplexer and now I trigger
> > the lockdep debug_check_no_locks_held error message when selecting the
> > mux input from userspace:
> > 
> > $ media-ctl --links "'imx6-mipi-csi2':1->'ipu1_csi0_mux':0[1]"
> > [   66.258368] 
> > [   66.259919] =
> > [   66.265369] [ BUG: media-ctl/258 still has locks held! ]
> > [   66.270810] 4.11.0-rc8-20170424-1+ #1305 Not tainted
> > [   66.275863] -
> > [   66.282158] 1 lock held by media-ctl/258:
> > [   66.286464]  #0:  (&mux->lock){+.+.+.}, at: [<8074a6c0>] 
> > mux_control_select+0x24/0x50
> > [   66.294424] 
> > [   66.294424] stack backtrace:
> > [   66.298980] CPU: 0 PID: 258 Comm: media-ctl Not tainted 4.11.0-rc8+ #1305
> > [   66.306771] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> > [   66.313334] Backtrace: 
> > [   66.315858] [<8010e5a4>] (dump_backtrace) from [<8010e8ac>] 
> > (show_stack+0x20/0x24)
> > [   66.323473]  r7:80e518d0 r6:80e518d0 r5:600d0013 r4:
> > [   66.329190] [<8010e88c>] (show_stack) from [<80496cf4>] 
> > (dump_stack+0xb0/0xdc)
> > [   66.336470] [<80496c44>] (dump_stack) from [<8017e404>] 
> > (debug_check_no_locks_held+0xb8/0xbc)
> > [   66.345043]  r9:ae8566b8 r8:ad88dc84 r7:ad88df58 r6:ad88dc84 r5:ad88df58 
> > r4:ae856400
> > [   66.352837] [<8017e34c>] (debug_check_no_locks_held) from [<8012b258>] 
> > (do_exit+0x79c/0xcc8)
> > [   66.361321] [<8012aabc>] (do_exit) from [<8012d25c>] 
> > (do_group_exit+0x4c/0xcc)
> > [   66.368581]  r7:00f8
> > [   66.371161] [<8012d210>] (do_group_exit) from [<8012d2fc>] 
> > (__wake_up_parent+0x0/0x30)
> > [   66.379120]  r7:00f8 r6:76f71798 r5: r4:0001
> > [   66.384837] [<8012d2dc>] (SyS_exit_group) from [<80109380>] 
> > (ret_fast_syscall+0x0/0x1c)
> > 
> > That correctly warns that the media-ctl process caused the mux->lock to
> > be locked and still held when the process exited. Do we need a usage
> > counter based mechanism for muxes that are (indirectly) controlled from
> > userspace?
[...]
> The question then becomes how to best tell the mux core that you want
> an exclusive mux. I see two options. Either you declare a mux controller
> as exclusive up front somehow (in the device tree presumably), or you
> add a mux_control_get_exclusive call that makes further calls to
> mux_control_get{,_exclusive} fail with -EBUSY. I think I like the
> latter better, if that can be made to work...

How about an atomic use_count on the mux_control, a bool shared that is
only set by the first consumer, and controls whether selecting locks?

--8<--
diff --git a/drivers/mux/mux-core.c b/drivers/mux/mux-core.c
index c02fa4dd2d099..1d18bb7f15e07 100644
--- a/drivers/mux/mux-core.c
+++ b/drivers/mux/mux-core.c
@@ -372,11 +372,12 @@ int mux_control_select(struct mux_control *mux, unsigned 
int state)
 {
int ret;
 
-   mutex_lock(&mux->lock);
+   if (mux->shared)
+   mutex_lock(&mux->lock);
 
ret = __mux_control_select(mux, state);
 
-   if (ret < 0)
+   if (ret < 0 && mux->shared)
mutex_unlock(&mux->lock);
 
return ret;
@@ -399,12 +400,12 @@ int mux_control_try_select(struct mux_control *mux, 
unsigned int state)
 {
int ret;
 
-   if (!mutex_trylock(&mux->lock))
+   if (mux->shared && !mutex_trylock(&mux->lock))
return -EBUSY;
 
ret = __mux_control_select(mux, state);
 
-   if (ret < 0)
+   if (ret < 0 && mux->shared)
mutex_unlock(&mux->lock);
 
return ret;
@@ -427,7 +428,8 @@ int mux_control_deselect(struct mux_control *mux)
mux->idle_state != mux->cached_state)
ret = mux_control_set(mux, mux->idle

Re: [PATCH v14 00/11] mux controller abstraction and iio/i2c muxes

[Peter Rosin]

On 2017-04-24 16:10, Philipp Zabel wrote:
> On Mon, 2017-04-24 at 13:37 +0200, Peter Rosin wrote:
>> On 2017-04-24 12:52, Philipp Zabel wrote:
>>> On Mon, 2017-04-24 at 10:36 +0200, Peter Rosin wrote:
>>>> Hi!
>>>>
>>>> The big change since v13 is that the mux state is now locked with a mutex
>>>> instead of an rwsem. Other that that, it is mostly restructuring and doc
>>>> changes. There are a few other "real" changes as well, but those changes
>>>> feel kind of minor. I guess what I'm trying to say is that although the
>>>> list of changes for v14 is longish, it's still basically the same as last
>>>> time.
>>>
>>> I have hooked this up to the video-multiplexer and now I trigger
>>> the lockdep debug_check_no_locks_held error message when selecting the
>>> mux input from userspace:
>>>
>>> $ media-ctl --links "'imx6-mipi-csi2':1->'ipu1_csi0_mux':0[1]"
>>> [   66.258368] 
>>> [   66.259919] =
>>> [   66.265369] [ BUG: media-ctl/258 still has locks held! ]
>>> [   66.270810] 4.11.0-rc8-20170424-1+ #1305 Not tainted
>>> [   66.275863] -
>>> [   66.282158] 1 lock held by media-ctl/258:
>>> [   66.286464]  #0:  (&mux->lock){+.+.+.}, at: [<8074a6c0>] 
>>> mux_control_select+0x24/0x50
>>> [   66.294424] 
>>> [   66.294424] stack backtrace:
>>> [   66.298980] CPU: 0 PID: 258 Comm: media-ctl Not tainted 4.11.0-rc8+ #1305
>>> [   66.306771] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
>>> [   66.313334] Backtrace: 
>>> [   66.315858] [<8010e5a4>] (dump_backtrace) from [<8010e8ac>] 
>>> (show_stack+0x20/0x24)
>>> [   66.323473]  r7:80e518d0 r6:80e518d0 r5:600d0013 r4:
>>> [   66.329190] [<8010e88c>] (show_stack) from [<80496cf4>] 
>>> (dump_stack+0xb0/0xdc)
>>> [   66.336470] [<80496c44>] (dump_stack) from [<8017e404>] 
>>> (debug_check_no_locks_held+0xb8/0xbc)
>>> [   66.345043]  r9:ae8566b8 r8:ad88dc84 r7:ad88df58 r6:ad88dc84 r5:ad88df58 
>>> r4:ae856400
>>> [   66.352837] [<8017e34c>] (debug_check_no_locks_held) from [<8012b258>] 
>>> (do_exit+0x79c/0xcc8)
>>> [   66.361321] [<8012aabc>] (do_exit) from [<8012d25c>] 
>>> (do_group_exit+0x4c/0xcc)
>>> [   66.368581]  r7:00f8
>>> [   66.371161] [<8012d210>] (do_group_exit) from [<8012d2fc>] 
>>> (__wake_up_parent+0x0/0x30)
>>> [   66.379120]  r7:00f8 r6:76f71798 r5: r4:0001
>>> [   66.384837] [<8012d2dc>] (SyS_exit_group) from [<80109380>] 
>>> (ret_fast_syscall+0x0/0x1c)
>>>
>>> That correctly warns that the media-ctl process caused the mux->lock to
>>> be locked and still held when the process exited. Do we need a usage
>>> counter based mechanism for muxes that are (indirectly) controlled from
>>> userspace?
> [...]
>> The question then becomes how to best tell the mux core that you want
>> an exclusive mux. I see two options. Either you declare a mux controller
>> as exclusive up front somehow (in the device tree presumably), or you
>> add a mux_control_get_exclusive call that makes further calls to
>> mux_control_get{,_exclusive} fail with -EBUSY. I think I like the
>> latter better, if that can be made to work...
> 
> How about an atomic use_count on the mux_control, a bool shared that is
> only set by the first consumer, and controls whether selecting locks?

That has the drawback that it is hard to restore the mux-control in a safe
way so that exclusive consumers are allowed after the last shared consumer
puts the mux away. Agreed, it's a corner case, but I had this very similar
patch going through the compiler when I got this mail. Does it work as well
as what you suggested?

Cheers,
peda

diff --git a/Documentation/driver-model/devres.txt 
b/Documentation/driver-model/devres.txt
index e2343d9cbec7..5a7352a83124 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -342,7 +342,8 @@ MUX
   devm_mux_chip_free()
   devm_mux_chip_register()
   devm_mux_chip_unregister()
-  devm_mux_control_get()
+  devm_mux_control_get_shared()
+  devm_mux_control_get_exclusive()
   devm_mux_control_put()
 
 PER-CPU MEM
diff --git a/drivers/i2c/muxes/i2c-mux-gpmux.c 
b/drivers/i2c/muxes/i2c-mux-gpmux.c
index 92cf5f48afe6..135d6baaebe5 100644
--- a/drivers/i2c/muxes/i2c-mux-gpmux.c
+++ b/drivers/i

Re: [PATCH v14 00/11] mux controller abstraction and iio/i2c muxes

[Philipp Zabel]

On Mon, 2017-04-24 at 16:36 +0200, Peter Rosin wrote:
[...]
> > How about an atomic use_count on the mux_control, a bool shared that is
> > only set by the first consumer, and controls whether selecting locks?
> 
> That has the drawback that it is hard to restore the mux-control in a safe
> way so that exclusive consumers are allowed after the last shared consumer
> puts the mux away.

True.

> Agreed, it's a corner case, but I had this very similar
> patch going through the compiler when I got this mail. Does it work as well
> as what you suggested?

Yes, this patch works just as well.

regards
Philipp

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 09/32] x86/mm: Provide general kernel support for memory encryption

[Tom Lendacky]

On 4/21/2017 4:52 PM, Dave Hansen wrote:

On 04/18/2017 02:17 PM, Tom Lendacky wrote:

@@ -55,7 +57,7 @@ static inline void copy_user_page(void *to, void *from, 
unsigned long vaddr,
__phys_addr_symbol(__phys_reloc_hide((unsigned long)(x)))

 #ifndef __va
-#define __va(x)((void *)((unsigned 
long)(x)+PAGE_OFFSET))
+#define __va(x)((void *)(__sme_clr(x) + PAGE_OFFSET))
 #endif


It seems wrong to be modifying __va().  It currently takes a physical
address, and this modifies it to take a physical address plus the SME bits.


This actually modifies it to be sure the encryption bit is not part of
the physical address.



How does that end up ever happening?  If we are pulling physical
addresses out of the page tables, we use p??_phys().  I'd expect *those*
to be masking off the SME bits.

Is it these cases?

pgd_t *base = __va(read_cr3());

For those, it seems like we really want to create two modes of reading
cr3.  One that truly reads CR3 and another that reads the pgd's physical
address out of CR3.  Then you only do the SME masking on the one
fetching a physical address, and the SME bits never leak into __va().


I'll investigate this and see if I can remove the mod to __va().

Thanks,
Tom




--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 09/32] x86/mm: Provide general kernel support for memory encryption

[Dave Hansen]

On 04/24/2017 08:53 AM, Tom Lendacky wrote:
> On 4/21/2017 4:52 PM, Dave Hansen wrote:
>> On 04/18/2017 02:17 PM, Tom Lendacky wrote:
>>> @@ -55,7 +57,7 @@ static inline void copy_user_page(void *to, void
>>> *from, unsigned long vaddr,
>>>  __phys_addr_symbol(__phys_reloc_hide((unsigned long)(x)))
>>>
>>>  #ifndef __va
>>> -#define __va(x)((void *)((unsigned long)(x)+PAGE_OFFSET))
>>> +#define __va(x)((void *)(__sme_clr(x) + PAGE_OFFSET))
>>>  #endif
>>
>> It seems wrong to be modifying __va().  It currently takes a physical
>> address, and this modifies it to take a physical address plus the SME
>> bits.
> 
> This actually modifies it to be sure the encryption bit is not part of
> the physical address.

If SME bits make it this far, we have a bug elsewhere.  Right?  Probably
best not to paper over it.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 09/32] x86/mm: Provide general kernel support for memory encryption

[Tom Lendacky]

On 4/24/2017 10:57 AM, Dave Hansen wrote:

On 04/24/2017 08:53 AM, Tom Lendacky wrote:

On 4/21/2017 4:52 PM, Dave Hansen wrote:

On 04/18/2017 02:17 PM, Tom Lendacky wrote:

@@ -55,7 +57,7 @@ static inline void copy_user_page(void *to, void
*from, unsigned long vaddr,
 __phys_addr_symbol(__phys_reloc_hide((unsigned long)(x)))

 #ifndef __va
-#define __va(x)((void *)((unsigned long)(x)+PAGE_OFFSET))
+#define __va(x)((void *)(__sme_clr(x) + PAGE_OFFSET))
 #endif


It seems wrong to be modifying __va().  It currently takes a physical
address, and this modifies it to take a physical address plus the SME
bits.


This actually modifies it to be sure the encryption bit is not part of
the physical address.


If SME bits make it this far, we have a bug elsewhere.  Right?  Probably
best not to paper over it.


That all depends on the approach.  Currently that's not the case for
the one situation that you mentioned with cr3.  But if we do take the
approach that we should never feed physical addresses to __va() with
the encryption bit set then, yes, it would imply a bug elsewhere - which
is probably a good approach.

I'll work on that. I could even add a debug config option that would
issue a warning should __va() encounter the encryption bit if SME is
enabled or active.

Thanks,
Tom




--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] arm64: Add MIDR values for Cavium cn83XX SoCs

[David Daney]

Signed-off-by: David Daney 
---
 arch/arm64/include/asm/cputype.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 0984d1b..235e77d 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -86,6 +86,7 @@
 
 #define CAVIUM_CPU_PART_THUNDERX   0x0A1
 #define CAVIUM_CPU_PART_THUNDERX_81XX  0x0A2
+#define CAVIUM_CPU_PART_THUNDERX_83XX  0x0A3
 
 #define BRCM_CPU_PART_VULCAN   0x516
 
@@ -96,6 +97,7 @@
 #define MIDR_CORTEX_A73 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A73)
 #define MIDR_THUNDERX  MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, 
CAVIUM_CPU_PART_THUNDERX)
 #define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, 
CAVIUM_CPU_PART_THUNDERX_81XX)
+#define MIDR_THUNDERX_83XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, 
CAVIUM_CPU_PART_THUNDERX_83XX)
 #define MIDR_QCOM_FALKOR_V1 MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, 
QCOM_CPU_PART_FALKOR_V1)
 
 #ifndef __ASSEMBLY__
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] arm64: Workaround for Thunder KVM hang issues.

[David Daney]

We have discovered in rare circumstances, guest execution may result
in host not receiving one or more interrupts.  This does not otherwise
affect guest or host execution and/or isolation.


David Daney (2):
  arm64: Add MIDR values for Cavium cn83XX SoCs
  arm64: Add workaround for Cavium Thunder erratum 30115

 Documentation/arm64/silicon-errata.txt |  1 +
 arch/arm64/Kconfig | 11 +++
 arch/arm64/include/asm/cpucaps.h   |  3 ++-
 arch/arm64/include/asm/cputype.h   |  2 ++
 arch/arm64/kernel/cpu_errata.c | 21 +
 arch/arm64/kvm/hyp/switch.c|  9 +
 6 files changed, 46 insertions(+), 1 deletion(-)

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] arm64: Add workaround for Cavium Thunder erratum 30115

[David Daney]

Some Cavium Thunder CPUs suffer a problem where a KVM guest may
inadvertently cause the host kernel to quit receiving interrupts.

The workaround is to toggle the group-1 interrupt enable on each exit
from the guest.

Signed-off-by: David Daney 
---
 Documentation/arm64/silicon-errata.txt |  1 +
 arch/arm64/Kconfig | 11 +++
 arch/arm64/include/asm/cpucaps.h   |  3 ++-
 arch/arm64/kernel/cpu_errata.c | 21 +
 arch/arm64/kvm/hyp/switch.c|  9 +
 5 files changed, 44 insertions(+), 1 deletion(-)

diff --git a/Documentation/arm64/silicon-errata.txt 
b/Documentation/arm64/silicon-errata.txt
index 10f2ddd..f5f93dc 100644
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -62,6 +62,7 @@ stable kernels.
 | Cavium | ThunderX GICv3  | #23154  | CAVIUM_ERRATUM_23154
|
 | Cavium | ThunderX Core   | #27456  | CAVIUM_ERRATUM_27456
|
 | Cavium | ThunderX SMMUv2 | #27704  | N/A 
|
+| Cavium | ThunderX Core   | #30115  | CAVIUM_ERRATUM_30115
|
 || | | 
|
 | Freescale/NXP  | LS2080A/LS1043A | A-008585| FSL_ERRATUM_A008585 
|
 || | | 
|
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e7f043e..fe29277 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -480,6 +480,17 @@ config CAVIUM_ERRATUM_27456
 
  If unsure, say Y.
 
+config CAVIUM_ERRATUM_30115
+   bool "Cavium erratum 30115: Guest may disable interrupts in host"
+   default y
+   help
+ On ThunderX T88 pass 1.x through 2.2, T81 pass 1.0 through
+ 1.2, and T83 Pass 1.0, KVM guest execution may disable
+ interrupts in host.  The fix is to reenable group 1
+ interrupts when returning to host mode.
+
+ If unsure, say Y.
+
 config QCOM_FALKOR_ERRATUM_1003
bool "Falkor E1003: Incorrect translation due to ASID change"
default y
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index b3aab8a..8d2272c 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -38,7 +38,8 @@
 #define ARM64_WORKAROUND_REPEAT_TLBI   17
 #define ARM64_WORKAROUND_QCOM_FALKOR_E1003 18
 #define ARM64_WORKAROUND_85892119
+#define ARM64_WORKAROUND_CAVIUM_30115  20
 
-#define ARM64_NCAPS20
+#define ARM64_NCAPS21
 
 #endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 2ed2a76..0e27f86 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -133,6 +133,27 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
MIDR_RANGE(MIDR_THUNDERX_81XX, 0x00, 0x00),
},
 #endif
+#ifdef CONFIG_CAVIUM_ERRATUM_30115
+   {
+   /* Cavium ThunderX, T88 pass 1.x - 2.2 */
+   .desc = "Cavium erratum 30115",
+   .capability = ARM64_WORKAROUND_CAVIUM_30115,
+   MIDR_RANGE(MIDR_THUNDERX, 0x00,
+  (1 << MIDR_VARIANT_SHIFT) | 2),
+   },
+   {
+   /* Cavium ThunderX, T81 pass 1.0 - 1.2 */
+   .desc = "Cavium erratum 30115",
+   .capability = ARM64_WORKAROUND_CAVIUM_30115,
+   MIDR_RANGE(MIDR_THUNDERX_81XX, 0x00, 0x02),
+   },
+   {
+   /* Cavium ThunderX, T83 pass 1.0 */
+   .desc = "Cavium erratum 30115",
+   .capability = ARM64_WORKAROUND_CAVIUM_30115,
+   MIDR_RANGE(MIDR_THUNDERX_83XX, 0x00, 0x00),
+   },
+#endif
{
.desc = "Mismatched cache line size",
.capability = ARM64_MISMATCHED_CACHE_LINE_SIZE,
diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
index aede165..c174b5f 100644
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -17,11 +17,13 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 static bool __hyp_text __fpsimd_enabled_nvhe(void)
 {
@@ -166,6 +168,13 @@ static void __hyp_text __vgic_save_state(struct kvm_vcpu 
*vcpu)
__vgic_v2_save_state(vcpu);
 
write_sysreg(read_sysreg(hcr_el2) & ~HCR_INT_OVERRIDE, hcr_el2);
+
+#ifdef CONFIG_CAVIUM_ERRATUM_30115
+   if (cpus_have_const_cap(ARM64_WORKAROUND_CAVIUM_30115)) {
+   gic_write_grpen1(0);
+   gic_write_grpen1(1);
+   }
+#endif
 }
 
 static void __hyp_text __vgic_restore_state(struct kvm_vcpu *vcpu)
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org

[PATCH v5 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

[Matt Brown]

This patchset introduces the tiocsti_restrict sysctl, whose default is
controlled via CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this
control restricts all TIOCSTI ioctl calls from non CAP_SYS_ADMIN users.

This patch was inspired from GRKERNSEC_HARDEN_TTY.

This patch would have prevented
https://bugzilla.redhat.com/show_bug.cgi?id=1411256 under the following
conditions:
* non-privileged container
* container run inside new user namespace

Possible effects on userland:

There could be a few user programs that would be effected by this
change.
See: 
notable programs are: agetty, csh, xemacs and tcsh

However, I still believe that this change is worth it given that the
Kconfig defaults to n. This will be a feature that is turned on for the
same reason that people activate it when using grsecurity. Users of this
opt-in feature will realize that they are choosing security over some OS
features like unprivileged TIOCSTI ioctls, as should be clear in the
Kconfig help message.

Threat Model/Patch Rational:

>From grsecurity's config for GRKERNSEC_HARDEN_TTY.

 | There are very few legitimate uses for this functionality and it
 | has made vulnerabilities in several 'su'-like programs possible in
 | the past.  Even without these vulnerabilities, it provides an
 | attacker with an easy mechanism to move laterally among other
 | processes within the same user's compromised session.

So if one process within a tty session becomes compromised it can follow
that additional processes, that are thought to be in different security
boundaries, can be compromised as a result. When using a program like su
or sudo, these additional processes could be in a tty session where TTY file
descriptors are indeed shared over privilege boundaries.

This is also an excellent writeup about the issue:


When user namespaces are in use, the check for the capability
CAP_SYS_ADMIN is done against the user namespace that originally opened
the tty.

# Changes since v4:
* fixed typo

# Changes since v3:
* use get_user_ns and put_user_ns to take and drop references to the owner
  user namespace because CONFIG_USER_NS is an option

# Changes since v2:
* take/drop reference to user namespace on tty struct alloc/free to prevent
  use-after-free.

# Changes since v1:
* added owner_user_ns to tty_struct to enable capability checks against
  the namespace that created the tty.
* rewording in different places to make patchset purpose clear
* Added Documentation
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

[Matt Brown]

This introduces the tiocsti_restrict sysctl, whose default is controlled via
CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this control restricts
all TIOCSTI ioctl calls from non CAP_SYS_ADMIN users.

This patch depends on patch 1/2

This patch was inspired from GRKERNSEC_HARDEN_TTY.

This patch would have prevented
https://bugzilla.redhat.com/show_bug.cgi?id=1411256 under the following
conditions:
* non-privileged container
* container run inside new user namespace

Possible effects on userland:

There could be a few user programs that would be effected by this
change.
See: 
notable programs are: agetty, csh, xemacs and tcsh

However, I still believe that this change is worth it given that the
Kconfig defaults to n. This will be a feature that is turned on for the
same reason that people activate it when using grsecurity. Users of this
opt-in feature will realize that they are choosing security over some OS
features like unprivileged TIOCSTI ioctls, as should be clear in the
Kconfig help message.

Threat Model/Patch Rational:

>From grsecurity's config for GRKERNSEC_HARDEN_TTY.

 | There are very few legitimate uses for this functionality and it
 | has made vulnerabilities in several 'su'-like programs possible in
 | the past.  Even without these vulnerabilities, it provides an
 | attacker with an easy mechanism to move laterally among other
 | processes within the same user's compromised session.

So if one process within a tty session becomes compromised it can follow
that additional processes, that are thought to be in different security
boundaries, can be compromised as a result. When using a program like su
or sudo, these additional processes could be in a tty session where TTY file
descriptors are indeed shared over privilege boundaries.

This is also an excellent writeup about the issue:


When user namespaces are in use, the check for the capability
CAP_SYS_ADMIN is done against the user namespace that originally opened
the tty.

Signed-off-by: Matt Brown 
---
 Documentation/sysctl/kernel.txt | 21 +
 drivers/tty/tty_io.c|  6 ++
 include/linux/tty.h |  2 ++
 kernel/sysctl.c | 12 
 security/Kconfig| 13 +
 5 files changed, 54 insertions(+)

diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index bac23c1..f7985cf 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -89,6 +89,7 @@ show up in /proc/sys/kernel:
 - sysctl_writes_strict
 - tainted
 - threads-max
+- tiocsti_restrict
 - unknown_nmi_panic
 - watchdog
 - watchdog_thresh
@@ -987,6 +988,26 @@ available RAM pages threads-max is reduced accordingly.
 
 ==
 
+tiocsti_restrict:
+
+This toggle indicates whether unprivileged users are prevented
+from using the TIOCSTI ioctl to inject commands into other processes
+which share a tty session.
+
+When tiocsti_restrict is set to (0) there are no restrictions(accept
+the default restriction of only being able to injection commands into
+one's own tty). When tiocsti_restrict is set to (1), users must
+have CAP_SYS_ADMIN to use the TIOCSTI ioctl.
+
+When user namespaces are in use, the check for the capability
+CAP_SYS_ADMIN is done against the user namespace that originally
+opened the tty.
+
+The kernel config option CONFIG_SECURITY_TIOCSTI_RESTRICT sets the
+default value of tiocsti_restrict.
+
+==
+
 unknown_nmi_panic:
 
 The value in this file affects behavior of handling NMI. When the
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index c276814..fe68d14 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -2297,11 +2297,17 @@ static int tty_fasync(int fd, struct file *filp, int on)
  * FIXME: may race normal receive processing
  */
 
+int tiocsti_restrict = IS_ENABLED(CONFIG_SECURITY_TIOCSTI_RESTRICT);
+
 static int tiocsti(struct tty_struct *tty, char __user *p)
 {
char ch, mbz = 0;
struct tty_ldisc *ld;
 
+   if (tiocsti_restrict && !ns_capable(tty->owner_user_ns,CAP_SYS_ADMIN)) {
+   pr_warn_ratelimited("TIOCSTI ioctl call blocked for 
non-privileged process\n");
+   return -EPERM;
+   }
if ((current->signal->tty != tty) && !capable(CAP_SYS_ADMIN))
return -EPERM;
if (get_user(ch, p))
diff --git a/include/linux/tty.h b/include/linux/tty.h
index d902d42..2fd7f49 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -344,6 +344,8 @@ struct tty_file_private {
struct list_head list;
 };
 
+extern int tiocsti_restrict;
+
 /* tty magic number */
 #define TTY_MAGIC  0x5401
 
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index acf0a5a..68d1363 100644
--- a/kernel/

[PATCH v5 1/2] security: tty: Add owner user namespace to tty_struct

[Matt Brown]

This patch adds struct user_namespace *owner_user_ns to the tty_struct.
Then it is set to current_user_ns() in the alloc_tty_struct function.

This is done to facilitate capability checks against the original user
namespace that allocated the tty.

E.g. ns_capable(tty->owner_user_ns,CAP_SYS_ADMIN)

This combined with the use of user namespace's will allow hardening
protections to be built to mitigate container escapes that utilize TTY
ioctls such as TIOCSTI.

See: https://bugzilla.redhat.com/show_bug.cgi?id=1411256

Signed-off-by: Matt Brown 
---
 drivers/tty/tty_io.c | 2 ++
 include/linux/tty.h  | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index e6d1a65..c276814 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -171,6 +171,7 @@ static void free_tty_struct(struct tty_struct *tty)
put_device(tty->dev);
kfree(tty->write_buf);
tty->magic = 0xDEADDEAD;
+   put_user_ns(tty->owner_user_ns);
kfree(tty);
 }
 
@@ -3191,6 +3192,7 @@ struct tty_struct *alloc_tty_struct(struct tty_driver 
*driver, int idx)
tty->index = idx;
tty_line_name(driver, idx, tty->name);
tty->dev = tty_get_device(tty);
+   tty->owner_user_ns = get_user_ns(current_user_ns());
 
return tty;
 }
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 1017e904..d902d42 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 
 /*
@@ -333,6 +334,7 @@ struct tty_struct {
/* If the tty has a pending do_SAK, queue it here - akpm */
struct work_struct SAK_work;
struct tty_port *port;
+   struct user_namespace *owner_user_ns;
 };
 
 /* Each of a tty's open files has private_data pointing to tty_file_private */
-- 
2.10.2

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html