[PATCH 3/3] slimbus: Add messaging APIs to slimbus framework

[Sagar Dharia]

Slimbus devices use value-element, and information elements to
control device parameters (e.g. value element is used to represent
gain for codec, information element is used to represent interrupt
status for codec when codec interrupt fires).
Messaging APIs are used to set/get these value and information
elements. Slimbus specification uses 8-bit "transaction IDs" for
messages where a read-value is anticipated. Framework uses a table
of pointers to store those TIDs and responds back to the caller in
O(1).
Caller can opt to do synchronous, or asynchronous reads/writes. For
asynchronous operations, the callback can be called from atomic
context.

Signed-off-by: Sagar Dharia 
Tested-by: Naveen Kaje 
---
 drivers/slimbus/slimbus.c | 273 ++
 include/linux/slimbus.h   | 124 +
 2 files changed, 397 insertions(+)

diff --git a/drivers/slimbus/slimbus.c b/drivers/slimbus/slimbus.c
index f51b503..44614e1 100644
--- a/drivers/slimbus/slimbus.c
+++ b/drivers/slimbus/slimbus.c
@@ -26,6 +26,14 @@ static DEFINE_IDR(ctrl_idr);
 static struct device_type slim_dev_type;
 static struct device_type slim_ctrl_type;
 
+#define DEFINE_SLIM_LDEST_TXN(name, mc, rl, la, msg) \
+   struct slim_msg_txn name = { rl, 0, mc, SLIM_MSG_DEST_LOGICALADDR, 0,\
+   0, la, msg, }
+
+#define DEFINE_SLIM_BCAST_TXN(name, mc, rl, la, msg) \
+   struct slim_msg_txn name = { rl, 0, mc, SLIM_MSG_DEST_BROADCAST, 0,\
+   0, la, msg, }
+
 static int slim_compare_eaddr(struct slim_eaddr *a, struct slim_eaddr *b)
 {
if (a->manf_id == b->manf_id && a->prod_code == b->prod_code &&
@@ -762,6 +770,271 @@ int slim_get_logical_addr(struct slim_device *sb, struct 
slim_eaddr *e_addr,
 }
 EXPORT_SYMBOL(slim_get_logical_addr);
 
+/*
+ * slim_msg_response: Deliver Message response received from a device to the
+ * framework.
+ * @ctrl: Controller handle
+ * @reply: Reply received from the device
+ * @len: Length of the reply
+ * @tid: Transaction ID received with which framework can associate reply.
+ * Called by controller to inform framework about the response received.
+ * This helps in making the API asynchronous, and controller-driver doesn't 
need
+ * to manage 1 more table other than the one managed by framework mapping TID
+ * with buffers
+ */
+void slim_msg_response(struct slim_controller *ctrl, u8 *reply, u8 tid, u8 len)
+{
+   struct slim_val_inf *msg;
+
+   spin_lock(>txn_lock);
+   msg = ctrl->txnt[tid];
+   if (msg == NULL || msg->rbuf == NULL) {
+   spin_unlock(>txn_lock);
+   dev_err(>dev, "Got response to invalid TID:%d, len:%d",
+   tid, len);
+   return;
+   }
+   memcpy(msg->rbuf, reply, len);
+   ctrl->txnt[tid] = NULL;
+   if (msg->comp_cb)
+   msg->comp_cb(msg->ctx);
+   spin_unlock(>txn_lock);
+}
+EXPORT_SYMBOL(slim_msg_response);
+
+static int slim_processtxn(struct slim_controller *ctrl,
+   struct slim_msg_txn *txn)
+{
+   int i = 0, ret = 0;
+   unsigned long flags;
+
+   if (txn->mt == SLIM_MSG_MT_CORE &&
+   (txn->mc == SLIM_MSG_MC_REQUEST_INFORMATION ||
+txn->mc == SLIM_MSG_MC_REQUEST_CLEAR_INFORMATION ||
+txn->mc == SLIM_MSG_MC_REQUEST_VALUE ||
+txn->mc == SLIM_MSG_MC_REQUEST_CLEAR_INFORMATION)) {
+   spin_lock_irqsave(>txn_lock, flags);
+   for (i = 0; i < ctrl->last_tid; i++) {
+   if (ctrl->txnt[i] == NULL)
+   break;
+   }
+   if (i >= ctrl->last_tid) {
+   if (ctrl->last_tid == 255) {
+   spin_unlock_irqrestore(>txn_lock, flags);
+   return -ENOMEM;
+   }
+   ctrl->last_tid++;
+   }
+   ctrl->txnt[i] = txn->msg;
+   txn->tid = i;
+   spin_unlock_irqrestore(>txn_lock, flags);
+   }
+
+   ret = ctrl->xfer_msg(ctrl, txn);
+   return ret;
+}
+
+static int slim_val_inf_sanity(struct slim_val_inf *msg, int oper)
+{
+   if (!msg || msg->num_bytes > 16 ||
+   (msg->start_offset + msg->num_bytes) > 0xC00)
+   return -EINVAL;
+   switch (oper) {
+   case SLIM_MSG_MC_REQUEST_VALUE:
+   case SLIM_MSG_MC_REQUEST_INFORMATION:
+   if (msg->rbuf == NULL)
+   return -EINVAL;
+   return 0;
+   case SLIM_MSG_MC_CHANGE_VALUE:
+   case SLIM_MSG_MC_CLEAR_INFORMATION:
+   if (msg->wbuf == NULL)
+   return -EINVAL;
+   return 0;
+   case SLIM_MSG_MC_REQUEST_CHANGE_VALUE:
+   case SLIM_MSG_MC_REQUEST_CLEAR_INFORMATION:
+   if (msg->rbuf == NULL || msg->wbuf == NULL)
+

[PATCH 2/3] of/slimbus: OF helper for SLIMbus

[Sagar Dharia]

OF helper routine scans the SLIMbus DeviceTree, allocates resources,
and creates slim_devices according to the hierarchy.

Signed-off-by: Sagar Dharia 
---
 drivers/slimbus/slimbus.c | 77 +++
 include/linux/slimbus.h   | 19 
 2 files changed, 96 insertions(+)

diff --git a/drivers/slimbus/slimbus.c b/drivers/slimbus/slimbus.c
index be4f2c7..f51b503 100644
--- a/drivers/slimbus/slimbus.c
+++ b/drivers/slimbus/slimbus.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static DEFINE_MUTEX(slim_lock);
 static DEFINE_IDR(ctrl_idr);
@@ -761,6 +762,82 @@ int slim_get_logical_addr(struct slim_device *sb, struct 
slim_eaddr *e_addr,
 }
 EXPORT_SYMBOL(slim_get_logical_addr);
 
+#if IS_ENABLED(CONFIG_OF)
+/* OF helpers for SLIMbus */
+int of_register_slim_devices(struct slim_controller *ctrl)
+{
+   struct device_node *node;
+   struct slim_boardinfo *temp, *binfo = NULL;
+   int n = 0;
+   int ret = 0;
+
+   if (!ctrl->dev.of_node)
+   return -EINVAL;
+
+   for_each_child_of_node(ctrl->dev.of_node, node) {
+   struct property *prop;
+   u8 *ea;
+   struct slim_device *slim;
+   char *name;
+
+   prop = of_find_property(node, "enumeration-addr", NULL);
+   if (!prop || prop->length != 6) {
+   dev_err(>dev, "of_slim: invalid E-addr");
+   continue;
+   }
+   ea = (u8 *)prop->value;
+   name = kcalloc(SLIMBUS_NAME_SIZE, sizeof(char), GFP_KERNEL);
+   if (!name) {
+   ret = -ENOMEM;
+   goto of_slim_err;
+   }
+   ret = of_modalias_node(node, name, SLIMBUS_NAME_SIZE);
+   if (ret < 0) {
+   dev_err(>dev, "of_slim: modalias fail:%d on %s\n",
+   ret, node->full_name);
+   kfree(name);
+   continue;
+   }
+   slim = kcalloc(1, sizeof(struct slim_device), GFP_KERNEL);
+   if (!slim) {
+   ret = -ENOMEM;
+   kfree(name);
+   goto of_slim_err;
+   }
+   slim->e_addr.manf_id = (u16)(ea[5] << 8) | ea[4];
+   slim->e_addr.prod_code = (u16)(ea[3] << 8) | ea[2];
+   slim->e_addr.dev_index = ea[1];
+   slim->e_addr.instance = ea[0];
+
+
+   temp = krealloc(binfo, (n + 1) * sizeof(struct slim_boardinfo),
+   GFP_KERNEL);
+   if (!temp) {
+   kfree(name);
+   kfree(slim);
+   goto of_slim_err;
+   }
+   binfo = temp;
+   slim->dev.of_node = of_node_get(node);
+   slim->name = name;
+   binfo[n].bus_num = ctrl->nr;
+   binfo[n].slim_slave = slim;
+   n++;
+   }
+   return slim_register_board_info(binfo, n);
+
+of_slim_err:
+   n--;
+   while (n >= 0) {
+   kfree(binfo[n].slim_slave->name);
+   kfree(binfo[n].slim_slave);
+   }
+   kfree(binfo);
+   return ret;
+}
+EXPORT_SYMBOL(of_register_slim_devices);
+#endif
+
 MODULE_LICENSE("GPL v2");
 MODULE_VERSION("0.1");
 MODULE_DESCRIPTION("Slimbus module");
diff --git a/include/linux/slimbus.h b/include/linux/slimbus.h
index 05b7594..61b7c74 100644
--- a/include/linux/slimbus.h
+++ b/include/linux/slimbus.h
@@ -370,6 +370,25 @@ static inline int slim_register_board_info(struct 
slim_boardinfo const *info,
 }
 #endif
 
+#if IS_ENABLED(CONFIG_OF)
+/*
+ * of_slim_register_devices() - Register devices in the SLIMbus Device Tree
+ * @ctrl: slim_controller which devices should be registered to.
+ *
+ * This routine scans the SLIMbus Device Tree, allocating resources and
+ * creating slim_devices according to the SLIMbus Device Tree
+ * hierarchy.
+ * This routine is normally called from the probe routine of the driver
+ * registering as a slim_controller.
+ */
+extern int of_register_slim_devices(struct slim_controller *ctrl);
+#else
+static int of_register_slim_devices(struct slim_controller *ctrl)
+{
+   return 0;
+}
+#endif
+
 static inline void *slim_get_ctrldata(const struct slim_controller *dev)
 {
return dev_get_drvdata(>dev);
-- 
1.8.2.1

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

[PATCH 0/3] Introduce framework for SLIMbus device drivers

[Sagar Dharia]

SLIMbus (Serial Low Power Interchip Media Bus) is a specification
developed by MIPI (Mobile Industry Processor Interface) alliance.
SLIMbus is a 2-wire implementation, which is used to communicate with
peripheral components like audio-codec.
SLIMbus uses Time-Division-Multiplexing to accommodate multiple data
channels, and control channel. Control channel has messages to do
device-enumeration, messages to send/receive control-data to/from
slimbus devices, messages for port/channel management, and messages to
do bandwidth allocation.
Framework is introduced to support  multiple instances of the bus
(1 controller per bus), and multiple slave devices per controller.
SPI and I2C frameworks, and comments from last time when I submitted
the patches were referred-to while working on this framework.

These patchsets introduce device-management, OF helpers, and messaging
APIs for SLIMbus. Framework patches to do channel, port and bandwidth
management are work-in-progress and will be sent out soon.

These patchsets were tested on Qualcomm Snapdragon processor board
using a controller driver, and a slimbus-dev module. This driver and
module will be sent out after the framework patches mentioned above.

Sagar Dharia (3):
  SLIMbus: Device management on SLIMbus
  of/slimbus: OF helper for SLIMbus
  slimbus: Add messaging APIs to slimbus framework

 drivers/Kconfig |2 +
 drivers/Makefile|1 +
 drivers/slimbus/Kconfig |9 +
 drivers/slimbus/Makefile|4 +
 drivers/slimbus/slimbus.c   | 1117 +++
 include/linux/mod_devicetable.h |   13 +
 include/linux/slimbus.h |  536 +++
 7 files changed, 1682 insertions(+)
 create mode 100644 drivers/slimbus/Kconfig
 create mode 100644 drivers/slimbus/Makefile
 create mode 100644 drivers/slimbus/slimbus.c
 create mode 100644 include/linux/slimbus.h

-- 
1.8.2.1

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

[PATCH 1/3] SLIMbus: Device management on SLIMbus

[Sagar Dharia]

SLIMbus (Serial Low Power Interchip Media Bus) is a specification
developed by MIPI (Mobile Industry Processor Interface) alliance.
SLIMbus is a 2-wire implementation, which is used to communicate with
peripheral components like audio-codec.
SLIMbus uses Time-Division-Multiplexing to accommodate multiple data
channels, and control channel. Control channel has messages to do
device-enumeration, messages to send/receive control-data to/from
slimbus devices, messages for port/channel management, and messages to
do bandwidth allocation.
The framework supports multiple instances of the bus (1 controller per
bus), and multiple slave devices per controller.

This patch does device enumeration, logical address assignment,
informing device when the device reports present/absent etc.
Reporting present may need the driver to do the needful (e.g. turning
on voltage regulators powering the device). So probe is called
if the device is added to board-info list for a controller.
Additionally device is probed when it reports present if that device
doesn't need any such steps mentioned above.

Signed-off-by: Sagar Dharia 
---
 drivers/Kconfig |   2 +
 drivers/Makefile|   1 +
 drivers/slimbus/Kconfig |   9 +
 drivers/slimbus/Makefile|   4 +
 drivers/slimbus/slimbus.c   | 767 
 include/linux/mod_devicetable.h |  13 +
 include/linux/slimbus.h | 393 
 7 files changed, 1189 insertions(+)
 create mode 100644 drivers/slimbus/Kconfig
 create mode 100644 drivers/slimbus/Makefile
 create mode 100644 drivers/slimbus/slimbus.c
 create mode 100644 include/linux/slimbus.h

diff --git a/drivers/Kconfig b/drivers/Kconfig
index c0cc96b..e39c969 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -182,4 +182,6 @@ source "drivers/thunderbolt/Kconfig"
 
 source "drivers/android/Kconfig"
 
+source "drivers/slimbus/Kconfig"
+
 endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 46d2554..37c1c88 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -74,6 +74,7 @@ obj-$(CONFIG_TARGET_CORE) += target/
 obj-$(CONFIG_MTD)  += mtd/
 obj-$(CONFIG_SPI)  += spi/
 obj-$(CONFIG_SPMI) += spmi/
+obj-$(CONFIG_SLIMBUS)  += slimbus/
 obj-y  += hsi/
 obj-y  += net/
 obj-$(CONFIG_ATM)  += atm/
diff --git a/drivers/slimbus/Kconfig b/drivers/slimbus/Kconfig
new file mode 100644
index 000..fb30497
--- /dev/null
+++ b/drivers/slimbus/Kconfig
@@ -0,0 +1,9 @@
+#
+# SLIMBUS driver configuration
+#
+menuconfig SLIMBUS
+   tristate "Slimbus support"
+   help
+ Slimbus is standard interface between baseband and audio codec,
+ and other peripheral components in mobile terminals.
+
diff --git a/drivers/slimbus/Makefile b/drivers/slimbus/Makefile
new file mode 100644
index 000..05f53bc
--- /dev/null
+++ b/drivers/slimbus/Makefile
@@ -0,0 +1,4 @@
+#
+# Makefile for kernel slimbus framework.
+#
+obj-$(CONFIG_SLIMBUS)  += slimbus.o
diff --git a/drivers/slimbus/slimbus.c b/drivers/slimbus/slimbus.c
new file mode 100644
index 000..be4f2c7
--- /dev/null
+++ b/drivers/slimbus/slimbus.c
@@ -0,0 +1,767 @@
+/* Copyright (c) 2011-2015, The Linux Foundation. All rights reserved.
+ *
+ * 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 
+
+static DEFINE_MUTEX(slim_lock);
+static DEFINE_IDR(ctrl_idr);
+static struct device_type slim_dev_type;
+static struct device_type slim_ctrl_type;
+
+static int slim_compare_eaddr(struct slim_eaddr *a, struct slim_eaddr *b)
+{
+   if (a->manf_id == b->manf_id && a->prod_code == b->prod_code &&
+   a->dev_index == b->dev_index &&
+   a->instance == b->instance)
+   return 0;
+   return -EIO;
+}
+
+static const struct slim_device_id *slim_match(const struct slim_device_id *id,
+   const struct slim_device *slim_dev)
+{
+   while (id->manf_id != 0 || id->prod_code != 0) {
+   if (id->manf_id == slim_dev->e_addr.manf_id &&
+   id->prod_code == slim_dev->e_addr.prod_code &&
+   id->dev_index == slim_dev->e_addr.dev_index)
+   return id;
+   id++;
+   }
+   return NULL;
+}
+
+static int slim_device_match(struct device *dev, struct device_driver *driver)
+{
+

Re: [PATCH 2/3] vfs, writeback: replace FS_CGROUP_WRITEBACK with MS_CGROUPWB

[Tejun Heo]

Hello, Christoph.

On Sat, Jun 13, 2015 at 09:16:08AM -0700, Christoph Hellwig wrote:
> On Fri, Jun 12, 2015 at 04:57:33PM -0500, Tejun Heo wrote:
> > FS_CGROUP_WRITEBACK indicates whether a file_system_type supports
> > cgroup writeback; however, different super_blocks of the same
> > file_system_type may or may not support cgroup writeback depending on
> > filesystem options.  This patch replaces FS_CGROUP_WRITEBACK with a
> > kernel-internal super_block->s_flags MS_CGROUPWB.  The concatenated
> > and abbreviated name is for consistency with other MS_* flags.
> 
> Nak.  As the uapi part makes it obvious the MS_ namespace is part
> of the userspace ABI.  Please add a new in-kernel flags field instead.

Are MS_ACTIVE and MS_BORN part of userpace ABI?  They seem pretty
internal.  I don't mind introducing a new internal flag field but it's
weird to put this single flag there with other internal flags in
->s_flags.

Assuming we add a new field, how do sb->s_iflags and SB_I_XXX sound?
Any better suggestions?

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1 linux-next] pnfs/flexfiles: use swap() in ff_layout_sort_mirrors()

[Fabian Frederick]

> On 12 June 2015 at 19:17 Joe Perches  wrote:
>
>
> On Fri, 2015-06-12 at 18:58 +0200, Fabian Frederick wrote:
> > Use kernel.h macro definition.
>
> A lot of these conversions seem to be for bubble sorts.
> Maybe it'd be useful to add a generic one somewhere.

Of course but those swap() conversions already do some smooth cleanup.
btw it will be easier to find sort occurences and replace them if necessary.

Regards,
Fabian
>
> > diff --git a/fs/nfs/flexfilelayout/flexfilelayout.c
> > b/fs/nfs/flexfilelayout/flexfilelayout.c
> []
> > @@ -182,17 +182,14 @@ static void _ff_layout_free_lseg(struct
> > nfs4_ff_layout_segment *fls)
> > 
> >  static void ff_layout_sort_mirrors(struct nfs4_ff_layout_segment *fls)
> >  {
> > -   struct nfs4_ff_layout_mirror *tmp;
> >     int i, j;
> > 
> >     for (i = 0; i < fls->mirror_array_cnt - 1; i++) {
> >             for (j = i + 1; j < fls->mirror_array_cnt; j++)
> >                     if (fls->mirror_array[i]->efficiency <
> > -                       fls->mirror_array[j]->efficiency) {
> > -                           tmp = fls->mirror_array[i];
> > -                           fls->mirror_array[i] = fls->mirror_array[j];
> > -                           fls->mirror_array[j] = tmp;
> > -                   }
> > +                       fls->mirror_array[j]->efficiency)
> > +                           swap(fls->mirror_array[i],
> > +                                fls->mirror_array[j]);
> >     }
> >  }
> > 
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v15 4/4] ARM: dts: add RK3288 power-domain node

[Caesar Wang]

This patch add the needed clocks into power-controller.

There are several reasons as follows:

Firstly, the clocks need be turned off to save power when
the system enter the suspend state. So we need to enumerate the clocks
in the dts. In order to power domain can turn on and off.

Secondly, the reset-circuit should reset be synchronous on rk3288,
then sync revoked. So we need to enable clocks of all devices.

Signed-off-by: jinkun.hong 
Signed-off-by: Caesar Wang 

---

Changes in v15:
- As Tomasz remarked previously the dts should represent the hardware
  and the power-domains are part of the pmu.
Series-changes: 12
- Remove essential clocks from rk3288 PD_VIO domain, Some clocks are
  essential for the system health and should not be turned down.
  However there is no owner for them so if they listed as belonging to power
  domain we'll try toggling them up and down during power domain transition.
  As a result we either fail to suspend or resume the system.
Series-changes: 10
- fix missing the #include .
- remove the notes.
Series-changes: 9
- add decription for power-doamin node.
Series-changes: 8
- DTS go back to v2.
Series-changes: 3
- Decomposition power-controller, changed to multiple controller
  (gpu-power-controller, hevc-power-controller).
Series-changes: 2
- make pd_vio clocks all one entry per line and alphabetize.
- power: power-controller move back to pinctrl: pinctrl.

Changes in v9: None

 arch/arm/boot/dts/rk3288.dtsi | 62 +++
 1 file changed, 62 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 165968d..8224070 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -550,6 +550,68 @@
pmu: power-management@ff73 {
compatible = "rockchip,rk3288-pmu", "syscon";
reg = <0xff73 0x100>;
+
+   pmu: power-management@ff73 {
+   compatible = "rockchip,rk3288-pmu", "syscon", "simple-mfd";
+   reg = <0xff73 0x100>;
+
+   power: power-controller {
+   compatible = "rockchip,rk3288-power-controller";
+   #power-domain-cells = <1>;
+   rockchip,pmu = <>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   pd_gpu {
+   reg = ;
+   clocks = < ACLK_GPU>;
+   };
+
+   pd_hevc {
+   reg = ;
+   clocks = < ACLK_HEVC>,
+< SCLK_HEVC_CABAC>,
+< SCLK_HEVC_CORE>,
+< HCLK_HEVC>;
+   };
+
+   pd_vio {
+   reg = ;
+   clocks = < ACLK_IEP>,
+< ACLK_ISP>,
+< ACLK_RGA>,
+< ACLK_VIP>,
+< ACLK_VOP0>,
+< ACLK_VOP1>,
+< DCLK_VOP0>,
+< DCLK_VOP1>,
+< HCLK_IEP>,
+< HCLK_ISP>,
+< HCLK_RGA>,
+< HCLK_VIP>,
+< HCLK_VOP0>,
+< HCLK_VOP1>,
+< PCLK_EDP_CTRL>,
+< PCLK_HDMI_CTRL>,
+< PCLK_LVDS_PHY>,
+< PCLK_MIPI_CSI>,
+< PCLK_MIPI_DSI0>,
+< PCLK_MIPI_DSI1>,
+< SCLK_EDP_24M>,
+< SCLK_EDP>,
+< SCLK_HDMI_CEC>,
+< SCLK_HDMI_HDCP>,
+< SCLK_ISP_JPE>,
+< SCLK_ISP>,
+< SCLK_RGA>;
+   };
+
+   pd_video {
+   reg = ;
+   clocks = < ACLK_VCODEC>,
+< HCLK_VCODEC>;
+   };
+   };
};
 
sgrf: syscon@ff74 {
-- 
1.9.1

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

[PATCH v15 2/4] ARM: power-domain: rockchip: add the support type on RK3288

[Caesar Wang]

At the moment, we can support these power-domain type on RK3288.
We can add more types on RK3288 in the future, that's need to do.

Signed-off-by: Caesar Wang 

---

Changes in v15:
- change the comment.

Changes in v9: None

 include/dt-bindings/power-domain/rk3288.h | 11 +++
 1 file changed, 11 insertions(+)
 create mode 100644 include/dt-bindings/power-domain/rk3288.h

diff --git a/include/dt-bindings/power-domain/rk3288.h 
b/include/dt-bindings/power-domain/rk3288.h
new file mode 100644
index 000..ca68c11
--- /dev/null
+++ b/include/dt-bindings/power-domain/rk3288.h
@@ -0,0 +1,11 @@
+#ifndef __DT_BINDINGS_POWER_DOMAIN_RK3288_H__
+#define __DT_BINDINGS_POWER_DOMAIN_RK3288_H__
+
+/* RK3288 power domain index */
+#define RK3288_PD_GPU  0
+#define RK3288_PD_VIO  1
+#define RK3288_PD_VIDEO2
+#define RK3288_PD_HEVC 3
+#define RK3288_PD_PERI 4
+
+#endif
-- 
1.9.1

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

[PATCH v15 3/4] soc: rockchip: power-domain: add power domain driver

[Caesar Wang]

In order to meet high performance and low power requirements, a power
management unit is designed or saving power when RK3288 in low power
mode.
The RK3288 PMU is dedicated for managing the power ot the whole chip.

Signed-off-by: jinkun.hong 
Signed-off-by: Caesar Wang 

---

Changes in v15:
- As the kevin suggestion, put the power-doamin driver into driver/soc/vendor.
- As Heiko suggestion, Patch 1: binding doc, 2: binding-header, 3: driver,
  4: dts-changes.
- return -ENXIO --> return -ENODEV.
Series-changes: 14
- does not need to set an owner,remove the "THIS_MODULE".
Series-changes: 13
- Remove essential clocks from rk3288 PD_VIO domain Some clocks are essential
  for the system health and should not be turned down. However there is no owner
  for them so if they listed as belonging to power domain we'll try toggling 
them
  up and down during power domain.
- Device drivers expect their devices to be powered on before their
  probing code is invoked. To achieve that we should start with
  power domains powered on (we may turn them off later once all devices enable
  runtime powermanagment and go idle).
- This change switches Rockchip power domain driver to use updated
  device_attach and device_detach API.
- set the gpu/core power domain power delay time.
- fix enumerating PM clocks for devices.
- fix use after free We can't use clk after we did clk_put(clk).
Series-changes: 12
- fix the title doamin->domain.
- updated device_attach and device_detach API,otherwise it will
  compile fail on next kernel.
Series-changes: 11
- fix pm_genpd_init(>genpd, NULL, false).
Series-changes: 10
- this switches over domain infos to use masks instead of recomputing
  them each time and also gets rid of custom domain translator and
  uses standard onecell on.
Series-changes: 9
- fix v8 changes as follows:
- This reconciles the v2 and v7 code so that we power domain have lists of 
clocks
  they trigger on and off during power transitions and independently from power
  domains clocks. We attach clocks to devices comprising power domain and 
prepare
  them so they are turn on and off by runtime PM.
- add rockchip_pm_add_one_domain() to control domains.
- add pd_start/pd_stop interface to control clocks.
Series-changes: 8
- This reconciles the v2 and v7 code so that we power domain have
  lists of clocks they toggle on and off during power transitions
  and independently from power domains clocks we attach clocks to
  devices comprising power domain and prepare them so they are
  turn on and off by runtime PM.
Series-changes: 7
 - Delete unused variables
Series-changes: 6
- delete pmu_lock.
- modify dev_lock using mutex.
- pm_clk_resume(pd->dev) change to pm_clk_resume(ed->dev).
- pm_clk_suspend(pd->dev) change to pm_clk_suspend(ed->dev).
- add devm_kfree(pd->dev, de) in rockchip_pm_domain_detach_dev.
Series-changes: 5
- delete idle_lock.
- add timeout in rockchip_pmu_set_idle_request().
Series-changes: 4
- use list storage dev.
Series-changes: 3
- change use pm_clk_resume() and pm_clk_suspend().
Series-changes: 2
- remove the "pd->pd.of_node = np".

Changes in v9: None

 drivers/soc/Kconfig   |   1 +
 drivers/soc/Makefile  |   1 +
 drivers/soc/rockchip/Kconfig  |  13 +
 drivers/soc/rockchip/Makefile |   4 +
 drivers/soc/rockchip/pm_domains.c | 506 ++
 5 files changed, 525 insertions(+)
 create mode 100644 drivers/soc/rockchip/Kconfig
 create mode 100644 drivers/soc/rockchip/Makefile
 create mode 100644 drivers/soc/rockchip/pm_domains.c

diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index d8bde82..e897c0ca 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -2,6 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
 
 source "drivers/soc/mediatek/Kconfig"
 source "drivers/soc/qcom/Kconfig"
+source "drivers/soc/rockchip/Kconfig"
 source "drivers/soc/ti/Kconfig"
 source "drivers/soc/versatile/Kconfig"
 
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 70042b2..91f7f18 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -4,6 +4,7 @@
 
 obj-$(CONFIG_ARCH_MEDIATEK)+= mediatek/
 obj-$(CONFIG_ARCH_QCOM)+= qcom/
+obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/
 obj-$(CONFIG_ARCH_TEGRA)   += tegra/
 obj-$(CONFIG_SOC_TI)   += ti/
 obj-$(CONFIG_PLAT_VERSATILE)   += versatile/
diff --git a/drivers/soc/rockchip/Kconfig b/drivers/soc/rockchip/Kconfig
new file mode 100644
index 000..5a7af4c
--- /dev/null
+++ b/drivers/soc/rockchip/Kconfig
@@ -0,0 +1,13 @@
+#
+# Rockchip Soc drivers
+#
+config PM_GENERIC_DOMAINS
+tristate "Rockchip generic power domain"
+depends on PM
+help
+  Say y here to enable power doamin support.
+  In order to meet high performance and low power requirements, a power
+  management unit is designed or saving power when RK3288 in low power
+  mode. The RK3288 PMU is dedicated for managing the power ot the 

[PATCH v15 0/4] ARM: rk3288: Add PM Domain support

[Caesar Wang]

Add power domain drivers based on generic power domain for
Rockchip platform, and support RK3288.

Verified on url =
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/v3.14

The following is the easy example.

vopb: vop@ff93 {
compatible = "rockchip,rk3288-vop";
...
iommus = <_mmu>;
power-domains = < RK3288_PD_VIO>;
status = "disabled";
...
};

vopb_mmu: iommu@ff930300 {
compatible = "rockchip,iommu";
...
interrupt-names = "vopb_mmu";
power-domains = < RK3288_PD_VIO>;
#iommu-cells = <0>;
status = "disabled";
...
};

vopl: vop@ff94 {
compatible = "rockchip,rk3288-vop";
reg = <0xff94 0x19c>;
...
iommus = <_mmu>;
power-domains = < RK3288_PD_VIO>;
status = "disabled";
...
};

vopl_mmu: iommu@ff940300 {
compatible = "rockchip,iommu";
...
interrupt-names = "vopl_mmu";
power-domains = < RK3288_PD_VIO>;
#iommu-cells = <0>;
status = "disabled";
};

There is a recent addition from Linus Walleij,
called simple-mfd [a] that is supposed to get added real early for kernel 4.2

[a]:
https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-integrator.git/commit/?h=simple-mfd=fcf294c020ff7ee4e3b1e96159e4dc7a17ad59d1

Here is my branch:

9c402ee ARM: dts: add RK3288 power-domain node
b1469c4 power-domain: rockchip: add power domain driver
ce13318 ARM: power-domain: rockchip: add the support type for the rk3288
9824091 dt-bindings: add document of Rockchip power domain
0ff0e5b MFD/OF: document MFD devices and handle simple-mfd
2bfc60d Merge tag 'misc-for-linus-4.1-rc8' of 
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
...

Note:

Sorry for long no any update.

As I known, there are somethings needed to do.
(1) about all the device clocks being listed in the power-domains itself,
Someone wish was to get the clocks by reading the clocks from the device nodes,

Perhaps, this series patchs are hard to be accepted or need to do more
can be accepted.

At the moment, I send the patch v15 to discuss the issue, This patch no
any sloved the pervious issue.


Changes in v15:
- change the comment.
- As the kevin suggestion, put the power-doamin driver into driver/soc/vendor.
- As Heiko suggestion, Patch 1: binding doc, 2: binding-header, 3: driver,
  4: dts-changes.
- return -ENXIO --> return -ENODEV.
Series-changes: 14
- does not need to set an owner,remove the "THIS_MODULE".
Series-changes: 13
- Remove essential clocks from rk3288 PD_VIO domain Some clocks are essential
  for the system health and should not be turned down. However there is no owner
  for them so if they listed as belonging to power domain we'll try toggling 
them
  up and down during power domain.
- Device drivers expect their devices to be powered on before their
  probing code is invoked. To achieve that we should start with
  power domains powered on (we may turn them off later once all devices enable
  runtime powermanagment and go idle).
- This change switches Rockchip power domain driver to use updated
  device_attach and device_detach API.
- set the gpu/core power domain power delay time.
- fix enumerating PM clocks for devices.
- fix use after free We can't use clk after we did clk_put(clk).
Series-changes: 12
- fix the title doamin->domain.
- updated device_attach and device_detach API,otherwise it will
  compile fail on next kernel.
Series-changes: 11
- fix pm_genpd_init(>genpd, NULL, false).
Series-changes: 10
- this switches over domain infos to use masks instead of recomputing
  them each time and also gets rid of custom domain translator and
  uses standard onecell on.
Series-changes: 9
- fix v8 changes as follows:
- This reconciles the v2 and v7 code so that we power domain have lists of 
clocks
  they trigger on and off during power transitions and independently from power
  domains clocks. We attach clocks to devices comprising power domain and 
prepare
  them so they are turn on and off by runtime PM.
- add rockchip_pm_add_one_domain() to control domains.
- add pd_start/pd_stop interface to control clocks.
Series-changes: 8
- This reconciles the v2 and v7 code so that we power domain have
  lists of clocks they toggle on and off during power transitions
  and independently from power domains clocks we attach clocks to
  devices comprising power domain and prepare them so they are
  turn on and off by runtime PM.
Series-changes: 7
 - Delete unused variables
Series-changes: 6
- delete pmu_lock.
- modify dev_lock using mutex.
- pm_clk_resume(pd->dev) change to pm_clk_resume(ed->dev).
- pm_clk_suspend(pd->dev) change to pm_clk_suspend(ed->dev).
- add devm_kfree(pd->dev, de) in rockchip_pm_domain_detach_dev.
Series-changes: 5
- delete idle_lock.
- add timeout in rockchip_pmu_set_idle_request().
Series-changes: 4
- use list storage dev.
Series-changes: 3
- change use pm_clk_resume() and pm_clk_suspend().
Series-changes: 2
- remove the "pd->pd.of_node = np".
- As Tomasz remarked previously the dts should 

[PATCH v15 1/4] dt-bindings: add document of Rockchip power domain

[Caesar Wang]

This add the necessary binding documentation for the power domain
found on Rockchip Socs.

Signed-off-by: jinkun.hong 
Signed-off-by: Caesar Wang 

---

Changes in v15: None
Changes in v9:
- add document decription.
Series-changes:8
- document go back to v2.
Series-changes:3
- DT structure has changed.
Series-changes:2
- move clocks to "optional".

 .../bindings/soc/rockchip/power_domain.txt | 48 ++
 1 file changed, 48 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/soc/rockchip/power_domain.txt

diff --git a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt 
b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
new file mode 100644
index 000..3e74e6d
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
@@ -0,0 +1,48 @@
+* Rockchip Power Domains
+
+Rockchip processors include support for multiple power domains which can be
+powered up/down by software based on different application scenes to save 
power.
+
+Required properties for power domain controller:
+- compatible: should be one of the following.
+* rockchip,rk3288-power-controller - for rk3288 type power domain.
+- #power-domain-cells: Number of cells in a power-domain specifier.
+  should be 1.
+- rockchip,pmu: phandle referencing a syscon providing the pmu registers
+- #address-cells: should be 1.
+- #size-cells: should be 0.
+
+Required properties for power domain sub nodes:
+- reg: index of the power domain, should use macros in:
+*  include/dt-bindings/power-domain/rk3288.h - for rk3288 type power 
domain.
+- clocks (optional): phandles to clocks which need to be enabled while power 
domain
+  switches state.
+
+Example:
+
+   power: power-controller {
+  compatible = "rockchip,rk3288-power-controller";
+  #power-domain-cells = <1>;
+  rockchip,pmu = <>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+  pd_gpu {
+  reg = ;
+  clocks = < ACLK_GPU>;
+  };
+   };
+
+Node of a device using power domains must have a power-domains property,
+containing a phandle to the power device node and an index specifying which
+power domain to use.
+The index should use macros in:
+   * include/dt-bindings/power-domain/rk3288.h - for rk3288 type power domain.
+
+Example of the node using power domain:
+
+   node {
+   /* ... */
+   power-domains = < RK3288_PD_GPU>;
+   /* ... */
+   };
-- 
1.9.1

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

Payment

[Finance Department]

Dear Winner,

You have been awarded the sum of  8,000,000.00 (Eight Million Pounds sterling) 
with reference number 77100146. This compensation funds from the United 
Nation.Send us your personal details to deliver your funds.

Gloria Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] staging:rtl8723au:rtw_ap:space prohibited between function name & '('

[Joglekar, Tejas (T.)]

From: Joglekar Tejas 

This patch removes the warning "space prohibited between
function name and open parenthesis"given by checkpatch.pl

Signed-off-by: Joglekar Tejas 
---
 drivers/staging/rtl8723au/core/rtw_ap.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/rtl8723au/core/rtw_ap.c 
b/drivers/staging/rtl8723au/core/rtw_ap.c
index 6456689..65b209a 100644
--- a/drivers/staging/rtl8723au/core/rtw_ap.c
+++ b/drivers/staging/rtl8723au/core/rtw_ap.c
@@ -1642,7 +1642,7 @@ u8 ap_free_sta23a(struct rtw_adapter *padapter, struct 
sta_info *psta, bool acti
return beacon_updated;
 }
 
-int rtw_ap_inform_ch_switch23a (struct rtw_adapter *padapter, u8 new_ch, u8 
ch_offset)
+int rtw_ap_inform_ch_switch23a(struct rtw_adapter *padapter, u8 new_ch, u8 
ch_offset)
 {
struct list_head *phead, *plist;
struct sta_info *psta = NULL;
@@ -1663,12 +1663,12 @@ int rtw_ap_inform_ch_switch23a (struct rtw_adapter 
*padapter, u8 new_ch, u8 ch_o
list_for_each(plist, phead) {
psta = container_of(plist, struct sta_info, asoc_list);
 
-   issue_action_spct_ch_switch23a (padapter, psta->hwaddr, new_ch, 
ch_offset);
+   issue_action_spct_ch_switch23a(padapter, psta->hwaddr, new_ch, 
ch_offset);
psta->expire_to = ((pstapriv->expire_to * 2) > 5) ? 5 : 
(pstapriv->expire_to * 2);
}
spin_unlock_bh(>asoc_list_lock);
 
-   issue_action_spct_ch_switch23a (padapter, bc_addr, new_ch, ch_offset);
+   issue_action_spct_ch_switch23a(padapter, bc_addr, new_ch, ch_offset);
 
return 0;
 }
@@ -1871,7 +1871,7 @@ void stop_ap_mode23a(struct rtw_adapter *padapter)
pmlmeext->bstart_bss = false;
 
/* reset and init security priv , this can refine with 
rtw_reset_securitypriv23a */
-   memset((unsigned char *)>securitypriv, 0, sizeof (struct 
security_priv));
+   memset((unsigned char *)>securitypriv, 0, sizeof(struct 
security_priv));
padapter->securitypriv.ndisauthtype = Ndis802_11AuthModeOpen;
padapter->securitypriv.ndisencryptstatus = Ndis802_11WEPDisabled;
 
-- 
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: lockup when C1E and high-resolution timers enabled

[Christoph Fritz]

On Sun, 2015-06-14 at 11:13 +0800, Daniel J Blueman wrote:
> On Sunday, June 14, 2015 at 4:00:06 AM UTC+8, Christoph Fritz wrote:
> > Hi,
> >
> >  on following computer configuration, I do get hard lockup under heavy
> > IO-Load (using rsync):
> >
> >  - CONFIG_HIGH_RES_TIMERS=y
> >  - CPU: AMD FX(tm)-8350 Eight-Core Processor (family 0x15 model 0x2)
> >  - Motherboard: 'GA-970A-UD3P (rev. 1.0)' AMD 970/SB950
> >  - BIOS: C1E enabled (on 'GA-970A-UD3P' there is no disable option)
> >  - Kernels: 4.1.0-rc6, 4.0.x, 3.16.x
> >
> > Tests:
> >  - add kernel parameter "idle=halt" -> system runs fine
> >  - disable CONFIG_HIGH_RES_TIMERS -> system runs fine
> >  - change motherboard and disable C1E -> system runs fine
> >  - change CPU to AMD Phenom II X6 Processor -> system runs fine
> [..]
> 
> C1E disconnects HyperTransport links when all cores enter C1 (halt)
> for a period of time; this is all at the platform level, so isn't due
> to the kernel. The AMD AGESA code which controls the setup of this
> mechanism is updated in the F2g BIOS:
> http://www.gigabyte.com/products/product-page.aspx?pid=4717#bios
> 
> Did you try both BIOS releases with defaults?

Yes, rechecked both versions: Same bad behaviour.

> If still issues, also try with the current family 10h microcode from
> http://www.amd64.org/microcode/amd-ucode-latest.tar.bz2

Don't you mean family 15h for 'AMD FX(tm)-8350' ?

already using latest microcode:

[0.514490] microcode: CPU0: patch_level=0x06000822
[0.514497] microcode: CPU1: patch_level=0x06000822
[0.514508] microcode: CPU2: patch_level=0x06000822
[0.514519] microcode: CPU3: patch_level=0x06000822
[0.514529] microcode: CPU4: patch_level=0x06000822
[0.514540] microcode: CPU5: patch_level=0x06000822
[0.514550] microcode: CPU6: patch_level=0x06000822
[0.514561] microcode: CPU7: patch_level=0x06000822


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

Re: [PATCH v2] ARM: dts: exynos4210-trats: add max8997 IRQ

[Krzysztof Kozlowski]

2014-03-26 19:07 GMT+09:00 Robert Baldyga :
> This patch adds IRQ line specification for the MAX8997 chip and necessary
> pinctrl group to configure pull-up and driver strength of the pin.
> It's needed for proper handling of IRQs coming from MAX8997 multifunction
> device (IRQs are used by PMIC, MUIC and RTC).
>
> Signed-off-by: Robert Baldyga 
> Reviewed-by: Tomasz Figa 

(limit the CC list)
Yet another old patch I found on LKML... Robert, is this patch still
worth applying? If yes, would you be so kind to rebase it and resend?

Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Payment

[Finance Department]

Dear Winner,

You have been awarded the sum of  8,000,000.00 (Eight Million Pounds sterling) 
with reference number 77100146. This compensation funds from the United 
Nation.Send us your personal details to deliver your funds.

Gloria Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] selinux: reduce locking overhead in inode_free_security()

[Raghavendra K T]

On 06/13/2015 04:05 AM, Waiman Long wrote:

On 06/12/2015 08:31 AM, Stephen Smalley wrote:

On 06/12/2015 02:26 AM, Raghavendra K T wrote:

On 06/12/2015 03:01 AM, Waiman Long wrote:

The inode_free_security() function just took the superblock's isec_lock
before checking and trying to remove the inode security struct from the
linked list. In many cases, the list was empty and so the lock taking
is wasteful as no useful work is done. On multi-socket systems with
a large number of CPUs, there can also be a fair amount of spinlock
contention on the isec_lock if many tasks are exiting at the same time.

This patch changes the code to check the state of the list first
before taking the lock and attempting to dequeue it. As this function
is called indirectly from __destroy_inode(), there can't be another
instance of inode_free_security() running on the same inode.

Signed-off-by: Waiman Long
---
   security/selinux/hooks.c |   15 ---
   1 files changed, 12 insertions(+), 3 deletions(-)

v1->v2:
   - Take out the second list_empty() test inside the lock.

diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 7dade28..e5cdad7 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -254,10 +254,19 @@ static void inode_free_security(struct inode
*inode)
   struct inode_security_struct *isec = inode->i_security;
   struct superblock_security_struct *sbsec =
inode->i_sb->s_security;

-spin_lock(>isec_lock);
-if (!list_empty(>list))
+/*
+ * As not all inode security structures are in a list, we check
for
+ * empty list outside of the lock to make sure that we won't waste
+ * time taking a lock doing nothing. As inode_free_security() is
+ * being called indirectly from __destroy_inode(), there is no way
+ * there can be two or more concurrent calls. So doing the
list_empty()
+ * test outside the loop should be safe.
+ */
+if (!list_empty(>list)) {
+spin_lock(>isec_lock);
   list_del_init(>list);

Stupid question,

I need to take a look at list_del_init() code, but it can so happen that
if !list_empty() check could happen simultaneously, then serially two
list_del_init() can happen.

is that not a problem()?

Hmm...I suppose that's possible (sb_finish_set_opts and
inode_free_security could both perform the list_del_init).  Ok, we'll
stay with the first version.



Actually, list_del_init() can be applied twice with no harm being done.
The first list_del_init() will set list-> next = list->prev = list. The
second one will do the same thing and so it should be safe.



Waiman,
I do not think it is just about list_del_init() twice

what if


CPU1   CPU2 CPU3

!list_empty() !list_empty()

lock
list_del_init()
unlock

 list_add()
lock
list_del_init
unlock

But this is valid only if list_add() is possible after first
list_del_init. I need to see code though.
OR am I missing something?












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

Re: [PATCH v2 6/6] regulator: qcom-spmi: Add vendor specific configuration

[Bjorn Andersson]

On Thu, Jun 11, 2015 at 8:13 PM, Rob Herring  wrote:
> On Thu, Jun 11, 2015 at 7:37 PM, Stephen Boyd  wrote:
>> Add support for over current protection (OCP), pin control
>> selection, soft start and soft start strength, auto-mode, input
>> current limiting, and pull down.
>>
>> Cc: 
>> Signed-off-by: Stephen Boyd 
>> ---
>>
>> Changes from v1:
>> * New patch split from original SPMI regulator driver
>>
>>  .../bindings/regulator/qcom,spmi-regulator.txt |  62 +
>>  drivers/regulator/qcom_spmi-regulator.c| 298 
>> -
>>  2 files changed, 358 insertions(+), 2 deletions(-)
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.txt 
>> b/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.txt
>> index 75b4604bad07..ab01a152e930 100644
>> --- a/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.txt
>> +++ b/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.txt
>> @@ -99,6 +99,68 @@ see regulator.txt - with additional custom properties 
>> described below:
>> soft start are active all the time. 0 = Set initial mode 
>> to
>> low power mode (LPM).
>>
>> +- qcom,auto-mode-enable:
>
> Auto regulator modes are fairly common. Can't we have a common property here?
>

I went with a similar set of booleans for mode selection in the
initial rpm driver for family A, but Kumar objected to this. So there
I ended up with "qcom,force-mode" - taking an enum - instead (see
mfd/qcom-rpm.txt). It would be nice if the various regulator drivers
have similar bindings...

>> +   Usage: optional
>> +   Value type: 
>
> This can be bool. Unless we want to have a mode property with "auto"
> being one possible value.
>
>> +   Description: 1 = Enable automatic hardware selection of regulator
>> +mode (HPM vs LPM); not available on boost type
>> +regulators. 0 = Disable auto mode selection.
>> +

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Payment

[Finance Department]

Dear Winner,

You have been awarded the sum of  8,000,000.00 (Eight Million Pounds sterling) 
with reference number 77100146. This compensation funds from the United 
Nation.Send us your personal details to deliver your funds.

Gloria Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v14 2/3] power-domain: rockchip: add power domain driver

[Caesar Wang]

Ulf,

Thanks for your comments.:-)



在 2015年05月28日 18:38, Ulf Hansson 写道:

On 24 April 2015 at 10:07, Caesar Wang  wrote:

In order to meet high performance and low power requirements, a power
management unit is designed or saving power when RK3288 in low power
mode.
The RK3288 PMU is dedicated for managing the power ot the whole chip.

Signed-off-by: jinkun.hong 
Signed-off-by: Caesar Wang 
---

  arch/arm/mach-rockchip/Kconfig  |   1 +
  arch/arm/mach-rockchip/Makefile |   1 +
  arch/arm/mach-rockchip/pm_domains.c | 506 
  3 files changed, 508 insertions(+)
  create mode 100644 arch/arm/mach-rockchip/pm_domains.c

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index ae4eb7c..578206b 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -15,6 +15,7 @@ config ARCH_ROCKCHIP
 select ROCKCHIP_TIMER
 select ARM_GLOBAL_TIMER
 select CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
+   select PM_GENERIC_DOMAINS if PM
 help
   Support for Rockchip's Cortex-A9 Single-to-Quad-Core-SoCs
   containing the RK2928, RK30xx and RK31xx series.
diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index 5c3a9b2..9c902d3 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -1,5 +1,6 @@
  CFLAGS_platsmp.o := -march=armv7-a

  obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip.o
+obj-$(CONFIG_PM_GENERIC_DOMAINS) += pm_domains.o
  obj-$(CONFIG_PM_SLEEP) += pm.o sleep.o
  obj-$(CONFIG_SMP) += headsmp.o platsmp.o
diff --git a/arch/arm/mach-rockchip/pm_domains.c 
b/arch/arm/mach-rockchip/pm_domains.c
new file mode 100644
index 000..92d2569
--- /dev/null
+++ b/arch/arm/mach-rockchip/pm_domains.c
@@ -0,0 +1,506 @@
+/*
+ * Rockchip Generic power domain support.
+ *
+ * Copyright (c) 2014 ROCKCHIP, Co. Ltd.
+ *
+ * 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 

clk-provider.h, why?


The following is needed.

_clk_get_name(clk)





+#include 
+#include 
+#include 

Same comment as in patch1. I don't find this header.


OK.
Perhaps, Making a mistake. the missing the patch in 
here.(https://patchwork.kernel.org/patch/6266881/)

+
+struct rockchip_domain_info {
+   int pwr_mask;
+   int status_mask;
+   int req_mask;
+   int idle_mask;
+   int ack_mask;
+};
+
+struct rockchip_pmu_info {
+   u32 pwr_offset;
+   u32 status_offset;
+   u32 req_offset;
+   u32 idle_offset;
+   u32 ack_offset;
+
+   u32 core_pwrcnt_offset;
+   u32 gpu_pwrcnt_offset;
+
+   unsigned int core_power_transition_time;
+   unsigned int gpu_power_transition_time;
+
+   int num_domains;
+   const struct rockchip_domain_info *domain_info;
+};
+
+struct rockchip_pm_domain {
+   struct generic_pm_domain genpd;
+   const struct rockchip_domain_info *info;
+   struct rockchip_pmu *pmu;
+   int num_clks;
+   struct clk *clks[];
+};
+
+struct rockchip_pmu {
+   struct device *dev;
+   struct regmap *regmap;
+   const struct rockchip_pmu_info *info;
+   struct mutex mutex; /* mutex lock for pmu */
+   struct genpd_onecell_data genpd_data;
+   struct generic_pm_domain *domains[];
+};
+
+#define to_rockchip_pd(gpd) container_of(gpd, struct rockchip_pm_domain, genpd)
+
+#define DOMAIN(pwr, status, req, idle, ack)\
+{  \
+   .pwr_mask = BIT(pwr),   \
+   .status_mask = BIT(status), \
+   .req_mask = BIT(req),   \
+   .idle_mask = BIT(idle), \
+   .ack_mask = BIT(ack),   \
+}
+
+#define DOMAIN_RK3288(pwr, status, req)\
+   DOMAIN(pwr, status, req, req, (req) + 16)
+
+static bool rockchip_pmu_domain_is_idle(struct rockchip_pm_domain *pd)
+{
+   struct rockchip_pmu *pmu = pd->pmu;
+   const struct rockchip_domain_info *pd_info = pd->info;
+   unsigned int val;
+
+   regmap_read(pmu->regmap, pmu->info->idle_offset, );
+   return (val & pd_info->idle_mask) == pd_info->idle_mask;
+}
+
+static int rockchip_pmu_set_idle_request(struct rockchip_pm_domain *pd,
+bool idle)
+{
+   const struct rockchip_domain_info *pd_info = pd->info;
+   struct rockchip_pmu *pmu = pd->pmu;
+   unsigned int val;
+
+   regmap_update_bits(pmu->regmap, pmu->info->req_offset,
+  pd_info->req_mask, idle ? -1U : 0);
+
+   dsb();
+
+   do {
+   regmap_read(pmu->regmap, pmu->info->ack_offset, );
+   } while ((val & pd_info->ack_mask) != (idle ? pd_info->ack_mask : 0));
+
+   while 

[PATCH] staging:rtl8723au:ioctl_cfg80211:spaces required around '>'

[Joglekar, Tejas (T.)]

From: Joglekar Tejas 

This patch removes the error given by checkpatch.pl
" spaces required around that '>' "

Signed-off-by: Joglekar Tejas 
---
 drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c 
b/drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c
index bc95ce8..feb5961 100644
--- a/drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c
@@ -1041,7 +1041,7 @@ static u16 rtw_get_cur_max_rate(struct rtw_adapter 
*adapter)
while (pcur_bss->SupportedRates[i] != 0 &&
   pcur_bss->SupportedRates[i] != 0xFF) {
rate = pcur_bss->SupportedRates[i] & 0x7F;
-   if (rate>max_rate)
+   if (rate > max_rate)
max_rate = rate;
i++;
}
-- 
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] iio:adc: XADC: Set offset explicitly to zero on voltage channels

[Gergely Imreh]

On 14 June 2015 at 02:30, Jonathan Cameron  wrote:
> On 11/06/15 09:22, Gergely Imreh wrote:
>> The Xilinx XADC driver has both a temperature channel and 8 voltage
>> channels. The voltage channels have no offset, but actually were still
>> set the same offset as the temperature channel. This did not cause
>> problems in /sys/bus/iio/ but can cause problems with other drivers
>> using iio data. For example iio-hwmon did return wrong voltage values
>> because of the offset.
>>
>> Change tested with the Parallella board.
>>
>> Signed-off-by: Gergely Imreh 
> Well spotted on the bug, but I think we are better off fixing this at the
> true source of the problem which is in drivers/iio/inkern.c
> iio_convert_raw_to_processed_unlocked which does a call to
> iio_channel_read(chan, , NULL, IIO_CHAN_INFO_OFFSET) then uses
> the error return to check if the offset parameter is available. It should
> be checking that before making this call with a call to iio_channel_has_info.
>
> I don't suppose you could prepare a patch fixing that as you found the 
> problem?

I'll check it out, and send an updated patch! Thanks for the pointers
to the core of the issue.

>
> If not I can fix it up sometime if no one else beats me to it.
>
> Thanks
>
> Jonathan
>> ---
>>  drivers/iio/adc/xilinx-xadc-core.c | 14 +++---
>>  1 file changed, 11 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/iio/adc/xilinx-xadc-core.c 
>> b/drivers/iio/adc/xilinx-xadc-core.c
>> index ab52be2..36efab7 100644
>> --- a/drivers/iio/adc/xilinx-xadc-core.c
>> +++ b/drivers/iio/adc/xilinx-xadc-core.c
>> @@ -877,9 +877,17 @@ static int xadc_read_raw(struct iio_dev *indio_dev,
>>   return -EINVAL;
>>   }
>>   case IIO_CHAN_INFO_OFFSET:
>> - /* Only the temperature channel has an offset */
>> - *val = -((273150 << 12) / 503975);
>> - return IIO_VAL_INT;
>> + switch (chan->type) {
>> + case IIO_VOLTAGE:
>> + *val = 0;
>> + return IIO_VAL_INT;
>> + case IIO_TEMP:
>> + /* Only the temperature channel has an offset */
>> + *val = -((273150 << 12) / 503975);
>> + return IIO_VAL_INT;
>> + default:
>> + return -EINVAL;
>> + }
>>   case IIO_CHAN_INFO_SAMP_FREQ:
>>   ret = xadc_read_adc_reg(xadc, XADC_REG_CONF2, );
>>   if (ret)
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: lockup when C1E and high-resolution timers enabled

[Daniel J Blueman]

On Sunday, June 14, 2015 at 4:00:06 AM UTC+8, Christoph Fritz wrote:
> Hi,
>
>  on following computer configuration, I do get hard lockup under heavy
> IO-Load (using rsync):
>
>  - CONFIG_HIGH_RES_TIMERS=y
>  - CPU: AMD FX(tm)-8350 Eight-Core Processor (family 0x15 model 0x2)
>  - Motherboard: 'GA-970A-UD3P (rev. 1.0)' AMD 970/SB950
>  - BIOS: C1E enabled (on 'GA-970A-UD3P' there is no disable option)
>  - Kernels: 4.1.0-rc6, 4.0.x, 3.16.x
>
> Tests:
>  - add kernel parameter "idle=halt" -> system runs fine
>  - disable CONFIG_HIGH_RES_TIMERS -> system runs fine
>  - change motherboard and disable C1E -> system runs fine
>  - change CPU to AMD Phenom II X6 Processor -> system runs fine
[..]

C1E disconnects HyperTransport links when all cores enter C1 (halt)
for a period of time; this is all at the platform level, so isn't due
to the kernel. The AMD AGESA code which controls the setup of this
mechanism is updated in the F2g BIOS:
http://www.gigabyte.com/products/product-page.aspx?pid=4717#bios

Did you try both BIOS releases with defaults?

If still issues, also try with the current family 10h microcode from
http://www.amd64.org/microcode/amd-ucode-latest.tar.bz2

Thanks,
  Daniel
-- 
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] NTB bug fixes for v4.1

[Jon Mason]

Hi Linus,
I apologize for the tardiness of this request.  Below are a couple of last
minute NTB bug fixes for v4.1. Please consider pulling them.

Thanks,
Jon


The following changes since commit d4a4f75cd8f29cd9464a5a32e9224a91571d6649:

  Linux 4.1-rc7 (2015-06-07 20:23:50 -0700)

are available in the git repository at:

  git://github.com/jonmason/ntb tags/ntb-4.1

for you to fetch changes up to ebaad1322d8080a1a8367ec631b345405d9879e2:

  ntb: initialize max_mw for Atom before using it (2015-06-11 09:27:24 -0400)


NTB bug fixes to address issues in unmapping the MW reg base and vbase,
and an uninitialized variable on Atom platforms.


Daniel Verkamp (1):
  ntb: initialize max_mw for Atom before using it

Jon Mason (1):
  ntb: iounmap MW reg and vbase in error path

 drivers/ntb/ntb_hw.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/8] nohz: Remove idle task special case

[Preeti U Murthy]

On 06/11/2015 11:06 PM, Frederic Weisbecker wrote:
> This is a leftover from old days to avoid conflicts with dynticks idle
> code. Now full dynticks and idle dynticks are better integrated and
> interact without known issue.

I am sorry but I fail to understand why the check on idle task was there
in the first place in the below code paths. It would help if you could
clarify this in the changelog as well.

> 
> So lets remove it.
> 
> Cc: Christoph Lameter 
> Cc: Ingo Molnar 
> Cc; John Stultz 
> Cc: Peter Zijlstra 
> Cc: Preeti U Murthy 
> Cc: Rik van Riel 
> Cc: Thomas Gleixner 
> Cc: Viresh Kumar 
> Signed-off-by: Frederic Weisbecker 
> ---
>  kernel/time/tick-sched.c | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> index 812f7a3..324482f 100644
> --- a/kernel/time/tick-sched.c
> +++ b/kernel/time/tick-sched.c
> @@ -208,10 +208,8 @@ void __tick_nohz_full_check(void)
>   struct tick_sched *ts = this_cpu_ptr(_cpu_sched);
> 
>   if (tick_nohz_full_cpu(smp_processor_id())) {
> - if (ts->tick_stopped && !is_idle_task(current)) {
> - if (!can_stop_full_tick())

can_stop_full_tick() would have bailed out if the current task was idle,
since it checks for the number of tasks being greater than 1 to restart
the tick. So why was the check is_idle_task() introduced earlier ?

> - tick_nohz_restart_sched_tick(ts, ktime_get());
> - }
> + if (ts->tick_stopped && !can_stop_full_tick())
> + tick_nohz_restart_sched_tick(ts, ktime_get());
>   }
>  }
> 
> @@ -710,7 +708,7 @@ static void tick_nohz_full_stop_tick(struct tick_sched 
> *ts)
>  #ifdef CONFIG_NO_HZ_FULL
>   int cpu = smp_processor_id();
> 
> - if (!tick_nohz_full_cpu(cpu) || is_idle_task(current))
> + if (!tick_nohz_full_cpu(cpu))

If the current task was indeed idle, the check on ts->inidle would have
succeeded in tick_irq_exit() and we would not have reached this function
at all, isn't it? So here too I am unable to understand why we had it in
the first place.

Regards
Preeti U Murthy
>   return;
> 
>   if (!ts->tick_stopped && ts->nohz_mode == NOHZ_MODE_INACTIVE)
> 

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

Re: [PATCH v5] seccomp: add ptrace options for suspend/resume

[Oleg Nesterov]

On 06/13, Tycho Andersen wrote:
>
> This patch is the first step in enabling checkpoint/restore of processes
> with seccomp enabled.

So just in case, I am fine with this version.

> One of the things CRIU does while dumping tasks is inject code into them
> via ptrace to collect information that is only available to the process
> itself. However, if we are in a seccomp mode where these processes are
> prohibited from making these syscalls, then what CRIU does kills the task.
> 
> This patch adds a new ptrace option, PTRACE_O_SUSPEND_SECCOMP, that enables
> a task from the init user namespace which has CAP_SYS_ADMIN and no seccomp
> filters to disable (and re-enable) seccomp filters for another task so that
> they can be successfully dumped (and restored). We restrict the set of
> processes that can disable seccomp through ptrace because although today
> ptrace can be used to bypass seccomp, there is some discussion of closing
> this loophole in the future and we would like this patch to not depend on
> that behavior and be future proofed for when it is removed.
> 
> Note that seccomp can be suspended before any filters are actually
> installed; this behavior is useful on criu restore, so that we can suspend
> seccomp, restore the filters, unmap our restore code from the restored
> process' address space, and then resume the task by detaching and have the
> filters resumed as well.
> 
> v2 changes:
> 
> * require that the tracer have no seccomp filters installed
> * drop TIF_NOTSC manipulation from the patch
> * change from ptrace command to a ptrace option and use this ptrace option
>   as the flag to check. This means that as soon as the tracer
>   detaches/dies, seccomp is re-enabled and as a corrollary that one can not
>   disable seccomp across PTRACE_ATTACHs.
> 
> v3 changes:
> 
> * get rid of various #ifdefs everywhere
> * report more sensible errors when PTRACE_O_SUSPEND_SECCOMP is incorrectly
>   used
> 
> v4 changes:
> 
> * get rid of may_suspend_seccomp() in favor of a capable() check in ptrace
>   directly
> 
> v5 changes:
> 
> * check that seccomp is not enabled (or suspended) on the tracer
> 
> Signed-off-by: Tycho Andersen 
> CC: Kees Cook 
> CC: Andy Lutomirski 
> CC: Will Drewry 
> CC: Roland McGrath 
> CC: Oleg Nesterov 
> CC: Pavel Emelyanov 
> CC: Serge E. Hallyn 
> ---
>  include/linux/ptrace.h  |  1 +
>  include/uapi/linux/ptrace.h |  6 --
>  kernel/ptrace.c | 13 +
>  kernel/seccomp.c|  8 
>  4 files changed, 26 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
> index 987a73a..061265f 100644
> --- a/include/linux/ptrace.h
> +++ b/include/linux/ptrace.h
> @@ -34,6 +34,7 @@
>  #define PT_TRACE_SECCOMP PT_EVENT_FLAG(PTRACE_EVENT_SECCOMP)
>  
>  #define PT_EXITKILL  (PTRACE_O_EXITKILL << PT_OPT_FLAG_SHIFT)
> +#define PT_SUSPEND_SECCOMP   (PTRACE_O_SUSPEND_SECCOMP << PT_OPT_FLAG_SHIFT)
>  
>  /* single stepping state bits (used on ARM and PA-RISC) */
>  #define PT_SINGLESTEP_BIT31
> diff --git a/include/uapi/linux/ptrace.h b/include/uapi/linux/ptrace.h
> index cf1019e..a7a6979 100644
> --- a/include/uapi/linux/ptrace.h
> +++ b/include/uapi/linux/ptrace.h
> @@ -89,9 +89,11 @@ struct ptrace_peeksiginfo_args {
>  #define PTRACE_O_TRACESECCOMP(1 << PTRACE_EVENT_SECCOMP)
>  
>  /* eventless options */
> -#define PTRACE_O_EXITKILL(1 << 20)
> +#define PTRACE_O_EXITKILL(1 << 20)
> +#define PTRACE_O_SUSPEND_SECCOMP (1 << 21)
>  
> -#define PTRACE_O_MASK(0x00ff | PTRACE_O_EXITKILL)
> +#define PTRACE_O_MASK(\
> + 0x00ff | PTRACE_O_EXITKILL | PTRACE_O_SUSPEND_SECCOMP)
>  
>  #include 
>  
> diff --git a/kernel/ptrace.c b/kernel/ptrace.c
> index c8e0e05..496028b 100644
> --- a/kernel/ptrace.c
> +++ b/kernel/ptrace.c
> @@ -556,6 +556,19 @@ static int ptrace_setoptions(struct task_struct *child, 
> unsigned long data)
>   if (data & ~(unsigned long)PTRACE_O_MASK)
>   return -EINVAL;
>  
> + if (unlikely(data & PTRACE_O_SUSPEND_SECCOMP)) {
> + if (!config_enabled(CONFIG_CHECKPOINT_RESTORE) ||
> + !config_enabled(CONFIG_SECCOMP))
> + return -EINVAL;
> +
> + if (!capable(CAP_SYS_ADMIN))
> + return -EPERM;
> +
> + if (current->seccomp.mode != SECCOMP_MODE_DISABLED ||
> + current->ptrace & PT_SUSPEND_SECCOMP)
> + return -EPERM;
> + }
> +
>   /* Avoid intermediate state when all opts are cleared */
>   flags = child->ptrace;
>   flags &= ~(PTRACE_O_MASK << PT_OPT_FLAG_SHIFT);
> diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> index 980fd26..645e42d 100644
> --- a/kernel/seccomp.c
> +++ b/kernel/seccomp.c
> @@ -590,6 +590,10 @@ void secure_computing_strict(int this_syscall)
>  {
>   int mode = current->seccomp.mode;
>  
> + if 

BUSINESS DEAL?

[Harrison Ken]

Dear Sir/Ma,

I need your consent to transfer $25.5M that has remained unclaimed since 1999. 
The funds will be moved to any of our correspondent Banks in "YOUR NAME" 
immediately to secure the funds first. The Principal will be shared on a 50/50 
basis.

Yours Faithfully,
Mr. Harrison Ken.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 07/18] kthread: Make iterant kthreads freezable by default

[Tejun Heo]

Hey, Petr.

On Fri, Jun 12, 2015 at 03:24:40PM +0200, Petr Mladek wrote:
> > * While hibernating, freezing writeback workers and whoever else which
> >   might issue IOs.  This is because we have to thaw devices to issue
> >   IOs to write out the prepared hibernation image.  If new IOs are
> >   issued from page cache or whereever when the devices are thawed for
> >   writing out the hibernation image, the hibernation image and the
> >   data on the disk deviate.
> 
> Just an idea. I do not say that it is a good solution. If we already
> thaw devices needed to write the data. It should be possible to thaw
> also kthreads needed to write the data.

Sure, we'd end up having to mark the involved kthreads and whatever
they may depend on with "freeze for snapshotting but not for writing
out images".

> >   Note that this only works because currently none of the block
> >   drivers which may be used to write out hibernation images depend on
> >   freezable kthreads and hopefully nobody issues IOs from unfreezable
> >   kthreads or bh or softirq, which, I think, can happen with
> >   preallocated requests or bio based devices.
> 
> It means that some kthreads must be stopped, some must be available,
> and we do not mind about the rest. I wonder which group is bigger.
> It might help to decide about the more safe default. It is not easy
> for me to decide :-/

Please do not spread freezer more than necessary.  It's not about
which part is larger but about not completely losing track of what's
going on.  At least now we can say "this needs freezer because XYZ"
and that XYZ actually points to something which needs to be
synchronized for PM operations.  If we flip the polarity, all we're
left with is "this can't be frozen because it deadlocks with XYZ"
which is a lot less information, both in terms of relevance and
amount, than the other way around.

> >   This is a very brittle approach.  Instead of controlling things
> >   where it actually can be controlled - the IO ingress point - we're
> >   trying to control all its users with a pretty blunt tool while at
> >   the same time depending on the fact that some of the low level
> >   subsystems don't happen to make use of the said blunt tool.
> >
> >   I think what we should do is simply blocking all non-image IOs from
> >   the block layer while writing out hibernation image.  It'd be
> >   simpler and a lot more reliable.
> 
> This sounds like an interesting idea to me. Do you already have some
> more precise plan in mind?

Unfortunately, no.  No concrete plans or patches yet but even then I'm
pretty sure we don't wanna head the other direction.  It's just wrong.

> Unfortunately, for me it is not easy to judge it. I wonder how many
> interfaces would need to get hacked to make this working.

Not much really.  We just need a way to flag IOs to write image - be
that a bio / request flag or task flag and then a way to tell the
block layer to block everything else.

> Also I wonder if they would be considered as a hack or a clean
> solution by the affected parties. By other words, I wonder if it is
> realistic.

I'd say it's pretty realistic.  This is synchronizing where the
operations need to be synchronized.  What part would be hackish?

> > * Device drivers which interact with their devices in a fully
> >   synchronous manner so that blocking the kthread always reliably
> >   quiesces the device.  For this to be true, the device shouldn't
> >   carry over any state across the freezing points.  There are drivers
> >   which are actually like this and it works for them.
> 
> I am trying to sort it in my head. In each case, we need to stop these
> kthreads in some well defined state. Also the kthread (or device)
> must be able to block the freezing if they are not in the state yet.

Whether kthreads need to be stopped or not is periphery once you have
a proper blocking / draining mechanism.  The thing is most of these
kthreads are blocked on requests coming down from upper layers anyway.
Once you plug queueing of new requests and drain whatever is in
flight, the kthread isn't gonna do anything anyway.

> The stop points are defined by try_to_freeze() now. And freezable
> kthreads block the freezer until they reach these points.

I'm repeating myself but that only works for fully synchronous devices
(ie. kthread processing one command at a time).  You need to drain
whatever is in flight too.  You can't do that with simple freezing
points.  There's a reason why a lot of drivers can't rely on freezer
for PM operations.  Drivers which can fully depend on freezer would be
minority.

> >   However, my impression is that people don't really scrutinize why
> >   freezer works for a specific case and tend to spray them all over
> >   and develop a fuzzy sense that freezing will somehow magically make
> >   the driver ready for PM operatoins.  It doesn't help that freezer is
> >   such a blunt tool and our historical usage has always been fuzzy -
> >   in the earlier days, 

arc_pmu not initialized in the arc/kernel/perf_event.c?

[Max Filippov]

Mischa, Vineet,

Looking at ARC PMU driver I've got an impression that its static arc_pmu
is left uninitialized, which possibly leads to Oops once registered
callbacks are invoked. I don't have neither ARC toolchain nor hardware to
test it, so I may be missing something. Below is the fix for it.

Thanks.
-- Max

---8<---
From: Max Filippov 
Subject: [PATCH] arc: fix use of uninitialized arc_pmu

static arc_pmu in the arch/arc/kernel/perf_event.c is not initialized as
it's shadowed by a local variable of the same name in the
arc_pmu_device_probe.

Signed-off-by: Max Filippov 
---
 arch/arc/kernel/perf_event.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arc/kernel/perf_event.c b/arch/arc/kernel/perf_event.c
index fd2ec50..57b58f5 100644
--- a/arch/arc/kernel/perf_event.c
+++ b/arch/arc/kernel/perf_event.c
@@ -266,7 +266,6 @@ static int arc_pmu_add(struct perf_event *event, int flags)
 
 static int arc_pmu_device_probe(struct platform_device *pdev)
 {
-   struct arc_pmu *arc_pmu;
struct arc_reg_pct_build pct_bcr;
struct arc_reg_cc_build cc_bcr;
int i, j, ret;
-- 
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next] Increase limit of macvtap queues

[Sergei Shtylyov]

Hello.

On 06/12/2015 04:30 PM, Pankaj Gupta wrote:


Macvtap should be compatible with tuntap for maximum number
of queues. '1059590254fa9dce9cafc4f07d1103dbec415e76' removes


   Please also specify that commit's summary line in parens.


the limitation and increases number of queues in tuntap.
Now, Its safe to increase number of queues in Macvtap as well.



Signed-off-by: Pankaj Gupta 


WBR, Sergei

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

Re: [BUG ?] staging: rtl8723au: condition with no effect

[Jes Sorensen]

Nicholas Mc Guire  writes:
> scanning for trivial bug-patters with coccinelle spatches returned:
> ./drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c:1395
>   WARNING: condition with no effect (if branch == else)
>
> drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c - line numbers from 4.1-rc7
> 1395if (bWithoutHWSM) {
> 1396/* value16 |= (APDM_HOST | FSM_HSUS |/PFM_ALDN); */
> 1397/*  2010/08/31 According to Filen description, we need to
> 1398use HW to shut down 8051 automatically. */
> 1399/*  Because suspend operation need the asistance of 8051
> 1400to wait for 3ms. */
> 1401value16 = APDM_HOST | AFSM_HSUS | PFM_ALDN;
> 1402} else {
> 1403value16 = APDM_HOST | AFSM_HSUS | PFM_ALDN;
> 1404}
> 1405 
> 1406rtl8723au_write16(padapter, REG_APS_FSMCO, value16);/* 0x4802 */
>
> Not clear what the intent is but this looks like a typo/bug in the assigment
> of value16 as the condition here has no effect.

Doesn't look like a typo, looks like someone at some point had commented
out PFM_ALDN in the bWithoutHWSM case. Why they did that and then later
overrode it, I have no idea.

Jes


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

Re: [PATCHv4 0/4] vme DMA and user space driver improvements

[Greg Kroah-Hartman]

On Sat, Jun 13, 2015 at 04:34:00PM +0300, Dmitry Kalinkin wrote:
> This reorders patches so that Greg can take first three, while fourth awaits
> maintainer's approval.
> 
> Dmitry Kalinkin (4):
>   staging: vme_user: remove forward declarations
>   staging: vme_user: remove open/release
>   staging: vme_user: remove buf_unalloc helper
>   staging: vme_user: provide DMA functionality

Applied the first 3, thanks.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC v1 14/25] genirq: Kill the first parameter 'irq' of irq_flow_handler_t

[Julia Lawall]

The semantic patch below considers the problem from another point of view, 
to find functions that may have a handler as an argument.  The results 
that are different than those considered already are as follows:

arch/x86/platform/uv/uv_irq.c:106 irq_domain_set_info
has a possible handler in argument 6
arch/sparc/kernel/leon_pci_grpci2.c:815 leon_update_virq_handling
has a possible handler in argument 2
arch/sparc/kernel/leon_kernel.c:79 leon_build_device_irq
has a possible handler in argument 2
arch/arm/mach-omap2/prm_common.c:331 irq_alloc_generic_chip
has a possible handler in argument 5
arch/mips/cavium-octeon/octeon-irq.c:1231 octeon_irq_set_ciu_mapping
has a possible handler in argument 6
arch/blackfin/mach-common/ints-priority.c:805 bfin_set_irq_handler
has a possible handler in argument 2
arch/m68k/q40/q40ints.c:84 m68k_setup_irq_controller
has a possible handler in argument 2
drivers/gpio/gpio-pcf857x.c:362 gpiochip_irqchip_add
has a possible handler in argument 4

The semantic patch looks for a function that has as argument a function 
that has arguments of type (unsigned int irq, struct irq_desc *desc) and a 
void return type.  It also looks for functions that have as argument a 
bunch of known irq handlers.

julia


@initialize:ocaml@
@@
let tbl = Hashtbl.create 101
let ln = Str.regexp "linux-next/" (* update as appropriate *)

let _ =
  List.iter (function x -> Hashtbl.add tbl x ())
[("__irq_set_handler",2);("irq_set_handler",2);
  ("irq_set_chained_handler",2);("irq_alloc_generic_chip",4);
  ("irq_alloc_domain_generic_chips",5);("irq_set_chip_and_handler_name",3);
  ("irq_set_chip_and_handler",3);("__irq_set_handler_locked",2);
  ("__irq_set_chip_handler_name_locked",3);("__irq_set_preflow_handler",2);
  ("gpiochip_set_chained_irqchip",4)]

let update g f n p =
  let n = n + 1 in
  let entry = (g,n) in
  try let _ = Hashtbl.find tbl entry in ()
  with Not_found ->
begin
  Hashtbl.add tbl entry ();
  let p = List.hd p in
  Printf.printf "%s:%d %s\n\thas a possible handler in argument %d\n"
(List.nth (Str.split ln p.file) 1) p.line g
n
end

@possible_handler@
identifier f,irq,desc;
@@

void f(unsigned int irq, struct irq_desc *desc) { ... }

@call@
identifier g,possible_handler.f;
expression list[n] es;
position p;
@@

g(es,f@p,...)

@script:ocaml@
p << call.p;
f << possible_handler.f;
g << call.g;
n << call.n;
@@

update g f n p

@call2@
identifier g,f;
expression list[n] es;
position p;
symbol handle_level_irq,handle_simple_irq,handle_edge_irq,
   handle_fasteoi_irq,handle_percpu_irq;
@@

g(es,\(handle_level_irq@f@p\|handle_simple_irq@f@p\|handle_edge_irq@f@p\|
   handle_fasteoi_irq@f@p\|handle_percpu_irq@f@p\),...)

@script:ocaml@
p << call2.p;
f << call2.f;
g << call2.g;
n << call2.n;
@@

update g f n p
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: General protection fault after STR (32 bit systems only)

[Brian Gerst]

On Sat, Jun 13, 2015 at 2:23 PM, Andy Lutomirski  wrote:
> On Sat, Jun 13, 2015 at 12:03 AM, Ingo Molnar  wrote:
>>
>> * Brian Gerst  wrote:
>>
>>> On Fri, Jun 12, 2015 at 4:36 AM, Ingo Molnar  wrote:
>>> >
>>> > * H. Peter Anvin  wrote:
>>> >
>>> >> %es is used implicitly by string instructions.
>>> >
>>> > Ok, so we are probably better off reloading ES as well early, right
>>> > when we return from the firmware, just in case something does
>>> > a copy before we hit the ES restore in restore_processor_state(),
>>> > which is a generic C function?
>>> >
>>> > Something like the patch below?
>>> >
>>> > I also added FS/GS/SS reloading to make it complete. If this (or a variant
>>> > thereof, it's still totally untested) works then we can remove the segment
>>> > save/restore layer in __save/restore_processor_state().
>>> >
>>> > Thanks,
>>> >
>>> > Ingo
>>> >
>>> > ===>
>>> >  arch/x86/kernel/acpi/wakeup_32.S | 13 +
>>> >  1 file changed, 13 insertions(+)
>>> >
>>> > diff --git a/arch/x86/kernel/acpi/wakeup_32.S 
>>> > b/arch/x86/kernel/acpi/wakeup_32.S
>>> > index 665c6b7d2ea9..1376a7fc21b7 100644
>>> > --- a/arch/x86/kernel/acpi/wakeup_32.S
>>> > +++ b/arch/x86/kernel/acpi/wakeup_32.S
>>> > @@ -61,6 +61,19 @@ ENTRY(wakeup_pmode_return)
>>> >
>>> >
>>> >  restore_registers:
>>> > +   /*
>>> > +* In case the BIOS corrupted our segment descriptors,
>>> > +* reload them to clear out any shadow descriptor
>>> > +* state:
>>> > +*/
>>> > +   movl$__USER_DS, %eax
>>> > +   movl%eax, %ds
>>> > +   movl%eax, %es
>>> > +   movl%eax, %fs
>>> > +   movl%eax, %gs
>>> > +   movl$__KERNEL_DS, %eax
>>> > +   movl%eax, %ss
>>> > +
>>> > movlsaved_context_ebp, %ebp
>>> > movlsaved_context_ebx, %ebx
>>> > movlsaved_context_esi, %esi
>>>
>>> If you follow the convoluted flow of the calls in this file, 
>>> wakeup_pmode_return
>>> is the first thing called from the trampoline on resume, and that loads the 
>>> data
>>> segments with __KERNEL_DS. [...]
>>
>> So if wakeup_pmode_return is really the first thing called then the whole 
>> premise
>> of shadow descriptor corruption goes out the window: we reload all relevant
>> segment registers.
>
> True, but it still leaves the fact that we're loading __KERNEL_DS
> instead of __USER_DS, right?  So we end up in the kernel in some
> context (I have no clue what context) with __KERNEL_DS loaded.  It's
> very easy for us to inadvertently fix it: we could return to userspace
> by any means whatsoever except SYSEXIT, or we could even return back
> to some preempted kernel context.
>
> I still think we should replace __KERNEL_DS with __USER_DS in
> wakeup_pmode_return and see if the problem goes away.

I'm pretty sure that's what the problem is.  If you look at the
sysexit path, it never reloads ds/es.  It assumes they are still
__USER_DS set at sysenter.  The iret path does restore all the user
segments.

--
Brian Gerst
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [char-misc-next 07/17] mei: bus: don't enable events implicitly in device enable

[Greg KH]

On Sat, Jun 13, 2015 at 10:11:39PM +0300, Tomas Winkler wrote:
> Always call mei_cl_register_event_cb explicitly so the events
> are enabled only when needed. The nfc driver is already using
> it that way so no need for further changes.

This doesn't seem to match up with the code being changed here.  You are
removing code.

I stopped reading here, please fix up the series and resend.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [char-misc-next 06/17] mei: bus: add kdoc for device attribute functions

[Greg KH]

On Sat, Jun 13, 2015 at 10:11:38PM +0300, Tomas Winkler wrote:
> 1. Rename uevent handler to mei_cl_device_uevent
> 2. Add kdoc for uevent and mod alias functions

2 things in one patch?  No, please make these separate patches.

And why add kdoc to static functions?  That makes no sense.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [char-misc-next 05/17] mei: bus: move driver api functions at the start of the file

[Greg KH]

On Sat, Jun 13, 2015 at 10:11:37PM +0300, Tomas Winkler wrote:
> To make the file more organize move mei client driver api
> to the start of the file and add Kdoc
> 
> There are no functional changes in this patch

/me hands Tomas some extra '.' characters to use in changelogs...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [char-misc-next 04/17] mei: bus: rename nfc.c to bus-fixup.c

[Greg KH]

On Sat, Jun 13, 2015 at 10:11:36PM +0300, Tomas Winkler wrote:
> In nfc.c we just create device name on the mei client bus
> we make it more generic in the following patches

That doesn't make sense, please reword to justify renaming the file.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [char-misc-next 03/17] mei: bus: rename device_list to simple devices

[Greg KH]

On Sat, Jun 13, 2015 at 10:11:35PM +0300, Tomas Winkler wrote:
> Signed-off-by: Tomas Winkler 

No changelog entry?  Sorry, can't accept it.

And why are you doing this patch?  renames for no reason isn't ok.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [char-misc-next 02/17] mei: bus: fix drivers and devices names confusion

[Greg KH]

On Sat, Jun 13, 2015 at 10:11:34PM +0300, Tomas Winkler wrote:
> the variables of type mei_cl_device are now cldev
> the variables of type mei_cl_driver are now cldrv

You are saying what you did, but not why you are doing it.  Renaming
variables for no good reason means I have to reject this patch, sorry.

> the variables of type mei_device are now bus in the
> bus layer context

What do you mean by this?

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 0/3] ARM: rockchip: fix the SMP

[Heiko Stübner]

Hi Caesar,

Am Dienstag, 9. Juni 2015, 17:49:56 schrieb Caesar Wang:
> Verified on url =
>
> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-> 
> 3.14 Tested by 179200 cycles are pass with CPU up/dowm test scripts.

I've applied this series to my soc branch for 4.3 ... it's a bit late for 
trying to cram this into 4.2. I've also added a Cc stable@ tag for patch1


Heiko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Patch RFC 2/2] tracing: gpio: add Kconfig option for enabling/disabling trace events

[Tal Shorer]

Add a new options to gpio Kconfig, CONFIG_GPIO_TRACING, that is used
for enabling/disabling compilation of gpio function trace events.

Signed-off-by: Tal Shorer 
---
 drivers/gpio/Kconfig| 6 ++
 include/trace/events/gpio.h | 4 
 2 files changed, 10 insertions(+)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index caefe80..1480a22 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -88,6 +88,12 @@ config GPIO_SYSFS
 config GPIO_GENERIC
tristate
 
+config GPIO_TRACING
+   bool "gpio tracing"
+   depends on TRACING
+   help
+ Enable tracing for gpio subsystem
+
 # put drivers in the right section, in alphabetical order
 
 # This symbol is selected by both I2C and SPI expanders
diff --git a/include/trace/events/gpio.h b/include/trace/events/gpio.h
index 927a8ad..09af636 100644
--- a/include/trace/events/gpio.h
+++ b/include/trace/events/gpio.h
@@ -1,6 +1,10 @@
 #undef TRACE_SYSTEM
 #define TRACE_SYSTEM gpio
 
+#ifndef CONFIG_GPIO_TRACING
+#define NOTRACE
+#endif
+
 #if !defined(_TRACE_GPIO_H) || defined(TRACE_HEADER_MULTI_READ)
 #define _TRACE_GPIO_H
 
-- 
2.2.2

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

[Patch RFC 1/2] tracing: allow disabling compilation of specific trace systems

[Tal Shorer]

Allow a trace events header file to disable compilation of its
trace events by defining the preprocessor macro NOTRACE.

This could be done, for example, according to a Kconfig option.

Signed-off-by: Tal Shorer 
---
 include/linux/tracepoint.h   | 6 +++---
 include/trace/define_trace.h | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
index a5f7f3e..c869f84 100644
--- a/include/linux/tracepoint.h
+++ b/include/linux/tracepoint.h
@@ -111,7 +111,7 @@ extern void syscall_unregfunc(void);
 #define TP_ARGS(args...)   args
 #define TP_CONDITION(args...)  args
 
-#ifdef CONFIG_TRACEPOINTS
+#if defined(CONFIG_TRACEPOINTS) && !defined(NOTRACE)
 
 /*
  * it_func[0] is never NULL because there is at least one element in the array
@@ -234,7 +234,7 @@ extern void syscall_unregfunc(void);
 #define EXPORT_TRACEPOINT_SYMBOL(name) \
EXPORT_SYMBOL(__tracepoint_##name)
 
-#else /* !CONFIG_TRACEPOINTS */
+#else /* !(defined(CONFIG_TRACEPOINTS) && !defined(NOTRACE)) */
 #define __DECLARE_TRACE(name, proto, args, cond, data_proto, data_args) \
static inline void trace_##name(proto)  \
{ } \
@@ -266,7 +266,7 @@ extern void syscall_unregfunc(void);
 #define EXPORT_TRACEPOINT_SYMBOL_GPL(name)
 #define EXPORT_TRACEPOINT_SYMBOL(name)
 
-#endif /* CONFIG_TRACEPOINTS */
+#endif /* defined(CONFIG_TRACEPOINTS) && !defined(NOTRACE) */
 
 #ifdef CONFIG_TRACING
 /**
diff --git a/include/trace/define_trace.h b/include/trace/define_trace.h
index 02e1003..e847fd7 100644
--- a/include/trace/define_trace.h
+++ b/include/trace/define_trace.h
@@ -86,7 +86,7 @@
 #undef DECLARE_TRACE
 #define DECLARE_TRACE(name, proto, args)
 
-#ifdef CONFIG_EVENT_TRACING
+#if defined(CONFIG_EVENT_TRACING) && !defined(NOTRACE)
 #include 
 #endif
 
-- 
2.2.2

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

[Patch RFC 0/2] tracing: allow disabling compilation of specific trace systems

[Tal Shorer]

Currently, enabling CONFIG_TRACING on a system comes as all-or-nothing: either
tracepoints for all subsystems are compiled (with CONFIG_TRACING) or none of
them do (without it).

This caused me an unacceptable performance penalty (obviously SOME penalty was
expected, but not one so severe) which made me revert the changes in
configuration.

The first patch in this series modifies the files that actually define the
tracepoint to look for a preprocessor macro NOTRACE and define nops (as if
CONFIG_TRACING was not set) instead of them.

The second patch provides an example of how I see this working, with the gpio
subsystem as the example for absolutely no reason.
If this idea is deemed worth the time by the community, I'll create patches for
the other subsystems.

Tal Shorer (2):
  tracing: allow disabling compilation of specific trace systems
  tracing: gpio: add Kconfig option for enabling/disabling trace events

 drivers/gpio/Kconfig | 6 ++
 include/linux/tracepoint.h   | 6 +++---
 include/trace/define_trace.h | 2 +-
 include/trace/events/gpio.h  | 4 
 4 files changed, 14 insertions(+), 4 deletions(-)

-- 
2.2.2

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

Re: lockup when C1E and high-resolution timers enabled

[Christoph Fritz]

On Sat, 2015-06-13 at 22:19 +0200, Heinz Diehl wrote:
> On 13.06.2015, Christoph Fritz wrote: 
> 
> >  - add kernel parameter "idle=halt" -> system runs fine
> >  - disable CONFIG_HIGH_RES_TIMERS -> system runs fine
> >  - change motherboard and disable C1E -> system runs fine
> >  - change CPU to AMD Phenom II X6 Processor -> system runs fine
> 
> I encountered quite some C1E related problems with different Gigabyte
> mainboards in the last few years. Try booting with
> acpi_skip_timer_override, it fixed most of those problems for me.
> 

Thanks for your hint, I already tried that: With kernel parameter
'acpi_skip_timer_override' kernel doesn't boot at all.

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

Re: [RFC v1 14/25] genirq: Kill the first parameter 'irq' of irq_flow_handler_t

[Julia Lawall]

On Sat, 13 Jun 2015, Thomas Gleixner wrote:

> On Sat, 13 Jun 2015, Julia Lawall wrote:
> 
> > The following are the cases that require some manual attention, either 
> > because the handler is a local variable or because it is some other kind 
> > of expression.
> 
> yep, found it in the logs already and found a missing search expression:
> 
> |
> gpiochip_set_chained_irqchip@p(e1,e2,e3,\(lih\|ih\|eh\))
> 
> This is really impressive work

Thanks :)

I'll add the above pattern, but I guess you already have the results for 
that case.

julia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC v1 14/25] genirq: Kill the first parameter 'irq' of irq_flow_handler_t

[Thomas Gleixner]

On Sat, 13 Jun 2015, Julia Lawall wrote:

> The following are the cases that require some manual attention, either 
> because the handler is a local variable or because it is some other kind 
> of expression.

yep, found it in the logs already and found a missing search expression:

|
gpiochip_set_chained_irqchip@p(e1,e2,e3,\(lih\|ih\|eh\))

This is really impressive work

Thanks

tglx
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: lockup when C1E and high-resolution timers enabled

[Heinz Diehl]

On 13.06.2015, Christoph Fritz wrote: 

>  - add kernel parameter "idle=halt" -> system runs fine
>  - disable CONFIG_HIGH_RES_TIMERS -> system runs fine
>  - change motherboard and disable C1E -> system runs fine
>  - change CPU to AMD Phenom II X6 Processor -> system runs fine

I encountered quite some C1E related problems with different Gigabyte
mainboards in the last few years. Try booting with
acpi_skip_timer_override, it fixed most of those problems for me.

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

Re: [RFC v1 14/25] genirq: Kill the first parameter 'irq' of irq_flow_handler_t

[Julia Lawall]

The following are the cases that require some manual attention, either 
because the handler is a local variable or because it is some other kind 
of expression.

julia

Local variable: arch/x86/kernel/apic/io_apic.c:932 hdl
Local variable: arch/sparc/kernel/leon_kernel.c:232 flow_handler
Local variable: arch/sparc/kernel/leon_kernel.c:257 flow_handler
Local variable: arch/powerpc/platforms/52xx/mpc52xx_pic.c:199 handler
Local variable: arch/powerpc/platforms/52xx/mpc52xx_pic.c:364 hndlr
Local variable: arch/powerpc/sysdev/qe_lib/qe_ic.c:377 high_handler
Local variable: arch/powerpc/sysdev/qe_lib/qe_ic.c:372 low_handler
Local variable: arch/mips/cavium-octeon/octeon-irq.c:69 handler
Local variable: arch/mips/alchemy/common/irq.c:494 handler
Local variable: arch/mips/alchemy/common/irq.c:706 hdl
Local variable: arch/blackfin/mach-common/ints-priority.c:693 handle
Local variable: arch/tile/kernel/irq.c:239 handle
Local variable: arch/m68k/kernel/ints.c:124 handle
Local variable: drivers/irqchip/irq-clps711x.c:152 handler
Local variable: drivers/gpio/gpio-ep93xx.c:211 handler
Local variable: drivers/gpio/gpiolib.c:447 parent_handler
Local variable: drivers/pinctrl/intel/pinctrl-cherryview.c:1328 handler
Local variable: kernel/irq/irqdomain.c:946 handler
Local variable: kernel/irq/irqdomain.c:1251 handler
Local variable: kernel/irq/chip.c:787 handle
Arbitrary expression: arch/ia64/kernel/iosapic.c:613 trigger == IOSAPIC_EDGE ? 
handle_edge_irq : handle_level_irq
Arbitrary expression: arch/powerpc/sysdev/mpic.c:1669 & mpic_cascade
Arbitrary expression: arch/mips/dec/ioasic-irq.c:111 1 << ( i - base ) & 
IO_IRQ_DMA_INFO ? handle_edge_irq : handle_fasteoi_irq
Arbitrary expression: drivers/irqchip/irq-or1k-pic.c:131 pic -> handle
Arbitrary expression: drivers/iio/industrialio-trigger.c:449 & handle_simple_irq
Arbitrary expression: drivers/gpio/gpio-sta2x11.c:347 ct -> handler
Arbitrary expression: drivers/gpio/gpiolib.c:482 chip -> irq_handler
Arbitrary expression: drivers/pinctrl/samsung/pinctrl-s3c24xx.c:517 handlers [ 
i ]
Arbitrary expression: drivers/pinctrl/samsung/pinctrl-s3c64xx.c:734 
s3c64xx_eint0_handlers [ i ]
Arbitrary expression: drivers/staging/iio/iio_dummy_evgen.c:89 & 
handle_simple_irq
Arbitrary expression: kernel/irq/generic-chip.c:461 ct -> handler
Arbitrary expression: kernel/irq/msi.c:167 info -> handler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Attached IBSP Award Letter

[IBSP]

 
Attached International Basic Sciences Programmer (IBSP) Award Letter for Claim
Mr. F. T. Fagebuder

2015 IBSP PROJECT LETTER.pdf
Description: Adobe PDF document

lockup when C1E and high-resolution timers enabled

[Christoph Fritz]

Hi,

 on following computer configuration, I do get hard lockup under heavy
IO-Load (using rsync):

 - CONFIG_HIGH_RES_TIMERS=y
 - CPU: AMD FX(tm)-8350 Eight-Core Processor (family 0x15 model 0x2)
 - Motherboard: 'GA-970A-UD3P (rev. 1.0)' AMD 970/SB950
 - BIOS: C1E enabled (on 'GA-970A-UD3P' there is no disable option)
 - Kernels: 4.1.0-rc6, 4.0.x, 3.16.x

Tests:
 - add kernel parameter "idle=halt" -> system runs fine
 - disable CONFIG_HIGH_RES_TIMERS -> system runs fine
 - change motherboard and disable C1E -> system runs fine
 - change CPU to AMD Phenom II X6 Processor -> system runs fine


$ cat /sys/devices/system/cpu/modalias 
cpu:type:x86,ven0002fam0015mod0002:
feature:,,0001,0002,0003,0004,0005,0006,0007,0008,0009,000B,000C,
000D,000E,000F,0010,0011,0013,0017,0018,0019,001A,001C,0020,0021,0022,
0023,0024,0025,0026,0027,0028,0029,002B,002C,002D,002E,002F,0030,0031,
0034,0036,0037,0038,0039,003A,003B,003D,0064,0068,006E,0070,0071,0074,
0075,0078,007A,007C,0080,0081,0083,0089,008C,008D,0093,0094,0097,0099,
009A,009B,009C,009D,00C0,00C1,00C2,00C3,00C4,00C5,00C6,00C7,00C8,00C9,
00CA,00CB,00CC,00CD,00CF,00D0,00D1,00D3,00D5,00D6,00D7,00D8,00E1,00E2,
00E8,0105,0106,0107,0108,0109,010A,010B,010C,010D,010E,010F,0123

$ cat /proc/cpuinfo 
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 21
model   : 2
model name  : AMD FX(tm)-8350 Eight-Core Processor
stepping: 0
microcode   : 0x6000832
cpu MHz : 1400.000
cache size  : 2048 KB
physical id : 0
siblings: 8
core id : 0
cpu cores   : 4
apicid  : 16
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc
extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1
sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic
cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt
lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb arat cpb
hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid
decodeassists pausefilter pfthreshold vmmcall bmi1
bugs: fxsave_leak sysret_ss_attrs
bogomips: 8036.70
TLB size: 1536 4K pages
clflush size: 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro


Any ideas?

Thanks
 -- Christoph



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

[PATCH] ipc: Modify message queue accounting to reflect both total user data and auxiliary kernel data

[Marcus Gelderie]

A while back, the message queue implementation in the kernel was
improved to use btrees to speed up retrieval of messages (commit
d6629859b36). The patch introducing the improved kernel handling of
message queues has, as a by-product, changed the meaning of the 
QSIZE field in the pseudo-file created for the queue. Before, this 
field reflected the size of the user-data in the queue. Since, it 
now also takes kernel data structures into account, this is no no longer
true. For example, if 13 bytes of user data are in the queue, on my 
machine the file reports a size of 61 bytes.

There was some discussion on this topic before (for example
https://lkml.org/lkml/2014/10/1/115). Reporting the size of the
message queue in kernel has its merits, but doing so in the QSIZE
field of the pseudo file corresponding to the queue is a breaking
change. This patch therefore returns the QSIZE field to its original
meaning. At the same time, it introduces a new field QKERSIZE that
reflects the size of the queue in kernel (user data + kernel data).

If the accounting should be improved, I'd be happy to take a look at 
that, too. I would propose to do that in terms of the newly introduced
field.

Signed-off-by: Marcus Gelderie 
---
 ipc/mqueue.c | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/ipc/mqueue.c b/ipc/mqueue.c
index 3aaea7f..7d4c464 100644
--- a/ipc/mqueue.c
+++ b/ipc/mqueue.c
@@ -41,7 +41,7 @@
 
 #define MQUEUE_MAGIC   0x19800202
 #define DIRENT_SIZE20
-#define FILENT_SIZE80
+#define FILENT_SIZE90
 
 #define SEND   0
 #define RECV   1
@@ -82,8 +82,12 @@ struct mqueue_inode_info {
/* for tasks waiting for free space and messages, respectively */
struct ext_wait_queue e_wait_q[2];
 
-   unsigned long qsize; /* size of queue in memory (sum of all msgs) */
-};
+   /* size of queue in memory (sum of all msgs plus kernel
+* data structures) */
+   unsigned long qsize;
+
+   /* size of user data in the queue (sum of all msgs) */
+   unsigned long q_usersize; };
 
 static const struct inode_operations mqueue_dir_inode_operations;
 static const struct file_operations mqueue_file_operations;
@@ -151,6 +155,7 @@ static int msg_insert(struct msg_msg *msg, struct 
mqueue_inode_info *info)
 insert_msg:
info->attr.mq_curmsgs++;
info->qsize += msg->m_ts;
+   info->q_usersize += msg->m_ts;
list_add_tail(>m_list, >msg_list);
return 0;
 }
@@ -210,6 +215,7 @@ try_again:
}
info->attr.mq_curmsgs--;
info->qsize -= msg->m_ts;
+   info->q_usersize -= msg->m_ts;
return msg;
 }
 
@@ -246,6 +252,7 @@ static struct inode *mqueue_get_inode(struct super_block 
*sb,
info->notify_owner = NULL;
info->notify_user_ns = NULL;
info->qsize = 0;
+   info->q_usersize = 0;
info->user = NULL;  /* set when all is ok */
info->msg_tree = RB_ROOT;
info->node_cache = NULL;
@@ -491,13 +498,14 @@ static ssize_t mqueue_read_file(struct file *filp, char 
__user *u_data,
 
spin_lock(>lock);
snprintf(buffer, sizeof(buffer),
-   "QSIZE:%-10lu NOTIFY:%-5d SIGNO:%-5d NOTIFY_PID:%-6d\n",
-   info->qsize,
+   "QSIZE:%-10lu NOTIFY:%-5d SIGNO:%-5d NOTIFY_PID:%-6d 
QKERSIZE:%-10lu\n",
+   info->q_usersize,
info->notify_owner ? info->notify.sigev_notify : 0,
(info->notify_owner &&
 info->notify.sigev_notify == SIGEV_SIGNAL) ?
info->notify.sigev_signo : 0,
-   pid_vnr(info->notify_owner));
+   pid_vnr(info->notify_owner),
+   info->qsize);
spin_unlock(>lock);
buffer[sizeof(buffer)-1] = '\0';
 
-- 
2.4.3

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

Re: [PATCH 02/12] x86/mm/hotplug: Remove pgd_list use from the memory hotplug code

[Oleg Nesterov]

On 06/13, Ingo Molnar wrote:
>
> @@ -169,29 +169,40 @@ void sync_global_pgds(unsigned long start, unsigned 
> long end, int removed)
>
>   for (address = start; address <= end; address += PGDIR_SIZE) {
>   const pgd_t *pgd_ref = pgd_offset_k(address);
> - struct page *page;
> + struct task_struct *g, *p;
>
>   /*
> -  * When it is called after memory hot remove, pgd_none()
> -  * returns true. In this case (removed == 1), we must clear
> -  * the PGD entries in the local PGD level page.
> +  * When this function is called after memory hot remove,
> +  * pgd_none() already returns true, but only the reference
> +  * kernel PGD has been cleared, not the process PGDs.
> +  *
> +  * So clear the affected entries in every process PGD as well:
>*/
>   if (pgd_none(*pgd_ref) && !removed)
>   continue;
>
> - spin_lock(_lock);
> - list_for_each_entry(page, _list, lru) {
> + spin_lock(_lock); /* Implies rcu_read_lock() for the task 
> list iteration: */
 ^^^

Hmm, but it doesn't if PREEMPT_RCU? No, no, I do not pretend I understand
how it actually works ;) But, say, rcu_check_callbacks() can be called from
irq and since spin_lock() doesn't increment current->rcu_read_lock_nesting
this can lead to rcu_preempt_qs()?

> + for_each_process_thread(g, p) {
> + struct mm_struct *mm;
>   pgd_t *pgd;
>   spinlock_t *pgt_lock;
>
> - pgd = (pgd_t *)page_address(page) + pgd_index(address);
> - /* the pgt_lock only for Xen */
> - pgt_lock = _page_get_mm(page)->page_table_lock;
> + task_lock(p);
> + mm = p->mm;
> + if (!mm) {
> + task_unlock(p);
> + continue;
> + }

Again, you can simplify this code and avoid for_each_process_thread() if
you use for_each_process() + find_lock_task_mm().

Oleg.

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

Re: [PATCH] gpio / ACPI: Add label to the gpio request

[Tobias Diedrich]

Mika Westerberg wrote:
> On Thu, Jun 11, 2015 at 02:08:22AM +0200, Tobias Diedrich wrote:
> > In create_gpio_led only the legacy pass propagates the label by passing it 
> > into
> > devm_gpio_request_one.
> > 
> > On the newer devicetree/acpi path the label is lost as far as the GPIO
> > subsystem goes (it is only retained as name in struct gpio_led.
> > 
> > Amend devm_get_gpiod_from_child to also pass the label into the GPIO layer, 
> > so
> > it will show up in /sys/kernel/debug/gpio, so instead of:
> > 
> > GPIOs 288-511, platform/PRP0001:00, AMD SBX00:
> >  gpio-477 (?   ) out hi
> >  gpio-478 (?   ) out lo
> >  gpio-479 (?   ) out hi
> > 
> > we get the much nicer output:
> > 
> > GPIOs 288-511, platform/PRP0001:00, AMD SBX00:
> >  gpio-477 (led1) out hi
> >  gpio-478 (led2) out lo
> >  gpio-479 (led3) out hi
> 
> I wonder if we can just put the con_id there?

leds-gpio doesn't seem to set con_id:
  led.gpiod = devm_get_gpiod_from_child(dev, NULL, child);

> > Signed-off-by: Tobias Diedrich 
> > ---
> >  drivers/gpio/devres.c | 6 +-
> >  drivers/gpio/gpiolib.c| 6 --
> >  include/linux/gpio/consumer.h | 3 ++-
> >  3 files changed, 11 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpio/devres.c b/drivers/gpio/devres.c
> > index 07ba823..089db97 100644
> > --- a/drivers/gpio/devres.c
> > +++ b/drivers/gpio/devres.c
> > @@ -103,13 +103,17 @@ struct gpio_desc *__must_check 
> > __devm_gpiod_get_index(struct device *dev,
> >  {
> > struct gpio_desc **dr;
> > struct gpio_desc *desc;
> > +   const char *label = NULL;
> >  
> > dr = devres_alloc(devm_gpiod_release, sizeof(struct gpio_desc *),
> >   GFP_KERNEL);
> > if (!dr)
> > return ERR_PTR(-ENOMEM);
> >  
> > -   desc = gpiod_get_index(dev, con_id, idx, flags);
> > +   if (fwnode_property_present(child, "label"))
> > +   fwnode_property_read_string(child, "label", );
> 
> This binding needs to be documented, I suppose.
> 
> But then again, does it really describe the hardware? We already have
> names like "linux,label" in the bindings but as far as I understand
> adding such things is not recommended.

Strange, this shouldn't even have compiled, botched the merge to git
HEAD.  Apparently my compile test didn't end up including this file.
This was supposed to go into devm_get_gpiod_from_child.

At least gpio-keys-polled and gpio-leds both use "label" and "gpios",
but I suppose that might not be true for all users of
devm_get_gpiod_from_child.

> > +
> > +   desc = gpiod_get_index(dev, con_id, idx, flags, label);
> > if (IS_ERR(desc)) {
> > devres_free(dr);
> > return desc;
> > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> > index 6bc612b..fb2be68 100644
> > --- a/drivers/gpio/gpiolib.c
> > +++ b/drivers/gpio/gpiolib.c
> > @@ -2017,6 +2017,7 @@ EXPORT_SYMBOL_GPL(__gpiod_get_index);
> >   * fwnode_get_named_gpiod - obtain a GPIO from firmware node
> >   * @fwnode:handle of the firmware node
> >   * @propname:  name of the firmware property representing the GPIO
> > + * @label: optional label for the GPIO
> >   *
> >   * This function can be used for drivers that get their configuration
> >   * from firmware.
> > @@ -2028,7 +2029,8 @@ EXPORT_SYMBOL_GPL(__gpiod_get_index);
> >   * In case of error an ERR_PTR() is returned.
> >   */
> >  struct gpio_desc *fwnode_get_named_gpiod(struct fwnode_handle *fwnode,
> > -const char *propname)
> > +const char *propname,
> > +const char *label)
> >  {
> > struct gpio_desc *desc = ERR_PTR(-ENODEV);
> > bool active_low = false;
> > @@ -2056,7 +2058,7 @@ struct gpio_desc *fwnode_get_named_gpiod(struct 
> > fwnode_handle *fwnode,
> > if (IS_ERR(desc))
> > return desc;
> >  
> > -   ret = gpiod_request(desc, NULL);
> > +   ret = gpiod_request(desc, label);
> > if (ret)
> > return ERR_PTR(ret);
> >  
> > diff --git a/include/linux/gpio/consumer.h b/include/linux/gpio/consumer.h
> > index 3a7c9ff..ef7d322 100644
> > --- a/include/linux/gpio/consumer.h
> > +++ b/include/linux/gpio/consumer.h
> > @@ -134,7 +134,8 @@ int desc_to_gpio(const struct gpio_desc *desc);
> >  struct fwnode_handle;
> >  
> >  struct gpio_desc *fwnode_get_named_gpiod(struct fwnode_handle *fwnode,
> > -const char *propname);
> > +const char *propname,
> > +const char *label);
> >  struct gpio_desc *devm_get_gpiod_from_child(struct device *dev,
> > const char *con_id,
> > struct fwnode_handle *child);
> > -- 
> > 2.1.4

-- 
Tobias  PGP: 

[char-misc-next 15/17] mei: bus: simplify how we build nfc bus name

[Tomas Winkler]

we will need this simplification when name build will
be just part of the fixup rutine

Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/bus-fixup.c | 116 ---
 drivers/misc/mei/bus.c   |   2 +-
 drivers/misc/mei/mei_dev.h   |   2 +-
 3 files changed, 56 insertions(+), 64 deletions(-)

diff --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/mei/bus-fixup.c
index d4b1cccb5bc1..ec03ecf80d41 100644
--- a/drivers/misc/mei/bus-fixup.c
+++ b/drivers/misc/mei/bus-fixup.c
@@ -145,7 +145,7 @@ struct mei_nfc_dev {
u8 fw_ivn;
u8 vendor_id;
u8 radio_type;
-   char *bus_name;
+   const char *bus_name;
 };
 
 /* UUIDs for NFC F/W clients */
@@ -184,69 +184,30 @@ static void mei_nfc_free(struct mei_nfc_dev *ndev)
kfree(ndev);
 }
 
-static int mei_nfc_build_bus_name(struct mei_nfc_dev *ndev)
-{
-   struct mei_device *bus;
-
-   if (!ndev->cl)
-   return -ENODEV;
-
-   bus = ndev->cl->dev;
-
-   switch (ndev->vendor_id) {
-   case MEI_NFC_VENDOR_INSIDE:
-   switch (ndev->radio_type) {
-   case MEI_NFC_VENDOR_INSIDE_UREAD:
-   ndev->bus_name = "microread";
-   return 0;
-
-   default:
-   dev_err(bus->dev, "Unknown radio type 0x%x\n",
-   ndev->radio_type);
-
-   return -EINVAL;
-   }
-
-   case MEI_NFC_VENDOR_NXP:
-   switch (ndev->radio_type) {
-   case MEI_NFC_VENDOR_NXP_PN544:
-   ndev->bus_name = "pn544";
-   return 0;
-   default:
-   dev_err(bus->dev, "Unknown radio type 0x%x\n",
-   ndev->radio_type);
-
-   return -EINVAL;
-   }
-
-   default:
-   dev_err(bus->dev, "Unknown vendor ID 0x%x\n",
-   ndev->vendor_id);
-
-   return -EINVAL;
-   }
-
-   return 0;
-}
-
-static int mei_nfc_if_version(struct mei_nfc_dev *ndev)
+/**
+ * mei_nfc_if_version - get NFC interface version
+ *
+ * @cl: host client (nfc info)
+ * @ver: NFC interface version to be filled in
+ *
+ * Return: 0 on success; < 0 otherwise
+ */
+static int mei_nfc_if_version(struct mei_cl *cl,
+ struct mei_nfc_if_version *ver)
 {
struct mei_device *bus;
-   struct mei_cl *cl;
-
-   struct mei_nfc_cmd cmd;
+   struct mei_nfc_cmd cmd = {
+   .command = MEI_NFC_CMD_MAINTENANCE,
+   .data_size = 1,
+   .sub_command = MEI_NFC_SUBCMD_IF_VERSION,
+   };
struct mei_nfc_reply *reply = NULL;
-   struct mei_nfc_if_version *version;
size_t if_version_length;
int bytes_recv, ret;
 
-   cl = ndev->cl_info;
bus = cl->dev;
 
-   memset(, 0, sizeof(struct mei_nfc_cmd));
-   cmd.command = MEI_NFC_CMD_MAINTENANCE;
-   cmd.data_size = 1;
-   cmd.sub_command = MEI_NFC_SUBCMD_IF_VERSION;
+   WARN_ON(mutex_is_locked(>device_lock));
 
ret = __mei_cl_send(cl, (u8 *), sizeof(struct mei_nfc_cmd), 1);
if (ret < 0) {
@@ -262,6 +223,7 @@ static int mei_nfc_if_version(struct mei_nfc_dev *ndev)
if (!reply)
return -ENOMEM;
 
+   ret = 0;
bytes_recv = __mei_cl_recv(cl, (u8 *)reply, if_version_length);
if (bytes_recv < 0 || bytes_recv < sizeof(struct mei_nfc_reply)) {
dev_err(bus->dev, "Could not read IF version\n");
@@ -269,17 +231,39 @@ static int mei_nfc_if_version(struct mei_nfc_dev *ndev)
goto err;
}
 
-   version = (struct mei_nfc_if_version *)reply->data;
+   memcpy(ver, reply->data, sizeof(struct mei_nfc_if_version));
 
-   ndev->fw_ivn = version->fw_ivn;
-   ndev->vendor_id = version->vendor_id;
-   ndev->radio_type = version->radio_type;
+   dev_info(bus->dev, "NFC MEI VERSION: IVN 0x%x Vendor ID 0x%x Type 
0x%x\n",
+   ver->fw_ivn, ver->vendor_id, ver->radio_type);
 
 err:
kfree(reply);
return ret;
 }
 
+/**
+ * mei_nfc_radio_name - derive nfc radio name from the interface version
+ *
+ * @ver: NFC radio version
+ *
+ * Return: radio name string
+ */
+static const char *mei_nfc_radio_name(struct mei_nfc_if_version *ver)
+{
+
+   if (ver->vendor_id == MEI_NFC_VENDOR_INSIDE) {
+   if (ver->radio_type == MEI_NFC_VENDOR_INSIDE_UREAD)
+   return "microread";
+   }
+
+   if (ver->vendor_id == MEI_NFC_VENDOR_NXP) {
+   if (ver->radio_type == MEI_NFC_VENDOR_NXP_PN544)
+   return "pn544";
+   }
+
+   return NULL;
+}
+
 static void mei_nfc_init(struct work_struct *work)
 {
struct mei_device *bus;
@@ -287,6 +271,7 @@ static void mei_nfc_init(struct work_struct *work)
struct mei_nfc_dev *ndev;
struct mei_cl 

[char-misc-next 06/17] mei: bus: add kdoc for device attribute functions

[Tomas Winkler]

1. Rename uevent handler to mei_cl_device_uevent
2. Add kdoc for uevent and mod alias functions

Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/bus.c | 43 +++
 1 file changed, 39 insertions(+), 4 deletions(-)

diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index b14662787d7e..201019c5f766 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -462,8 +462,17 @@ static int mei_cl_device_remove(struct device *dev)
return cldrv->remove(cldev);
 }
 
+/**
+ * name_show - client device name sysfs entry
+ *
+ * @dev: device
+ * @a: device attribute
+ * @buf: a buffer to fill
+ *
+ * Return: bytes to read or < 0 on error
+ */
 static ssize_t name_show(struct device *dev, struct device_attribute *a,
-char *buf)
+char *buf)
 {
struct mei_cl_device *cldev = to_mei_cl_device(dev);
size_t len;
@@ -474,8 +483,17 @@ static ssize_t name_show(struct device *dev, struct 
device_attribute *a,
 }
 static DEVICE_ATTR_RO(name);
 
+/**
+ * uuid_show - client uuid sysfs entry
+ *
+ * @dev: device
+ * @a: device attribute
+ * @buf: a buffer to fill
+ *
+ * Return: bytes to read or < 0 on error
+ */
 static ssize_t uuid_show(struct device *dev, struct device_attribute *a,
-char *buf)
+char *buf)
 {
struct mei_cl_device *cldev = to_mei_cl_device(dev);
const uuid_le *uuid = mei_me_cl_uuid(cldev->me_cl);
@@ -487,6 +505,15 @@ static ssize_t uuid_show(struct device *dev, struct 
device_attribute *a,
 }
 static DEVICE_ATTR_RO(uuid);
 
+/**
+ * modalias_show - modalias sysfs entry
+ *
+ * @dev: device
+ * @a: device attribute
+ * @buf: a buffer to fill
+ *
+ * Return: bytes to read or < 0 on error
+ */
 static ssize_t modalias_show(struct device *dev, struct device_attribute *a,
 char *buf)
 {
@@ -509,7 +536,15 @@ static struct attribute *mei_cl_dev_attrs[] = {
 };
 ATTRIBUTE_GROUPS(mei_cl_dev);
 
-static int mei_cl_uevent(struct device *dev, struct kobj_uevent_env *env)
+/**
+ * mei_cl_device_uevent - me client bus uevent handler
+ *
+ * @dev: device
+ * @env: uevent kobject
+ *
+ * Return: 0 on success -ENOMEM on when add_uevent_var fails
+ */
+static int mei_cl_device_uevent(struct device *dev, struct kobj_uevent_env 
*env)
 {
struct mei_cl_device *cldev = to_mei_cl_device(dev);
const uuid_le *uuid = mei_me_cl_uuid(cldev->me_cl);
@@ -533,7 +568,7 @@ static struct bus_type mei_cl_bus_type = {
.match  = mei_cl_device_match,
.probe  = mei_cl_device_probe,
.remove = mei_cl_device_remove,
-   .uevent = mei_cl_uevent,
+   .uevent = mei_cl_device_uevent,
 };
 
 static void mei_cl_dev_release(struct device *dev)
-- 
2.4.2

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

[char-misc-next 16/17] mei: bus: also unregister the driver when removing the device

[Tomas Winkler]

Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/bus.c | 36 ++--
 1 file changed, 34 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index fa3eff216eff..33898bed6209 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -767,11 +767,43 @@ struct mei_cl_device *mei_cl_add_device(struct mei_device 
*bus,
 }
 EXPORT_SYMBOL_GPL(mei_cl_add_device);
 
+/**
+ * mei_cl_bus_dev_stop - stop the driver
+ *
+ * @cldev: me client device
+ */
+static void mei_cl_bus_dev_stop(struct mei_cl_device *cldev)
+{
+   if (cldev->is_added)
+   device_release_driver(>dev);
+}
+
+/**
+ * mei_cl_bus_dev_destroy - destroy me client devices object
+ *
+ * @cldev: me client device
+ */
+static void mei_cl_bus_dev_destroy(struct mei_cl_device *cldev)
+{
+   if (!cldev->is_added)
+   return;
+
+   device_del(>dev);
+
+   cldev->is_added = 0;
+   put_device(>dev);
+}
+
+/**
+ * mei_cl_remove_device - remove a devices form the bus
+ *
+ * @cldev: me client device
+ */
 void mei_cl_remove_device(struct mei_cl_device *cldev)
 {
-   device_unregister(>dev);
+   mei_cl_bus_dev_stop(cldev);
+   mei_cl_bus_dev_destroy(cldev);
 }
-EXPORT_SYMBOL_GPL(mei_cl_remove_device);
 
 int __mei_cl_driver_register(struct mei_cl_driver *cldrv, struct module *owner)
 {
-- 
2.4.2

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

[char-misc-next 17/17] mei: bus: link client devices instead of host clients

[Tomas Winkler]

MEI bus was designed around nfc and was hard to extend.
Instead of the hard coded way of adding the devices on the mei bus
we scan the whole me client list and create a device for each
eligible me client (mei_cl_bus_rescan); currently we support
only clients with single connection and fixed address clients.
NFC radio name detection is run as a fixup routine

The patch replaces handling the device list based on struct me_cl
to device list based on me_cl_devices. The creating a connection
is pushed from the device creation time to device enablement.

Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/bus-fixup.c | 288 ++-
 drivers/misc/mei/bus.c   | 213 ++--
 drivers/misc/mei/client.c|   9 +-
 drivers/misc/mei/init.c  |   2 -
 drivers/misc/mei/mei_dev.h   |  11 +-
 5 files changed, 187 insertions(+), 336 deletions(-)

diff --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/mei/bus-fixup.c
index ec03ecf80d41..3e536ca85f7d 100644
--- a/drivers/misc/mei/bus-fixup.c
+++ b/drivers/misc/mei/bus-fixup.c
@@ -30,6 +30,11 @@
 #define MEI_UUID_NFC_INFO UUID_LE(0xd2de1625, 0x382d, 0x417d, \
0x48, 0xa4, 0xef, 0xab, 0xba, 0x8a, 0x12, 0x06)
 
+static const uuid_le mei_nfc_info_guid = MEI_UUID_NFC_INFO;
+
+#define MEI_UUID_NFC_HCI UUID_LE(0x0bb17a78, 0x2a8e, 0x4c50, \
+   0x94, 0xd4, 0x50, 0x26, 0x67, 0x23, 0x77, 0x5c)
+
 #define MEI_UUID_ANY NULL_UUID_LE
 
 /**
@@ -93,68 +98,10 @@ struct mei_nfc_if_version {
u8 radio_type;
 } __packed;
 
-struct mei_nfc_connect {
-   u8 fw_ivn;
-   u8 vendor_id;
-} __packed;
-
-struct mei_nfc_connect_resp {
-   u8 fw_ivn;
-   u8 vendor_id;
-   u16 me_major;
-   u16 me_minor;
-   u16 me_hotfix;
-   u16 me_build;
-} __packed;
-
-struct mei_nfc_hci_hdr {
-   u8 cmd;
-   u8 status;
-   u16 req_id;
-   u32 reserved;
-   u16 data_size;
-} __packed;
 
 #define MEI_NFC_CMD_MAINTENANCE 0x00
-#define MEI_NFC_CMD_HCI_SEND 0x01
-#define MEI_NFC_CMD_HCI_RECV 0x02
-
-#define MEI_NFC_SUBCMD_CONNECT0x00
 #define MEI_NFC_SUBCMD_IF_VERSION 0x01
 
-#define MEI_NFC_HEADER_SIZE 10
-
-/**
- * struct mei_nfc_dev - NFC mei device
- *
- * @me_cl: NFC me client
- * @cl: NFC host client
- * @cl_info: NFC info host client
- * @init_work: perform connection to the info client
- * @fw_ivn: NFC Interface Version Number
- * @vendor_id: NFC manufacturer ID
- * @radio_type: NFC radio type
- * @bus_name: bus name
- *
- */
-struct mei_nfc_dev {
-   struct mei_me_client *me_cl;
-   struct mei_cl *cl;
-   struct mei_cl *cl_info;
-   struct work_struct init_work;
-   u8 fw_ivn;
-   u8 vendor_id;
-   u8 radio_type;
-   const char *bus_name;
-};
-
-/* UUIDs for NFC F/W clients */
-const uuid_le mei_nfc_guid = UUID_LE(0x0bb17a78, 0x2a8e, 0x4c50,
-0x94, 0xd4, 0x50, 0x26,
-0x67, 0x23, 0x77, 0x5c);
-
-static const uuid_le mei_nfc_info_guid = MEI_UUID_NFC_INFO;
-
 /* Vendors */
 #define MEI_NFC_VENDOR_INSIDE 0x00
 #define MEI_NFC_VENDOR_NXP0x01
@@ -163,27 +110,6 @@ static const uuid_le mei_nfc_info_guid = MEI_UUID_NFC_INFO;
 #define MEI_NFC_VENDOR_INSIDE_UREAD 0x00
 #define MEI_NFC_VENDOR_NXP_PN5440x01
 
-static void mei_nfc_free(struct mei_nfc_dev *ndev)
-{
-   if (!ndev)
-   return;
-
-   if (ndev->cl) {
-   list_del(>cl->device_link);
-   mei_cl_unlink(ndev->cl);
-   kfree(ndev->cl);
-   }
-
-   if (ndev->cl_info) {
-   list_del(>cl_info->device_link);
-   mei_cl_unlink(ndev->cl_info);
-   kfree(ndev->cl_info);
-   }
-
-   mei_me_cl_put(ndev->me_cl);
-   kfree(ndev);
-}
-
 /**
  * mei_nfc_if_version - get NFC interface version
  *
@@ -264,177 +190,86 @@ static const char *mei_nfc_radio_name(struct 
mei_nfc_if_version *ver)
return NULL;
 }
 
-static void mei_nfc_init(struct work_struct *work)
+/**
+ * mei_nfc - The nfc fixup function. The function retrieves nfc radio
+ *name and set is as device attribute so we can load
+ *the proper device driver for it
+ *
+ * @cldev: me client device (nfc)
+ */
+static void mei_nfc(struct mei_cl_device *cldev)
 {
struct mei_device *bus;
-   struct mei_cl_device *cldev;
-   struct mei_nfc_dev *ndev;
-   struct mei_cl *cl_info;
-   struct mei_me_client *me_cl_info;
-   struct mei_nfc_if_version version;
+   struct mei_cl *cl;
+   struct mei_me_client *me_cl = NULL;
+   struct mei_nfc_if_version ver;
+   const char *radio_name = NULL;
+   int ret;
 
-   ndev = container_of(work, struct mei_nfc_dev, init_work);
+   bus = cldev->bus;
 
-   cl_info = ndev->cl_info;
-   bus = cl_info->dev;
+   dev_dbg(bus->dev, "running hook %s: %pUl match=%d\n",
+   __func__, mei_me_cl_uuid(cldev->me_cl), 

[char-misc-next 08/17] mei: bus: report if event registration failed

[Tomas Winkler]

Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/bus.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index 9069d89b93d7..5bd16d4417bb 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -255,6 +255,8 @@ void mei_cl_bus_rx_event(struct mei_cl *cl)
 int mei_cl_register_event_cb(struct mei_cl_device *cldev,
  mei_cl_event_cb_t event_cb, void *context)
 {
+   int ret;
+
if (cldev->event_cb)
return -EALREADY;
 
@@ -263,7 +265,9 @@ int mei_cl_register_event_cb(struct mei_cl_device *cldev,
cldev->event_context = context;
INIT_WORK(>event_work, mei_bus_event_work);
 
-   mei_cl_read_start(cldev->cl, 0, NULL);
+   ret = mei_cl_read_start(cldev->cl, 0, NULL);
+   if (ret && ret != -EBUSY)
+   return ret;
 
return 0;
 }
-- 
2.4.2

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

[char-misc-next 13/17] mei: bus: enable running fixup routines before device registration

[Tomas Winkler]

We split the device registration to allocation and device struct
initialization , setup, and final registration.
This way we can run fixups and quirks during the setup stage on
an initialized device. If a fixup sets do_match flag to false
the device won't be registered on the bus.

Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/bus-fixup.c | 30 +++
 drivers/misc/mei/bus.c   | 91 
 drivers/misc/mei/mei_dev.h   |  2 +-
 include/linux/mei_cl_bus.h   |  4 ++
 4 files changed, 111 insertions(+), 16 deletions(-)

diff --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/mei/bus-fixup.c
index 9bd76cda1608..2c02a338f63b 100644
--- a/drivers/misc/mei/bus-fixup.c
+++ b/drivers/misc/mei/bus-fixup.c
@@ -20,12 +20,15 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
 #include "mei_dev.h"
 #include "client.h"
 
+#define MEI_UUID_ANY NULL_UUID_LE
+
 struct mei_nfc_cmd {
u8 command;
u8 status;
@@ -411,4 +414,31 @@ void mei_nfc_host_exit(struct mei_device *bus)
mutex_unlock(>device_lock);
 }
 
+#define MEI_FIXUP(_uuid, _hook) { _uuid, _hook }
+
+static struct mei_fixup {
+
+   const uuid_le uuid;
+   void (*hook)(struct mei_cl_device *cldev);
+} mei_fixups[] = {};
+
+/**
+ * mei_cl_dev_fixup - run fixup handlers
+ *
+ * @cldev: me client device
+ */
+void mei_cl_dev_fixup(struct mei_cl_device *cldev)
+{
+   struct mei_fixup *f;
+   const uuid_le *uuid = mei_me_cl_uuid(cldev->me_cl);
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(mei_fixups); i++) {
+
+   f = _fixups[i];
+   if (uuid_le_cmp(f->uuid, MEI_UUID_ANY) == 0 ||
+   uuid_le_cmp(f->uuid, *uuid) == 0)
+   f->hook(cldev);
+   }
+}
 
diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index 592f2a1651bf..8ff824950597 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -435,6 +435,9 @@ static int mei_cl_device_match(struct device *dev, struct 
device_driver *drv)
if (!cldev)
return 0;
 
+   if (!cldev->do_match)
+   return 0;
+
if (!cldrv || !cldrv->id_table)
return 0;
 
@@ -660,6 +663,76 @@ struct mei_cl *mei_cl_bus_find_cl_by_uuid(struct 
mei_device *bus,
return NULL;
 }
 
+/**
+ * mei_cl_dev_alloc - initialize and allocate mei client device
+ *
+ * @bus: mei device
+ * @me_cl: me client
+ *
+ * Return: allocated device structur or NULL on allocation failure
+ */
+static struct mei_cl_device *mei_cl_dev_alloc(struct mei_device *bus,
+ struct mei_me_client *me_cl)
+{
+   struct mei_cl_device *cldev;
+
+   cldev = kzalloc(sizeof(struct mei_cl_device), GFP_KERNEL);
+   if (!cldev)
+   return NULL;
+
+   device_initialize(>dev);
+   cldev->dev.parent = bus->dev;
+   cldev->dev.bus= _cl_bus_type;
+   cldev->dev.type   = _cl_device_type;
+   cldev->bus= mei_dev_bus_get(bus);
+   cldev->me_cl  = mei_me_cl_get(me_cl);
+   cldev->is_added   = 0;
+   INIT_LIST_HEAD(>bus_list);
+
+   return cldev;
+}
+
+/**
+ * mei_cl_dev_setup - setup me client device
+ *run fix up routines and set the device name
+ *
+ * @bus: mei device
+ * @cldev: me client device
+ *
+ * Return: true if the device is eligible for enumeration
+ */
+static bool mei_cl_dev_setup(struct mei_device *bus,
+struct mei_cl_device *cldev)
+{
+   cldev->do_match = 1;
+   mei_cl_dev_fixup(cldev);
+
+   if (cldev->do_match)
+   dev_set_name(>dev, "mei:%s:%pUl",
+cldev->name, mei_me_cl_uuid(cldev->me_cl));
+
+   return cldev->do_match == 1;
+}
+
+/**
+ * mei_cl_bus_dev_add - add me client devices
+ *
+ * @cldev: me client device
+ *
+ * Return: 0 on success; < 0 on failre
+ */
+static int mei_cl_bus_dev_add(struct mei_cl_device *cldev)
+{
+   int ret;
+
+   dev_dbg(cldev->bus->dev, "adding %pUL\n", mei_me_cl_uuid(cldev->me_cl));
+   ret = device_add(>dev);
+   if (!ret)
+   cldev->is_added = 1;
+
+   return ret;
+}
+
 struct mei_cl_device *mei_cl_add_device(struct mei_device *bus,
struct mei_me_client *me_cl,
struct mei_cl *cl,
@@ -668,28 +741,16 @@ struct mei_cl_device *mei_cl_add_device(struct mei_device 
*bus,
struct mei_cl_device *cldev;
int status;
 
-   cldev = kzalloc(sizeof(struct mei_cl_device), GFP_KERNEL);
+   cldev = mei_cl_dev_alloc(bus, me_cl);
if (!cldev)
return NULL;
 
-   cldev->me_cl = mei_me_cl_get(me_cl);
-   if (!cldev->me_cl) {
-   kfree(cldev);
-   return NULL;
-   }
-
cldev->cl = cl;
-   cldev->dev.parent = bus->dev;
-   cldev->dev.bus = _cl_bus_type;
-   cldev->dev.type = _cl_device_type;
-   

[char-misc-next 12/17] mei: bus: add me client device list infrastructure

[Tomas Winkler]

Instead of holding the list of host clients (me_cl)
we want to keep the list me client devices (mei_cl_device)
This way we may postpone the creating of connection only when needed
Add list head to mei_cl_device and cl_bus_lock
Add bus_added flag to the me client (mei_me_client) to track if
the appropriate mei_cl_device was already created and is_added
flag to mei_cl_device to track if it was already added to the list
across the bus rescans

Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/bus.c | 1 +
 drivers/misc/mei/init.c| 1 +
 drivers/misc/mei/mei_dev.h | 6 --
 include/linux/mei_cl_bus.h | 4 
 4 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index 2bed403b87f7..592f2a1651bf 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -683,6 +683,7 @@ struct mei_cl_device *mei_cl_add_device(struct mei_device 
*bus,
cldev->dev.bus = _cl_bus_type;
cldev->dev.type = _cl_device_type;
cldev->bus  = mei_dev_bus_get(bus);
+   INIT_LIST_HEAD(>bus_list);
 
strlcpy(cldev->name, name, sizeof(cldev->name));
 
diff --git a/drivers/misc/mei/init.c b/drivers/misc/mei/init.c
index 64331a5ce990..6fbd13c10381 100644
--- a/drivers/misc/mei/init.c
+++ b/drivers/misc/mei/init.c
@@ -392,6 +392,7 @@ void mei_device_init(struct mei_device *dev,
INIT_LIST_HEAD(>me_clients);
mutex_init(>device_lock);
init_rwsem(>me_clients_rwsem);
+   mutex_init(>cl_bus_lock);
init_waitqueue_head(>wait_hw_ready);
init_waitqueue_head(>wait_pg);
init_waitqueue_head(>wait_hbm_start);
diff --git a/drivers/misc/mei/mei_dev.h b/drivers/misc/mei/mei_dev.h
index 2a1ab7958734..4ce11c98b61a 100644
--- a/drivers/misc/mei/mei_dev.h
+++ b/drivers/misc/mei/mei_dev.h
@@ -178,7 +178,7 @@ struct mei_fw_status {
  * @client_id: me client id
  * @mei_flow_ctrl_creds: flow control credits
  * @connect_count: number connections to this client
- * @reserved: reserved
+ * @bus_added: added to bus
  */
 struct mei_me_client {
struct list_head list;
@@ -187,7 +187,7 @@ struct mei_me_client {
u8 client_id;
u8 mei_flow_ctrl_creds;
u8 connect_count;
-   u8 reserved;
+   u8 bus_added;
 };
 
 
@@ -446,6 +446,7 @@ const char *mei_pg_state_str(enum mei_pg_state state);
  * @init_work   : work item for the device init
  * @reset_work  : work item for the device reset
  *
+ * @cl_bus_lock : client bus list lock
  * @devices : mei client bus list
  *
  * @dbgfs_dir   : debugfs mei root directory
@@ -541,6 +542,7 @@ struct mei_device {
struct work_struct init_work;
struct work_struct reset_work;
 
+   struct mutex cl_bus_lock;
struct list_head devices;
 
 #if IS_ENABLED(CONFIG_DEBUG_FS)
diff --git a/include/linux/mei_cl_bus.h b/include/linux/mei_cl_bus.h
index 4c5c25b3222c..85239138251c 100644
--- a/include/linux/mei_cl_bus.h
+++ b/include/linux/mei_cl_bus.h
@@ -18,6 +18,7 @@ typedef void (*mei_cl_event_cb_t)(struct mei_cl_device 
*device,
  * Drivers for MEI devices will get an mei_cl_device pointer
  * when being probed and shall use it for doing ME bus I/O.
  *
+ * @bus_list: device on the bus list
  * @bus: parent mei device
  * @dev: linux driver model device pointer
  * @me_cl: me client
@@ -28,9 +29,11 @@ typedef void (*mei_cl_event_cb_t)(struct mei_cl_device 
*device,
  * events (e.g. Rx buffer pending) notifications.
  * @event_context: event callback run context
  * @events: Events bitmask sent to the driver.
+ * @is_added: device is already scanned
  * @priv_data: client private data
  */
 struct mei_cl_device {
+   struct list_head bus_list;
struct mei_device *bus;
struct device dev;
 
@@ -42,6 +45,7 @@ struct mei_cl_device {
mei_cl_event_cb_t event_cb;
void *event_context;
unsigned long events;
+   unsigned int is_added:1;
 
void *priv_data;
 };
-- 
2.4.2

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

[char-misc-next 11/17] mei: bus: add reference to bus device in struct mei_cl_client

[Tomas Winkler]

Add reference to the bus device (mei_device) for easier access.
To ensures that referencing cldev->bus is valid during cldev life time
we increase the bus ref counter on a client device creation and drop it
on the device release.

Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/bus.c | 17 +
 include/linux/mei_cl_bus.h |  3 +++
 2 files changed, 20 insertions(+)

diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index ee0a9e50ac76..2bed403b87f7 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -616,6 +616,20 @@ static struct bus_type mei_cl_bus_type = {
.uevent = mei_cl_device_uevent,
 };
 
+static struct mei_device *mei_dev_bus_get(struct mei_device *bus)
+{
+   if (bus)
+   get_device(bus->dev);
+
+   return bus;
+}
+
+static void mei_dev_bus_put(struct mei_device *bus)
+{
+   if (bus)
+   put_device(bus->dev);
+}
+
 static void mei_cl_dev_release(struct device *dev)
 {
struct mei_cl_device *cldev = to_mei_cl_device(dev);
@@ -624,6 +638,7 @@ static void mei_cl_dev_release(struct device *dev)
return;
 
mei_me_cl_put(cldev->me_cl);
+   mei_dev_bus_put(cldev->bus);
kfree(cldev);
 }
 
@@ -667,6 +682,7 @@ struct mei_cl_device *mei_cl_add_device(struct mei_device 
*bus,
cldev->dev.parent = bus->dev;
cldev->dev.bus = _cl_bus_type;
cldev->dev.type = _cl_device_type;
+   cldev->bus  = mei_dev_bus_get(bus);
 
strlcpy(cldev->name, name, sizeof(cldev->name));
 
@@ -676,6 +692,7 @@ struct mei_cl_device *mei_cl_add_device(struct mei_device 
*bus,
if (status) {
dev_err(bus->dev, "Failed to register MEI device\n");
mei_me_cl_put(cldev->me_cl);
+   mei_dev_bus_put(bus);
kfree(cldev);
return NULL;
}
diff --git a/include/linux/mei_cl_bus.h b/include/linux/mei_cl_bus.h
index a16b1f9c1aca..4c5c25b3222c 100644
--- a/include/linux/mei_cl_bus.h
+++ b/include/linux/mei_cl_bus.h
@@ -6,6 +6,7 @@
 #include 
 
 struct mei_cl_device;
+struct mei_device;
 
 typedef void (*mei_cl_event_cb_t)(struct mei_cl_device *device,
   u32 events, void *context);
@@ -17,6 +18,7 @@ typedef void (*mei_cl_event_cb_t)(struct mei_cl_device 
*device,
  * Drivers for MEI devices will get an mei_cl_device pointer
  * when being probed and shall use it for doing ME bus I/O.
  *
+ * @bus: parent mei device
  * @dev: linux driver model device pointer
  * @me_cl: me client
  * @cl: mei client
@@ -29,6 +31,7 @@ typedef void (*mei_cl_event_cb_t)(struct mei_cl_device 
*device,
  * @priv_data: client private data
  */
 struct mei_cl_device {
+   struct mei_device *bus;
struct device dev;
 
struct mei_me_client *me_cl;
-- 
2.4.2

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

[char-misc-next 14/17] mei: bus: blacklist clients by number of connections and nfc info client

[Tomas Winkler]

Currently we support only clients with single connection
and fixed address clients so all other clients are blacklisted

Blacklist nfc info client which is only used for retrieval
of the NFC radio version

Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/bus-fixup.c | 42 ++
 1 file changed, 38 insertions(+), 4 deletions(-)

diff --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/mei/bus-fixup.c
index 2c02a338f63b..d4b1cccb5bc1 100644
--- a/drivers/misc/mei/bus-fixup.c
+++ b/drivers/misc/mei/bus-fixup.c
@@ -27,8 +27,41 @@
 #include "mei_dev.h"
 #include "client.h"
 
+#define MEI_UUID_NFC_INFO UUID_LE(0xd2de1625, 0x382d, 0x417d, \
+   0x48, 0xa4, 0xef, 0xab, 0xba, 0x8a, 0x12, 0x06)
+
 #define MEI_UUID_ANY NULL_UUID_LE
 
+/**
+ * number_of_connections - determine whether an client be on the bus
+ *according number of connections
+ *We support only clients:
+ *   1. with single connection
+ *   2. and fixed clients (max_number_of_connections == 0)
+ *
+ * @cldev: me clients device
+ */
+static void number_of_connections(struct mei_cl_device *cldev)
+{
+   dev_dbg(>dev, "running hook %s on %pUl\n",
+   __func__, mei_me_cl_uuid(cldev->me_cl));
+
+   if (cldev->me_cl->props.max_number_of_connections > 1)
+   cldev->do_match = 0;
+}
+
+/**
+ * blacklist - blacklist a client from the bus
+ *
+ * @cldev: me clients device
+ */
+static void blacklist(struct mei_cl_device *cldev)
+{
+   dev_dbg(>dev, "running hook %s on %pUl\n",
+   __func__, mei_me_cl_uuid(cldev->me_cl));
+   cldev->do_match = 0;
+}
+
 struct mei_nfc_cmd {
u8 command;
u8 status;
@@ -120,9 +153,7 @@ const uuid_le mei_nfc_guid = UUID_LE(0x0bb17a78, 0x2a8e, 
0x4c50,
 0x94, 0xd4, 0x50, 0x26,
 0x67, 0x23, 0x77, 0x5c);
 
-static const uuid_le mei_nfc_info_guid = UUID_LE(0xd2de1625, 0x382d, 0x417d,
-   0x48, 0xa4, 0xef, 0xab,
-   0xba, 0x8a, 0x12, 0x06);
+static const uuid_le mei_nfc_info_guid = MEI_UUID_NFC_INFO;
 
 /* Vendors */
 #define MEI_NFC_VENDOR_INSIDE 0x00
@@ -420,7 +451,10 @@ static struct mei_fixup {
 
const uuid_le uuid;
void (*hook)(struct mei_cl_device *cldev);
-} mei_fixups[] = {};
+} mei_fixups[] = {
+   MEI_FIXUP(MEI_UUID_ANY, number_of_connections),
+   MEI_FIXUP(MEI_UUID_NFC_INFO, blacklist),
+};
 
 /**
  * mei_cl_dev_fixup - run fixup handlers
-- 
2.4.2

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

[char-misc-next 10/17] mei: bus: revamp probe and remove functions

[Tomas Winkler]

Instead of generating device id on the fly during probing we
find the matching id entry on the device id table.
Get bus the module reference counter so it cannot
be unloaded after the driver has bounded to the client
device

Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/bus.c | 41 ++---
 1 file changed, 30 insertions(+), 11 deletions(-)

diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index 1a9c8d7906c9..ee0a9e50ac76 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -445,30 +445,49 @@ static int mei_cl_device_match(struct device *dev, struct 
device_driver *drv)
return 0;
 }
 
+/**
+ * mei_cl_device_probe - bus probe function
+ *
+ * @dev: device
+ *
+ * Return:  0 on success; < 0 otherwise
+ */
 static int mei_cl_device_probe(struct device *dev)
 {
-   struct mei_cl_device *cldev = to_mei_cl_device(dev);
+   struct mei_cl_device *cldev;
struct mei_cl_driver *cldrv;
-   struct mei_cl_device_id id;
+   const struct mei_cl_device_id *id;
+
+   cldev = to_mei_cl_device(dev);
+   cldrv = to_mei_cl_driver(dev->driver);
 
if (!cldev)
return 0;
 
-   cldrv = to_mei_cl_driver(dev->driver);
if (!cldrv || !cldrv->probe)
return -ENODEV;
 
-   dev_dbg(dev, "Device probe\n");
+   id = mei_cl_device_find(cldev, cldrv);
+   if (!id)
+   return -ENODEV;
 
-   strlcpy(id.name, cldev->name, sizeof(id.name));
+   __module_get(THIS_MODULE);
 
-   return cldrv->probe(cldev, );
+   return cldrv->probe(cldev, id);
 }
 
+/**
+ * mei_cl_device_remove - remove device from the bus
+ *
+ * @dev: device
+ *
+ * Return:  0 on success; < 0 otherwise
+ */
 static int mei_cl_device_remove(struct device *dev)
 {
struct mei_cl_device *cldev = to_mei_cl_device(dev);
struct mei_cl_driver *cldrv;
+   int ret = 0;
 
if (!cldev || !dev->driver)
return 0;
@@ -479,13 +498,13 @@ static int mei_cl_device_remove(struct device *dev)
}
 
cldrv = to_mei_cl_driver(dev->driver);
-   if (!cldrv->remove) {
-   dev->driver = NULL;
+   if (cldrv->remove)
+   ret = cldrv->remove(cldev);
 
-   return 0;
-   }
+   module_put(THIS_MODULE);
+   dev->driver = NULL;
+   return ret;
 
-   return cldrv->remove(cldev);
 }
 
 /**
-- 
2.4.2

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

[char-misc-next 07/17] mei: bus: don't enable events implicitly in device enable

[Tomas Winkler]

Always call mei_cl_register_event_cb explicitly so the events
are enabled only when needed. The nfc driver is already using
it that way so no need for further changes.

Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/bus.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index 201019c5f766..9069d89b93d7 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -331,9 +331,6 @@ int mei_cl_enable_device(struct mei_cl_device *cldev)
 
mutex_unlock(>device_lock);
 
-   if (cldev->event_cb)
-   mei_cl_read_start(cldev->cl, 0, NULL);
-
return 0;
 }
 EXPORT_SYMBOL_GPL(mei_cl_enable_device);
-- 
2.4.2

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

[char-misc-next 09/17] mei: bus: simplify device matching

[Tomas Winkler]

mei_cl_device_match now calls mei_cl_device_find that returns
the matching device id in the device id table

Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/bus.c | 63 +++---
 1 file changed, 44 insertions(+), 19 deletions(-)

diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index 5bd16d4417bb..1a9c8d7906c9 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -384,39 +384,64 @@ out:
 }
 EXPORT_SYMBOL_GPL(mei_cl_disable_device);
 
-static int mei_cl_device_match(struct device *dev, struct device_driver *drv)
+/**
+ * mei_cl_device_find - find matching entry in the driver id table
+ *
+ * @cldev: me client device
+ * @cldrv: me client driver
+ *
+ * Return: id on success; NULL if no id is matching
+ */
+static const
+struct mei_cl_device_id *mei_cl_device_find(struct mei_cl_device *cldev,
+   struct mei_cl_driver *cldrv)
 {
-   struct mei_cl_device *cldev = to_mei_cl_device(dev);
-   struct mei_cl_driver *cldrv = to_mei_cl_driver(drv);
const struct mei_cl_device_id *id;
const uuid_le *uuid;
-   const char *name;
-
-   if (!cldev)
-   return 0;
 
uuid = mei_me_cl_uuid(cldev->me_cl);
-   name = cldev->name;
-
-   if (!cldrv || !cldrv->id_table)
-   return 0;
 
id = cldrv->id_table;
-
while (uuid_le_cmp(NULL_UUID_LE, id->uuid)) {
-
if (!uuid_le_cmp(*uuid, id->uuid)) {
-   if (id->name[0]) {
-   if (!strncmp(name, id->name, sizeof(id->name)))
-   return 1;
-   } else {
-   return 1;
-   }
+
+   if (!cldev->name[0])
+   return id;
+
+   if (!strncmp(cldev->name, id->name, sizeof(id->name)))
+   return id;
}
 
id++;
}
 
+   return NULL;
+}
+
+/**
+ * mei_cl_device_match  - device match function
+ *
+ * @dev: device
+ * @drv: driver
+ *
+ * Return:  1 if matching device was found 0 otherwise
+ */
+static int mei_cl_device_match(struct device *dev, struct device_driver *drv)
+{
+   struct mei_cl_device *cldev = to_mei_cl_device(dev);
+   struct mei_cl_driver *cldrv = to_mei_cl_driver(drv);
+   const struct mei_cl_device_id *found_id;
+
+   if (!cldev)
+   return 0;
+
+   if (!cldrv || !cldrv->id_table)
+   return 0;
+
+   found_id = mei_cl_device_find(cldev, cldrv);
+   if (found_id)
+   return 1;
+
return 0;
 }
 
-- 
2.4.2

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

[char-misc-next 00/17] revamp mei bus

[Tomas Winkler]

MEI bus was designed around nfc and was hard to extend.
Instead of hard coded way of adding the devices on the mei bus
we scan whole me client list and create a device for each
eligible me client


Tomas Winkler (17):
  MAINTAINERS: mei: add mei_cl_bus.h to maintained file list
  mei: bus: fix drivers and devices names confusion
  mei: bus: rename device_list to simple devices
  mei: bus: rename nfc.c to bus-fixup.c
  mei: bus: move driver api functions at the start of the file
  mei: bus: add kdoc for device attribute functions
  mei: bus: don't enable events implicitly in device enable
  mei: bus: report if event registration failed
  mei: bus: simplify device matching
  mei: bus: revamp probe and remove functions
  mei: bus: add reference to bus device in struct mei_cl_client
  mei: bus: add me client device list infrastructure
  mei: bus: enable running fixup routines before device registration
  mei: bus: blacklist clients by number of connections and nfc info
client
  mei: bus: simplify how we build nfc bus name
  mei: bus: also unregister the driver when removing the device
  mei: bus: link client devices instead of host clients

 MAINTAINERS  |   1 +
 drivers/misc/mei/Makefile|   2 +-
 drivers/misc/mei/bus-fixup.c | 306 +
 drivers/misc/mei/bus.c   | 994 ---
 drivers/misc/mei/client.c|   9 +-
 drivers/misc/mei/init.c  |   5 +-
 drivers/misc/mei/mei_dev.h   |  30 +-
 drivers/misc/mei/nfc.c   | 414 --
 include/linux/mei_cl_bus.h   |  11 +
 9 files changed, 986 insertions(+), 786 deletions(-)
 create mode 100644 drivers/misc/mei/bus-fixup.c
 delete mode 100644 drivers/misc/mei/nfc.c

-- 
2.4.2

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

[char-misc-next 03/17] mei: bus: rename device_list to simple devices

[Tomas Winkler]

Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/bus.c | 4 ++--
 drivers/misc/mei/init.c| 2 +-
 drivers/misc/mei/mei_dev.h | 5 ++---
 drivers/misc/mei/nfc.c | 4 ++--
 4 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index a40be68dd7aa..2ae7e521f029 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -203,7 +203,7 @@ struct mei_cl *mei_cl_bus_find_cl_by_uuid(struct mei_device 
*bus,
 {
struct mei_cl *cl;
 
-   list_for_each_entry(cl, >device_list, device_link) {
+   list_for_each_entry(cl, >devices, device_link) {
if (cl->cldev && cl->cldev->me_cl &&
!uuid_le_cmp(uuid, *mei_me_cl_uuid(cl->cldev->me_cl)))
return cl;
@@ -557,7 +557,7 @@ void mei_cl_bus_remove_devices(struct mei_device *bus)
struct mei_cl *cl, *next;
 
mutex_lock(>device_lock);
-   list_for_each_entry_safe(cl, next, >device_list, device_link) {
+   list_for_each_entry_safe(cl, next, >devices, device_link) {
if (cl->cldev)
mei_cl_remove_device(cl->cldev);
 
diff --git a/drivers/misc/mei/init.c b/drivers/misc/mei/init.c
index 94514b2c7a50..64331a5ce990 100644
--- a/drivers/misc/mei/init.c
+++ b/drivers/misc/mei/init.c
@@ -388,7 +388,7 @@ void mei_device_init(struct mei_device *dev,
 {
/* setup our list array */
INIT_LIST_HEAD(>file_list);
-   INIT_LIST_HEAD(>device_list);
+   INIT_LIST_HEAD(>devices);
INIT_LIST_HEAD(>me_clients);
mutex_init(>device_lock);
init_rwsem(>me_clients_rwsem);
diff --git a/drivers/misc/mei/mei_dev.h b/drivers/misc/mei/mei_dev.h
index bc65fb42aea9..2a1ab7958734 100644
--- a/drivers/misc/mei/mei_dev.h
+++ b/drivers/misc/mei/mei_dev.h
@@ -446,7 +446,7 @@ const char *mei_pg_state_str(enum mei_pg_state state);
  * @init_work   : work item for the device init
  * @reset_work  : work item for the device reset
  *
- * @device_list : mei client bus list
+ * @devices : mei client bus list
  *
  * @dbgfs_dir   : debugfs mei root directory
  *
@@ -541,8 +541,7 @@ struct mei_device {
struct work_struct init_work;
struct work_struct reset_work;
 
-   /* List of bus devices */
-   struct list_head device_list;
+   struct list_head devices;
 
 #if IS_ENABLED(CONFIG_DEBUG_FS)
struct dentry *dbgfs_dir;
diff --git a/drivers/misc/mei/nfc.c b/drivers/misc/mei/nfc.c
index 51a864a2b2b5..9bd76cda1608 100644
--- a/drivers/misc/mei/nfc.c
+++ b/drivers/misc/mei/nfc.c
@@ -357,7 +357,7 @@ int mei_nfc_host_init(struct mei_device *bus, struct 
mei_me_client *me_cl)
goto err;
}
 
-   list_add_tail(_info->device_link, >device_list);
+   list_add_tail(_info->device_link, >devices);
 
ndev->cl_info = cl_info;
 
@@ -367,7 +367,7 @@ int mei_nfc_host_init(struct mei_device *bus, struct 
mei_me_client *me_cl)
goto err;
}
 
-   list_add_tail(>device_link, >device_list);
+   list_add_tail(>device_link, >devices);
 
ndev->cl = cl;
 
-- 
2.4.2

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

[char-misc-next 01/17] MAINTAINERS: mei: add mei_cl_bus.h to maintained file list

[Tomas Winkler]

mei_cl_bus.h was overlooked when we added the mei bus

Signed-off-by: Tomas Winkler 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f6ba62c3db82..c58e2f0612e7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5279,6 +5279,7 @@ M:Tomas Winkler 
 L: linux-kernel@vger.kernel.org
 S: Supported
 F: include/uapi/linux/mei.h
+F: include/linux/mei_cl_bus.h
 F: drivers/misc/mei/*
 F: Documentation/misc-devices/mei/*
 
-- 
2.4.2

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

[char-misc-next 05/17] mei: bus: move driver api functions at the start of the file

[Tomas Winkler]

To make the file more organize move mei client driver api
to the start of the file and add Kdoc

There are no functional changes in this patch

Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/bus.c | 798 +++--
 1 file changed, 443 insertions(+), 355 deletions(-)

diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index 2ae7e521f029..b14662787d7e 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -30,527 +30,615 @@
 #define to_mei_cl_driver(d) container_of(d, struct mei_cl_driver, driver)
 #define to_mei_cl_device(d) container_of(d, struct mei_cl_device, dev)
 
-static int mei_cl_device_match(struct device *dev, struct device_driver *drv)
+/**
+ * __mei_cl_send - internal client send (write)
+ *
+ * @cl: host client
+ * @buf: buffer to send
+ * @length: buffer length
+ * @blocking: wait for write completion
+ *
+ * Return: written size bytes or < 0 on error
+ */
+ssize_t __mei_cl_send(struct mei_cl *cl, u8 *buf, size_t length,
+   bool blocking)
 {
-   struct mei_cl_device *cldev = to_mei_cl_device(dev);
-   struct mei_cl_driver *cldrv = to_mei_cl_driver(drv);
-   const struct mei_cl_device_id *id;
-   const uuid_le *uuid;
-   const char *name;
-
-   if (!cldev)
-   return 0;
+   struct mei_device *bus;
+   struct mei_cl_cb *cb = NULL;
+   ssize_t rets;
 
-   uuid = mei_me_cl_uuid(cldev->me_cl);
-   name = cldev->name;
+   if (WARN_ON(!cl || !cl->dev))
+   return -ENODEV;
 
-   if (!cldrv || !cldrv->id_table)
-   return 0;
+   bus = cl->dev;
 
-   id = cldrv->id_table;
+   mutex_lock(>device_lock);
+   if (!mei_cl_is_connected(cl)) {
+   rets = -ENODEV;
+   goto out;
+   }
 
-   while (uuid_le_cmp(NULL_UUID_LE, id->uuid)) {
+   /* Check if we have an ME client device */
+   if (!mei_me_cl_is_active(cl->me_cl)) {
+   rets = -ENOTTY;
+   goto out;
+   }
 
-   if (!uuid_le_cmp(*uuid, id->uuid)) {
-   if (id->name[0]) {
-   if (!strncmp(name, id->name, sizeof(id->name)))
-   return 1;
-   } else {
-   return 1;
-   }
-   }
+   if (length > mei_cl_mtu(cl)) {
+   rets = -EFBIG;
+   goto out;
+   }
 
-   id++;
+   cb = mei_cl_alloc_cb(cl, length, MEI_FOP_WRITE, NULL);
+   if (!cb) {
+   rets = -ENOMEM;
+   goto out;
}
 
-   return 0;
+   memcpy(cb->buf.data, buf, length);
+
+   rets = mei_cl_write(cl, cb, blocking);
+
+out:
+   mutex_unlock(>device_lock);
+   if (rets < 0)
+   mei_io_cb_free(cb);
+
+   return rets;
 }
 
-static int mei_cl_device_probe(struct device *dev)
+/**
+ * __mei_cl_recv - internal client receive (read)
+ *
+ * @cl: host client
+ * @buf: buffer to send
+ * @length: buffer length
+ *
+ * Return: read size in bytes of < 0 on error
+ */
+ssize_t __mei_cl_recv(struct mei_cl *cl, u8 *buf, size_t length)
 {
-   struct mei_cl_device *cldev = to_mei_cl_device(dev);
-   struct mei_cl_driver *cldrv;
-   struct mei_cl_device_id id;
-
-   if (!cldev)
-   return 0;
+   struct mei_device *bus;
+   struct mei_cl_cb *cb;
+   size_t r_length;
+   ssize_t rets;
 
-   cldrv = to_mei_cl_driver(dev->driver);
-   if (!cldrv || !cldrv->probe)
+   if (WARN_ON(!cl || !cl->dev))
return -ENODEV;
 
-   dev_dbg(dev, "Device probe\n");
+   bus = cl->dev;
 
-   strlcpy(id.name, cldev->name, sizeof(id.name));
+   mutex_lock(>device_lock);
 
-   return cldrv->probe(cldev, );
-}
+   cb = mei_cl_read_cb(cl, NULL);
+   if (cb)
+   goto copy;
 
-static int mei_cl_device_remove(struct device *dev)
-{
-   struct mei_cl_device *cldev = to_mei_cl_device(dev);
-   struct mei_cl_driver *cldrv;
+   rets = mei_cl_read_start(cl, length, NULL);
+   if (rets && rets != -EBUSY)
+   goto out;
 
-   if (!cldev || !dev->driver)
-   return 0;
+   if (list_empty(>rd_completed) && !waitqueue_active(>rx_wait)) {
 
-   if (cldev->event_cb) {
-   cldev->event_cb = NULL;
-   cancel_work_sync(>event_work);
-   }
+   mutex_unlock(>device_lock);
 
-   cldrv = to_mei_cl_driver(dev->driver);
-   if (!cldrv->remove) {
-   dev->driver = NULL;
+   if (wait_event_interruptible(cl->rx_wait,
+   (!list_empty(>rd_completed)) ||
+   (!mei_cl_is_connected(cl {
 
-   return 0;
+   if (signal_pending(current))
+   return -EINTR;
+   return 

[char-misc-next 04/17] mei: bus: rename nfc.c to bus-fixup.c

[Tomas Winkler]

In nfc.c we just create device name on the mei client bus
we make it more generic in the following patches

Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/Makefile   | 2 +-
 drivers/misc/mei/{nfc.c => bus-fixup.c} | 0
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename drivers/misc/mei/{nfc.c => bus-fixup.c} (100%)

diff --git a/drivers/misc/mei/Makefile b/drivers/misc/mei/Makefile
index 518914a82b83..01447ca21c26 100644
--- a/drivers/misc/mei/Makefile
+++ b/drivers/misc/mei/Makefile
@@ -11,7 +11,7 @@ mei-objs += main.o
 mei-objs += amthif.o
 mei-objs += wd.o
 mei-objs += bus.o
-mei-objs += nfc.o
+mei-objs += bus-fixup.o
 mei-$(CONFIG_DEBUG_FS) += debugfs.o
 
 obj-$(CONFIG_INTEL_MEI_ME) += mei-me.o
diff --git a/drivers/misc/mei/nfc.c b/drivers/misc/mei/bus-fixup.c
similarity index 100%
rename from drivers/misc/mei/nfc.c
rename to drivers/misc/mei/bus-fixup.c
-- 
2.4.2

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

[char-misc-next 02/17] mei: bus: fix drivers and devices names confusion

[Tomas Winkler]

the variables of type mei_cl_device are now cldev
the variables of type mei_cl_driver are now cldrv
the variables of type mei_device are now bus in the
bus layer context

Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/bus.c | 272 ++---
 drivers/misc/mei/mei_dev.h |  12 +-
 drivers/misc/mei/nfc.c |  80 ++---
 3 files changed, 182 insertions(+), 182 deletions(-)

diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index 357b6ae4d207..a40be68dd7aa 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -32,22 +32,22 @@
 
 static int mei_cl_device_match(struct device *dev, struct device_driver *drv)
 {
-   struct mei_cl_device *device = to_mei_cl_device(dev);
-   struct mei_cl_driver *driver = to_mei_cl_driver(drv);
+   struct mei_cl_device *cldev = to_mei_cl_device(dev);
+   struct mei_cl_driver *cldrv = to_mei_cl_driver(drv);
const struct mei_cl_device_id *id;
const uuid_le *uuid;
const char *name;
 
-   if (!device)
+   if (!cldev)
return 0;
 
-   uuid = mei_me_cl_uuid(device->me_cl);
-   name = device->name;
+   uuid = mei_me_cl_uuid(cldev->me_cl);
+   name = cldev->name;
 
-   if (!driver || !driver->id_table)
+   if (!cldrv || !cldrv->id_table)
return 0;
 
-   id = driver->id_table;
+   id = cldrv->id_table;
 
while (uuid_le_cmp(NULL_UUID_LE, id->uuid)) {
 
@@ -68,54 +68,54 @@ static int mei_cl_device_match(struct device *dev, struct 
device_driver *drv)
 
 static int mei_cl_device_probe(struct device *dev)
 {
-   struct mei_cl_device *device = to_mei_cl_device(dev);
-   struct mei_cl_driver *driver;
+   struct mei_cl_device *cldev = to_mei_cl_device(dev);
+   struct mei_cl_driver *cldrv;
struct mei_cl_device_id id;
 
-   if (!device)
+   if (!cldev)
return 0;
 
-   driver = to_mei_cl_driver(dev->driver);
-   if (!driver || !driver->probe)
+   cldrv = to_mei_cl_driver(dev->driver);
+   if (!cldrv || !cldrv->probe)
return -ENODEV;
 
dev_dbg(dev, "Device probe\n");
 
-   strlcpy(id.name, device->name, sizeof(id.name));
+   strlcpy(id.name, cldev->name, sizeof(id.name));
 
-   return driver->probe(device, );
+   return cldrv->probe(cldev, );
 }
 
 static int mei_cl_device_remove(struct device *dev)
 {
-   struct mei_cl_device *device = to_mei_cl_device(dev);
-   struct mei_cl_driver *driver;
+   struct mei_cl_device *cldev = to_mei_cl_device(dev);
+   struct mei_cl_driver *cldrv;
 
-   if (!device || !dev->driver)
+   if (!cldev || !dev->driver)
return 0;
 
-   if (device->event_cb) {
-   device->event_cb = NULL;
-   cancel_work_sync(>event_work);
+   if (cldev->event_cb) {
+   cldev->event_cb = NULL;
+   cancel_work_sync(>event_work);
}
 
-   driver = to_mei_cl_driver(dev->driver);
-   if (!driver->remove) {
+   cldrv = to_mei_cl_driver(dev->driver);
+   if (!cldrv->remove) {
dev->driver = NULL;
 
return 0;
}
 
-   return driver->remove(device);
+   return cldrv->remove(cldev);
 }
 
 static ssize_t name_show(struct device *dev, struct device_attribute *a,
 char *buf)
 {
-   struct mei_cl_device *device = to_mei_cl_device(dev);
+   struct mei_cl_device *cldev = to_mei_cl_device(dev);
size_t len;
 
-   len = snprintf(buf, PAGE_SIZE, "%s", device->name);
+   len = snprintf(buf, PAGE_SIZE, "%s", cldev->name);
 
return (len >= PAGE_SIZE) ? (PAGE_SIZE - 1) : len;
 }
@@ -124,8 +124,8 @@ static DEVICE_ATTR_RO(name);
 static ssize_t uuid_show(struct device *dev, struct device_attribute *a,
 char *buf)
 {
-   struct mei_cl_device *device = to_mei_cl_device(dev);
-   const uuid_le *uuid = mei_me_cl_uuid(device->me_cl);
+   struct mei_cl_device *cldev = to_mei_cl_device(dev);
+   const uuid_le *uuid = mei_me_cl_uuid(cldev->me_cl);
size_t len;
 
len = snprintf(buf, PAGE_SIZE, "%pUl", uuid);
@@ -137,12 +137,12 @@ static DEVICE_ATTR_RO(uuid);
 static ssize_t modalias_show(struct device *dev, struct device_attribute *a,
 char *buf)
 {
-   struct mei_cl_device *device = to_mei_cl_device(dev);
-   const uuid_le *uuid = mei_me_cl_uuid(device->me_cl);
+   struct mei_cl_device *cldev = to_mei_cl_device(dev);
+   const uuid_le *uuid = mei_me_cl_uuid(cldev->me_cl);
size_t len;
 
len = snprintf(buf, PAGE_SIZE, "mei:%s:" MEI_CL_UUID_FMT ":",
-   device->name, MEI_CL_UUID_ARGS(uuid->b));
+   cldev->name, MEI_CL_UUID_ARGS(uuid->b));
 
return (len >= PAGE_SIZE) ? (PAGE_SIZE - 1) : len;
 }
@@ -158,17 +158,17 @@ ATTRIBUTE_GROUPS(mei_cl_dev);
 
 static int 

why do we need vmalloc_sync_all?

[Oleg Nesterov]

I didn't read v2 yet, but I'd like to ask a question.

Why do we need vmalloc_sync_all()?

It has a single caller, register_die_notifier() which calls it without
any explanation. IMO, this needs a comment at least.

I am not sure I understand the changelog in 101f12af correctly, but
at first glance vmalloc_sync_all() is no longer needed at least on x86,
do_page_fault() no longer does notify_die(DIE_PAGE_FAULT). And btw
DIE_PAGE_FAULT has no users. DIE_MNI too...

Perhaps we can simply kill it on x86?

As for other architectures I am not sure. arch/tile implements
vmalloc_sync_all() and uses notify_die() in do_page_fault().

And in any case register_die_notifier()->vmalloc_sync() looks strange.
If (say) arch/tile needs this to fix the problem with modules, perhaps
it should do vmalloc_sync_all() in do_init_module() paths?

Oleg.

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

[GIT pull] irq fix for 4.1

[Thomas Gleixner]

Linus,

please pull the latest irq-urgent-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
irq-urgent-for-linus

A single fix for an off by one bug in the sunxi irqchip driver.

Thanks,

tglx

-->
Axel Lin (1):
  irqchip: sunxi-nmi: Fix off-by-one error in irq iterator


 drivers/irqchip/irq-sunxi-nmi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-sunxi-nmi.c b/drivers/irqchip/irq-sunxi-nmi.c
index 4a9ce5b50c5b..6b2b582433bd 100644
--- a/drivers/irqchip/irq-sunxi-nmi.c
+++ b/drivers/irqchip/irq-sunxi-nmi.c
@@ -104,7 +104,7 @@ static int sunxi_sc_nmi_set_type(struct irq_data *data, 
unsigned int flow_type)
irqd_set_trigger_type(data, flow_type);
irq_setup_alt_chip(data, flow_type);
 
-   for (i = 0; i <= gc->num_ct; i++, ct++)
+   for (i = 0; i < gc->num_ct; i++, ct++)
if (ct->type & flow_type)
ctrl_off = ct->regs.type;
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] gitignore: Add MIPS vmlinux.32 to the list

[Florian Fainelli]

2015-04-24 10:27 GMT-07:00 Florian Fainelli :
> MIPS64 kernels builds will produce a vmlinux.32 kernel image for
> compatibility, ignore them.

Ralf, Michal, which one of you should take this patch?

>
> Signed-off-by: Florian Fainelli 
> ---
>  .gitignore | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/.gitignore b/.gitignore
> index acb6afe6b7a3..6c7ca7a2d52e 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -43,6 +43,7 @@ Module.symvers
>  /TAGS
>  /linux
>  /vmlinux
> +/vmlinux.32
>  /vmlinux-gdb.py
>  /vmlinuz
>  /System.map
> --
> 2.1.0
>



-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] driver/clk/clk-si5338: Add common clock framework driver for si5338

[York Sun]

SI5338 is a programmable clock generator. It has 4 sets of inputs,
PLL, multisynth and dividers to make 4 outputs. This driver splits
them into multiple clocks to comply with common clock framework.

See Documentation/devicetree/bindings/clock/silabs,si5338.txt for
details.

Signed-off-by: York Sun 
CC: Mike Turquette 
CC: Sebastian Hesselbarth 
CC: Guenter Roeck 
CC: Andrey Filippov  
---
 .../devicetree/bindings/clock/silabs,si5338.txt|  173 +
 drivers/clk/Kconfig|   14 +-
 drivers/clk/Makefile   |1 +
 drivers/clk/clk-si5338.c   | 3653 
 drivers/clk/clk-si5338.h   |  305 ++
 include/dt-bindings/clock/clk-si5338.h |   69 +
 include/linux/platform_data/si5338.h   |   49 +
 7 files changed, 4263 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/clock/silabs,si5338.txt
 create mode 100644 drivers/clk/clk-si5338.c
 create mode 100644 drivers/clk/clk-si5338.h
 create mode 100644 include/dt-bindings/clock/clk-si5338.h
 create mode 100644 include/linux/platform_data/si5338.h

diff --git a/Documentation/devicetree/bindings/clock/silabs,si5338.txt 
b/Documentation/devicetree/bindings/clock/silabs,si5338.txt
new file mode 100644
index 000..aeeb81d
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/silabs,si5338.txt
@@ -0,0 +1,173 @@
+Binding for Silicon Labs Si5338 programmable i2c clock generator.
+
+Reference
+[1] Si5338 Data Sheet
+http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5338.pdf
+
+The Si5338 is a programmable i2c clock generators with up to 4 output
+clocks. It has 4 sets of possible input clocks
+
+IN1/IN2: differential
+IN3: single-ended
+IN4: single-ended
+IN5/IN6: differential
+
+Additionally, IN1/IN2 can be used as XTAL with different setting.
+The clock tree looks like below (without support of zero-delay)
+
+
+  IN1/IN2 IN3 IN4 IN5/IN6
+ | |   | |
+   --| |   | |
+   | | |   | |
+   | \ /   \ /
+   |  \   / \   /
+   |   \ /   \ /
+ XTAL REFCLKFBCLK
+   |   |  \ /   |
+   |   |   \   /|
+   |   | DIVREFCLK DIVFBCLK |
+   |   | \   /  |
+   |   |  \ /   |
+   |   |   \   /|
+   |   |PLL |
+   |   |  / | | \   |
+   |   | /  / \  \  |
+   |   |/  /   \  \ |
+   |   |   /   |   |   \|
+   |   |   |   |   |   ||
+   |   |  MS0 MS1 MS2 MS3   |
+   |   |   |   |   |   ||
+
+   OUT0  OUT1  OUT2  OUT3
+
+The output clock can choose from any of the above clock as its source, with
+exceptions: MS1 can only be used for OUT1, MS2 can only be used for OUT2, MS3
+can only be used for OUT3.
+
+==I2C device node==
+
+Required properties:
+- compatible: shall be "silabs,si5338".
+- reg: i2c device address, shall be 0x60, 0x61, 0x70, or 0x71
+- #clock-cells: shall be set to 1 for multiple outputs
+- clocks: list of parent clocks in the order of , , , , 

+  Note, xtal and in1/2 are mutually exclusive. Only one can be set.
+- #address-cells: shall be set to 1.
+- #size-cells: shall be set to 0.
+
+Optional properties if not set by platform driver:
+- silab,ref-source: source of refclk, valid value is defined as
+   #define SI5338_REF_SRC_CLKIN12  0
+   #define SI5338_REF_SRC_CLKIN3   1
+   #define SI5338_REF_SRC_XTAL 4
+- silab,fb-source:  source of fbclk, valid value is defined as
+   #define SI5338_FB_SRC_CLKIN42
+   #define SI5338_FB_SRC_CLKIN56   3
+   #define SI5338_FB_SRC_NOCLK 5
+- silabs,pll-source: source of pll, valid value is defined as
+   #define SI5338_PFD_IN_REF_REFCLK   0
+   #define SI5338_PFD_IN_REF_FBCLK1
+   #define SI5338_PFD_IN_REF_DIVREFCLK2
+   #define SI5338_PFD_IN_REF_DIVFBCLK 3
+   #define SI5338_PFD_IN_REF_XOCLK4
+   #define SI5338_PFD_IN_REF_NOCLK5
+- silabs,pll-master: Pick one MS (0, 1, 2, or 3) to allow chaning PLL rate
+   This is arbitrary since MS0/1/2/3 share one PLL.  PLL can be calculated
+   backward to satisfy MS.
+
+==Child nodes==
+
+Each of the clock outputs can be configured individually by
+using a child node to the I2C device node. If a child node for a clock
+output is not set, platform driver has to set up.
+
+Required child node properties:
+- reg: number of clock output.
+
+Optional child node properties:
+- silabs,drive-config: the configuration of output driver
+  The valid value list is long. Please refer to soruce code.
+- silabs,clock-source: source clock of the output divider
+   #define SI5338_OUT_MUX_FBCLK0
+   #define 

Re: [PATCH 2/2] iio: proximity: sx9500: Fix proximity value

[Daniel Baluta]

On Sat, Jun 13, 2015 at 9:21 PM, Jonathan Cameron  wrote:
> On 12/06/15 08:40, Vlad Dogaru wrote:
>> On Thu, Jun 11, 2015 at 06:49:34PM +0300, Daniel Baluta wrote:
>>> Because of the ABI confusion proximity value exposed by SX9500
>>> was inverted.
>>>
>>> Signed-off-by: Daniel Baluta 
>>
>> Reviewed-by: Vlad Dogaru 
>>
>> Sorry for causing the confusion, it was the only proximity sensor I had
>> encountered to date.
> Greg,
>
> I've cc'd you to let you know that this fix causes an ABI change for
> one driver.  Technically that driver actually matched with the current 
> documentation,
> just the documentation was misleading and lots of drivers have ended up with
> the reverse interpretation (question was whether proximity values get larger
> or smaller as you get nearer).
>
> Anyhow, given timing I doubt the pull request will reach you until after the
> merge window.  I am also going to mark this for stable to cover the 4.0 and 
> 4.1
> kernels that have this driver in them.
>
> Hope that's fine!
>
> Applied to the fixes-togreg branch of iio.git
>
> Daniel, thanks for clearing this mess up and checking through all the drivers
> and datasheets to figure out it was only this one!

You are welcome. Also, lets not forget that as mentioned in the cover letter
there is still one driver that needs to be fixed. That is stk3310,
where the fix is not
trivial, but I have already talked with Tiberiu and he will take care of it.

thanks,
Daniel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] iio:adc: XADC: Set offset explicitly to zero on voltage channels

[Jonathan Cameron]

On 11/06/15 09:22, Gergely Imreh wrote:
> The Xilinx XADC driver has both a temperature channel and 8 voltage
> channels. The voltage channels have no offset, but actually were still
> set the same offset as the temperature channel. This did not cause
> problems in /sys/bus/iio/ but can cause problems with other drivers
> using iio data. For example iio-hwmon did return wrong voltage values
> because of the offset.
> 
> Change tested with the Parallella board.
> 
> Signed-off-by: Gergely Imreh 
Well spotted on the bug, but I think we are better off fixing this at the
true source of the problem which is in drivers/iio/inkern.c 
iio_convert_raw_to_processed_unlocked which does a call to 
iio_channel_read(chan, , NULL, IIO_CHAN_INFO_OFFSET) then uses
the error return to check if the offset parameter is available. It should
be checking that before making this call with a call to iio_channel_has_info.

I don't suppose you could prepare a patch fixing that as you found the problem?

If not I can fix it up sometime if no one else beats me to it.

Thanks

Jonathan
> ---
>  drivers/iio/adc/xilinx-xadc-core.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/iio/adc/xilinx-xadc-core.c 
> b/drivers/iio/adc/xilinx-xadc-core.c
> index ab52be2..36efab7 100644
> --- a/drivers/iio/adc/xilinx-xadc-core.c
> +++ b/drivers/iio/adc/xilinx-xadc-core.c
> @@ -877,9 +877,17 @@ static int xadc_read_raw(struct iio_dev *indio_dev,
>   return -EINVAL;
>   }
>   case IIO_CHAN_INFO_OFFSET:
> - /* Only the temperature channel has an offset */
> - *val = -((273150 << 12) / 503975);
> - return IIO_VAL_INT;
> + switch (chan->type) {
> + case IIO_VOLTAGE:
> + *val = 0;
> + return IIO_VAL_INT;
> + case IIO_TEMP:
> + /* Only the temperature channel has an offset */
> + *val = -((273150 << 12) / 503975);
> + return IIO_VAL_INT;
> + default:
> + return -EINVAL;
> + }
>   case IIO_CHAN_INFO_SAMP_FREQ:
>   ret = xadc_read_adc_reg(xadc, XADC_REG_CONF2, );
>   if (ret)
> 

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

Re: [PATCH 00/21] On-demand device registration

[Alexander Holler]

Am 12.06.2015 um 13:36 schrieb Alexander Holler:

Am 12.06.2015 um 13:19 schrieb Alexander Holler:

Am 12.06.2015 um 09:25 schrieb Linus Walleij:

On Thu, Jun 11, 2015 at 6:40 PM, Alexander Holler
 wrote:

Am 11.06.2015 um 14:30 schrieb Linus Walleij:



Certainly it is possible to create deadlocks in this scenario, but the
scope is not to create an ubreakable system.


IAnd what happens if you run into a deadlock? Do you print "you've
lost, try
changing your kernel config" in some output hidden by a
splash-screen? ;)


Sorry it sounds like a blanket argument, the fact that there are
mutexes in the kernel makes it possible to deadlock, it doesn't
mean we don't use mutexes. Some programming problems are
just like such.


I'm not talking about specific deadlocks through mutexes. I'm talking
about what happens when driver A needs driver B which needs driver A.
How do you recognise and handle that with your instrumented on-demand
device initialization? Such a circular dependency might happen by just
adding a new fucntion call or by changing the kernel configuration. And
with the on-demand stuff, the possibility that the developer introducing
this new (maybe optional) call will never hit such a circular dependency
is high. So you will end up with a never ending stream of problem
reports whenever someone introduced such a circular dependecy without
having noticed it.

And to come back to specific deadlocks, if you are extending function
calls from something former simple to something which might initialize a
whole bunch of drivers, needing maybe seconds, I wouldn't say this is a
blanket argument, but a real thread.


Keep in mind, that the possibility that a function call ends up with
initializing a whole bunch of other drivers, is not determined
statically, but depends on the configuration and runtime behaviour of
the actual system the on-demand stuff actually happens.

E.g. if driver A is faster one system that driver B, the whole bunch of
drivers might become initialized by a call in driver A. But if driver B
was faster on the developers system (or the system is configured to
first init driver B), than the whole bunch of drivers might have become
initialized by driver B on the developers system. Thus he never might
have hit a possible problem when the whole bunch of drivers got
initialized in driver A.

That means it isn't always a good idea to create dynamic systems (like
on-demand device initialization), because it's very hard to foresee and
correctly handle their runtime behaviour.


And because you've said that "problem space is a bit convoluted" and I 
disagree, here's a summary from my point of view:


1. All the necessary information (dependencies between drivers) already 
exists at compile time. The set of dependencies between drivers might 
become smaller by configuration, but will not become larger. So there 
should be NO need to collect them at runtime, e.g. by instrumenting 
function calls. I've described the problems I see with that above. I've 
choosen DT as source of dependencies because it offers an easy 
accessible and almost complete set of dependencies. I just had to add 
some type information to the dtb in order to identify the dependencies 
(phandles). But other ways to collect the dependencies would work too. 
Even the most simple way to add a static list of dependencies to each 
driver (which later on might be automated by some more clever stuff than 
adding them manually) would do the trick.


2. The problem to sort a set of nodes (drivers) with dependencies is 
solved since a long time and almost any developers uses it regularly in 
form of make. And everyone who used make -jN knows that the possible 
parallel initialization of drivers I've talked about, is already solved too.


3. In order to initialize the drivers in some specific order, their 
initcalls must be identified. I've offered a possible solution to that 
without much changes, but many other, even better ways, are possible 
too. It just depends on how much you want to change and on how much of 
these changes you will be able to feed into mainline kernel (which 
depends on your connections/relations inside the core kernel crew). E.g. 
instead of still just relying on one-dimensional arrays with (anonymous) 
pointers to initcalls, a multidimensional array of initcalls and 
drivername (and maybe more information) might be thinkable.


4. x86/amd64/ACPI-people, so most longtime and core kernel maintainers 
obviously don't have much interest until you've solved 1. in a way they 
can use too. So the necessary changes for 2. or 3. will have a big 
hurdle to take if 1. isn't solved usable for them too.



Alexander Holler


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

Re: [PATCH v2 13/17] x86/tsc: Rename native_read_tsc() to rdtsc_unordered()

[Andy Lutomirski]

On Sat, Jun 13, 2015 at 1:57 AM, Borislav Petkov  wrote:
> On Fri, Jun 12, 2015 at 04:44:53PM -0700, Andy Lutomirski wrote:
>> Now that there is no paravirt TSC, the "native" is inappropriate.
>> The fact that rdtsc is not ordered can catch people by surprise, so
>> call it rdtsc_unordered().
>>
>> Signed-off-by: Andy Lutomirski 
>
> ...
>
>> @@ -109,7 +109,16 @@ notrace static inline int 
>> native_write_msr_safe(unsigned int msr,
>>  extern int rdmsr_safe_regs(u32 regs[8]);
>>  extern int wrmsr_safe_regs(u32 regs[8]);
>>
>> -static __always_inline unsigned long long native_read_tsc(void)
>> +/**
>> + * rdtsc_unordered() - returns the current TSC without ordering constraints
>> + *
>> + * rdtsc_unordered() returns the result of RDTSC as a 64-bit integer.  The
>> + * only ordering constraint it supplies is the ordering implied by
>> + * "asm volatile": it will put the RDTSC in the place you expect.  The
>> + * CPU can and will speculatively execute that RDTSC, though, so the
>> + * results can be non-monotonic if compared on different CPUs.
>> + */
>> +static __always_inline unsigned long long rdtsc_unordered(void)
>
> I like the rdtsc_ordered() thing because it wraps the barrier and people
> cannot just forget it. But let's call this not rdtsc_unordered() but
> simply
>
> rdtsc()
>
> The "_unordered" suffix is unnecessary IMO since this function is a
> simple wrapper around the hw insn and we do that naming scheme with all
> such wrappers.

I could go either way here.  rdtsc() is weird because people seem to
forget about the barrier.  Maybe I'm being unnecessarily paranoid.

--Andy

>
> --
> Regards/Gruss,
> Boris.
>
> ECO tip #101: Trim your mails when you reply.
> --



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 15/17] x86: Add rdtsc_ordered() and use it in trivial call sites

[Andy Lutomirski]

On Sat, Jun 13, 2015 at 2:02 AM, Borislav Petkov  wrote:
> On Fri, Jun 12, 2015 at 04:44:55PM -0700, Andy Lutomirski wrote:
>> barrier_before_rdtsc(); rdtsc_unordered() is an unnecessary mouthful and
>> requires more thought than should be necessary.  Add an rdtsc_ordered()
>> helper and replace the trivial call sites with it.
>>
>> This should not change generated code.
>>
>> Signed-off-by: Andy Lutomirski 
>> ---
>
> ...
>
>> diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
>> index a47fb11af5f5..22d69d2d1f0d 100644
>> --- a/arch/x86/include/asm/msr.h
>> +++ b/arch/x86/include/asm/msr.h
>> @@ -148,6 +148,20 @@ static __always_inline void barrier_before_rdtsc(void)
>> "lfence", X86_FEATURE_LFENCE_RDTSC);
>>  }
>>
>> +/**
>> + * rdtsc_ordered() - read the current TSC in program order
>> + *
>> + * rdtsc_ordered() returns the result of RDTSC as a 64-bit integer.
>> + * It is ordered like a load to a global in-memory counter.  It should
>> + * be impossible to observe non-monotonic rdtsc_unordered() behavior
>> + * across multiple CPUs as long as the TSC is synced.
>> + */
>> +static __always_inline unsigned long long rdtsc_ordered(void)
>> +{
>> + barrier_before_rdtsc();
>> + return rdtsc_unordered();
>> +}
>> +
>
> I don't see the final tree state with all those applied (too lazy to
> apply them) but why not simply kill barrier_before_rdtsc() and inline
> the alternative into rdtsc_ordered()?
>
> I mean, I don't see usage for it somewhere else...

There's the awful, awful code in kvmclock.  I'll fix that as part of
v3 and get rid of barrier_before_rdtsc().

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: General protection fault after STR (32 bit systems only)

[Andy Lutomirski]

On Sat, Jun 13, 2015 at 12:03 AM, Ingo Molnar  wrote:
>
> * Brian Gerst  wrote:
>
>> On Fri, Jun 12, 2015 at 4:36 AM, Ingo Molnar  wrote:
>> >
>> > * H. Peter Anvin  wrote:
>> >
>> >> %es is used implicitly by string instructions.
>> >
>> > Ok, so we are probably better off reloading ES as well early, right
>> > when we return from the firmware, just in case something does
>> > a copy before we hit the ES restore in restore_processor_state(),
>> > which is a generic C function?
>> >
>> > Something like the patch below?
>> >
>> > I also added FS/GS/SS reloading to make it complete. If this (or a variant
>> > thereof, it's still totally untested) works then we can remove the segment
>> > save/restore layer in __save/restore_processor_state().
>> >
>> > Thanks,
>> >
>> > Ingo
>> >
>> > ===>
>> >  arch/x86/kernel/acpi/wakeup_32.S | 13 +
>> >  1 file changed, 13 insertions(+)
>> >
>> > diff --git a/arch/x86/kernel/acpi/wakeup_32.S 
>> > b/arch/x86/kernel/acpi/wakeup_32.S
>> > index 665c6b7d2ea9..1376a7fc21b7 100644
>> > --- a/arch/x86/kernel/acpi/wakeup_32.S
>> > +++ b/arch/x86/kernel/acpi/wakeup_32.S
>> > @@ -61,6 +61,19 @@ ENTRY(wakeup_pmode_return)
>> >
>> >
>> >  restore_registers:
>> > +   /*
>> > +* In case the BIOS corrupted our segment descriptors,
>> > +* reload them to clear out any shadow descriptor
>> > +* state:
>> > +*/
>> > +   movl$__USER_DS, %eax
>> > +   movl%eax, %ds
>> > +   movl%eax, %es
>> > +   movl%eax, %fs
>> > +   movl%eax, %gs
>> > +   movl$__KERNEL_DS, %eax
>> > +   movl%eax, %ss
>> > +
>> > movlsaved_context_ebp, %ebp
>> > movlsaved_context_ebx, %ebx
>> > movlsaved_context_esi, %esi
>>
>> If you follow the convoluted flow of the calls in this file, 
>> wakeup_pmode_return
>> is the first thing called from the trampoline on resume, and that loads the 
>> data
>> segments with __KERNEL_DS. [...]
>
> So if wakeup_pmode_return is really the first thing called then the whole 
> premise
> of shadow descriptor corruption goes out the window: we reload all relevant
> segment registers.

True, but it still leaves the fact that we're loading __KERNEL_DS
instead of __USER_DS, right?  So we end up in the kernel in some
context (I have no clue what context) with __KERNEL_DS loaded.  It's
very easy for us to inadvertently fix it: we could return to userspace
by any means whatsoever except SYSEXIT, or we could even return back
to some preempted kernel context.

I still think we should replace __KERNEL_DS with __USER_DS in
wakeup_pmode_return and see if the problem goes away.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] iio: proximity: sx9500: Fix proximity value

[Jonathan Cameron]

On 12/06/15 08:40, Vlad Dogaru wrote:
> On Thu, Jun 11, 2015 at 06:49:34PM +0300, Daniel Baluta wrote:
>> Because of the ABI confusion proximity value exposed by SX9500
>> was inverted.
>>
>> Signed-off-by: Daniel Baluta 
> 
> Reviewed-by: Vlad Dogaru 
> 
> Sorry for causing the confusion, it was the only proximity sensor I had
> encountered to date.
Greg,

I've cc'd you to let you know that this fix causes an ABI change for
one driver.  Technically that driver actually matched with the current 
documentation,
just the documentation was misleading and lots of drivers have ended up with
the reverse interpretation (question was whether proximity values get larger
or smaller as you get nearer). 

Anyhow, given timing I doubt the pull request will reach you until after the
merge window.  I am also going to mark this for stable to cover the 4.0 and 4.1
kernels that have this driver in them.

Hope that's fine!

Applied to the fixes-togreg branch of iio.git

Daniel, thanks for clearing this mess up and checking through all the drivers
and datasheets to figure out it was only this one!

Jonathan

> 
>> ---
>>  drivers/iio/proximity/sx9500.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/iio/proximity/sx9500.c b/drivers/iio/proximity/sx9500.c
>> index 2042e37..01494cd 100644
>> --- a/drivers/iio/proximity/sx9500.c
>> +++ b/drivers/iio/proximity/sx9500.c
>> @@ -281,7 +281,7 @@ static int sx9500_read_prox_data(struct sx9500_data 
>> *data,
>>  if (ret < 0)
>>  return ret;
>>  
>> -*val = 32767 - (s16)be16_to_cpu(regval);
>> +*val = be16_to_cpu(regval);
>>  
>>  return IIO_VAL_INT;
>>  }
>> -- 
>> 1.9.1
>>

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

[char-misc] mei: reset flow control on the last client disconnection

[Tomas Winkler]

From: Alexander Usyskin 

The FW resets the flow control for single buffer clients when the last
host client disconnects, also the driver has to follow this policy and
zero the flow control counter in such case.

Cc:  #4.1
Signed-off-by: Alexander Usyskin 
Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/client.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c
index ae0160e02b34..6decbe136ea7 100644
--- a/drivers/misc/mei/client.c
+++ b/drivers/misc/mei/client.c
@@ -755,6 +755,9 @@ void mei_cl_set_disconnected(struct mei_cl *cl)
if (!WARN_ON(cl->me_cl->connect_count == 0))
cl->me_cl->connect_count--;
 
+   if (cl->me_cl->connect_count == 0)
+   cl->me_cl->mei_flow_ctrl_creds = 0;
+
mei_me_cl_put(cl->me_cl);
cl->me_cl = NULL;
 }
-- 
2.4.2

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

Re: [PATCH 07/12] x86/virt/guest/xen: Remove use of pgd_list from the Xen guest code

[Oleg Nesterov]

On 06/13, Ingo Molnar wrote:
>
> * Oleg Nesterov  wrote:
>
> > > So we could add tsk->mm_leader or so,
> >
> > No, no, please do not. Just do something like
> >
> > for_each_process(p) {
> >
> > for_each_thread(p, t) {
>
> So far that's what the for_each_process_thread() iterations I added do, right?

Not really,

> > if (t->mm) {
> > do_something(t->mm);
> > break;
^

Note this "break". We stop the inner loop right after we find a thread "t"
with ->mm != NULL. In the likely case t == p (group leader) so the inner
loop stops on the 1st iteration.


> > But either way I don't understand what protects this ->mm. Perhaps this 
> > needs
> > find_lock_task_mm().
>
> That's indeed a bug: I'll add task_lock()/unlock() before looking at ->mm.

Well, in this particular case we are safe. As Boris explained this is called
from stop_machine(). But sync_global_pgds() is not safe.

> find_lock_task_mm() is not needed IMHO: we have a stable reference to 't', as
> task can only go away via RCU expiry, and all the iterations I added are 
> (supposed
> to) be RCU safe.

Sure, you can do lock/unlock by hand. But find_lock_task_mm() can simplify
the code because it checks subthreads if group_leader->mm == NULL. You can
simply do

rcu_read_lock();
for_each_process(p) {
t = find_lock_task_mm(p);
if (!t)
continue;

do_something(t->mm);
task_unlock(t);
}
rcu_read_unlock();

Oleg.

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

Re: [PATCH 1/2] iio: inv-mpu: Export scale_available attributes

[Jonathan Cameron]

On 12/06/15 16:10, Adriana Reus wrote:
> Export the available scales for accel and gyro in order
> to hint the user-space as to what are the available valid values.
> 
> Signed-off-by: Adriana Reus 
Applied to the togreg branch of iio.git - initially pushed out
as testing for the autobuilders to play with it.

Thanks,

Jonathan
> ---
>  drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c 
> b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> index 17d4bb1..096e545 100644
> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> @@ -673,6 +673,10 @@ static const struct iio_chan_spec inv_mpu_channels[] = {
>  
>  /* constant IIO attribute */
>  static IIO_CONST_ATTR_SAMP_FREQ_AVAIL("10 20 50 100 200 500");
> +static IIO_CONST_ATTR(in_anglvel_scale_available,
> +   "0.000133090 0.000266181 0.000532362 
> 0.001064724");
> +static IIO_CONST_ATTR(in_accel_scale_available,
> +   "0.000598 0.001196 0.002392 
> 0.004785");
>  static IIO_DEV_ATTR_SAMP_FREQ(S_IRUGO | S_IWUSR, inv_fifo_rate_show,
>   inv_mpu6050_fifo_rate_store);
>  static IIO_DEVICE_ATTR(in_gyro_matrix, S_IRUGO, inv_attr_show, NULL,
> @@ -685,6 +689,8 @@ static struct attribute *inv_attributes[] = {
>   _dev_attr_in_accel_matrix.dev_attr.attr,
>   _dev_attr_sampling_frequency.dev_attr.attr,
>   _const_attr_sampling_frequency_available.dev_attr.attr,
> + _const_attr_in_accel_scale_available.dev_attr.attr,
> + _const_attr_in_anglvel_scale_available.dev_attr.attr,
>   NULL,
>  };
>  
> 

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

Re: [PATCH 2/2] iio: inv-mpu: Specify the expected format/precision for write channels

[Jonathan Cameron]

On 11/06/15 18:31, Ge Gao wrote:
> These code looks good to me.
> Thanks.
> 
> Best Regards,
> 
> Ge GAO
Ge, formal Ack definitely preferred, but thanks for taking a look.

Adriana, please put fixes at the start of such a series.  It didn't
matter here as the two changes were non overlapping but they take
different paths so if there is overlap I need to get the fix
out ASAP and then the improvements such as patch 1 can follow slower.

Anyhow, applied to the fixes-togreg branch of iio.git (probably to
go upstream post the merge window now). Marked for stable.
> 
> 
> -Original Message-
> From: Adriana Reus [mailto:adriana.r...@intel.com] 
> Sent: Friday, June 12, 2015 8:10 AM
> To: Ge Gao; ji...@kernel.org
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Adriana Reus
> Subject: [PATCH 2/2] iio: inv-mpu: Specify the expected format/precision for 
> write channels
> 
> The gyroscope needs IIO_VAL_INT_PLUS_NANO for the scale channel and unless 
> specified write returns MICRO by default.
> This needs to be properly specified so that write operations into scale have 
> the expected behaviour.
> 
> Signed-off-by: Adriana Reus 
> ---
>  drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c 
> b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> index 096e545..4de5374 100644
> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> @@ -431,6 +431,23 @@ static int inv_mpu6050_write_gyro_scale(struct 
> inv_mpu6050_state *st, int val)
>   return -EINVAL;
>  }
>  
> +static int inv_write_raw_get_fmt(struct iio_dev *indio_dev,
> +  struct iio_chan_spec const *chan, long mask) {
> + switch (mask) {
> + case IIO_CHAN_INFO_SCALE:
> + switch (chan->type) {
> + case IIO_ANGL_VEL:
> + return IIO_VAL_INT_PLUS_NANO;
> + default:
> + return IIO_VAL_INT_PLUS_MICRO;
> + }
> + default:
> + return IIO_VAL_INT_PLUS_MICRO;
> + }
> +
> + return -EINVAL;
> +}
>  static int inv_mpu6050_write_accel_scale(struct inv_mpu6050_state *st, int 
> val)  {
>   int result, i;
> @@ -702,6 +719,7 @@ static const struct iio_info mpu_info = {
>   .driver_module = THIS_MODULE,
>   .read_raw = _mpu6050_read_raw,
>   .write_raw = _mpu6050_write_raw,
> + .write_raw_get_fmt = _write_raw_get_fmt,
>   .attrs = _attribute_group,
>   .validate_trigger = inv_mpu6050_validate_trigger,  };
> --
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

Re: [PATCH v3 5/5] i8042: Add i8042_dt.h glue for DT support

[Roman Volkov]

Something prevents me from following the thread, replying to myself.

> В Sat, 14 Mar 2015 20:20:38 -0700
> Dmitry Torokhov  wrote:
>   
> > 
> > Hi Roman,
> > 
> > On Mon, Feb 16, 2015 at 12:11:43AM +0300, Roman Volkov wrote:
> > > Documentation for 'intel,8042' DT compatible node.
> > > 
> > > Signed-off-by: Tony Prisk 
> > > Signed-off-by: Roman Volkov 
> > > ---
> > >  .../devicetree/bindings/input/intel-8042.txt   | 26
> > > ++ 1 file changed, 26 insertions(+)
> > >  create mode 100644
> > > Documentation/devicetree/bindings/input/intel-8042.txt
> > > 
> > > diff --git
> > > a/Documentation/devicetree/bindings/input/intel-8042.txt
> > > b/Documentation/devicetree/bindings/input/intel-8042.txt new file
> > > mode 100644 index 000..ab8a3e0 --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/input/intel-8042.txt
> > > @@ -0,0 +1,26 @@
> > > +Intel 8042 Keyboard Controller
> > > +
> > > +Required properties:
> > > +- compatible: should be "intel,8042"
> > > +- regs: memory for keyboard controller
> > > +- interrupts: usually, two interrupts should be specified
> > > (keyboard and aux).
> > > + However, only one interrupt is also allowed in case of
> > > absence of the
> > > + physical port in the controller. The i8042 driver must be
> > > loaded with
> > > + nokbd/noaux option in this case.
> > > +- interrupt-names: interrupt names corresponding to numbers in
> > > the list.
> > > + "kbd" is the keyboard interrupt and "aux" is the
> > > auxiliary (mouse)
> > > + interrupt.
> > > +- command-reg: offset in memory for command register
> > > +- status-reg: offset in memory for status register
> > > +- data-reg: offset in memory for data register
> > > +
> > > +Example:
> > > + i8042@d8008800 {
> > > + compatible = "intel,8042";
> > > + regs = <0xd8008800 0x100>;
> > > + interrupts = <23>, <4>;
> > > + interrupt-names = "kbd", "aux";
> > > + command-reg = <0x04>;
> > > + status-reg = <0x04>;
> > > + data-reg = <0x00>;
> > > + };
> > 
> > No, we already have existing OF bindings for i8042 on sparc and
> > powerpc, I do not think we need to invent a brand new one.
> > 
> > Thanks.
> > 

I have looked more into that header (i8042-sparcio.h). Probably 8042 is
broken for SPARCs, because there is the platform_driver registered twice
with the same name "i8042". One driver is registered by
platform_create_bundle() from i8042.c and another from
platform_driver_register() from the i8042_sparcio.h. Kernel prints a
message "Error: Driver 'i8042' is already registered, aborting...".

I have not tested SPARC version of the kernel, just used the same code
for ARM, to rewrite my patch set.

There is no bindings at all for i8042, because a binding requires
the 'compatible' property to be defined, according to ePAPR. In the
SPARC header there is an ancient surrogate with searching by name
instead of the 'compatible' property (I understand, no standards were
defined for that hardware those days).

Regards,
Roman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 06/12] x86/mm: Enable and use the arch_pgd_init_late() method

[Oleg Nesterov]

On 06/13, Ingo Molnar wrote:
>
> * Ingo Molnar  wrote:
>
> > * Oleg Nesterov  wrote:
> >
> > >
> > > Afaics, we need to ensure that:
> > >
> > > > +   if (pgd_val(*pgd_src))
> > > > +   WRITE_ONCE(*pgd_dst, *pgd_src);
> > >
> > > either we notice the recent update of this PGD, or (say) the subsequent
> > > sync_global_pgds() can miss the child.
> > >
> > > How the write barrier can help?
> >
> > So the real thing this pairs with is the earlier:
> >
> > tsk->mm = mm;
> >
> > plus the linking of the new task in the task list.
> >
> > _that_ write must become visible to others before we do the (conditional) 
> > copy
> > ourselves.

Hmm. that write must be visible before we start to _read_ *pgd_src,
afaics.

> > Granted, it happens quite a bit earlier, and the task linking's use of 
> > locking
> > is a natural barrier - but since this is lockless I didn't want to leave a
> > silent assumption in.

I agree,

> Ah, there's another detail I forgot. This might handle the fork case, but in
> exec() we have:
>
> tsk->mm = mm;
> arch_pgd_init_late(mm);

Yes, this too.

But wmb() can't help. At least we need the full mb() to serialize the
STORE above (or list addition in copy_process) with the LOAD which
reads *pgd_src.

Plus we need another mb() in sync_global_pgds(), say, before the main
for_each_process() loop.


it would be nice to make this more simple/clear somehow...

Oleg.

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

Re: [PATCH 3.10 14/46] d_walk() might skip too much

[Willy Tarreau]

Hi Jari,

On Sat, Jun 13, 2015 at 07:01:31PM +0300, Jari Ruusu wrote:
> When Al Viro's VFS deadlock fix "deal with deadlock in d_walk()" was
> backported to 3.10.y 3.4.y and 3.2.y stable kernel brances, the deadlock fix
> was copied to 3 different places. Later, a bug in that code was discovered.
> Al Viro's fix involved fixing only one part of code in mainline kernel. That
> fix is called "d_walk() might skip too much".
> 
> 3.10.y 3.4.y and 3.2.y stable kernel brances need that later fix copied to 3
> different places. Greg Kroah-Hartman included Al Viro's "d_walk() might skip
> too much" fix only once in 3.10.80 kernel, leaving 2 more places without a
> fix.
> 
> The patch below was not written by me. I only applied Al Viro's "d_walk()
> might skip too much" fix 2 more times to 3.10.80 kernel, and cheched that
> the fixes went to correct places. With this patch applied, all 3 places that
> I am aware of 3.10.y stable branch are now fixed.
> 
> Signed-off-by: Jari Ruusu 

Next time, please don't forget to mention the mainline commit IDs in
addition to the message subjects, it helps a lot. The IDs from the
stable branches are less important since it's generally quite easy
to find them thanks to the mainline ID which appears in the message.
Just for reference :

  - ca5358e ("deal with deadlock in d_walk()")
  - 2159184 ("d_walk() might skip too much")

Thanks,
Willy

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

Re: doubt about sm7xxfb (was: Re: [PATCH v4 0/7] staging: fsl-mc: New functionality to the MC bus driver)

[Joe Perches]

On Sat, 2015-06-13 at 09:28 -0700, Greg KH wrote:
> On Sat, Jun 13, 2015 at 02:16:18PM +0530, Sudip Mukherjee wrote:
[]
> > Your reply above was for a different thread but my doubt started from
> > this. I was working on adding the Dual-Head support to sm7xxfb. So that
> > is also a new functionality which is not in the current driver as of now.
> > Then should i instead concentrate on getting that out of staging? If yes,
> > can you please have a look (when you are free) at it to see if anything
> > else needs to be done.
> 
> Yes, please work on getting it out of staging.
> 
> If you think it's ready, then submit a patch that moves it, copying the
> proper maintainers, and I'll be glad to review it.

It seems ready to me.

As far as I can tell, there's just a few niggles
that could be done:

Something like (too lazy to separate them into multiple patches)

o reduce indentation a couple of places
o add newlines to logging messages
o add const to static array
o use consistent function declaration style

It's unfortunate there are so many #ifdef __BIG_ENDIAN uses.

---
 drivers/staging/sm7xxfb/sm7xxfb.c | 203 ++
 1 file changed, 96 insertions(+), 107 deletions(-)

diff --git a/drivers/staging/sm7xxfb/sm7xxfb.c 
b/drivers/staging/sm7xxfb/sm7xxfb.c
index 5db26f1..5be2560 100644
--- a/drivers/staging/sm7xxfb/sm7xxfb.c
+++ b/drivers/staging/sm7xxfb/sm7xxfb.c
@@ -94,7 +94,7 @@ struct vesa_mode {
u16  lfb_depth;
 };
 
-static struct vesa_mode vesa_mode_table[] = {
+static const struct vesa_mode vesa_mode_table[] = {
{"0x301", 640,  480,  8},
{"0x303", 800,  600,  8},
{"0x305", 1024, 768,  8},
@@ -255,37 +255,32 @@ static int smtc_setcolreg(unsigned regno, unsigned red, 
unsigned green,
/*
 * 16/32 bit true-colour, use pseudo-palette for 16 base color
 */
-   if (regno < 16) {
-   if (sfb->fb->var.bits_per_pixel == 16) {
-   u32 *pal = sfb->fb->pseudo_palette;
-
-   val = chan_to_field(red, >fb->var.red);
-   val |= chan_to_field(green,
->fb->var.green);
-   val |= chan_to_field(blue, >fb->var.blue);
+   if (regno >= 16)
+   break;
+   if (sfb->fb->var.bits_per_pixel == 16) {
+   u32 *pal = sfb->fb->pseudo_palette;
+
+   val = chan_to_field(red, >fb->var.red);
+   val |= chan_to_field(green, >fb->var.green);
+   val |= chan_to_field(blue, >fb->var.blue);
 #ifdef __BIG_ENDIAN
-   pal[regno] =
-   ((red & 0xf800) >> 8) |
-   ((green & 0xe000) >> 13) |
-   ((green & 0x1c00) << 3) |
-   ((blue & 0xf800) >> 3);
+   pal[regno] = (((red & 0xf800) >> 8) |
+ ((green & 0xe000) >> 13) |
+ ((green & 0x1c00) << 3) |
+ ((blue & 0xf800) >> 3));
 #else
-   pal[regno] = val;
+   pal[regno] = val;
 #endif
-   } else {
-   u32 *pal = sfb->fb->pseudo_palette;
+   } else {
+   u32 *pal = sfb->fb->pseudo_palette;
 
-   val = chan_to_field(red, >fb->var.red);
-   val |= chan_to_field(green,
->fb->var.green);
-   val |= chan_to_field(blue, >fb->var.blue);
+   val = chan_to_field(red, >fb->var.red);
+   val |= chan_to_field(green, >fb->var.green);
+   val |= chan_to_field(blue, >fb->var.blue);
 #ifdef __BIG_ENDIAN
-   val =
-   (val & 0xff00ff00 >> 8) |
-   (val & 0x00ff00ff << 8);
+   val = (val & 0xff00ff00 >> 8) | (val & 0x00ff00ff << 8);
 #endif
-   pal[regno] = val;
-   }
+   pal[regno] = val;
}
break;
 
@@ -302,8 +297,8 @@ static int smtc_setcolreg(unsigned regno, unsigned red, 
unsigned green,
 }
 
 #ifdef __BIG_ENDIAN
-static ssize_t smtcfb_read(struct fb_info *info, char __user *buf, size_t
-   count, loff_t *ppos)
+static ssize_t smtcfb_read(struct fb_info *info, char __user *buf,
+  size_t count, loff_t *ppos)
 {
unsigned long p = *ppos;
 
@@ -346,9 +341,8 @@ static ssize_t smtcfb_read(struct fb_info *info, char 
__user *buf, size_t

Re: Regression in 3.10.80 vs. 3.10.79

[Roland Dreier]

On Fri, Jun 12, 2015 at 7:52 PM, Rafael J. Wysocki  wrote:
> Below is a more sophisticated, so to speak, version of it with a changelog and
> all.  It works for me, but more testing would be much appreciated.

Great, I'm convinced by your reasoning that this makes sense.  I'm
building 3.10.80 patched with this (needed a tiny bit of context
adjustment because acpi_dev_filter_resource_type() hadn't been added
to 3.10 yet), and will confirm that it fixes the issue I saw.

Thanks!
  Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC v1 14/25] genirq: Kill the first parameter 'irq' of irq_flow_handler_t

[Jiang Liu]

On 2015/6/13 22:53, Julia Lawall wrote:
> Better formatted diff.
Great thanks to you, Julia!
It seems really attractively, I will try to figure out
whether I have caught all the cases.

BTW, a new version of these patch set has been posted at:
http://comments.gmane.org/gmane.linux.kernel.pci/42320

I have also push the new version to github in case you need
to access it:
 https://github.com/jiangliu/linux.git irq:irqdesc_v2

Thanks!
Gerry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Questions about interrupt

[Alex Feng]

Hi experts,

I have trouble about interrupt. I need low level trigger the interrupt. My 
control flow is that when data is less than a threshold, it needs keeping 
interrupt until data is supplied.  

So I use the flag `IRQ_TYPE_LEVEL_LOW `, but it doesn’t work. I have also tried 
`IRQF_TRIGGER_LOW`, it also doesn’t work.

I have checked the hardware register, the interrupt GPIO is still `falling 
edges`, not `low level`.

My board is ARM S3C6410 tiny board. 


   221  /* inkprinter */
   222  #define S3C64XX_PA_INKPRINTER (0x3000)
   223  #define S3C64XX_SZ_INKPRINTER SZ_1M
   224  static struct resource inkprinter_resources[] = {
   225  [0] = {
   226  .start  = S3C64XX_PA_INKPRINTER,
   227  .end= S3C64XX_PA_INKPRINTER + 
S3C64XX_SZ_INKPRINTER,
   228  .flags  = IORESOURCE_MEM,
   229  },
   230  [1] = {
   231  .start  = IRQ_EINT(1),
   232  .end= IRQ_EINT(1),
   233  .flags = IORESOURCE_IRQ | IRQ_TYPE_LEVEL_LOW,
   234  }
   235  };
   236  static struct platform_device s3c_device_inkprinter = {
   237  .name   = "inkprinter",
   238  .num_resources  = ARRAY_SIZE(inkprinter_resources),
   239  .resource   = inkprinter_resources,
   240  };
   241


My question is :

Is `IRQ_TYPE_LEVEL_LOW ` or `IRQF_TRIGGER_LOW `  for low level trigger? Or some 
other problem? Any tips?
Your response will be highly appreciated. 

Thanks,
/Alex--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: doubt about sm7xxfb (was: Re: [PATCH v4 0/7] staging: fsl-mc: New functionality to the MC bus driver)

[Greg KH]

On Sat, Jun 13, 2015 at 02:16:18PM +0530, Sudip Mukherjee wrote:
> On Fri, Jun 12, 2015 at 05:18:49PM -0700, Greg KH wrote:
> > On Tue, Jun 09, 2015 at 04:59:01PM -0500, J. German Rivera wrote:
> > > This patch series includes new functionality for the Freescale fsl-mc
> > > bus driver.
> > 
> > Why are people working on "new functionality" instead of working on
> > getting this out of the staging tree?  I really hate adding new
> > functions to staging drivers, as this is not the correct place for
> > drivers to be in the tree.  People should be working to get them out of
> > this location, and then you can add new functions to them.
> Hi Greg,
> Your reply above was for a different thread but my doubt started from
> this. I was working on adding the Dual-Head support to sm7xxfb. So that
> is also a new functionality which is not in the current driver as of now.
> Then should i instead concentrate on getting that out of staging? If yes,
> can you please have a look (when you are free) at it to see if anything
> else needs to be done.

Yes, please work on getting it out of staging.

If you think it's ready, then submit a patch that moves it, copying the
proper maintainers, and I'll be glad to review it.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ipmi: constify ACPI device ids

[Corey Minyard]

Queued for the next kernel release.  Thanks.

-corey

On 06/13/2015 07:19 AM, Mathias Krause wrote:
> Constify the ACPI device ID array, it doesn't need to be writable at
> runtime.
>
> Signed-off-by: Mathias Krause 
> ---
>  drivers/char/ipmi/ipmi_ssif.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/char/ipmi/ipmi_ssif.c b/drivers/char/ipmi/ipmi_ssif.c
> index 207689c444a8..95a0910d91e4 100644
> --- a/drivers/char/ipmi/ipmi_ssif.c
> +++ b/drivers/char/ipmi/ipmi_ssif.c
> @@ -1787,7 +1787,7 @@ skip_addr:
>  }
>  
>  #ifdef CONFIG_ACPI
> -static struct acpi_device_id ssif_acpi_match[] = {
> +static const struct acpi_device_id ssif_acpi_match[] = {
>   { "IPI0001", 0 },
>   { },
>  };

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

Re: [PATCH v4 0/8] Support for Open-Channel SSDs

[Matias Bjorling]

On 06/11/2015 12:29 PM, Christoph Hellwig wrote:
> On Wed, Jun 10, 2015 at 08:11:42PM +0200, Matias Bjorling wrote:
>> 1. A get/put flash block API, that user-space applications can use.
>> That will enable application-driven FTLs. E.g. RocksDB can be integrated
>> tightly with the SSD. Allowing data placement and garbage collection to
>> be strictly controlled. Data placement will reduce the need for
>> over-provisioning, as data that age at the same time are placed in the
>> same flash block, and garbage collection can be scheduled to not
>> interfere with user requests. Together, it will remove I/O outliers
>> significantly.
>>
>> 2. Large drive arrays with global FTL. The stacking block device model
>> enables this. It allows an FTL to span multiple devices, and thus
>> perform data placement and garbage collection over tens to hundred of
>> devices. That'll greatly improve wear-leveling, as there is a much
>> higher probability of a fully inactive block with more flash.
>> Additionally, as the parallelism grows within the storage array, we can
>> slice and dice the devices using the get/put flash block API and enable
>> applications to get predictable performance, while using large arrays
>> that have a single address space.
>>
>> If it too much for now to get upstream, I can live with (2) removed and
>> then I make the changes you proposed.
> 
> In this case your driver API really isn't the Linux block API
> anymore.  I think the right API is a simple asynchronous submit with
> callback into the driver, with the block device only provided by
> the lightnvm layer.

Agree. A group is working on a RocksDB prototype at the moment. When
that is done, such an interface would be polished and submitted for
review. The first patches here are to lay the groundwork for block I/O
FTLs and generic flash block interface.

> 
> Note that for NVMe it might still make sense to implement this using
> blk-mq and a struct request, but those should be internal similar to
> how NVMe implements admin commands.

How about handling I/O merges? In the case where a block API is exposed
with a global FTL, filesystems relies on I/O merges for improving
performance. If using internal commands, merging has to implemented in
the lightnvm stack itself, I rather want to use blk-mq and not duplicate
the effort. I've kept the stacking model, so that I/Os go through the
queue I/O path and then picked up in the device driver.




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

Re: [PATCH 2/3] vfs, writeback: replace FS_CGROUP_WRITEBACK with MS_CGROUPWB

[Christoph Hellwig]

On Fri, Jun 12, 2015 at 04:57:33PM -0500, Tejun Heo wrote:
> FS_CGROUP_WRITEBACK indicates whether a file_system_type supports
> cgroup writeback; however, different super_blocks of the same
> file_system_type may or may not support cgroup writeback depending on
> filesystem options.  This patch replaces FS_CGROUP_WRITEBACK with a
> kernel-internal super_block->s_flags MS_CGROUPWB.  The concatenated
> and abbreviated name is for consistency with other MS_* flags.

Nak.  As the uapi part makes it obvious the MS_ namespace is part
of the userspace ABI.  Please add a new in-kernel flags field instead.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.10 14/46] d_walk() might skip too much

[Jari Ruusu]

When Al Viro's VFS deadlock fix "deal with deadlock in d_walk()" was
backported to 3.10.y 3.4.y and 3.2.y stable kernel brances, the deadlock fix
was copied to 3 different places. Later, a bug in that code was discovered.
Al Viro's fix involved fixing only one part of code in mainline kernel. That
fix is called "d_walk() might skip too much".

3.10.y 3.4.y and 3.2.y stable kernel brances need that later fix copied to 3
different places. Greg Kroah-Hartman included Al Viro's "d_walk() might skip
too much" fix only once in 3.10.80 kernel, leaving 2 more places without a
fix.

The patch below was not written by me. I only applied Al Viro's "d_walk()
might skip too much" fix 2 more times to 3.10.80 kernel, and cheched that
the fixes went to correct places. With this patch applied, all 3 places that
I am aware of 3.10.y stable branch are now fixed.

Signed-off-by: Jari Ruusu 

--- linux-3.10.80/fs/dcache.c.OLD   2015-06-11 19:22:31.0 +0300
+++ linux-3.10.80/fs/dcache.c   2015-06-11 19:32:59.0 +0300
@@ -1053,13 +1053,13 @@
/* might go back up the wrong parent if we have had a rename. */
if (!locked && read_seqretry(_lock, seq))
goto rename_retry;
-   next = child->d_child.next;
-   while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED)) {
+   /* go into the first sibling still alive */
+   do {
+   next = child->d_child.next;
if (next == _parent->d_subdirs)
goto ascend;
child = list_entry(next, struct dentry, d_child);
-   next = next->next;
-   }
+   } while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED));
rcu_read_unlock();
goto resume;
}
@@ -2977,13 +2977,13 @@
/* might go back up the wrong parent if we have had a rename. */
if (!locked && read_seqretry(_lock, seq))
goto rename_retry;
-   next = child->d_child.next;
-   while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED)) {
+   /* go into the first sibling still alive */
+   do {
+   next = child->d_child.next;
if (next == _parent->d_subdirs)
goto ascend;
child = list_entry(next, struct dentry, d_child);
-   next = next->next;
-   }
+   } while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED));
rcu_read_unlock();
goto resume;
}

-- 
Jari Ruusu  4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD  ACDF F073 3C80 8132 F189
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] selinux: reduce locking overhead in inode_free_security()

[Eric Paris]

On Sat, 2015-06-13 at 10:35 +0300, Yury wrote:
> 
> On 13.06.2015 01:35, Waiman Long wrote:
> > On 06/12/2015 08:31 AM, Stephen Smalley wrote:
> > > On 06/12/2015 02:26 AM, Raghavendra K T wrote:
> > > > On 06/12/2015 03:01 AM, Waiman Long wrote:
> > > > > The inode_free_security() function just took the superblock's 
> > > > > 
> > > > > isec_lock
> > > > > before checking and trying to remove the inode security 
> > > > > struct from 
> > > > > the
> > > > > linked list. In many cases, the list was empty and so the 
> > > > > lock taking
> > > > > is wasteful as no useful work is done. On multi-socket 
> > > > > systems with
> > > > > a large number of CPUs, there can also be a fair amount of 
> > > > > spinlock
> > > > > contention on the isec_lock if many tasks are exiting at the 
> > > > > same 
> > > > > time.
> > > > > 
> > > > > This patch changes the code to check the state of the list 
> > > > > first
> > > > > before taking the lock and attempting to dequeue it. As this 
> > > > > function
> > > > > is called indirectly from __destroy_inode(), there can't be 
> > > > > another
> > > > > instance of inode_free_security() running on the same inode.
> > > > > 
> > > > > Signed-off-by: Waiman Long
> > > > > ---
> > > > >security/selinux/hooks.c |   15 ---
> > > > >1 files changed, 12 insertions(+), 3 deletions(-)
> > > > > 
> > > > > v1->v2:
> > > > >- Take out the second list_empty() test inside the lock.
> > > > > 
> > > > > diff --git a/security/selinux/hooks.c 
> > > > > b/security/selinux/hooks.c
> > > > > index 7dade28..e5cdad7 100644
> > > > > --- a/security/selinux/hooks.c
> > > > > +++ b/security/selinux/hooks.c
> > > > > @@ -254,10 +254,19 @@ static void inode_free_security(struct 
> > > > > inode
> > > > > *inode)
> > > > >struct inode_security_struct *isec = inode
> > > > > ->i_security;
> > > > >struct superblock_security_struct *sbsec = 
> > > > > inode->i_sb->s_security;
> > > > > 
> > > > > -spin_lock(>isec_lock);
> > > > > -if (!list_empty(>list))
> > > > > +/*
> > > > > + * As not all inode security structures are in a list, 
> > > > > we 
> > > > > check for
> > > > > + * empty list outside of the lock to make sure that we 
> > > > > won't 
> > > > > waste
> > > > > + * time taking a lock doing nothing. As 
> > > > > inode_free_security() is
> > > > > + * being called indirectly from __destroy_inode(), there 
> > > > > is no 
> > > > > way
> > > > > + * there can be two or more concurrent calls. So doing 
> > > > > the
> > > > > list_empty()
> > > > > + * test outside the loop should be safe.
> > > > > + */
> > > > > +if (!list_empty(>list)) {
> > > > > +spin_lock(>isec_lock);
> > > > >list_del_init(>list);
> > > > Stupid question,
> > > > 
> > > > I need to take a look at list_del_init() code, but it can so 
> > > > happen 
> > > > that
> > > > if !list_empty() check could happen simultaneously, then 
> > > > serially two
> > > > list_del_init() can happen.
> > > > 
> > > > is that not a problem()?
> > > Hmm...I suppose that's possible (sb_finish_set_opts and
> > > inode_free_security could both perform the list_del_init).  Ok, 
> > > we'll
> > > stay with the first version.
> > > 
> > 
> > Actually, list_del_init() can be applied twice with no harm being 
> > done. The first list_del_init() will set list-> next = list->prev = 
> > 
> > list. The second one will do the same thing and so it should be 
> > safe.
> > 
> > Cheers,
> > Longman
> > 
> 
> Hello, Waiman!
> 
> At first, minor.
> For me, moving the line 'if (!list_empty(>list))' out of lock 
> is 
> not possible just because 'inode_free_security' is called from 
> '__destroy_inode' only. You cannot rely on it in future. It's rather 
> possible because empty list is invariant under 'list_del_init', as 
> you 
> noted here. In fact, you can call 'list_del_init' unconditionally 
> here, 
> and condition is the only optimization to decrease lock contention. 
> So, 
> I'd like to ask you reflect it in your comment.
> 
> At second, less minor.
> Now that you access list element outside of the lock, why don't you 
> use 
> 'list_empty_careful' instead of 'list_empty'? It may eliminate 
> possible 
> race between, say, 'list_add' and 'list_empty', and costs you 
> virtually 
> nothing.

Agree, the comment isn't really accurate. list_empty() outside of the
lock is safe because there is only one place one can ever get onto the
list. If you are already off (as most inodes will be!) the lock and
remove would be completely useless.

list_empty_careful() is not safe against list_add().

http://marc.info/?l=git-commits-head=107277005829348

I'm not even really sure what it is safe/useful for, but the comment
does seem like it would be fine for our case. I guess it might be
appropriate with the other task calling list_del_init().  In this case,
I don't believe we care to sync at all (especially since there can't be
another task, but