<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/misc/mei/main.c, branch linux-4.17.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.17.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.17.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2018-03-14T18:33:13Z</updated>
<entry>
<title>mei: remove dev_err message on an unsupported ioctl</title>
<updated>2018-03-14T18:33:13Z</updated>
<author>
<name>Colin Ian King</name>
</author>
<published>2018-02-27T16:21:05Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=bb0829a741792b56c908d7745bc0b2b540293bcc'/>
<id>urn:sha1:bb0829a741792b56c908d7745bc0b2b540293bcc</id>
<content type='text'>
Currently the driver spams the kernel log on unsupported ioctls which is
unnecessary as the ioctl returns -ENOIOCTLCMD to indicate this anyway.
I suspect this was originally for debugging purposes but it really is not
required so remove it.

Signed-off-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mei: limit the number of queued writes</title>
<updated>2018-03-14T18:33:13Z</updated>
<author>
<name>Alexander Usyskin</name>
</author>
<published>2018-02-25T18:07:05Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=af336cabe08363ba8493e7d7e5d070353eb30caa'/>
<id>urn:sha1:af336cabe08363ba8493e7d7e5d070353eb30caa</id>
<content type='text'>
Limit the number of queued writes per client.
Writes above this threshold are blocked till place
in the transmit queue is available.
The limit is configurable via sysfs and defaults to 50.
The implementation should provide blocking I/O behavior.
Prior to this change one would end up in the hands of OOM.

Signed-off-by: Alexander Usyskin &lt;alexander.usyskin@intel.com&gt;
Signed-off-by: Tomas Winkler &lt;tomas.winkler@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>vfs: do bulk POLL* -&gt; EPOLL* replacement</title>
<updated>2018-02-11T22:34:03Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2018-02-11T22:34:03Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a9a08845e9acbd224e4ee466f5c1275ed50054e8'/>
<id>urn:sha1:a9a08845e9acbd224e4ee466f5c1275ed50054e8</id>
<content type='text'>
This is the mindless scripted replacement of kernel use of POLL*
variables as described by Al, done by this script:

    for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do
        L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'`
        for f in $L; do sed -i "-es/^\([^\"]*\)\(\&lt;POLL$V\&gt;\)/\\1E\\2/" $f; done
    done

with de-mangling cleanups yet to come.

NOTE! On almost all architectures, the EPOLL* constants have the same
values as the POLL* constants do.  But they keyword here is "almost".
For various bad reasons they aren't the same, and epoll() doesn't
actually work quite correctly in some cases due to this on Sparc et al.

The next patch from Al will sort out the final differences, and we
should be all done.

Scripted-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>the rest of drivers/*: annotate -&gt;poll() instances</title>
<updated>2017-11-28T16:06:58Z</updated>
<author>
<name>Al Viro</name>
</author>
<published>2017-07-03T10:39:46Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=afc9a42b7464f76e1388cad87d8543c69f6f74ed'/>
<id>urn:sha1:afc9a42b7464f76e1388cad87d8543c69f6f74ed</id>
<content type='text'>
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>annotate poll_table_struct -&gt;_key</title>
<updated>2017-11-27T21:19:54Z</updated>
<author>
<name>Al Viro</name>
</author>
<published>2017-07-03T07:14:15Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=01699437758328090813212ecefe3ab6f0d5b9cc'/>
<id>urn:sha1:01699437758328090813212ecefe3ab6f0d5b9cc</id>
<content type='text'>
Only POLL... bitmaps ever end up there and their only use is checking
for POLL... bits in them.

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>mei: implement fsync</title>
<updated>2017-04-08T15:38:25Z</updated>
<author>
<name>Alexander Usyskin</name>
</author>
<published>2017-03-20T13:04:06Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=58cde1a64c5e140e6ba498aaa406e063957e35df'/>
<id>urn:sha1:58cde1a64c5e140e6ba498aaa406e063957e35df</id>
<content type='text'>
When write() returns successfully, it is only assumed that a message
was successfully queued. Add fsync syscall implementation to help
user-space ensure that all data is written.

Signed-off-by: Tomas Winkler &lt;tomas.winkler@intel.com&gt;
Signed-off-by: Alexander Usyskin &lt;alexander.usyskin@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mei: drop amthif internal client</title>
<updated>2017-04-08T15:38:25Z</updated>
<author>
<name>Alexander Usyskin</name>
</author>
<published>2017-03-20T13:04:03Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=394a77d0bb63756871750400068d8b0c3582fba7'/>
<id>urn:sha1:394a77d0bb63756871750400068d8b0c3582fba7</id>
<content type='text'>
AMTHIF has special support in the mei drive, it handles multiplexing
multiple user space connection above single me client connection.
Since there is no additional addressing information there is a strict
requirement on the traffic order on each connection and on the "read
after write" order within the connection. This creates a lot of
complexity mostly because the other client types do not necessarily fall
under the same restriction.    After carefully studying the use of the
AMTHIF client, we came to conclusion that the multiplexing is not really
utilized by any application and we may safely remove that support and
significantly simplify the driver.

Signed-off-by: Alexander Usyskin &lt;alexander.usyskin@intel.com&gt;
Signed-off-by: Tomas Winkler &lt;tomas.winkler@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>sched/headers: Prepare to move signal wakeup &amp; sigpending methods from &lt;linux/sched.h&gt; into &lt;linux/sched/signal.h&gt;</title>
<updated>2017-03-02T07:42:32Z</updated>
<author>
<name>Ingo Molnar</name>
</author>
<published>2017-02-02T18:15:33Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=174cd4b1e5fbd0d74c68cf3a74f5bd4923485512'/>
<id>urn:sha1:174cd4b1e5fbd0d74c68cf3a74f5bd4923485512</id>
<content type='text'>
Fix up affected files that include this signal functionality via sched.h.

Acked-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Mike Galbraith &lt;efault@gmx.de&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</content>
</entry>
<entry>
<title>mei: remove support for broken parallel read</title>
<updated>2017-02-10T14:20:44Z</updated>
<author>
<name>Alexander Usyskin</name>
</author>
<published>2017-02-07T22:41:45Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=cb97fbbcac15982406e0c74cd5512a8b6fcf10b3'/>
<id>urn:sha1:cb97fbbcac15982406e0c74cd5512a8b6fcf10b3</id>
<content type='text'>
Parallel reads from multiple threads on a file descriptor
are not well defined and racy. It is safer to return to original
behavior and simply fail the additional read.
The solution is to remove request for next read credit.

Cc: &lt;stable@vger.kernel.org&gt; #4.9
Fixes: ff1586a7ea57 ("mei: enqueue consecutive reads")
Signed-off-by: Alexander Usyskin &lt;alexander.usyskin@intel.com&gt;
Signed-off-by: Tomas Winkler &lt;tomas.winkler@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mei: enable to set the internal flag for client write</title>
<updated>2016-11-10T12:18:02Z</updated>
<author>
<name>Alexander Usyskin</name>
</author>
<published>2016-11-08T16:26:08Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e0cb6b2f878d210441e8ed232e98454ccc7fd812'/>
<id>urn:sha1:e0cb6b2f878d210441e8ed232e98454ccc7fd812</id>
<content type='text'>
Prepare the client write functions to set the internal flag in message
header. Carry both blocking and internal modes inside the transmit cb,
and call internal bus function  __mei_cl_send() with send mode bit mask.
The Internal flag should be added only on messages generated by the
driver.

Signed-off-by: Alexander Usyskin &lt;alexander.usyskin@intel.com&gt;
Signed-off-by: Tomas Winkler &lt;tomas.winkler@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
