RE: [PATCH 4/5] rpmsg: Driver for user space endpoint interface

2016-10-10 Thread Marek Novak 
-Original Message-
From: Bjorn Andersson [mailto:bjorn.anders...@linaro.org] 
Sent: Saturday, October 08, 2016 6:23 AM
To: Ohad Ben-Cohen ; Bjorn Andersson 

Cc: Jonathan Corbet ; Linus Walleij ; 
Marek Novak ; Matteo Sartori ; 
Michal Simek ; linux-doc@vger.kernel.org; 
linux-ker...@vger.kernel.org; linux-remotep...@vger.kernel.org; 
linux-arm-ker...@lists.infradead.org; linux-arm-...@vger.kernel.org
Subject: [PATCH 4/5] rpmsg: Driver for user space endpoint interface

This driver allows rpmsg instances to expose access to rpmsg endpoints to user 
space processes. It provides a control interface, allowing userspace to export 
endpoints and an endpoint interface for each exposed endpoint.

The implementation is based on prior art by Texas Instrument, Google, PetaLogix 
and was derived from a FreeRTOS performance statistics driver written by Michal 
Simek.

The control interface provides a "create endpoint" ioctl, which is fed a name, 
source and destination address. The three values are used to create the 
endpoint, in a backend-specific way, and a rpmsg endpoint device is created - 
with the three parameters are available in sysfs for udev usage.

E.g. to create an endpoint device for one of the Qualcomm SMD channel related 
to DIAG one would issue:

  struct rpmsg_endpoint_info info = { "DIAG_CNTL", 0, 0 };
  int fd = open("/dev/rpmsg_ctrl0", O_RDWR);
  ioctl(fd, RPMSG_CREATE_EPT_IOCTL, );

Each created endpoint device shows up as an individual character device in 
/dev, allowing permission to be controlled on a per-endpoint basis.
The rpmsg endpoint will be created and destroyed following the opening and 
closing of the endpoint device, allowing rpmsg backends to open and close the 
physical channel, if supported by the wire protocol.

Cc: Marek Novak 
Cc: Matteo Sartori 
Cc: Michal Simek 
Signed-off-by: Bjorn Andersson 
---
 Documentation/ioctl/ioctl-number.txt |   1 +
 drivers/rpmsg/Makefile   |   2 +-
 drivers/rpmsg/rpmsg_char.c   | 576 +++
 drivers/rpmsg/rpmsg_internal.h   |   2 +
 include/uapi/linux/rpmsg.h   |  35 +++
 5 files changed, 615 insertions(+), 1 deletion(-)  create mode 100644 
drivers/rpmsg/rpmsg_char.c  create mode 100644 include/uapi/linux/rpmsg.h

diff --git a/Documentation/ioctl/ioctl-number.txt 
b/Documentation/ioctl/ioctl-number.txt
index 81c7f2bb7daf..08244bea5048 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -321,6 +321,7 @@ Code  Seq#(hex) Include FileComments
 0xB1   00-1F   PPPoX   
 0xB3   00  linux/mmc/ioctl.h
 0xB4   00-0F   linux/gpio.h
+0xB5   00-0F   uapi/linux/rpmsg.h  

 0xC0   00-0F   linux/usb/iowarrior.h
 0xCA   00-0F   uapi/misc/cxl.h
 0xCA   80-8F   uapi/scsi/cxlflash_ioctl.h
diff --git a/drivers/rpmsg/Makefile b/drivers/rpmsg/Makefile index 
ae9c9132cf76..5daf1209b77d 100644
--- a/drivers/rpmsg/Makefile
+++ b/drivers/rpmsg/Makefile
@@ -1,3 +1,3 @@
-obj-$(CONFIG_RPMSG)+= rpmsg_core.o
+obj-$(CONFIG_RPMSG)+= rpmsg_core.o rpmsg_char.o
 obj-$(CONFIG_RPMSG_QCOM_SMD)   += qcom_smd.o
 obj-$(CONFIG_RPMSG_VIRTIO) += virtio_rpmsg_bus.o
diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c new file 
mode 100644 index ..a398a63e8d44
--- /dev/null
+++ b/drivers/rpmsg/rpmsg_char.c
@@ -0,0 +1,576 @@
+/*
+ * Copyright (c) 2016, Linaro Ltd.
+ * Copyright (c) 2012, Michal Simek 
+ * Copyright (c) 2012, PetaLogix
+ * Copyright (c) 2011, Texas Instruments, Inc.
+ * Copyright (c) 2011, Google, Inc.
+ *
+ * Based on rpmsg performance statistics driver by Michal Simek, which 
+in turn
+ * was based on TI & Google OMX rpmsg driver.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "rpmsg_internal.h"
+
+#define RPMSG_DEV_MAX  256
+
+static dev_t rpmsg_major;
+static struct class *rpmsg_class;
+
+static DEFINE_IDA(rpmsg_ctrl_ida);
+static DEFINE_IDA(rpmsg_ept_ida);
+static DEFINE_IDA(rpmsg_minor_ida);
+
+#define dev_to_eptdev(dev) container_of(dev,

Re: [PATCHv4] hwmon: Add tc654 driver

2016-10-10 Thread Rob Herring 
On Tue, Oct 11, 2016 at 10:26:31AM +1300, Chris Packham wrote:
> Add support for the tc654 and tc655 fan controllers from Microchip.
> 
> http://ww1.microchip.com/downloads/en/DeviceDoc/20001734C.pdf
> 
> Signed-off-by: Chris Packham 
> ---
> Changes in v4:
> - tab-align values in #defines
> - ensure locking in set_pwm covers updating cached values
> - populate the cached value for the config register in tc654_probe()
> 
> Changes in v3:
> - typofix in documentation
> - add missing value to tc654_pwm_map, re-generate based on datasheet.
> - remove unnecessary hwmon_dev member from struct tc654_data
> - bug fixes in set_fan_min() and show_pwm_mode()
> - miscellaneous style fixes
>  
> Changes in v2:
> - Add Documentation/hwmon/tc654
> - Incorporate most of the review comments from Guenter. Additional error
>   handling is added. Unused/unnecessary code is removed. I decided not
>   to go down the regmap path yet. I may circle back to it when I look at
>   using regmap in the adm9240 driver.
> 
>  .../devicetree/bindings/i2c/trivial-devices.txt|   2 +

Expect a merge conflict with the IIO tree.

Acked-by: Rob Herring 

>  Documentation/hwmon/tc654  |  31 ++
>  drivers/hwmon/Kconfig  |  11 +
>  drivers/hwmon/Makefile |   1 +
>  drivers/hwmon/tc654.c  | 514 
> +
>  5 files changed, 559 insertions(+)
>  create mode 100644 Documentation/hwmon/tc654
>  create mode 100644 drivers/hwmon/tc654.c
--
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 8/8] Input: elan_i2c - add Host Notify support

2016-10-10 Thread Dmitry Torokhov 
Hi Benjamin,

On Mon, Oct 10, 2016 at 9:42 AM, Benjamin Tissoires
 wrote:
> The Thinkpad series 13 uses Host Notify to report the interrupt.
> Add elan_smb_alert() to handle those interrupts and disable the irq
> handling on this case.
>
> Signed-off-by: Benjamin Tissoires 
>

Why do we have to do this in the driver instead of having I2C core set
it up for us? I expect we'd be repeating this block of code for every
driver that has an option of using SMbus notify.

Thanks!

> ---
>
> new in v4 (was submitted on linux-input with the .alert callback)
> ---
>  drivers/input/mouse/elan_i2c_core.c | 15 +++
>  1 file changed, 15 insertions(+)
>
> diff --git a/drivers/input/mouse/elan_i2c_core.c 
> b/drivers/input/mouse/elan_i2c_core.c
> index 6f16eb4..4aaac5d 100644
> --- a/drivers/input/mouse/elan_i2c_core.c
> +++ b/drivers/input/mouse/elan_i2c_core.c
> @@ -1040,6 +1040,21 @@ static int elan_probe(struct i2c_client *client,
> I2C_FUNC_SMBUS_BLOCK_DATA |
> I2C_FUNC_SMBUS_I2C_BLOCK)) {
> transport_ops = _smbus_ops;
> +
> +   if (!irq) {
> +   if (!i2c_check_functionality(client->adapter,
> +   I2C_FUNC_SMBUS_HOST_NOTIFY)) {
> +   dev_err(dev, "no Host Notify support\n");
> +   return -ENODEV;
> +   }
> +
> +   irq = i2c_smbus_host_notify_to_irq(client);
> +   if (irq < 0) {
> +   dev_err(dev,
> +   "Unable to request a Host Notify 
> IRQ.\n");
> +   return irq;
> +   }
> +   }
> } else {
> dev_err(dev, "not a supported I2C/SMBus adapter\n");
> return -EIO;
> --
> 2.7.4
>



-- 
Dmitry
--
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

[PATCHv4] hwmon: Add tc654 driver

2016-10-10 Thread Chris Packham 
Add support for the tc654 and tc655 fan controllers from Microchip.

http://ww1.microchip.com/downloads/en/DeviceDoc/20001734C.pdf

Signed-off-by: Chris Packham 
---
Changes in v4:
- tab-align values in #defines
- ensure locking in set_pwm covers updating cached values
- populate the cached value for the config register in tc654_probe()

Changes in v3:
- typofix in documentation
- add missing value to tc654_pwm_map, re-generate based on datasheet.
- remove unnecessary hwmon_dev member from struct tc654_data
- bug fixes in set_fan_min() and show_pwm_mode()
- miscellaneous style fixes
 
Changes in v2:
- Add Documentation/hwmon/tc654
- Incorporate most of the review comments from Guenter. Additional error
  handling is added. Unused/unnecessary code is removed. I decided not
  to go down the regmap path yet. I may circle back to it when I look at
  using regmap in the adm9240 driver.

 .../devicetree/bindings/i2c/trivial-devices.txt|   2 +
 Documentation/hwmon/tc654  |  31 ++
 drivers/hwmon/Kconfig  |  11 +
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/tc654.c  | 514 +
 5 files changed, 559 insertions(+)
 create mode 100644 Documentation/hwmon/tc654
 create mode 100644 drivers/hwmon/tc654.c

diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt 
b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index 1416c6a0d2cd..833fb9f133d3 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -122,6 +122,8 @@ microchip,mcp4662-502   Microchip 8-bit Dual I2C 
Digital Potentiometer with NV Mem
 microchip,mcp4662-103  Microchip 8-bit Dual I2C Digital Potentiometer with NV 
Memory (10k)
 microchip,mcp4662-503  Microchip 8-bit Dual I2C Digital Potentiometer with NV 
Memory (50k)
 microchip,mcp4662-104  Microchip 8-bit Dual I2C Digital Potentiometer with NV 
Memory (100k)
+microchip,tc654PWM Fan Speed Controller With Fan Fault 
Detection
+microchip,tc655PWM Fan Speed Controller With Fan Fault 
Detection
 national,lm63  Temperature sensor with integrated fan control
 national,lm75  I2C TEMP SENSOR
 national,lm80  Serial Interface ACPI-Compatible Microprocessor System 
Hardware Monitor
diff --git a/Documentation/hwmon/tc654 b/Documentation/hwmon/tc654
new file mode 100644
index ..91a2843f5f98
--- /dev/null
+++ b/Documentation/hwmon/tc654
@@ -0,0 +1,31 @@
+Kernel driver tc654
+===
+
+Supported chips:
+  * Microship TC654 and TC655
+Prefix: 'tc654'
+Datasheet: http://ww1.microchip.com/downloads/en/DeviceDoc/20001734C.pdf
+
+Authors:
+Chris Packham 
+Masahiko Iwamoto 
+
+Description
+---
+This driver implements support for the Microchip TC654 and TC655.
+
+The TC654 uses the 2-wire interface compatible with the SMBUS 2.0
+specification. The TC654 has two (2) inputs for measuring fan RPM and
+one (1) PWM output which can be used for fan control.
+
+Configuration Notes
+---
+Ordinarily the pwm1_mode ABI is used for controlling the pwm output
+mode.  However, for this chip the output is always pwm, and the
+pwm1_mode determines if the pwm output is controlled via the pwm1 value
+or via the Vin analog input.
+
+
+Setting pwm1_mode to 1 will cause the pwm output to be driven based on
+the pwm1 value. Setting pwm1_mode to 0 will cause the pwm output to be
+driven based on the Vin input.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 45cef3d2c75c..8681bc65cde5 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -907,6 +907,17 @@ config SENSORS_MCP3021
  This driver can also be built as a module.  If so, the module
  will be called mcp3021.
 
+config SENSORS_TC654
+   tristate "Microchip TC654/TC655 and compatibles"
+   depends on I2C
+   help
+ If you say yes here you get support for TC654 and TC655.
+ The TC654 and TC655 are PWM mode fan speed controllers with
+ FanSense technology for use with brushless DC fans.
+
+ This driver can also be built as a module.  If so, the module
+ will be called tc654.
+
 config SENSORS_MENF21BMC_HWMON
tristate "MEN 14F021P00 BMC Hardware Monitoring"
depends on MFD_MENF21BMC
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index aecf4ba17460..c651f0f1d047 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -122,6 +122,7 @@ obj-$(CONFIG_SENSORS_MAX6697)   += max6697.o
 obj-$(CONFIG_SENSORS_MAX31790) += max31790.o
 obj-$(CONFIG_SENSORS_MC13783_ADC)+= mc13783-adc.o
 obj-$(CONFIG_SENSORS_MCP3021)  += mcp3021.o
+obj-$(CONFIG_SENSORS_TC654)+= tc654.o
 obj-$(CONFIG_SENSORS_MENF21BMC_HWMON) +=

Re: [PATCHv3] hwmon: Add tc654 driver

2016-10-10 Thread Guenter Roeck 
On Mon, Oct 10, 2016 at 08:08:14PM +, Chris Packham wrote:
> On 10/11/2016 02:22 AM, Guenter Roeck wrote:
> >> +  if (val)
> >> > +data->config |= TC654_REG_CONFIG_DUTYC;
> >> > +else
> >> > +data->config &= ~TC654_REG_CONFIG_DUTYC;
> > I just realized that this won't work as intended. Problem is that you
> > only fill data->config when reading an attribute. So, if a set function
> > is called prior to reading an attribute, data->config will be 0, and
> > you end up overwriting the original configuration.
> >
> 
> Should I just read it in the probe function or fill it in with the 
> documented hardware defaults?

Reading it would be better - that leaves the option open that it was configured
by ROMMON or BIOS.

Guenter
--
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: [PATCHv3] hwmon: Add tc654 driver

2016-10-10 Thread Chris Packham 
On 10/11/2016 02:22 AM, Guenter Roeck wrote:
>> +if (val)
>> > +  data->config |= TC654_REG_CONFIG_DUTYC;
>> > +  else
>> > +  data->config &= ~TC654_REG_CONFIG_DUTYC;
> I just realized that this won't work as intended. Problem is that you
> only fill data->config when reading an attribute. So, if a set function
> is called prior to reading an attribute, data->config will be 0, and
> you end up overwriting the original configuration.
>

Should I just read it in the probe function or fill it in with the 
documented hardware defaults?
--
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 v4 5/8] i2c: i801: remove SMBNTFDDAT reads as they always seem to return 0

2016-10-10 Thread Benjamin Tissoires 
On the platform tested, reading SMBNTFDDAT always returns 0 (using 1 read
of a word or 2 of 2 bytes). Given that we are not sure why and that we
don't need to rely on the data parameter in the current users of Host
Notify, remove this part of the code.

If someone wants to re-enable it, just revert this commit and data should
be available.

Signed-off-by: Benjamin Tissoires 

---

no changes in v4

no changes in v3

new in v2
---
 drivers/i2c/busses/i2c-i801.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index 88b2e31..42a6a89 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -117,7 +117,6 @@
 #define SMBSLVSTS(p)   (16 + (p)->smba)/* ICH3 and later */
 #define SMBSLVCMD(p)   (17 + (p)->smba)/* ICH3 and later */
 #define SMBNTFDADD(p)  (20 + (p)->smba)/* ICH3 and later */
-#define SMBNTFDDAT(p)  (22 + (p)->smba)/* ICH3 and later */
 
 /* PCI Address Constants */
 #define SMBBAR 4
@@ -578,12 +577,15 @@ static void i801_isr_byte_done(struct i801_priv *priv)
 static irqreturn_t i801_host_notify_isr(struct i801_priv *priv)
 {
unsigned short addr;
-   unsigned int data;
 
addr = inb_p(SMBNTFDADD(priv)) >> 1;
-   data = inw_p(SMBNTFDDAT(priv));
 
-   i2c_handle_smbus_host_notify(priv->host_notify, addr, data);
+   /*
+* With the tested platforms, reading SMBNTFDDAT (22 + (p)->smba)
+* always returns 0 and is safe to read.
+* We just use 0 given we have no use of the data right now.
+*/
+   i2c_handle_smbus_host_notify(priv->host_notify, addr, 0);
 
/* clear Host Notify bit and return */
outb_p(SMBSLVSTS_HST_NTFY_STS, SMBSLVSTS(priv));
-- 
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 v4 6/8] i2c: use an IRQ to report Host Notify events, not alert

2016-10-10 Thread Benjamin Tissoires 
The current SMBus Host Notify implementation relies on .alert() to
relay its notifications. However, the use cases where SMBus Host
Notify is needed currently is to signal data ready on touchpads.

This is closer to an IRQ than a custom API through .alert().
Given that the 2 touchpad manufacturers (Synaptics and Elan) that
use SMBus Host Notify don't put any data in the SMBus payload, the
concept actually matches one to one.

Benefits are multiple:
- simpler code and API: the client just needs to get the IRQ through
  i2c_smbus_host_notify_to_irq(), nothing needs to be added in the
  adapter beside internally enabling it.
- no more specific workqueue, the threading is handled by IRQ core
  directly (when required)
- no more races when removing the device (the drivers are already
  required to disable irq on remove)
- simpler handling for drivers: use plain regular IRQs
- no more dependency on i2c-smbus for i2c-i801 (and any other adapter)
- the IRQ domain is created automatically when the adapter exports
  the Host Notify capability, but the IRQ are allocated on demand
- the domain is automatically destroyed on remove
- fewer lines of code (minus 20, yeah!)

Signed-off-by: Benjamin Tissoires 

---

new in v4
---
 Documentation/i2c/smbus-protocol |  10 ++--
 drivers/i2c/busses/i2c-i801.c|  31 +++
 drivers/i2c/i2c-core.c   | 117 +++
 drivers/i2c/i2c-smbus.c  | 102 --
 include/linux/i2c-smbus.h|  27 -
 include/linux/i2c.h  |   5 ++
 6 files changed, 135 insertions(+), 157 deletions(-)

diff --git a/Documentation/i2c/smbus-protocol b/Documentation/i2c/smbus-protocol
index 14d4ec1..8a29ba3 100644
--- a/Documentation/i2c/smbus-protocol
+++ b/Documentation/i2c/smbus-protocol
@@ -200,10 +200,12 @@ alerting device's address.
 [S] [HostAddr] [Wr] A [DevAddr] A [DataLow] A [DataHigh] A [P]
 
 This is implemented in the following way in the Linux kernel:
-* I2C bus drivers which support SMBus Host Notify should call
-  i2c_setup_smbus_host_notify() to setup SMBus Host Notify support.
-* I2C drivers for devices which can trigger SMBus Host Notify should implement
-  the optional alert() callback.
+* I2C bus drivers which support SMBus Host Notify should report
+  I2C_FUNC_SMBUS_HOST_NOTIFY.
+* I2C drivers for devices which can trigger SMBus Host Notify should request
+  a Host Notify IRQ through i2c_smbus_host_notify_to_irq().
+
+There is currently no way to retrieve the data parameter from the client.
 
 
 Packet Error Checking (PEC)
diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index 42a6a89..a016b48 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -266,7 +266,6 @@ struct i801_priv {
 */
bool acpi_reserved;
struct mutex acpi_lock;
-   struct smbus_host_notify *host_notify;
 };
 
 #define FEATURE_SMBUS_PEC  BIT(0)
@@ -582,10 +581,10 @@ static irqreturn_t i801_host_notify_isr(struct i801_priv 
*priv)
 
/*
 * With the tested platforms, reading SMBNTFDDAT (22 + (p)->smba)
-* always returns 0 and is safe to read.
-* We just use 0 given we have no use of the data right now.
+* always returns 0. Our current implementation doesn't provide
+* data, so we just ignore it.
 */
-   i2c_handle_smbus_host_notify(priv->host_notify, addr, 0);
+   i2c_handle_smbus_host_notify(>adapter, addr);
 
/* clear Host Notify bit and return */
outb_p(SMBSLVSTS_HST_NTFY_STS, SMBSLVSTS(priv));
@@ -941,17 +940,12 @@ static u32 i801_func(struct i2c_adapter *adapter)
I2C_FUNC_SMBUS_HOST_NOTIFY : 0);
 }
 
-static int i801_enable_host_notify(struct i2c_adapter *adapter)
+static void i801_enable_host_notify(struct i2c_adapter *adapter)
 {
struct i801_priv *priv = i2c_get_adapdata(adapter);
 
if (!(priv->features & FEATURE_HOST_NOTIFY))
-   return -ENOTSUPP;
-
-   if (!priv->host_notify)
-   priv->host_notify = i2c_setup_smbus_host_notify(adapter);
-   if (!priv->host_notify)
-   return -ENOMEM;
+   return;
 
priv->original_slvcmd = inb_p(SMBSLVCMD(priv));
 
@@ -961,8 +955,6 @@ static int i801_enable_host_notify(struct i2c_adapter 
*adapter)
 
/* clear Host Notify bit to allow a new notification */
outb_p(SMBSLVSTS_HST_NTFY_STS, SMBSLVSTS(priv));
-
-   return 0;
 }
 
 static void i801_disable_host_notify(struct i801_priv *priv)
@@ -1631,14 +1623,7 @@ static int i801_probe(struct pci_dev *dev, const struct 
pci_device_id *id)
return err;
}
 
-   /*
-* Enable Host Notify for chips that supports it.
-* It is done after i2c_add_adapter() so that we are sure the work queue
-* is not used if i2c_add_adapter() fails.
-*/
-   err =

[PATCH v4 2/8] i2c: i801: minor formatting issues

2016-10-10 Thread Benjamin Tissoires 
No functional changes, just typos and remove unused #define.

Reviewed-by: Jean Delvare 
Signed-off-by: Benjamin Tissoires 

---

no changes in v4

no changes in v3

no changes in v2
---
 drivers/i2c/busses/i2c-i801.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index 3a2fdf5..cfb74fc 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -186,10 +186,10 @@
 #define SMBHSTSTS_INTR 0x02
 #define SMBHSTSTS_HOST_BUSY0x01
 
-/* Host Notify Status registers bits */
+/* Host Notify Status register bits */
 #define SMBSLVSTS_HST_NTFY_STS 1
 
-/* Host Notify Command registers bits */
+/* Host Notify Command register bits */
 #define SMBSLVCMD_HST_NTFY_INTREN  0x01
 
 #define STATUS_ERROR_FLAGS (SMBHSTSTS_FAILED | SMBHSTSTS_BUS_ERR | \
@@ -270,8 +270,6 @@ struct i801_priv {
struct smbus_host_notify *host_notify;
 };
 
-#define SMBHSTNTFY_SIZE8
-
 #define FEATURE_SMBUS_PEC  (1 << 0)
 #define FEATURE_BLOCK_BUFFER   (1 << 1)
 #define FEATURE_BLOCK_PROC (1 << 2)
-- 
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 v4 3/8] i2c: i801: use BIT() macro for bits definition

2016-10-10 Thread Benjamin Tissoires 
i801 mixes hexadecimal and decimal values for defining bits. However,
we have a nice BIT() macro for this exact purpose.

No functional changes, cleanup only.

Reviewed-by: Jean Delvare 
Signed-off-by: Benjamin Tissoires 

---

no changes in v4

no changes in v3

no changes in v2
---
 drivers/i2c/busses/i2c-i801.c | 50 +--
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index cfb74fc..5928ee2 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -136,26 +136,26 @@
 #define SBREG_SMBCTRL  0xc6000c
 
 /* Host status bits for SMBPCISTS */
-#define SMBPCISTS_INTS 0x08
+#define SMBPCISTS_INTS BIT(3)
 
 /* Control bits for SMBPCICTL */
-#define SMBPCICTL_INTDIS   0x0400
+#define SMBPCICTL_INTDIS   BIT(10)
 
 /* Host configuration bits for SMBHSTCFG */
-#define SMBHSTCFG_HST_EN   1
-#define SMBHSTCFG_SMB_SMI_EN   2
-#define SMBHSTCFG_I2C_EN   4
+#define SMBHSTCFG_HST_EN   BIT(0)
+#define SMBHSTCFG_SMB_SMI_EN   BIT(1)
+#define SMBHSTCFG_I2C_EN   BIT(2)
 
 /* TCO configuration bits for TCOCTL */
-#define TCOCTL_EN  0x0100
+#define TCOCTL_EN  BIT(8)
 
 /* Auxiliary status register bits, ICH4+ only */
-#define SMBAUXSTS_CRCE 1
-#define SMBAUXSTS_STCO 2
+#define SMBAUXSTS_CRCE BIT(0)
+#define SMBAUXSTS_STCO BIT(1)
 
 /* Auxiliary control register bits, ICH4+ only */
-#define SMBAUXCTL_CRC  1
-#define SMBAUXCTL_E32B 2
+#define SMBAUXCTL_CRC  BIT(0)
+#define SMBAUXCTL_E32B BIT(1)
 
 /* Other settings */
 #define MAX_RETRIES400
@@ -170,27 +170,27 @@
 #define I801_I2C_BLOCK_DATA0x18/* ICH5 and later */
 
 /* I801 Host Control register bits */
-#define SMBHSTCNT_INTREN   0x01
-#define SMBHSTCNT_KILL 0x02
-#define SMBHSTCNT_LAST_BYTE0x20
-#define SMBHSTCNT_START0x40
-#define SMBHSTCNT_PEC_EN   0x80/* ICH3 and later */
+#define SMBHSTCNT_INTREN   BIT(0)
+#define SMBHSTCNT_KILL BIT(1)
+#define SMBHSTCNT_LAST_BYTEBIT(5)
+#define SMBHSTCNT_STARTBIT(6)
+#define SMBHSTCNT_PEC_EN   BIT(7)  /* ICH3 and later */
 
 /* I801 Hosts Status register bits */
-#define SMBHSTSTS_BYTE_DONE0x80
-#define SMBHSTSTS_INUSE_STS0x40
-#define SMBHSTSTS_SMBALERT_STS 0x20
-#define SMBHSTSTS_FAILED   0x10
-#define SMBHSTSTS_BUS_ERR  0x08
-#define SMBHSTSTS_DEV_ERR  0x04
-#define SMBHSTSTS_INTR 0x02
-#define SMBHSTSTS_HOST_BUSY0x01
+#define SMBHSTSTS_BYTE_DONEBIT(7)
+#define SMBHSTSTS_INUSE_STSBIT(6)
+#define SMBHSTSTS_SMBALERT_STS BIT(5)
+#define SMBHSTSTS_FAILED   BIT(4)
+#define SMBHSTSTS_BUS_ERR  BIT(3)
+#define SMBHSTSTS_DEV_ERR  BIT(2)
+#define SMBHSTSTS_INTR BIT(1)
+#define SMBHSTSTS_HOST_BUSYBIT(0)
 
 /* Host Notify Status register bits */
-#define SMBSLVSTS_HST_NTFY_STS 1
+#define SMBSLVSTS_HST_NTFY_STS BIT(0)
 
 /* Host Notify Command register bits */
-#define SMBSLVCMD_HST_NTFY_INTREN  0x01
+#define SMBSLVCMD_HST_NTFY_INTREN  BIT(0)
 
 #define STATUS_ERROR_FLAGS (SMBHSTSTS_FAILED | SMBHSTSTS_BUS_ERR | \
 SMBHSTSTS_DEV_ERR)
-- 
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 v4 1/8] i2c: i801: store and restore the SLVCMD register at load and unload

2016-10-10 Thread Benjamin Tissoires 
Also do not override any other configuration in this register.

Signed-off-by: Benjamin Tissoires 

---

changes in v4:
- add the i801_disable_host_notify function here as this gets the
  first in the series

no changes in v3

new in v2
---
 drivers/i2c/busses/i2c-i801.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index 22a0ed4..3a2fdf5 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -240,6 +240,7 @@ struct i801_priv {
struct i2c_adapter adapter;
unsigned long smba;
unsigned char original_hstcfg;
+   unsigned char original_slvcmd;
struct pci_dev *pci_dev;
unsigned int features;
 
@@ -952,13 +953,26 @@ static int i801_enable_host_notify(struct i2c_adapter 
*adapter)
if (!priv->host_notify)
return -ENOMEM;
 
-   outb_p(SMBSLVCMD_HST_NTFY_INTREN, SMBSLVCMD(priv));
+   priv->original_slvcmd = inb_p(SMBSLVCMD(priv));
+
+   if (!(SMBSLVCMD_HST_NTFY_INTREN & priv->original_slvcmd))
+   outb_p(SMBSLVCMD_HST_NTFY_INTREN | priv->original_slvcmd,
+  SMBSLVCMD(priv));
+
/* clear Host Notify bit to allow a new notification */
outb_p(SMBSLVSTS_HST_NTFY_STS, SMBSLVSTS(priv));
 
return 0;
 }
 
+static void i801_disable_host_notify(struct i801_priv *priv)
+{
+   if (!(priv->features & FEATURE_HOST_NOTIFY))
+   return;
+
+   outb_p(priv->original_slvcmd, SMBSLVCMD(priv));
+}
+
 static const struct i2c_algorithm smbus_algorithm = {
.smbus_xfer = i801_access,
.functionality  = i801_func,
@@ -1647,6 +1661,7 @@ static void i801_remove(struct pci_dev *dev)
pm_runtime_forbid(>dev);
pm_runtime_get_noresume(>dev);
 
+   i801_disable_host_notify(priv);
i801_del_mux(priv);
i2c_del_adapter(>adapter);
i801_acpi_remove(priv);
-- 
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 v4 8/8] Input: elan_i2c - add Host Notify support

2016-10-10 Thread Benjamin Tissoires 
The Thinkpad series 13 uses Host Notify to report the interrupt.
Add elan_smb_alert() to handle those interrupts and disable the irq
handling on this case.

Signed-off-by: Benjamin Tissoires 

---

new in v4 (was submitted on linux-input with the .alert callback)
---
 drivers/input/mouse/elan_i2c_core.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/input/mouse/elan_i2c_core.c 
b/drivers/input/mouse/elan_i2c_core.c
index 6f16eb4..4aaac5d 100644
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -1040,6 +1040,21 @@ static int elan_probe(struct i2c_client *client,
I2C_FUNC_SMBUS_BLOCK_DATA |
I2C_FUNC_SMBUS_I2C_BLOCK)) {
transport_ops = _smbus_ops;
+
+   if (!irq) {
+   if (!i2c_check_functionality(client->adapter,
+   I2C_FUNC_SMBUS_HOST_NOTIFY)) {
+   dev_err(dev, "no Host Notify support\n");
+   return -ENODEV;
+   }
+
+   irq = i2c_smbus_host_notify_to_irq(client);
+   if (irq < 0) {
+   dev_err(dev,
+   "Unable to request a Host Notify 
IRQ.\n");
+   return irq;
+   }
+   }
} else {
dev_err(dev, "not a supported I2C/SMBus adapter\n");
return -EIO;
-- 
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 v4 4/8] i2c: i801: use the BIT() macro for FEATURES_* also

2016-10-10 Thread Benjamin Tissoires 
no functional changes

Signed-off-by: Benjamin Tissoires 

---

no changes in v4

no changes in v3

new in v2
---
 drivers/i2c/busses/i2c-i801.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index 5928ee2..88b2e31 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -270,15 +270,15 @@ struct i801_priv {
struct smbus_host_notify *host_notify;
 };
 
-#define FEATURE_SMBUS_PEC  (1 << 0)
-#define FEATURE_BLOCK_BUFFER   (1 << 1)
-#define FEATURE_BLOCK_PROC (1 << 2)
-#define FEATURE_I2C_BLOCK_READ (1 << 3)
-#define FEATURE_IRQ(1 << 4)
-#define FEATURE_HOST_NOTIFY(1 << 5)
+#define FEATURE_SMBUS_PEC  BIT(0)
+#define FEATURE_BLOCK_BUFFER   BIT(1)
+#define FEATURE_BLOCK_PROC BIT(2)
+#define FEATURE_I2C_BLOCK_READ BIT(3)
+#define FEATURE_IRQBIT(4)
+#define FEATURE_HOST_NOTIFYBIT(5)
 /* Not really a feature, but it's convenient to handle it as such */
-#define FEATURE_IDF(1 << 15)
-#define FEATURE_TCO(1 << 16)
+#define FEATURE_IDFBIT(15)
+#define FEATURE_TCOBIT(16)
 
 static const char *i801_feature_names[] = {
"SMBus PEC",
-- 
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 v4 7/8] Input: elan_i2c - store the irq in struct elan_tp_data

2016-10-10 Thread Benjamin Tissoires 
And make sure we have one available.

Signed-off-by: Benjamin Tissoires 

---

new in v4
---
 drivers/input/mouse/elan_i2c_core.c | 34 ++
 1 file changed, 22 insertions(+), 12 deletions(-)

diff --git a/drivers/input/mouse/elan_i2c_core.c 
b/drivers/input/mouse/elan_i2c_core.c
index d15b338..6f16eb4 100644
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -62,6 +62,7 @@ struct elan_tp_data {
struct i2c_client   *client;
struct input_dev*input;
struct regulator*vcc;
+   int irq;
 
const struct elan_transport_ops *ops;
 
@@ -457,7 +458,7 @@ static int elan_update_firmware(struct elan_tp_data *data,
 
dev_dbg(>dev, "Starting firmware update\n");
 
-   disable_irq(client->irq);
+   disable_irq(data->irq);
data->in_fw_update = true;
 
retval = __elan_update_firmware(data, fw);
@@ -471,7 +472,7 @@ static int elan_update_firmware(struct elan_tp_data *data,
}
 
data->in_fw_update = false;
-   enable_irq(client->irq);
+   enable_irq(data->irq);
 
return retval;
 }
@@ -599,7 +600,7 @@ static ssize_t calibrate_store(struct device *dev,
if (retval)
return retval;
 
-   disable_irq(client->irq);
+   disable_irq(data->irq);
 
data->mode |= ETP_ENABLE_CALIBRATE;
retval = data->ops->set_mode(client, data->mode);
@@ -645,7 +646,7 @@ out_disable_calibrate:
retval = error;
}
 out:
-   enable_irq(client->irq);
+   enable_irq(data->irq);
mutex_unlock(>sysfs_mutex);
return retval ?: count;
 }
@@ -711,7 +712,7 @@ static ssize_t acquire_store(struct device *dev, struct 
device_attribute *attr,
if (retval)
return retval;
 
-   disable_irq(client->irq);
+   disable_irq(data->irq);
 
data->baseline_ready = false;
 
@@ -753,7 +754,7 @@ out_disable_calibrate:
retval = error;
}
 out:
-   enable_irq(client->irq);
+   enable_irq(data->irq);
mutex_unlock(>sysfs_mutex);
return retval ?: count;
 }
@@ -1026,6 +1027,9 @@ static int elan_probe(struct i2c_client *client,
struct elan_tp_data *data;
unsigned long irqflags;
int error;
+   int irq;
+
+   irq = client->irq;
 
if (IS_ENABLED(CONFIG_MOUSE_ELAN_I2C_I2C) &&
i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
@@ -1041,6 +1045,11 @@ static int elan_probe(struct i2c_client *client,
return -EIO;
}
 
+   if (irq <= 0) {
+   dev_err(dev, "no IRQ provided.\n");
+   return -ENODEV;
+   }
+
data = devm_kzalloc(>dev, sizeof(struct elan_tp_data),
GFP_KERNEL);
if (!data)
@@ -1049,6 +1058,7 @@ static int elan_probe(struct i2c_client *client,
i2c_set_clientdata(client, data);
 
data->ops = transport_ops;
+   data->irq = irq;
data->client = client;
init_completion(>fw_completion);
mutex_init(>sysfs_mutex);
@@ -1121,12 +1131,12 @@ static int elan_probe(struct i2c_client *client,
 */
irqflags = client->dev.of_node ? 0 : IRQF_TRIGGER_FALLING;
 
-   error = devm_request_threaded_irq(>dev, client->irq,
+   error = devm_request_threaded_irq(>dev, data->irq,
  NULL, elan_isr,
  irqflags | IRQF_ONESHOT,
  client->name, data);
if (error) {
-   dev_err(>dev, "cannot register irq=%d\n", client->irq);
+   dev_err(>dev, "cannot register irq=%d\n", data->irq);
return error;
}
 
@@ -1179,12 +1189,12 @@ static int __maybe_unused elan_suspend(struct device 
*dev)
if (ret)
return ret;
 
-   disable_irq(client->irq);
+   disable_irq(data->irq);
 
if (device_may_wakeup(dev)) {
ret = elan_sleep(data);
/* Enable wake from IRQ */
-   data->irq_wake = (enable_irq_wake(client->irq) == 0);
+   data->irq_wake = (enable_irq_wake(data->irq) == 0);
} else {
ret = elan_disable_power(data);
}
@@ -1200,7 +1210,7 @@ static int __maybe_unused elan_resume(struct device *dev)
int error;
 
if (device_may_wakeup(dev) && data->irq_wake) {
-   disable_irq_wake(client->irq);
+   disable_irq_wake(data->irq);
data->irq_wake = false;
}
 
@@ -1215,7 +1225,7 @@ static int __maybe_unused elan_resume(struct device *dev)
dev_err(dev, "initialize when resuming failed: %d\n", error);
 
 err:
-   enable_irq(data->client->irq);
+   enable_irq(data->irq);
return error;
 }
 
-- 
2.7.4

--
To unsubscribe

[PATCH v4 0/8] i2c: Host Notify / i801 fixes

2016-10-10 Thread Benjamin Tissoires 
Hi Wolfram, Dmitry,

this is a respin of the series "i2c: Host Notify / i801 fixes".
The changes have been driven by Dmitry who made me realise that using
.alert() was not good, while using an irqchip was a much better choice.

I have dropped in the series the fixes for i2c-smbus given that the code
gets removed. This new code is IMO simpler and provide a better interface
for everybody (adapter and clients), see patch 8/8.

Dmitry, the changes in the Elan driver are simple enough, and I wonder if
they could not go through Wolfram's tree. I have other pending patches for
elan_i2c (trackstick and binding from PS/2) so maybe this might not be the
best solution to have the I2C tree taking the changes.
Also, if this gets merged, that would mean for RMI4, only the HID backend
will not be using IRQ, but we could do the same IRQ reporting than here.

Cheers,
Benjamin

Benjamin Tissoires (8):
  i2c: i801: store and restore the SLVCMD register at load and unload
  i2c: i801: minor formatting issues
  i2c: i801: use BIT() macro for bits definition
  i2c: i801: use the BIT() macro for FEATURES_* also
  i2c: i801: remove SMBNTFDDAT reads as they always seem to return 0
  i2c: use an IRQ to report Host Notify events, not alert
  Input: elan_i2c - store the irq in struct elan_tp_data
  Input: elan_i2c - add Host Notify support

 Documentation/i2c/smbus-protocol|  10 +--
 drivers/i2c/busses/i2c-i801.c   | 120 ++--
 drivers/i2c/i2c-core.c  | 117 +++
 drivers/i2c/i2c-smbus.c | 102 --
 drivers/input/mouse/elan_i2c_core.c |  49 +++
 include/linux/i2c-smbus.h   |  27 
 include/linux/i2c.h |   5 ++
 7 files changed, 224 insertions(+), 206 deletions(-)

-- 
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 v3 0/1] man/set_mempolicy.2,mbind.2: add MPOL_LOCAL NUMA memory policy documentation

2016-10-10 Thread Piotr Kwapulinski 
The MPOL_LOCAL mode has been implemented by
Peter Zijlstra 
(commit: 479e2802d09f1e18a97262c4c6f8f17ae5884bd8).
Add the documentation for this mode.

Signed-off-by: Piotr Kwapulinski 
---
This version fixes grammar
---
 man2/mbind.2 | 28 
 man2/set_mempolicy.2 | 19 ++-
 2 files changed, 42 insertions(+), 5 deletions(-)

diff --git a/man2/mbind.2 b/man2/mbind.2
index 3ea24f6..854580c 100644
--- a/man2/mbind.2
+++ b/man2/mbind.2
@@ -130,8 +130,9 @@ argument must specify one of
 .BR MPOL_DEFAULT ,
 .BR MPOL_BIND ,
 .BR MPOL_INTERLEAVE ,
+.BR MPOL_PREFERRED ,
 or
-.BR MPOL_PREFERRED .
+.BR MPOL_LOCAL .
 All policy modes except
 .B MPOL_DEFAULT
 require the caller to specify via the
@@ -258,9 +259,26 @@ and
 .I maxnode
 arguments specify the empty set, then the memory is allocated on
 the node of the CPU that triggered the allocation.
-This is the only way to specify "local allocation" for a
-range of memory via
-.BR mbind ().
+
+.B MPOL_LOCAL
+specifies the "local allocation", the memory is allocated on
+the node of the CPU that triggered the allocation, "local node".
+The
+.I nodemask
+and
+.I maxnode
+arguments must specify the empty set. If the "local node" is low
+on free memory the kernel will try to allocate memory from other
+nodes. The kernel will allocate memory from the "local node"
+whenever memory for this node is available. If the "local node"
+is not allowed by the process's current cpuset context the kernel
+will try to allocate memory from other nodes. The kernel will
+allocate memory from the "local node" whenever it becomes allowed
+by the process's current cpuset context. In contrast
+.B MPOL_DEFAULT
+reverts to the policy of the process which may have been set with
+.BR set_mempolicy (2).
+It may not be the "local allocation".
 
 If
 .B MPOL_MF_STRICT
@@ -440,6 +458,8 @@ To select explicit "local allocation" for a memory range,
 specify a
 .I mode
 of
+.B MPOL_LOCAL
+or
 .B MPOL_PREFERRED
 with an empty set of nodes.
 This method will work for
diff --git a/man2/set_mempolicy.2 b/man2/set_mempolicy.2
index 1f02037..22b0f7c 100644
--- a/man2/set_mempolicy.2
+++ b/man2/set_mempolicy.2
@@ -79,8 +79,9 @@ argument must specify one of
 .BR MPOL_DEFAULT ,
 .BR MPOL_BIND ,
 .BR MPOL_INTERLEAVE ,
+.BR MPOL_PREFERRED ,
 or
-.BR MPOL_PREFERRED .
+.BR MPOL_LOCAL .
 All modes except
 .B MPOL_DEFAULT
 require the caller to specify via the
@@ -211,6 +212,22 @@ arguments specify the empty set, then the policy
 specifies "local allocation"
 (like the system default policy discussed above).
 
+.B MPOL_LOCAL
+specifies the "local allocation", the memory is allocated on
+the node of the CPU that triggered the allocation, "local node".
+The
+.I nodemask
+and
+.I maxnode
+arguments must specify the empty set. If the "local node" is low
+on free memory the kernel will try to allocate memory from other
+nodes. The kernel will allocate memory from the "local node"
+whenever memory for this node is available. If the "local node"
+is not allowed by the process's current cpuset context the kernel
+will try to allocate memory from other nodes. The kernel will
+allocate memory from the "local node" whenever it becomes allowed
+by the process's current cpuset context.
+
 The thread memory policy is preserved across an
 .BR execve (2),
 and is inherited by child threads created using
-- 
2.10.0

--
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] leds: trigger: Introduce an USB port trigger

2016-10-10 Thread Pavel Machek 
On Wed 2016-08-31 14:23:13, Alan Stern wrote:
> On Tue, 30 Aug 2016, Rafał Miłecki wrote:
> 
> > >> As you quite often need more complex LED management, there are
> > >> triggers that were introduced in 2006 by c3bc9956ec52f ("[PATCH] LED:
> > >> add LED trigger tupport"). Some triggers are trivial and could be
> > >> implemented in userspace as well (e.g. "timer"). Some had to be
> > >> implemented in kernelspace (CPU activity, MTD activity, etc.). Having
> > >> few triggers compiled, you can assign them to LEDs at it pleases you.
> > >> Your hardware may have generic LED (not labeled) and you can
> > >> dynamically assign various triggers to it, depending e.g. on user
> > >> actions. E.g. if user (using GUI or whatever) wants to see flash
> > >> activity, your userspace script should do:
> > >> echo mtd > /sys/class/leds/foo/trigger
> > >
> > > So for example, you might want to do:
> > >
> > > echo usb1-4 >/sys/class/leds/foo/trigger
> > >
> > > and then have the "foo" LED toggle whenever an URB was submitted or
> > > completed for a device attached to the 1-4 port.  Right?
> > 
> > Not really as it won't cover some pretty common use cases. Many home
> > routers have few USB ports (2-5) and only 1 USB LED. It has to be
> > possible to assign few USB ports to a single LED (trigger). That way
> > LED should be turned on (and kept on) if there is at least 1 USB
> > device connected. You obviously can't do:
> > echo "usb1-1 usb1-2 usb2-1" > /sys/class/leds/foo/trigger
> > 
> > This was already brought up by Rob (who mentioned CPU trigger) and I
> > replied him pretty much the same way in:
> > https://lkml.org/lkml/2016/7/29/38
> > (reply starts with "Anyway, the serious limitation I see").
> 
> The code for a bunch of triggers must already be written.  What would 
> the user do if he wanted to flash a single LED in response to both
> CPU activity and MTD activity?  If not
> 
>   echo "cpu mtd" >/sys/class/leds/foo/trigger

Lets not overcomplicate this... What if user wanted to blink only when
there's both cpu and mtd activity?

I mean, there are way too many possible combinations, but we should
not implement everything. "Heartbeat" for example is nice demo and
nice test case, but ...

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH V4] leds: trigger: Introduce an USB port trigger

2016-10-10 Thread Pavel Machek 
Hi!

> This commit adds a new trigger responsible for turning on LED when USB
> device gets connected to the specified USB port. This can can useful for
> various home routers that have USB port(s) and a proper LED telling user
> a device is connected.
> 
> The trigger gets its documentation file but basically it just requires
> specifying USB port in a Linux format (e.g. echo 1-1 > new_port).
> 
> During work on this trigger there was a plan to add DT bindings for it,
> but there wasn't an agreement on the format yet. This can be worked on
> later, a sysfs interface is needed anyway for platforms not using DT.
> 
> Another planned feature is support for LED reacting to the USB activity.
> This can be implemented with another sysfs file for setting mode. The
> default mode wouldn't change so there won't be ABI breakage and such
> feature can be safely implemented later.

Actually... USB device plugs/unplugs are pretty rare events... Can we
just do this in userspace using udevd?

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v11 2/4] drm: Add API for capturing frame CRCs

2016-10-10 Thread Emil Velikov 
On 6 October 2016 at 16:21, Tomeu Vizoso  wrote:
> Adds files and directories to debugfs for controlling and reading frame
> CRCs, per CRTC:
>
> dri/0/crtc-0/crc
> dri/0/crtc-0/crc/control
> dri/0/crtc-0/crc/data
>
> Drivers can implement the set_crc_source callback() in drm_crtc_funcs to
> start and stop generating frame CRCs and can add entries to the output
> by calling drm_crtc_add_crc_entry.
>
> v2:
> - Lots of good fixes suggested by Thierry.
> - Added documentation.
> - Changed the debugfs layout.
> - Moved to allocate the entries circular queue once when frame
>   generation gets enabled for the first time.
> v3:
> - Use the control file just to select the source, and start and stop
>   capture when the data file is opened and closed, respectively.
> - Make variable the number of CRC values per entry, per source.
> - Allocate entries queue each time we start capturing as now there
>   isn't a fixed number of CRC values per entry.
> - Store the frame counter in the data file as a 8-digit hex number.
> - For sources that cannot provide useful frame numbers, place
>    in the frame field.
>
> v4:
> - Build only if CONFIG_DEBUG_FS is enabled.
> - Use memdup_user_nul.
> - Consolidate calculation of the size of an entry in a helper.
> - Add 0x prefix to hex numbers in the data file.
> - Remove unnecessary snprintf and strlen usage in read callback.
>
> v5:
> - Made the crcs array in drm_crtc_crc_entry fixed-size
> - Lots of other smaller improvements suggested by Emil Velikov
>
> v7:
> - Move definition of drm_debugfs_crtc_crc_add to drm_internal.h
>
> v8:
> - Call debugfs_remove_recursive when we fail to create the minor
>   device
>
> v9:
> - Register the debugfs directory for a crtc from
>   drm_crtc_register_all()
>
> v10:
> - Don't let debugfs failures interrupt CRTC registration (Emil
>   Velikov)
>
> v11:
> - Remove extra brace that broke compilation. Sorry!
>
> Signed-off-by: Tomeu Vizoso 

Reviewed-by: Emil Velikov 

Emil
--
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: [PATCHv3] hwmon: Add tc654 driver

2016-10-10 Thread Guenter Roeck 

On 10/09/2016 03:12 PM, Chris Packham wrote:

Add support for the tc654 and tc655 fan controllers from Microchip.

http://ww1.microchip.com/downloads/en/DeviceDoc/20001734C.pdf

Signed-off-by: Chris Packham 
---
Changes in v3:
- typofix in documentation
- add missing value to tc654_pwm_map, re-generate based on datasheet.
- remove unnecessary hwmon_dev member from struct tc654_data
- bug fixes in set_fan_min() and show_pwm_mode()
- miscellaneous style fixes

Changes in v2:
- Add Documentation/hwmon/tc654
- Incorporate most of the review comments from Guenter. Additional error
  handling is added. Unused/unnecessary code is removed. I decided not
  to go down the regmap path yet. I may circle back to it when I look at
  using regmap in the adm9240 driver.

 .../devicetree/bindings/i2c/trivial-devices.txt|   2 +
 Documentation/hwmon/tc654  |  31 ++
 drivers/hwmon/Kconfig  |  11 +
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/tc654.c  | 509 +
 5 files changed, 554 insertions(+)
 create mode 100644 Documentation/hwmon/tc654
 create mode 100644 drivers/hwmon/tc654.c

diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt 
b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index 1416c6a0d2cd..833fb9f133d3 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -122,6 +122,8 @@ microchip,mcp4662-502   Microchip 8-bit Dual I2C 
Digital Potentiometer with NV Mem
 microchip,mcp4662-103  Microchip 8-bit Dual I2C Digital Potentiometer with NV 
Memory (10k)
 microchip,mcp4662-503  Microchip 8-bit Dual I2C Digital Potentiometer with NV 
Memory (50k)
 microchip,mcp4662-104  Microchip 8-bit Dual I2C Digital Potentiometer with NV 
Memory (100k)
+microchip,tc654PWM Fan Speed Controller With Fan Fault 
Detection
+microchip,tc655PWM Fan Speed Controller With Fan Fault 
Detection
 national,lm63  Temperature sensor with integrated fan control
 national,lm75  I2C TEMP SENSOR
 national,lm80  Serial Interface ACPI-Compatible Microprocessor System 
Hardware Monitor
diff --git a/Documentation/hwmon/tc654 b/Documentation/hwmon/tc654
new file mode 100644
index ..91a2843f5f98
--- /dev/null
+++ b/Documentation/hwmon/tc654
@@ -0,0 +1,31 @@
+Kernel driver tc654
+===
+
+Supported chips:
+  * Microship TC654 and TC655
+Prefix: 'tc654'
+Datasheet: http://ww1.microchip.com/downloads/en/DeviceDoc/20001734C.pdf
+
+Authors:
+Chris Packham 
+Masahiko Iwamoto 
+
+Description
+---
+This driver implements support for the Microchip TC654 and TC655.
+
+The TC654 uses the 2-wire interface compatible with the SMBUS 2.0
+specification. The TC654 has two (2) inputs for measuring fan RPM and
+one (1) PWM output which can be used for fan control.
+
+Configuration Notes
+---
+Ordinarily the pwm1_mode ABI is used for controlling the pwm output
+mode.  However, for this chip the output is always pwm, and the
+pwm1_mode determines if the pwm output is controlled via the pwm1 value
+or via the Vin analog input.
+
+
+Setting pwm1_mode to 1 will cause the pwm output to be driven based on
+the pwm1 value. Setting pwm1_mode to 0 will cause the pwm output to be
+driven based on the Vin input.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 45cef3d2c75c..8681bc65cde5 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -907,6 +907,17 @@ config SENSORS_MCP3021
  This driver can also be built as a module.  If so, the module
  will be called mcp3021.

+config SENSORS_TC654
+   tristate "Microchip TC654/TC655 and compatibles"
+   depends on I2C
+   help
+ If you say yes here you get support for TC654 and TC655.
+ The TC654 and TC655 are PWM mode fan speed controllers with
+ FanSense technology for use with brushless DC fans.
+
+ This driver can also be built as a module.  If so, the module
+ will be called tc654.
+
 config SENSORS_MENF21BMC_HWMON
tristate "MEN 14F021P00 BMC Hardware Monitoring"
depends on MFD_MENF21BMC
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index aecf4ba17460..c651f0f1d047 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -122,6 +122,7 @@ obj-$(CONFIG_SENSORS_MAX6697)   += max6697.o
 obj-$(CONFIG_SENSORS_MAX31790) += max31790.o
 obj-$(CONFIG_SENSORS_MC13783_ADC)+= mc13783-adc.o
 obj-$(CONFIG_SENSORS_MCP3021)  += mcp3021.o
+obj-$(CONFIG_SENSORS_TC654)+= tc654.o
 obj-$(CONFIG_SENSORS_MENF21BMC_HWMON) += menf21bmc_hwmon.o
 obj-$(CONFIG_SENSORS_NCT6683)  += nct6683.o
 obj-$(CONFIG_SENSORS_NCT6775)  += nct6775.o
diff --git

Re: [PATCH v11 2/4] drm: Add API for capturing frame CRCs

2016-10-10 Thread Tomeu Vizoso 
Adding Benjamin Gaignard to CC in case he wants to comment on the
usage of the registration functions, as suggested by Daniel Vetter.

Regards,

Tomeu

On 6 October 2016 at 17:21, Tomeu Vizoso  wrote:
> Adds files and directories to debugfs for controlling and reading frame
> CRCs, per CRTC:
>
> dri/0/crtc-0/crc
> dri/0/crtc-0/crc/control
> dri/0/crtc-0/crc/data
>
> Drivers can implement the set_crc_source callback() in drm_crtc_funcs to
> start and stop generating frame CRCs and can add entries to the output
> by calling drm_crtc_add_crc_entry.
>
> v2:
> - Lots of good fixes suggested by Thierry.
> - Added documentation.
> - Changed the debugfs layout.
> - Moved to allocate the entries circular queue once when frame
>   generation gets enabled for the first time.
> v3:
> - Use the control file just to select the source, and start and stop
>   capture when the data file is opened and closed, respectively.
> - Make variable the number of CRC values per entry, per source.
> - Allocate entries queue each time we start capturing as now there
>   isn't a fixed number of CRC values per entry.
> - Store the frame counter in the data file as a 8-digit hex number.
> - For sources that cannot provide useful frame numbers, place
>    in the frame field.
>
> v4:
> - Build only if CONFIG_DEBUG_FS is enabled.
> - Use memdup_user_nul.
> - Consolidate calculation of the size of an entry in a helper.
> - Add 0x prefix to hex numbers in the data file.
> - Remove unnecessary snprintf and strlen usage in read callback.
>
> v5:
> - Made the crcs array in drm_crtc_crc_entry fixed-size
> - Lots of other smaller improvements suggested by Emil Velikov
>
> v7:
> - Move definition of drm_debugfs_crtc_crc_add to drm_internal.h
>
> v8:
> - Call debugfs_remove_recursive when we fail to create the minor
>   device
>
> v9:
> - Register the debugfs directory for a crtc from
>   drm_crtc_register_all()
>
> v10:
> - Don't let debugfs failures interrupt CRTC registration (Emil
>   Velikov)
>
> v11:
> - Remove extra brace that broke compilation. Sorry!
>
> Signed-off-by: Tomeu Vizoso 
> ---
>
>  Documentation/gpu/drm-uapi.rst|   6 +
>  drivers/gpu/drm/Makefile  |   3 +-
>  drivers/gpu/drm/drm_crtc.c|  34 +++-
>  drivers/gpu/drm/drm_debugfs.c |  34 +++-
>  drivers/gpu/drm/drm_debugfs_crc.c | 351 
> ++
>  drivers/gpu/drm/drm_internal.h|  16 ++
>  include/drm/drm_crtc.h|  41 +
>  include/drm/drm_debugfs_crc.h |  73 
>  8 files changed, 555 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/gpu/drm/drm_debugfs_crc.c
>  create mode 100644 include/drm/drm_debugfs_crc.h
>
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 1ba301cebe16..de3ac9f90f8f 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -216,3 +216,9 @@ interfaces. Especially since all hardware-acceleration 
> interfaces to
>  userspace are driver specific for efficiency and other reasons these
>  interfaces can be rather substantial. Hence every driver has its own
>  chapter.
> +
> +Testing and validation
> +==
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c
> +   :doc: CRC ABI
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 25c720454017..74579d2e796e 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -9,7 +9,7 @@ drm-y   :=  drm_auth.o drm_bufs.o drm_cache.o \
> drm_scatter.o drm_pci.o \
> drm_platform.o drm_sysfs.o drm_hashtab.o drm_mm.o \
> drm_crtc.o drm_fourcc.o drm_modes.o drm_edid.o \
> -   drm_info.o drm_debugfs.o drm_encoder_slave.o \
> +   drm_info.o drm_encoder_slave.o \
> drm_trace_points.o drm_global.o drm_prime.o \
> drm_rect.o drm_vma_manager.o drm_flip_work.o \
> drm_modeset_lock.o drm_atomic.o drm_bridge.o \
> @@ -23,6 +23,7 @@ drm-$(CONFIG_PCI) += ati_pcigart.o
>  drm-$(CONFIG_DRM_PANEL) += drm_panel.o
>  drm-$(CONFIG_OF) += drm_of.o
>  drm-$(CONFIG_AGP) += drm_agpsupport.o
> +drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
>
>  drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
> drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 2d7bedf28647..60403bf7a4ff 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -40,7 +40,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>
>  #include "drm_crtc_internal.h"
>  #include "drm_internal.h"
> @@ -122,6 +122,10 @@ static int drm_crtc_register_all(struct drm_device *dev)
> int ret = 0;

Re: [RFC PATCH-tip v4 02/10] locking/rwsem: Stop active read lock ASAP

2016-10-10 Thread Christoph Hellwig 
On Mon, Oct 10, 2016 at 05:07:45PM +1100, Dave Chinner wrote:
> > > *However*, the DAX IO path locking in XFS  has changed in 4.9-rc1 to
> > > match the buffered IO single writer POSIX semantics - the test is a
> > > bad test based on the fact it exercised a path that is under heavy
> > > development and so can't be used as a regression test across
> > > multiple kernels.
> > 
> > That being said - I wonder if we should allow the shared lock on DAX
> > files IFF the user is specifying O_DIRECT in the open mode..
> 
> It should do - if it doesn't then we screwed up the IO path
> selection logic in XFS and we'll need to fix it.

Depends on your defintion of "we".  The DAX code has always abused the
direct I/O path, and that abuse is ingrained in the VFS path in a way that
we can't easily undo it in XFS, e.g. take a look at io_is_direct and
iocb_flags in include/linux/fs.h, which ensure that DAX I/O will always
appear as IOCB_DIRECT to the fs.  It will take some time to untagle
this, but it's on my todo list once the last file system (ext4)
untangles the DAX and direct I/O path.
--
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] regulator/overview.txt: Use ".." for ranges, instead of "->"

2016-10-10 Thread Linus Walleij 
On Mon, Oct 3, 2016 at 10:45 AM, Pavel Machek  wrote:

> Using "->" to indicate range is not too common, switch to ".."
>
> Signed-off-by: Pavel Machek 

You sent this patch to me... resend it to the regulator maintainer.

Yours,
Linus Walleij
--
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] gpio/board.txt: point to gpiod_set_value

2016-10-10 Thread Linus Walleij 
On Mon, Oct 3, 2016 at 10:43 AM, Pavel Machek  wrote:

> gpiod_set_value() is preffered interface these days, so add a
> pointer. Also fix a missing ).
>
> Signed-off-by: Pavel Machek 

Patch applied with some tweaking.

Yours,
Linus Walleij
--
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: [RFC PATCH-tip v4 02/10] locking/rwsem: Stop active read lock ASAP

2016-10-10 Thread Dave Chinner 
On Sun, Oct 09, 2016 at 08:17:48AM -0700, Christoph Hellwig wrote:
> On Fri, Oct 07, 2016 at 08:47:51AM +1100, Dave Chinner wrote:
> > Except that it's DAX, and in 4.7-rc1 that used shared locking at the
> > XFS level and never took exclusive locks.
> > 
> > *However*, the DAX IO path locking in XFS  has changed in 4.9-rc1 to
> > match the buffered IO single writer POSIX semantics - the test is a
> > bad test based on the fact it exercised a path that is under heavy
> > development and so can't be used as a regression test across
> > multiple kernels.
> 
> That being said - I wonder if we should allow the shared lock on DAX
> files IFF the user is specifying O_DIRECT in the open mode..

It should do - if it doesn't then we screwed up the IO path
selection logic in XFS and we'll need to fix it.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com
--
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