[char-misc-next RESEND 0/6] mei updates

[char-misc-next RESEND 0/6] mei updates

[Tomas Winkler]

I've sent those patches ~ two months ago but were probably dropped from
the queue so resending them again.

Alexander Usyskin (2):
  mei: prevent queuing new flow control credit.
  mei: always copy the read buffer if data is ready

Tomas Winkler (4):
  mei: bus: remove redundant uuid string in debug messages
  mei: trace pci configuration space io
  mei: fix fasync return value on error
  mei: drop nfc leftovers from the mei driver

 drivers/misc/mei/bus-fixup.c | 10 ++++------
 drivers/misc/mei/client.c    | 21 ++++++++++++++++++++-
 drivers/misc/mei/hw-me.c     | 10 ++++++++--
 drivers/misc/mei/hw-txe.c    | 10 ++++++++--
 drivers/misc/mei/main.c      | 38 ++++++++++++++++++--------------------
 drivers/misc/mei/mei-trace.c |  2 ++
 drivers/misc/mei/mei-trace.h | 38 ++++++++++++++++++++++++++++++++++++++
 drivers/misc/mei/mei_dev.h   | 11 -----------
 8 files changed, 98 insertions(+), 42 deletions(-)

-- 
2.4.3

[char-misc-next 1/6 RESEND] mei: bus: remove redundant uuid string in debug messages

[Tomas Winkler]

Remove uuid from the debug messages in bus-fixup.c
as this is already part of the device name.

Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
 drivers/misc/mei/bus-fixup.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/mei/bus-fixup.c
index 020de5919c21..b2d2a6ea576c 100644
--- a/drivers/misc/mei/bus-fixup.c
+++ b/drivers/misc/mei/bus-fixup.c
@@ -48,8 +48,7 @@ static const uuid_le mei_nfc_info_guid = MEI_UUID_NFC_INFO;
  */
 static void number_of_connections(struct mei_cl_device *cldev)
 {
-	dev_dbg(&cldev->dev, "running hook %s on %pUl\n",
-			__func__, mei_me_cl_uuid(cldev->me_cl));
+	dev_dbg(&cldev->dev, "running hook %s\n", __func__);
 
 	if (cldev->me_cl->props.max_number_of_connections > 1)
 		cldev->do_match = 0;
@@ -62,8 +61,8 @@ static void number_of_connections(struct mei_cl_device *cldev)
  */
 static void blacklist(struct mei_cl_device *cldev)
 {
-	dev_dbg(&cldev->dev, "running hook %s on %pUl\n",
-			__func__, mei_me_cl_uuid(cldev->me_cl));
+	dev_dbg(&cldev->dev, "running hook %s\n", __func__);
+
 	cldev->do_match = 0;
 }
 
@@ -208,8 +207,7 @@ static void mei_nfc(struct mei_cl_device *cldev)
 
 	bus = cldev->bus;
 
-	dev_dbg(bus->dev, "running hook %s: %pUl match=%d\n",
-		__func__, mei_me_cl_uuid(cldev->me_cl), cldev->do_match);
+	dev_dbg(&cldev->dev, "running hook %s\n", __func__);
 
 	mutex_lock(&bus->device_lock);
 	/* we need to connect to INFO GUID */
-- 
2.4.3

[char-misc-next 2/6 RESEND] mei: trace pci configuration space io

[Tomas Winkler]

Use tracing events also for reading and writing pci configuration space
<debugfs>/tracing/events/mei/mei_pci_reg_{read,write}

Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
 drivers/misc/mei/hw-me.c     | 10 ++++++++--
 drivers/misc/mei/hw-txe.c    | 10 ++++++++--
 drivers/misc/mei/mei-trace.c |  2 ++
 drivers/misc/mei/mei-trace.h | 38 ++++++++++++++++++++++++++++++++++++++
 4 files changed, 56 insertions(+), 4 deletions(-)

diff --git a/drivers/misc/mei/hw-me.c b/drivers/misc/mei/hw-me.c
index 25b1997a62cb..e2fb44cc5c37 100644
--- a/drivers/misc/mei/hw-me.c
+++ b/drivers/misc/mei/hw-me.c
@@ -189,8 +189,11 @@ static int mei_me_fw_status(struct mei_device *dev,
 
 	fw_status->count = fw_src->count;
 	for (i = 0; i < fw_src->count && i < MEI_FW_STATUS_MAX; i++) {
-		ret = pci_read_config_dword(pdev,
-			fw_src->status[i], &fw_status->status[i]);
+		ret = pci_read_config_dword(pdev, fw_src->status[i],
+					    &fw_status->status[i]);
+		trace_mei_pci_cfg_read(dev->dev, "PCI_CFG_HSF_X",
+				       fw_src->status[i],
+				       fw_status->status[i]);
 		if (ret)
 			return ret;
 	}
@@ -215,6 +218,7 @@ static void mei_me_hw_config(struct mei_device *dev)
 
 	reg = 0;
 	pci_read_config_dword(pdev, PCI_CFG_HFS_1, &reg);
+	trace_mei_pci_cfg_read(dev->dev, "PCI_CFG_HFS_1", PCI_CFG_HFS_1, reg);
 	hw->d0i3_supported =
 		((reg & PCI_CFG_HFS_1_D0I3_MSK) == PCI_CFG_HFS_1_D0I3_MSK);
 
@@ -1248,6 +1252,7 @@ static bool mei_me_fw_type_nm(struct pci_dev *pdev)
 	u32 reg;
 
 	pci_read_config_dword(pdev, PCI_CFG_HFS_2, &reg);
+	trace_mei_pci_cfg_read(&pdev->dev, "PCI_CFG_HFS_2", PCI_CFG_HFS_2, reg);
 	/* make sure that bit 9 (NM) is up and bit 10 (DM) is down */
 	return (reg & 0x600) == 0x200;
 }
@@ -1260,6 +1265,7 @@ static bool mei_me_fw_type_sps(struct pci_dev *pdev)
 	u32 reg;
 	/* Read MFW Status check for SPS Firmware */
 	pci_read_config_dword(pdev, PCI_CFG_HFS_1, &reg);
+	trace_mei_pci_cfg_read(&pdev->dev, "PCI_CFG_HFS_1", PCI_CFG_HFS_1, reg);
 	/* if bits [19:16] = 15, running SPFirmware */
 	return (reg & 0xf0000) == 0xf0000;
 }
diff --git a/drivers/misc/mei/hw-txe.c b/drivers/misc/mei/hw-txe.c
index bae680c648ff..4a6c1b85f11e 100644
--- a/drivers/misc/mei/hw-txe.c
+++ b/drivers/misc/mei/hw-txe.c
@@ -28,6 +28,9 @@
 #include "client.h"
 #include "hbm.h"
 
+#include "mei-trace.h"
+
+
 /**
  * mei_txe_reg_read - Reads 32bit data from the txe device
  *
@@ -640,8 +643,11 @@ static int mei_txe_fw_status(struct mei_device *dev,
 
 	fw_status->count = fw_src->count;
 	for (i = 0; i < fw_src->count && i < MEI_FW_STATUS_MAX; i++) {
-		ret = pci_read_config_dword(pdev,
-			fw_src->status[i], &fw_status->status[i]);
+		ret = pci_read_config_dword(pdev, fw_src->status[i],
+					    &fw_status->status[i]);
+		trace_mei_pci_cfg_read(dev->dev, "PCI_CFG_HSF_X",
+				       fw_src->status[i],
+				       fw_status->status[i]);
 		if (ret)
 			return ret;
 	}
diff --git a/drivers/misc/mei/mei-trace.c b/drivers/misc/mei/mei-trace.c
index 388efb519138..e19e6acb191b 100644
--- a/drivers/misc/mei/mei-trace.c
+++ b/drivers/misc/mei/mei-trace.c
@@ -22,4 +22,6 @@
 
 EXPORT_TRACEPOINT_SYMBOL(mei_reg_read);
 EXPORT_TRACEPOINT_SYMBOL(mei_reg_write);
+EXPORT_TRACEPOINT_SYMBOL(mei_pci_cfg_read);
+EXPORT_TRACEPOINT_SYMBOL(mei_pci_cfg_write);
 #endif /* __CHECKER__ */
diff --git a/drivers/misc/mei/mei-trace.h b/drivers/misc/mei/mei-trace.h
index 47e1bc6551d4..86e5068837c1 100644
--- a/drivers/misc/mei/mei-trace.h
+++ b/drivers/misc/mei/mei-trace.h
@@ -64,6 +64,44 @@ TRACE_EVENT(mei_reg_write,
 		  __get_str(dev), __entry->reg,  __entry->offs, __entry->val)
 );
 
+TRACE_EVENT(mei_pci_cfg_read,
+	TP_PROTO(const struct device *dev, const char *reg, u32 offs, u32 val),
+	TP_ARGS(dev, reg, offs, val),
+	TP_STRUCT__entry(
+		__string(dev, dev_name(dev))
+		__field(const char *, reg)
+		__field(u32, offs)
+		__field(u32, val)
+	),
+	TP_fast_assign(
+		__assign_str(dev, dev_name(dev))
+		__entry->reg  = reg;
+		__entry->offs = offs;
+		__entry->val = val;
+	),
+	TP_printk("[%s] pci cfg read %s:[%#x] = %#x",
+		  __get_str(dev), __entry->reg, __entry->offs, __entry->val)
+);
+
+TRACE_EVENT(mei_pci_cfg_write,
+	TP_PROTO(const struct device *dev, const char *reg, u32 offs, u32 val),
+	TP_ARGS(dev, reg, offs, val),
+	TP_STRUCT__entry(
+		__string(dev, dev_name(dev))
+		__field(const char *, reg)
+		__field(u32, offs)
+		__field(u32, val)
+	),
+	TP_fast_assign(
+		__assign_str(dev, dev_name(dev))
+		__entry->reg = reg;
+		__entry->offs = offs;
+		__entry->val = val;
+	),
+	TP_printk("[%s] pci cfg write %s[%#x] = %#x)",
+		  __get_str(dev), __entry->reg,  __entry->offs, __entry->val)
+);
+
 #endif /* _MEI_TRACE_H_ */
 
 /* This part must be outside protection */
-- 
2.4.3

[char-misc-next 3/6 RESEND] mei: prevent queuing new flow control credit.

[Tomas Winkler]

From: Alexander Usyskin <alexander.usyskin@intel.com>

The MEI  FW can receive only one flow control for read.
Currently the driver only checks if a flow control credit was already
sent and read is pending in the rd_pending queue, but it also has to
check if flow control credit already queued in the write control queue
to prevent sending more than one flow control credits.

Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
 drivers/misc/mei/client.c | 21 ++++++++++++++++++++-
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c
index a6c87c713193..72e32615acd9 100644
--- a/drivers/misc/mei/client.c
+++ b/drivers/misc/mei/client.c
@@ -1422,6 +1422,25 @@ out:
 }
 
 /**
+ * mei_cl_is_read_fc_cb - check if read cb is waiting for flow control
+ *                        for given host client
+ *
+ * @cl: host client
+ *
+ * Return: true, if found at least one cb.
+ */
+static bool mei_cl_is_read_fc_cb(struct mei_cl *cl)
+{
+	struct mei_device *dev = cl->dev;
+	struct mei_cl_cb *cb;
+
+	list_for_each_entry(cb, &dev->ctrl_wr_list.list, list)
+		if (cb->fop_type == MEI_FOP_READ && cb->cl == cl)
+			return true;
+	return false;
+}
+
+/**
  * mei_cl_read_start - the start read client message function.
  *
  * @cl: host client
@@ -1445,7 +1464,7 @@ int mei_cl_read_start(struct mei_cl *cl, size_t length, struct file *fp)
 		return -ENODEV;
 
 	/* HW currently supports only one pending read */
-	if (!list_empty(&cl->rd_pending))
+	if (!list_empty(&cl->rd_pending) || mei_cl_is_read_fc_cb(cl))
 		return -EBUSY;
 
 	if (!mei_me_cl_is_active(cl->me_cl)) {
-- 
2.4.3

[char-misc-next 4/6 RESEND] mei: always copy the read buffer if data is ready

[Tomas Winkler]

From: Alexander Usyskin <alexander.usyskin@intel.com>

Copy completed callback content to the user space
if we have such callback ready in the beginning of the read.
Simplify offset processing logic as byproduct.

This is a refinement for:
commit 139aacf757fc ("mei: fix read after read scenario")

Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
 drivers/misc/mei/main.c | 32 ++++++++++++++------------------
 1 file changed, 14 insertions(+), 18 deletions(-)

diff --git a/drivers/misc/mei/main.c b/drivers/misc/mei/main.c
index b2f2486b3d75..1ee8b492fc4a 100644
--- a/drivers/misc/mei/main.c
+++ b/drivers/misc/mei/main.c
@@ -159,27 +159,22 @@ static ssize_t mei_read(struct file *file, char __user *ubuf,
 		goto out;
 	}
 
+	if (ubuf == NULL) {
+		rets = -EMSGSIZE;
+		goto out;
+	}
+
 	if (cl == &dev->iamthif_cl) {
 		rets = mei_amthif_read(dev, file, ubuf, length, offset);
 		goto out;
 	}
 
 	cb = mei_cl_read_cb(cl, file);
-	if (cb) {
-		/* read what left */
-		if (cb->buf_idx > *offset)
-			goto copy_buffer;
-		/* offset is beyond buf_idx we have no more data return 0 */
-		if (cb->buf_idx > 0 && cb->buf_idx <= *offset) {
-			rets = 0;
-			goto free;
-		}
-		/* Offset needs to be cleaned for contiguous reads*/
-		if (cb->buf_idx == 0 && *offset > 0)
-			*offset = 0;
-	} else if (*offset > 0) {
+	if (cb)
+		goto copy_buffer;
+
+	if (*offset > 0)
 		*offset = 0;
-	}
 
 	err = mei_cl_read_start(cl, length, file);
 	if (err && err != -EBUSY) {
@@ -231,10 +226,10 @@ copy_buffer:
 		goto free;
 	}
 
-	cl_dbg(dev, cl, "buf.size = %d buf.idx = %ld\n",
-	    cb->buf.size, cb->buf_idx);
-	if (length == 0 || ubuf == NULL || *offset > cb->buf_idx) {
-		rets = -EMSGSIZE;
+	cl_dbg(dev, cl, "buf.size = %d buf.idx = %ld offset = %lld\n",
+	       cb->buf.size, cb->buf_idx, *offset);
+	if (*offset >= cb->buf_idx) {
+		rets = 0;
 		goto free;
 	}
 
@@ -255,6 +250,7 @@ copy_buffer:
 
 free:
 	mei_io_cb_free(cb);
+	*offset = 0;
 
 out:
 	cl_dbg(dev, cl, "end mei read rets = %d\n", rets);
-- 
2.4.3

[char-misc-next 5/6 RESEND] mei: fix fasync return value on error

[Tomas Winkler]

fasync should return a negative value on error
and not poll mask POLLERR.

Cc: <stable@vger.kernel.org> # 4.3+
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
 drivers/misc/mei/main.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/mei/main.c b/drivers/misc/mei/main.c
index 1ee8b492fc4a..36ca15234344 100644
--- a/drivers/misc/mei/main.c
+++ b/drivers/misc/mei/main.c
@@ -653,7 +653,9 @@ out:
  * @file: pointer to file structure
  * @band: band bitmap
  *
- * Return: poll mask
+ * Return: negative on error,
+ *         0 if it did no changes,
+ *         and positive a process was added or deleted
  */
 static int mei_fasync(int fd, struct file *file, int band)
 {
@@ -661,7 +663,7 @@ static int mei_fasync(int fd, struct file *file, int band)
 	struct mei_cl *cl = file->private_data;
 
 	if (!mei_cl_is_connected(cl))
-		return POLLERR;
+		return -ENODEV;
 
 	return fasync_helper(fd, file, band, &cl->ev_async);
 }
-- 
2.4.3

[char-misc-next 6/6 RESEND] mei: drop nfc leftovers from the mei driver

[Tomas Winkler]

We left few function prototypes in the header file after
moving nfc logic to bus.

Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
 drivers/misc/mei/mei_dev.h | 11 -----------
 1 file changed, 11 deletions(-)

diff --git a/drivers/misc/mei/mei_dev.h b/drivers/misc/mei/mei_dev.h
index 4250555d5e72..b54d9d9cacea 100644
--- a/drivers/misc/mei/mei_dev.h
+++ b/drivers/misc/mei/mei_dev.h
@@ -649,17 +649,6 @@ int mei_amthif_irq_read_msg(struct mei_cl *cl,
 			    struct mei_cl_cb *complete_list);
 int mei_amthif_irq_read(struct mei_device *dev, s32 *slots);
 
-/*
- * NFC functions
- */
-int mei_nfc_host_init(struct mei_device *dev, struct mei_me_client *me_cl);
-void mei_nfc_host_exit(struct mei_device *dev);
-
-/*
- * NFC Client UUID
- */
-extern const uuid_le mei_nfc_guid;
-
 int mei_wd_send(struct mei_device *dev);
 int mei_wd_stop(struct mei_device *dev);
 int mei_wd_host_init(struct mei_device *dev, struct mei_me_client *me_cl);
-- 
2.4.3

Re: [char-misc-next RESEND 0/6] mei updates

[Greg Kroah-Hartman]

On Thu, Jan 07, 2016 at 02:46:33PM +0200, Tomas Winkler wrote:
> I've sent those patches ~ two months ago but were probably dropped from
> the queue so resending them again.

sorry, they are still in there, it's been a busy few months, I'll get to
these for the next release, it's too late for this one, my fault.

greg k-h

RE: [char-misc-next RESEND 0/6] mei updates

[Winkler, Tomas]

> On Thu, Jan 07, 2016 at 02:46:33PM +0200, Tomas Winkler wrote:
> > I've sent those patches ~ two months ago but were probably dropped from
> > the queue so resending them again.
> 
> sorry, they are still in there, it's been a busy few months, I'll get to
> these for the next release, it's too late for this one, my fault. 

Can you be specific what is next release, the merging window is still not open...
I have tons of patches it is just blocked by the watchdog removal from the core driver, which I've just reposted as well on top of this series. 

Thanks
Tomas 

Re: [char-misc-next RESEND 0/6] mei updates

[Greg Kroah-Hartman]

On Thu, Jan 07, 2016 at 10:56:34PM +0000, Winkler, Tomas wrote:
> 
> 
> > On Thu, Jan 07, 2016 at 02:46:33PM +0200, Tomas Winkler wrote:
> > > I've sent those patches ~ two months ago but were probably dropped from
> > > the queue so resending them again.
> > 
> > sorry, they are still in there, it's been a busy few months, I'll get to
> > these for the next release, it's too late for this one, my fault. 
> 
> Can you be specific what is next release, the merging window is still not open...

The "merge window" is for subsystem maintainers to merge to Linus, I
have to have my tree "closed" for a week before that for linux-next to
settle down.  It's been this way for a very long time.

> I have tons of patches it is just blocked by the watchdog removal from
> the core driver, which I've just reposted as well on top of this
> series. 

Sorry for the delay these past 2 months, should be caught up for the
next release cycle.  And your watchdog repost wouldn't have made it into
this release anyway :)

thanks,

greg k-h

RE: [char-misc-next RESEND 0/6] mei updates

[Winkler, Tomas]

> 
> On Thu, Jan 07, 2016 at 10:56:34PM +0000, Winkler, Tomas wrote:
> >
> >
> > > On Thu, Jan 07, 2016 at 02:46:33PM +0200, Tomas Winkler wrote:
> > > > I've sent those patches ~ two months ago but were probably dropped from
> > > > the queue so resending them again.
> > >
> > > sorry, they are still in there, it's been a busy few months, I'll get to
> > > these for the next release, it's too late for this one, my fault.
> >
> > Can you be specific what is next release, the merging window is still not open...
> 
> The "merge window" is for subsystem maintainers to merge to Linus, I
> have to have my tree "closed" for a week before that for linux-next to
> settle down.  It's been this way for a very long time.

Understood, I've just paid attention that the parport patches was applied  last few days so I've also tried my luck
Anyhow please reconsider ' mei: fix fasync return value on error' which was originally indented for 4.4-rc5 and should go to the stable.

> 
> > I have tons of patches it is just blocked by the watchdog removal from
> > the core driver, which I've just reposted as well on top of this
> > series.
> 
> Sorry for the delay these past 2 months, should be caught up for the
> next release cycle.  And your watchdog repost wouldn't have made it into
> this release anyway :)

Okay, I would just ask you to do give some priority to review our patches after the merging window so I don't have to carry too long queue for months. 
 
Tomas
Thanks

Re: [char-misc-next RESEND 0/6] mei updates

[Greg Kroah-Hartman]

On Thu, Jan 07, 2016 at 11:32:20PM +0000, Winkler, Tomas wrote:
> 
> > 
> > On Thu, Jan 07, 2016 at 10:56:34PM +0000, Winkler, Tomas wrote:
> > >
> > >
> > > > On Thu, Jan 07, 2016 at 02:46:33PM +0200, Tomas Winkler wrote:
> > > > > I've sent those patches ~ two months ago but were probably dropped from
> > > > > the queue so resending them again.
> > > >
> > > > sorry, they are still in there, it's been a busy few months, I'll get to
> > > > these for the next release, it's too late for this one, my fault.
> > >
> > > Can you be specific what is next release, the merging window is still not open...
> > 
> > The "merge window" is for subsystem maintainers to merge to Linus, I
> > have to have my tree "closed" for a week before that for linux-next to
> > settle down.  It's been this way for a very long time.
> 
> Understood, I've just paid attention that the parport patches was
> applied  last few days so I've also tried my luck Anyhow please
> reconsider ' mei: fix fasync return value on error' which was
> originally indented for 4.4-rc5 and should go to the stable.

the parport ones were tiny code style issues.  I'll go look at this
fasync patch now...

thanks,

greg k-h

Re: [char-misc-next RESEND 0/6] mei updates

[Sudip Mukherjee]

On Thu, Jan 07, 2016 at 05:02:00PM -0800, Greg Kroah-Hartman wrote:
> On Thu, Jan 07, 2016 at 11:32:20PM +0000, Winkler, Tomas wrote:
> > 
> > > 
> > > On Thu, Jan 07, 2016 at 10:56:34PM +0000, Winkler, Tomas wrote:
> > > >
> > > >
> > > > > On Thu, Jan 07, 2016 at 02:46:33PM +0200, Tomas Winkler wrote:
> > > > > > I've sent those patches ~ two months ago but were probably dropped from
> > > > > > the queue so resending them again.
> > > > >
> > > > > sorry, they are still in there, it's been a busy few months, I'll get to
> > > > > these for the next release, it's too late for this one, my fault.
> > > >
> > > > Can you be specific what is next release, the merging window is still not open...
> > > 
> > > The "merge window" is for subsystem maintainers to merge to Linus, I
> > > have to have my tree "closed" for a week before that for linux-next to
> > > settle down.  It's been this way for a very long time.
> > 
> > Understood, I've just paid attention that the parport patches was
> > applied  last few days so I've also tried my luck Anyhow please
> > reconsider ' mei: fix fasync return value on error' which was
> > originally indented for 4.4-rc5 and should go to the stable.
> 
> the parport ones were tiny code style issues.  I'll go look at this
> fasync patch now...

Thanks for the parport. I didn't expect you will apply that at this
time.
Can you please also have a look at:
[PATCH] drivers/tty/serial: delete unused MODULE_DEVICE_TABLE from atmel_serial.c
by Paul Gortmaker <paul.gortmaker@windriver.com>

rc1 allmodconfig build will fail in some arch without this. But no hurries,
since it is a fix it can go for rc2 also. :)

regards
sudip

Re: [char-misc-next RESEND 0/6] mei updates

[Greg Kroah-Hartman]

On Sat, Jan 09, 2016 at 10:29:52AM +0530, Sudip Mukherjee wrote:
> On Thu, Jan 07, 2016 at 05:02:00PM -0800, Greg Kroah-Hartman wrote:
> > On Thu, Jan 07, 2016 at 11:32:20PM +0000, Winkler, Tomas wrote:
> > > 
> > > > 
> > > > On Thu, Jan 07, 2016 at 10:56:34PM +0000, Winkler, Tomas wrote:
> > > > >
> > > > >
> > > > > > On Thu, Jan 07, 2016 at 02:46:33PM +0200, Tomas Winkler wrote:
> > > > > > > I've sent those patches ~ two months ago but were probably dropped from
> > > > > > > the queue so resending them again.
> > > > > >
> > > > > > sorry, they are still in there, it's been a busy few months, I'll get to
> > > > > > these for the next release, it's too late for this one, my fault.
> > > > >
> > > > > Can you be specific what is next release, the merging window is still not open...
> > > > 
> > > > The "merge window" is for subsystem maintainers to merge to Linus, I
> > > > have to have my tree "closed" for a week before that for linux-next to
> > > > settle down.  It's been this way for a very long time.
> > > 
> > > Understood, I've just paid attention that the parport patches was
> > > applied  last few days so I've also tried my luck Anyhow please
> > > reconsider ' mei: fix fasync return value on error' which was
> > > originally indented for 4.4-rc5 and should go to the stable.
> > 
> > the parport ones were tiny code style issues.  I'll go look at this
> > fasync patch now...
> 
> Thanks for the parport. I didn't expect you will apply that at this
> time.
> Can you please also have a look at:
> [PATCH] drivers/tty/serial: delete unused MODULE_DEVICE_TABLE from atmel_serial.c
> by Paul Gortmaker <paul.gortmaker@windriver.com>
> 
> rc1 allmodconfig build will fail in some arch without this. But no hurries,
> since it is a fix it can go for rc2 also. :)

Ah crap, I though I had picked up the needed tty/serial fixes, but I
missed that one, thanks, will go get to it now...

Is there anything else that you happened to notice that I should get
into 4.5-rc1 that I missed?

thanks,

greg k-h

Re: [char-misc-next RESEND 0/6] mei updates

[Sudip Mukherjee]

On Fri, Jan 08, 2016 at 09:10:11PM -0800, Greg Kroah-Hartman wrote:
> On Sat, Jan 09, 2016 at 10:29:52AM +0530, Sudip Mukherjee wrote:
> > On Thu, Jan 07, 2016 at 05:02:00PM -0800, Greg Kroah-Hartman wrote:
> > > On Thu, Jan 07, 2016 at 11:32:20PM +0000, Winkler, Tomas wrote:
> > > > 
> > > > > 
> > > > > On Thu, Jan 07, 2016 at 10:56:34PM +0000, Winkler, Tomas wrote:
> > > > > >
> > > > > >
> > > > > > > On Thu, Jan 07, 2016 at 02:46:33PM +0200, Tomas Winkler wrote:
> > > > > > > > I've sent those patches ~ two months ago but were probably dropped from
> > > > > > > > the queue so resending them again.
> > > > > > >
> > > > > > > sorry, they are still in there, it's been a busy few months, I'll get to
> > > > > > > these for the next release, it's too late for this one, my fault.
> > > > > >
> > > > > > Can you be specific what is next release, the merging window is still not open...
> > > > > 
> > > > > The "merge window" is for subsystem maintainers to merge to Linus, I
> > > > > have to have my tree "closed" for a week before that for linux-next to
> > > > > settle down.  It's been this way for a very long time.
> > > > 
> > > > Understood, I've just paid attention that the parport patches was
> > > > applied  last few days so I've also tried my luck Anyhow please
> > > > reconsider ' mei: fix fasync return value on error' which was
> > > > originally indented for 4.4-rc5 and should go to the stable.
> > > 
> > > the parport ones were tiny code style issues.  I'll go look at this
> > > fasync patch now...
> > 
> > Thanks for the parport. I didn't expect you will apply that at this
> > time.
> > Can you please also have a look at:
> > [PATCH] drivers/tty/serial: delete unused MODULE_DEVICE_TABLE from atmel_serial.c
> > by Paul Gortmaker <paul.gortmaker@windriver.com>
> > 
> > rc1 allmodconfig build will fail in some arch without this. But no hurries,
> > since it is a fix it can go for rc2 also. :)
> 
> Ah crap, I though I had picked up the needed tty/serial fixes, but I
> missed that one, thanks, will go get to it now...

Thanks.

> 
> Is there anything else that you happened to notice that I should get
> into 4.5-rc1 that I missed?

Nothing else from your side I guess, atleast not related to any build
failure that i monitor. There will be build failure related to some other
patches, one in drm and one in media. They are not yet in linux-next so
I don't have any idea if they will be included for rc1 or not.

regards
sudip

RE: [char-misc-next RESEND 0/6] mei updates

[Winkler, Tomas]

> 
> 
> >
> > On Thu, Jan 07, 2016 at 10:56:34PM +0000, Winkler, Tomas wrote:
> > >
> > >
> > > > On Thu, Jan 07, 2016 at 02:46:33PM +0200, Tomas Winkler wrote:
> > > > > I've sent those patches ~ two months ago but were probably dropped
> from
> > > > > the queue so resending them again.
> > > >
> > > > sorry, they are still in there, it's been a busy few months, I'll get to
> > > > these for the next release, it's too late for this one, my fault.
> > >
> > > Can you be specific what is next release, the merging window is still not
> open...
> >
> > The "merge window" is for subsystem maintainers to merge to Linus, I
> > have to have my tree "closed" for a week before that for linux-next to
> > settle down.  It's been this way for a very long time.
> 
> Understood, I've just paid attention that the parport patches was applied  last
> few days so I've also tried my luck
> Anyhow please reconsider ' mei: fix fasync return value on error' which was
> originally indented for 4.4-rc5 and should go to the stable.
> 
> >
> > > I have tons of patches it is just blocked by the watchdog removal from
> > > the core driver, which I've just reposted as well on top of this
> > > series.
> >
> > Sorry for the delay these past 2 months, should be caught up for the
> > next release cycle.  And your watchdog repost wouldn't have made it into
> > this release anyway :)
> 
> Okay, I would just ask you to do give some priority to review our patches after
> the merging window so I don't have to carry too long queue for months.

Hello Greg, 
After 4.5-rc1 was tagged, I would like to start sending  our patches for the char-misc-next branch 
I wonder if to resend the whole queue rebased or 4.5-rc1 or continuation of this series. 
 
Tomas
Thanks

Re: [char-misc-next RESEND 0/6] mei updates

['Greg Kroah-Hartman']

On Wed, Jan 27, 2016 at 09:22:17PM +0000, Winkler, Tomas wrote:
> > 
> > 
> > >
> > > On Thu, Jan 07, 2016 at 10:56:34PM +0000, Winkler, Tomas wrote:
> > > >
> > > >
> > > > > On Thu, Jan 07, 2016 at 02:46:33PM +0200, Tomas Winkler wrote:
> > > > > > I've sent those patches ~ two months ago but were probably dropped
> > from
> > > > > > the queue so resending them again.
> > > > >
> > > > > sorry, they are still in there, it's been a busy few months, I'll get to
> > > > > these for the next release, it's too late for this one, my fault.
> > > >
> > > > Can you be specific what is next release, the merging window is still not
> > open...
> > >
> > > The "merge window" is for subsystem maintainers to merge to Linus, I
> > > have to have my tree "closed" for a week before that for linux-next to
> > > settle down.  It's been this way for a very long time.
> > 
> > Understood, I've just paid attention that the parport patches was applied  last
> > few days so I've also tried my luck
> > Anyhow please reconsider ' mei: fix fasync return value on error' which was
> > originally indented for 4.4-rc5 and should go to the stable.
> > 
> > >
> > > > I have tons of patches it is just blocked by the watchdog removal from
> > > > the core driver, which I've just reposted as well on top of this
> > > > series.
> > >
> > > Sorry for the delay these past 2 months, should be caught up for the
> > > next release cycle.  And your watchdog repost wouldn't have made it into
> > > this release anyway :)
> > 
> > Okay, I would just ask you to do give some priority to review our patches after
> > the merging window so I don't have to carry too long queue for months.
> 
> Hello Greg, 
> After 4.5-rc1 was tagged, I would like to start sending  our patches for the char-misc-next branch 
> I wonder if to resend the whole queue rebased or 4.5-rc1 or continuation of this series. 

Which ever you want, it's up to you.

greg k-h

RE: [char-misc-next RESEND 0/6] mei updates

[Winkler, Tomas]

> 
> On Wed, Jan 27, 2016 at 09:22:17PM +0000, Winkler, Tomas wrote:
> > >
> > >
> > > >
> > > > On Thu, Jan 07, 2016 at 10:56:34PM +0000, Winkler, Tomas wrote:
> > > > >
> > > > >
> > > > > > On Thu, Jan 07, 2016 at 02:46:33PM +0200, Tomas Winkler wrote:
> > > > > > > I've sent those patches ~ two months ago but were probably dropped
> > > from
> > > > > > > the queue so resending them again.
> > > > > >
> > > > > > sorry, they are still in there, it's been a busy few months, I'll get to
> > > > > > these for the next release, it's too late for this one, my fault.
> > > > >
> > > > > Can you be specific what is next release, the merging window is still not
> > > open...
> > > >
> > > > The "merge window" is for subsystem maintainers to merge to Linus, I
> > > > have to have my tree "closed" for a week before that for linux-next to
> > > > settle down.  It's been this way for a very long time.
> > >
> > > Understood, I've just paid attention that the parport patches was applied  last
> > > few days so I've also tried my luck
> > > Anyhow please reconsider ' mei: fix fasync return value on error' which was
> > > originally indented for 4.4-rc5 and should go to the stable.
> > >
> > > >
> > > > > I have tons of patches it is just blocked by the watchdog removal from
> > > > > the core driver, which I've just reposted as well on top of this
> > > > > series.
> > > >
> > > > Sorry for the delay these past 2 months, should be caught up for the
> > > > next release cycle.  And your watchdog repost wouldn't have made it into
> > > > this release anyway :)
> > >
> > > Okay, I would just ask you to do give some priority to review our patches after
> > > the merging window so I don't have to carry too long queue for months.
> >
> > Hello Greg,
> > After 4.5-rc1 was tagged, I would like to start sending  our patches for the char-
> misc-next branch
> > I wonder if to resend the whole queue rebased or 4.5-rc1 or continuation of
> this series.
> 
> Which ever you want, it's up to you.
Okay, so please review apply this series and ignore the watchdog patches which I will resend later on.

Thanks 
Tomas 

Re: [char-misc-next RESEND 0/6] mei updates

[Greg Kroah-Hartman]

On Thu, Jan 07, 2016 at 02:46:33PM +0200, Tomas Winkler wrote:
> I've sent those patches ~ two months ago but were probably dropped from
> the queue so resending them again.
> 
> Alexander Usyskin (2):
>   mei: prevent queuing new flow control credit.
>   mei: always copy the read buffer if data is ready
> 
> Tomas Winkler (4):
>   mei: bus: remove redundant uuid string in debug messages
>   mei: trace pci configuration space io
>   mei: fix fasync return value on error
>   mei: drop nfc leftovers from the mei driver

Not all of these applied, please fix up and resend the missing ones.

thanks,

greg k-h

RE: [char-misc-next RESEND 0/6] mei updates

[Winkler, Tomas]

> -----Original Message-----
> From: Greg Kroah-Hartman [mailto:gregkh@linuxfoundation.org]
> Sent: Sunday, February 07, 2016 08:09
> To: Winkler, Tomas
> Cc: Usyskin, Alexander; linux-kernel@vger.kernel.org
> Subject: Re: [char-misc-next RESEND 0/6] mei updates
> 
> On Thu, Jan 07, 2016 at 02:46:33PM +0200, Tomas Winkler wrote:
> > I've sent those patches ~ two months ago but were probably dropped from
> > the queue so resending them again.
> >
> > Alexander Usyskin (2):
> >   mei: prevent queuing new flow control credit.
> >   mei: always copy the read buffer if data is ready
> >
> > Tomas Winkler (4):
> >   mei: bus: remove redundant uuid string in debug messages
> >   mei: trace pci configuration space io
> >   mei: fix fasync return value on error
> >   mei: drop nfc leftovers from the mei driver
> 
> Not all of these applied, please fix up and resend the missing ones.
Will do though, have you applied this one for 4.5-rcX? http://www.spinics.net/lists/stable/msg115051.html
Thanks
Tomas

Re: [char-misc-next RESEND 0/6] mei updates

[Greg Kroah-Hartman]

On Sun, Feb 07, 2016 at 09:17:11AM +0000, Winkler, Tomas wrote:
> 
> 
> > -----Original Message-----
> > From: Greg Kroah-Hartman [mailto:gregkh@linuxfoundation.org]
> > Sent: Sunday, February 07, 2016 08:09
> > To: Winkler, Tomas
> > Cc: Usyskin, Alexander; linux-kernel@vger.kernel.org
> > Subject: Re: [char-misc-next RESEND 0/6] mei updates
> > 
> > On Thu, Jan 07, 2016 at 02:46:33PM +0200, Tomas Winkler wrote:
> > > I've sent those patches ~ two months ago but were probably dropped from
> > > the queue so resending them again.
> > >
> > > Alexander Usyskin (2):
> > >   mei: prevent queuing new flow control credit.
> > >   mei: always copy the read buffer if data is ready
> > >
> > > Tomas Winkler (4):
> > >   mei: bus: remove redundant uuid string in debug messages
> > >   mei: trace pci configuration space io
> > >   mei: fix fasync return value on error
> > >   mei: drop nfc leftovers from the mei driver
> > 
> > Not all of these applied, please fix up and resend the missing ones.
> Will do though, have you applied this one for 4.5-rcX? http://www.spinics.net/lists/stable/msg115051.html

You should have gotten an email saying I did so...