Re: [PATCH v2 01/12] fs-verity: add a documentation file

2018-12-21 Thread Matthew Wilcox
On Fri, Dec 21, 2018 at 10:47:14AM -0500, Theodore Y. Ts'o wrote:
> Linus --- we're going round and round, and I don't think this is
> really a technical dispute at this point, but rather an aesthetics
> one.  Will you be willing to accept my pull request for a feature
> which is being shippped on millions of Android phones, has been out
> for review for months, and for which, if we *really* need to add
> uselessly complicated interface later, we can do that?  It's always
> been the case for internal Kernel interfaces not to add code "just in
> case" it's useful, but rather when a user turns up.  I argue we should
> be doing the same thing for user-space visible interfaces.

To look at it another way, this is an aesthetic dispute in which all those
who have offered opinions from outside Google -- myself, Dave Chinner &
Christoph all really dislike this interface.  I'd be happy to discuss
alternative interfaces, particularly ones which allow for the current
internal implementation, but I think this interface is really bad.

In contrast to "we'll just fix it up later" (which usually applies
to in-kernel interfaces), we have a policy of not breaking userspace,
so accepting this interface means setting it in stone.  We should get
it right.


Re: [PATCH v2 01/12] fs-verity: add a documentation file

2018-12-21 Thread Theodore Y. Ts'o
On Thu, Dec 20, 2018 at 11:04:47PM -0800, Christoph Hellwig wrote:
> Ted, I think you know yourself this isn't true.  Whenever we added
> useful interface to one of the major file systems we had other pick
> it up, and that is a good thing because the last thing we need is
> fragmentation of interfaces.  And even if that wasn't the case I don't
> think we should take short cuts, because even if an interface was just
> for a file system or two it still needs to be properly desgined.

This is why I think the interface argument is totally bogus.

If you're OK with Darrick's suggested interface, where you pass in a
file descriptor, offset and length --- that's just a superset of the
current interface, except where the file descriptor is in the file
which is going to be protected using fs-verity.  So there's if you're
OK with that interface, we can add that interface later, and it's
really no big deal; it certainly doesn't add any extra complexity for
XFS --- assuming that XFS even gets around to adding support for
fs-verity.

Adding that extra complexity is not necessary for the current users of
the interface, and as I've said multiple times before, there's no
*value* in allowing the Merkle tree to be passed in via some arbitrary
file descriptor, which might even be on a separate fhile system, as
opposed in the file which is about to be protected using fs-verity.

Linus --- we're going round and round, and I don't think this is
really a technical dispute at this point, but rather an aesthetics
one.  Will you be willing to accept my pull request for a feature
which is being shippped on millions of Android phones, has been out
for review for months, and for which, if we *really* need to add
uselessly complicated interface later, we can do that?  It's always
been the case for internal Kernel interfaces not to add code "just in
case" it's useful, but rather when a user turns up.  I argue we should
be doing the same thing for user-space visible interfaces.

Regards,

- Ted



Re: [PATCH] drm: add capability DRM_CAP_ASYNC_UPDATE

2018-12-21 Thread Michel Dänzer
On 2018-12-21 2:26 p.m., Daniel Vetter wrote:
> On Fri, Dec 21, 2018 at 10:47:27AM +0100, Michel Dänzer wrote:
>> On 2018-12-20 6:16 p.m., Michel Dänzer wrote:
>>> On 2018-12-20 6:09 p.m., Daniel Vetter wrote:
 On Thu, Dec 20, 2018 at 6:03 PM Alex Deucher  wrote:
> On Thu, Dec 20, 2018 at 11:54 AM Daniel Vetter  wrote:

>> Not sure about the gamma thing since we had opposite bugs on i915
>> about gamma not being vsynced and tearing terribly. Cursor is special
>> since it tends to be too small to notice tearing.
>
> Our cursor hw (and possibly gamma as well Nicholas?  Harry?) is double
> buffered, so we can update it any time for the most part and the
> changes won't take affect until the next vupdate period.

 Hm, I guess we could make the gamma update optionally async, and let
 drivers deal. The issue is that the current async helper stuff won't
 cope with gamma updates (it's aimed at plane updates only, not at crtc
 property updates). Or we get userspace to do proper atomic updates. Or
 we do some faking in the kernel, e.g. waiting with the gamma update
 until the next atomic update happens. But that kinda breaks
 ->atomic_check.
>>>
>>> Would it be possible to merge gamma changes into a pending commit, if
>>> there is one, and create a new commit otherwise?
>>>
>>> Otherwise the atomic API just moves this same problem to be solved by
>>> userspace.
>>
>> Actually, I'm not sure this is even solvable in a Xorg driver. When it
>> gets called to update the gamma LUT:
>>
>> 1. If there's a pending atomic commit, it cannot amend that, can it?
> 
> Yup, but on the kernel side we kinda have the same problem.

It's probably easier to solve in the kernel though; any solution
allowing userspace to amend commits would likely need similar changes in
the kernel anyway.


>> 2. It has no way of knowing when the next atomic commit would be
>> submitted e.g. for a page flip, so it kind of has to create its own
>> commit for the gamma update.
> 
> Block handler is what I had in mind for the fallback commit, if no other
> commit happened meanwhile (which would need to include it).

The BlockHandler runs more or less immediately after the gamma update,
after any other X11 requests submitted later by the same client and
flushed to the X server together. So this would still result in a commit
with only the gamma update most of the time. There might be a small
chance of combining with a flip with something like Night Light which is
done by the compositor itself (but still only if the compositor defers
the gamma update until just before it call SwapBuffers), basically 0
chance with something separate like RedShift.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer


Fair Pay Available Source OS year end summary:

2018-12-21 Thread Ywe Cærlyn
I have been working with the philosophy behind Oxxoï For Fair O.S. the last 
half year and a bit more, and it is implementations of practical principles 
from my research on monotheism that has been top 1% on academia.edu that is the 
background, and present a summary for what it is about. 


Oxxoi For Fair O.S.
---


Delyar: absolute, global online currency, decentralized and free from inflation.

FPY Licence: intended for use in a system, where fair pay transactions are 
done, for use, maintenance  and support. Free for poor.

Islam: Coherent philosophy, replacing The Bible, as background in earlier OSs 
(Unix), also with a  zën-concept of The Gódh, that works in our culture, Oxxoi, 
that has decreed "deal justly", and is the  background for Fair Pay OS 
reasoning and labour party politics that are similar, and work union  efforts, 
also using The Miriam Font, for script-like text accuracy.

Ultimate Iterations Of Tech: [1.] 4K (8k quadratic WR-GB subpixels) standard 
screenmode, for minimal  psychovisual noise, at 72.734HZ refresh rate, also 
minimal psychovisual noise, approximating reality,  and monotheistic principles 
most. [2.] Fast Fantasymode Reduced Rendering Surface Gaming Mode, for  games: 
1920x1080 rendering with 2x multisampling antialiasing only (transparency 
multisampling also  on) for smoothing the edges just a bit, more gets blurry, 
and 2x anistotropic filtering, for round  edges on zoomed textures and "game 
profile", and also -0.1250 lod bias, for "game profile". Negative  lod bias 
allowed, high quality filtering, and no trilinear optimization. Upscaled 3x by 
NN, and  followed by a median filter, for extrapolating a pseudo 3x res, and 
resampled to 4K,  with a bicubic  (a=75) filter. 
(https://www.youtube.com/watch?v=gOnHhchv4k8) [3.] One Pole Diode Filter DA 
converter,  for ultrahigh speed hi-frequency 1 bit stream gibbsfree DA 
conversion, for professional -110dB  noisefloor. [4.] CPU: Instruction set, may 
combined several things in one clock, for higher virtual  frequency, and closer 
to high-level paradigm thinking. For instance, a 4pole filter (one input, one  
output), can be combined into a one clock operation. JSR could take arguments. 
And commonly used  functions, that has just one input, and one output, can be 
done in one clock, And this could even be  done in parallel. (Particulary what 
needs to be optimized is ofcourse the inner loop, beyond the HZ  timer, which 
in our testing is best at 90).

Beneficience: We also ofcourse fully support 3d-printed clothing, houses and 
tools.  Maybe even for a  little Decentralized On-Grid Non-city technology 
developments driven life one day, taking centralized  efforts and technology, 
to decentralized growth places.

Technocracy: The ultimate conclusion on a resulting political system is a 
technocracy, more democratic  than a democracy, and theocratic like a 
theocracy, where a Léad manages specialists seleted by their  workgroup. This 
all part of information reduction to a managable level, and with a standard  
monotheistic language.


Have a nice Vacations Season.
Ywe Cærlyn.


RE: [PATCH] treewide: replace RETPOLINE with CONFIG_RETPOLINE

2018-12-21 Thread David Laight
From: Borislav Petkov
> Sent: 21 December 2018 10:47
> On Fri, Dec 21, 2018 at 05:33:47PM +0800, WANG Chao wrote:
> > On 12/11/18 at 12:37P, WANG Chao wrote:
> > > Since commit 4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend
> > > on compiler support"), RETPOLINE has been replaced by CONFIG_RETPOLINE.
> > >
> > > Fixes: 4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend on 
> > > compiler support")
> > > Signed-off-by: WANG Chao 
> >
> > ping ...
> 
> This one somehow slipped through the cracks... :-\
> 
> Ok, let's see: this could be relevant for the case when a module built
> with a compiler which doesn't support retpolines, gets loaded on a
> system which is built with retpolines.

Isn't the real problem someone taking a kernel from (say) kernel.org
that is compiled for retpolines and then trying to compile an additional
module on a system that has an old compiler?

> Which is pretty seldom as the majority of setups out there should have
> a retpoline-enabled compiler. And should not allow loading external
> modules anyway, but that's a different story.

Most of an external module is likely to be a big '.o' file that (I expect)
has to be compiled without retpolines in order to be linkable into old
kernels.
(Either that or it doesn't matter at all because it is just a change
to the generated code.)

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)


[PATCH v2] staging: rtlwifi: convert to DEFINE_SHOW_ATTRIBUTE

2018-12-21 Thread Yangtao Li
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.

Signed-off-by: Yangtao Li 
---
v2:
-modify RTL_DEBUGFS_ADD_CORE macro
---
 drivers/staging/rtlwifi/debug.c | 23 ++-
 1 file changed, 6 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/rtlwifi/debug.c b/drivers/staging/rtlwifi/debug.c
index 8999feda29b4..dd1cc27e9544 100644
--- a/drivers/staging/rtlwifi/debug.c
+++ b/drivers/staging/rtlwifi/debug.c
@@ -79,24 +79,13 @@ struct rtl_debugfs_priv {
 
 static struct dentry *debugfs_topdir;
 
-static int rtl_debug_get_common(struct seq_file *m, void *v)
+static int common_show(struct seq_file *m, void *v)
 {
struct rtl_debugfs_priv *debugfs_priv = m->private;
 
return debugfs_priv->cb_read(m, v);
 }
-
-static int dl_debug_open_common(struct inode *inode, struct file *file)
-{
-   return single_open(file, rtl_debug_get_common, inode->i_private);
-}
-
-static const struct file_operations file_ops_common = {
-   .open = dl_debug_open_common,
-   .read = seq_read,
-   .llseek = seq_lseek,
-   .release = single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(common);
 
 static int rtl_debug_get_mac_page(struct seq_file *m, void *v)
 {
@@ -439,7 +428,7 @@ static ssize_t rtl_debugfs_common_write(struct file *filp,
return debugfs_priv->cb_write(filp, buffer, count, loff);
 }
 
-static const struct file_operations file_ops_common_write = {
+static const struct file_operations common_write_fops = {
.owner = THIS_MODULE,
.write = rtl_debugfs_common_write,
.open = simple_open,
@@ -488,7 +477,7 @@ static int rtl_debugfs_open_rw(struct inode *inode, struct 
file *filp)
int ret = 0;
 
if (filp->f_mode & FMODE_READ)
-   ret = single_open(filp, rtl_debug_get_common, inode->i_private);
+   ret = single_open(filp, common_show, inode->i_private);
else
filp->private_data = inode->i_private;
 
@@ -509,7 +498,7 @@ static struct rtl_debugfs_priv rtl_debug_priv_phydm_cmd = {
.cb_data = 0,
 };
 
-static const struct file_operations file_ops_common_rw = {
+static const struct file_operations common_rw_fops = {
.owner = THIS_MODULE,
.open = rtl_debugfs_open_rw,
.release = rtl_debugfs_close_rw,
@@ -523,7 +512,7 @@ static const struct file_operations file_ops_common_rw = {
rtl_debug_priv_ ##name.rtlpriv = rtlpriv;  \
debugfs_create_file(#name, mode, parent,   \
_debug_priv_ ##name,   \
-   _ops_ ##fopname); \
+   _ ##fops); \
} while (0)
 
 #define RTL_DEBUGFS_ADD(name) \
-- 
2.17.0



Re: [PATCH] binderfs: implement sysctls

2018-12-21 Thread Greg KH
On Fri, Dec 21, 2018 at 03:12:42PM +0100, Christian Brauner wrote:
> On Fri, Dec 21, 2018 at 02:55:09PM +0100, Greg KH wrote:
> > On Fri, Dec 21, 2018 at 02:39:09PM +0100, Christian Brauner wrote:
> > > This implements three sysctls that have very specific goals:
> > 
> > Ick, why?
> > 
> > What are these going to be used for?  Who will "control" them?  As you
> 
> Only global root in the initial user namespace. See the reasons below. :)
> 
> > are putting them in the "global" namespace, that feels like something
> > that binderfs was trying to avoid in the first place.
> 
> There are a couple of reason imho:
> - Global root needs a way to restrict how many binder devices can be
>   allocated across all user + ipc namespace pairs.
>   One obvious reason is that otherwise userns root in a non-initial user
>   namespace can allocate a huge number of binder devices (pick a random
>   number say 10.000) and use up a lot of kernel memory.

Root can do tons of other bad things too, why are you picking on
binderfs here?  :)

>   In addition they can pound on the binder.c code causing a lot of
>   contention for the remaining global lock in there.

That's the problem of that container, don't let it do that.  Or remove
the global lock :)

>   We should let global root explicitly restrict non-initial namespaces
>   in this respect. Imho, that's just good security design. :)

If you do not trust your container enough to have it properly allocate
the correct binder resources, then perhaps you shouldn't be allowing it
to allocate any resources at all?

> - The reason for having a number of reserved devices is when the initial
>   binderfs mount needs to bump the number of binder devices after the
>   initial allocation done during say boot (e.g. it could've removed
>   devices and wants to reallocate new ones but all binder minor numbers
>   have been given out or just needs additional devices). By reserving an
>   initial pool of binder devices this can be easily accounted for and
>   future proofs userspace. This is to say: global root in the initial
>   userns + ipcns gets dibs on however many devices it wants. :)

binder devices do not "come and go" at runtime, you need to set them up
initially and then all is fine.  So there should never be a need for the
"global" instance to need "more" binder devices once it is up and
running.  So I don't see what you are really trying to solve here.

You seem to be trying to protect the system from the container you just
gave root to and trusted it with creating its own binder instances.
If you do not trust it to create binder instances then do not allow it
to create binder instances!  :)

> - The fact that we have a single shared pool of binder device minor
>   numbers for all namespaces imho makes it necessary for the global root
>   user in the initial ipc + user namespace to manage device allocation
>   and delegation.

You are managing the allocation, you are giving who ever asks for one a
device.  If you run out of devices, oops, you run out of devices, that's
it.  Are you really ever going to run out of a major's number of binder
devices?

> The binderfs sysctl stuff is really small code-wise and adds a lot of
> security without any performance impact on the code itself. So we
> actually very strictly adhere to the requirement to not blindly
> sacrifice performance for security. :)

But you are adding a brand new user/kernel api by emulating one that is
very old and not the best at all, to try to protect from something that
seems like you can't really "protect" from in the first place.

You now have a mis-match of sysctls, ioctls and file operations all
working on the same logical thing.  And all interacting in different and
uncertian ways.  Are you sure that's wise?

If the binderfs code as-is isn't "safe enough" to use without this, then
we need to revisit it before someone starts to use it...

thanks,

greg k-h


Re: [PATCH net-next 0/4] bridge: implement Multicast Router Discovery (RFC4286)

2018-12-21 Thread Nikolay Aleksandrov
On 12/21/18 5:15 PM, Linus Lüssing wrote:
> Hi,
> 
> This patchset adds initial Multicast Router Discovery support to
> the Linux bridge (RFC4286). With MRD it is possible to detect multicast
> routers and mark bridge ports and forward multicast packets to such routers
> accordingly.
> 
> So far, multicast routers are detected via IGMP/MLD queries and PIM
> messages in the Linux bridge. As there is only one active, selected
> querier at a time RFC4541 ("Considerations for Internet Group Management
> Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping
> Switches") section 2.1.1.a) recommends snooping Multicast Router
> Advertisements as provided by MRD (RFC4286).
> 
> 
> The first two patches are refactoring some existing code which is reused
> for parsing the Multicast Router Advertisements later in the fourth
> patch. The third patch lets the bridge join the all-snoopers multicast
> address to be able to reliably receive the Multicast Router
> Advertisements.
> 
> 
> What is not implemented yet from RFC4286 yet:
> 
> * Sending Multicast Router Solicitations:
>   -> RFC4286: "[...] may be sent when [...] an interface is
>  (re-)initialized [or] MRD is enabled"
> * Snooping Multicast Router Terminations:
>   -> currently this only relies on our own timeouts
> * Adjusting timeouts with the values provided in the announcements
> 
> 
> Regards, Linus
> 
> 
> 

Hi Linus,
Nice work, unfortunately net-next is currenty closed. Anyway I'll
review the patches in detail after the holidays so if there's
anything it can be adjusted for when net-next opens up.

Thanks,
 Nik



Re: [PATCH] pstore: Convert buf_lock to semaphore

2018-12-21 Thread Ard Biesheuvel
On Tue, 4 Dec 2018 at 19:06, Sebastian Andrzej Siewior
 wrote:
>
> On 2018-12-04 09:23:13 [-0800], Kees Cook wrote:
> > Okay, so, if kmsg_dump() uses rcu_read_lock(), that means efi-pstore
> > can _never_ sleep, and it's nothing to do with pstore internals. :( I
> > guess we just hard-code it, then? And efi-pstore should probably only
> > attach to pstore if it has a nonblock implementation (and warn if one
> > isn't available).
>
> I was about to suggest that. I am not aware if anything else could use
> efi_pstore_write() use that but otherwise you could hardcode it.
>

efivar_entry_set_safe() will only use the default backend if no
non-blocking variant is provided, in which case it assumes that the
default one is non-blocking. Perhaps we should just assign both
function pointers to the same function in this case.


[PATCH 0/3] soc: fsl: add DPAA2 log console support

2018-12-21 Thread Ioana Ciornei
This patch set adds support for exporting DPAA2 firmware console
logs to userspace.

The first two patches add the needed device tree node and its documentation
while the third one adds the actual platform driver.

Ioana Ciornei (3):
  arm64: dts: add dpaa2-console node for DPAA2 platforms
  Documentation: DT: Add entry for DPAA2 console
  soc: fsl: add DPAA2 console support

 .../devicetree/bindings/misc/dpaa2-console.txt |  11 +
 MAINTAINERS|   1 +
 arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi |   5 +
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi |   5 +
 drivers/soc/fsl/Kconfig|  10 +
 drivers/soc/fsl/Makefile   |   1 +
 drivers/soc/fsl/dpaa2-console.c| 306 +
 7 files changed, 339 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/misc/dpaa2-console.txt
 create mode 100644 drivers/soc/fsl/dpaa2-console.c

-- 
1.9.1



[PATCH 3/3] soc: fsl: add DPAA2 console support

2018-12-21 Thread Ioana Ciornei
This patch adds DPAA2 MC and AIOP console log support.

The platform driver probes on the "dpaa2-console" device tree node
which describes the base firmware address needed in order to infer the
start address of both firmware logs: MC and AIOP.
It then exports two misc char devices which can be used to dump
the needed logs.

Signed-off-by: Ioana Ciornei 
Signed-off-by: Roy Pledge 
---
 drivers/soc/fsl/Kconfig |  10 ++
 drivers/soc/fsl/Makefile|   1 +
 drivers/soc/fsl/dpaa2-console.c | 306 
 3 files changed, 317 insertions(+)
 create mode 100644 drivers/soc/fsl/dpaa2-console.c

diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
index 8f80e8b..94229a0 100644
--- a/drivers/soc/fsl/Kconfig
+++ b/drivers/soc/fsl/Kconfig
@@ -28,4 +28,14 @@ config FSL_MC_DPIO
  other DPAA2 objects. This driver does not expose the DPIO
  objects individually, but groups them under a service layer
  API.
+
+config DPAA2_CONSOLE
+   tristate "QorIQ DPAA2 console driver"
+   depends on OF && (ARCH_LAYERSCAPE || (COMPILE_TEST && (ARM || ARM64 || 
X86_LOCAL_APIC || PPC)))
+   default y
+   help
+ Console driver for DPAA2 platforms. Exports 2 char devices,
+ /dev/dpaa2_mc_console and /dev/dpaa2_aiop_console,
+ which can be used to dump the Management Complex and AIOP
+ firmware logs.
 endmenu
diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
index 803ef1b..57762c9 100644
--- a/drivers/soc/fsl/Makefile
+++ b/drivers/soc/fsl/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_QUICC_ENGINE)  += qe/
 obj-$(CONFIG_CPM)  += qe/
 obj-$(CONFIG_FSL_GUTS) += guts.o
 obj-$(CONFIG_FSL_MC_DPIO)  += dpio/
+obj-$(CONFIG_DPAA2_CONSOLE)+= dpaa2-console.o
diff --git a/drivers/soc/fsl/dpaa2-console.c b/drivers/soc/fsl/dpaa2-console.c
new file mode 100644
index 000..b088834
--- /dev/null
+++ b/drivers/soc/fsl/dpaa2-console.c
@@ -0,0 +1,306 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/* Copyright 2015-2016 Freescale Semiconductor Inc.
+ * Copyright 2018 NXP
+ */
+
+#define pr_fmt(fmt) "dpaa2-console: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+MODULE_LICENSE("Dual BSD/GPL");
+MODULE_AUTHOR("Roy Pledge ");
+MODULE_DESCRIPTION("DPAA2 console driver");
+
+/* MC firmware base low/high registers indexes */
+#define MCFBALR_OFFSET 0
+#define MCFBAHR_OFFSET 1
+
+/* Bit masks used to get the most/least significant part of the MC base addr */
+#define MC_FW_ADDR_MASK_HIGH 0x1
+#define MC_FW_ADDR_MASK_LOW  0xE000
+
+#define MC_BUFFER_OFFSET 0x0100
+#define MC_BUFFER_SIZE   (1024 * 1024 * 16)
+#define MC_OFFSET_DELTA  MC_BUFFER_OFFSET
+
+#define AIOP_BUFFER_OFFSET 0x0600
+#define AIOP_BUFFER_SIZE   (1024 * 1024 * 16)
+#define AIOP_OFFSET_DELTA  0
+
+#define LOG_HEADER_FLAG_BUFFER_WRAPAROUND 0x8000
+#define LAST_BYTE(a) ((a) & ~(LOG_HEADER_FLAG_BUFFER_WRAPAROUND))
+
+/* MC and AIOP Magic words */
+#define MAGIC_MC   0x4d430100
+#define MAGIC_AIOP 0x41494F50
+
+struct log_header {
+   __le32 magic_word;
+   char reserved[4];
+   __le32 buf_start;
+   __le32 buf_length;
+   __le32 last_byte;
+};
+
+struct console_data {
+   char *map_addr;
+   struct log_header *hdr;
+   char *start_addr;
+   char *end_addr;
+   char *end_of_data;
+   char *cur_ptr;
+};
+
+struct resource mc_base_addr;
+
+static inline void adjust_end(struct console_data *cd)
+{
+   u32 last_byte = readl(>hdr->last_byte);
+
+   cd->end_of_data = cd->start_addr + LAST_BYTE(last_byte);
+}
+
+static u64 get_mc_fw_base_address(void)
+{
+   u64 mcfwbase = 0ULL;
+   u32 *mcfbaregs;
+
+   mcfbaregs = (u32 *)ioremap(mc_base_addr.start,
+  resource_size(_base_addr));
+   if (!mcfbaregs) {
+   pr_err("could not map MC Firmaware Base registers\n");
+   return -EIO;
+   }
+
+   mcfwbase  = readl(mcfbaregs + MCFBAHR_OFFSET) & MC_FW_ADDR_MASK_HIGH;
+   mcfwbase <<= 32;
+   mcfwbase |= readl(mcfbaregs + MCFBALR_OFFSET) & MC_FW_ADDR_MASK_LOW;
+   iounmap(mcfbaregs);
+
+   pr_debug("MC base address at 0x%016llx\n", mcfwbase);
+   return mcfwbase;
+}
+
+static ssize_t dpaa2_console_size(struct console_data *cd)
+{
+   ssize_t size;
+
+   if (cd->cur_ptr <= cd->end_of_data)
+   size = cd->end_of_data - cd->cur_ptr;
+   else
+   size = (cd->end_addr - cd->cur_ptr) +
+   (cd->end_of_data - cd->start_addr);
+
+   return size;
+}
+
+static int dpaa2_generic_console_open(struct inode *node, struct file *fp,
+ u64 offset, u64 size,
+ u32 expected_magic,
+ u32 offset_delta)
+{
+   u32 read_magic, wrapped, 

[PATCH 2/3] Documentation: DT: Add entry for DPAA2 console

2018-12-21 Thread Ioana Ciornei
This patch adds a devicetree binding documentation for
FSL's DPAA2 console.

Signed-off-by: Ioana Ciornei 
---
 Documentation/devicetree/bindings/misc/dpaa2-console.txt | 11 +++
 MAINTAINERS  |  1 +
 2 files changed, 12 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/misc/dpaa2-console.txt

diff --git a/Documentation/devicetree/bindings/misc/dpaa2-console.txt 
b/Documentation/devicetree/bindings/misc/dpaa2-console.txt
new file mode 100644
index 000..f4e16b1
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/dpaa2-console.txt
@@ -0,0 +1,11 @@
+DPAA2 console support
+
+Required properties:
+
+- compatible
+Value type: 
+Definition: Must be "dpaa2-console".
+- reg
+Value type: 
+Definition: A standard property.  Specifies the region where the MCFBA
+(MC firmware base address) register can be found.
diff --git a/MAINTAINERS b/MAINTAINERS
index 7b76a80..229d4fb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5969,6 +5969,7 @@ M:Li Yang 
 L: linuxppc-...@lists.ozlabs.org
 L: linux-arm-ker...@lists.infradead.org
 S: Maintained
+F: Documentation/devicetree/bindings/misc/dpaa2-console.txt
 F: Documentation/devicetree/bindings/soc/fsl/
 F: drivers/soc/fsl/
 F: include/linux/fsl/
-- 
1.9.1



[PATCH 1/3] arm64: dts: add dpaa2-console node for DPAA2 platforms

2018-12-21 Thread Ioana Ciornei
Add the dpaa2-console device tree node for the following
DPAA2 based platforms: LS1088A, LS2080A and LS2088A.

Signed-off-by: Ioana Ciornei 
---
 arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 5 +
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 5 +
 2 files changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index e73e55f..664e337 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -569,6 +569,11 @@
clock-names = "apb_pclk", "wdog_clk";
};
 
+   dpaa2-console@0x08340020 {
+   compatible = "dpaa2-console";
+   reg = <0x 0x08340020 0 0x2>;
+   };
+
fsl_mc: fsl-mc@80c00 {
compatible = "fsl,qoriq-mc";
reg = <0x0008 0x0c00 0 0x40>,/* MC portal 
base */
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index d188774..6db6ea4 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -333,6 +333,11 @@
};
};
 
+   dpaa2-console@0x08340020 {
+   compatible = "dpaa2-console";
+   reg = <0x 0x08340020 0 0x2>;
+   };
+
fsl_mc: fsl-mc@80c00 {
compatible = "fsl,qoriq-mc";
reg = <0x0008 0x0c00 0 0x40>,/* MC portal 
base */
-- 
1.9.1



Re: [PATCH 03/10] SCSI: fcoe: convert to use BUS_ATTR_WO

2018-12-21 Thread James Bottomley
[scsi list cc added]
On Fri, 2018-12-21 at 08:54 +0100, Greg Kroah-Hartman wrote:
> We are trying to get rid of BUS_ATTR() and the usage of that in the
> fcoe driver can be trivially converted to use BUS_ATTR_WO(), so use
> that instead.
> 
> At the same time remove a unneeded EXPORT_SYMBOL() marking for the
> sysfs callback function we are renaming, no idea of how that got into
> the tree...

The EXPORT_SYMBOL removal is fine, but

[...]
> --- a/include/scsi/libfcoe.h
> +++ b/include/scsi/libfcoe.h
> @@ -405,10 +405,8 @@ int fcoe_transport_attach(struct fcoe_transport
> *ft);
>  int fcoe_transport_detach(struct fcoe_transport *ft);
> 
>  /* sysfs store handler for ctrl_control interface */
> -ssize_t fcoe_ctlr_create_store(struct bus_type *bus,
> -const char *buf, size_t count);
> -ssize_t fcoe_ctlr_destroy_store(struct bus_type *bus,
> - const char *buf, size_t count);
> +ssize_t ctlr_create_store(struct bus_type *bus, const char *buf,
> size_t count);
> +ssize_t ctlr_destroy_store(struct bus_type *bus, const char *buf,
> size_t count);

You're really damaging our prefix namespace here.  It looks like the
ctlr_ name is a farly recent addition for sysfs (only myra/b) use it in
SCSI but it's inviting symbol clashes.

Since the XXX_ATTR_RO seem to be defined with only local file usage in
mind, I think we need static functions to shim the problem, like below
(provided this is the only instance, because if it isn't, you probably
need a XXX_ATTR_WO_prefix() macro)

James

---

diff --git a/drivers/scsi/fcoe/fcoe_sysfs.c b/drivers/scsi/fcoe/fcoe_sysfs.c
index 5c8310bade61..88e5c26ce381 100644
--- a/drivers/scsi/fcoe/fcoe_sysfs.c
+++ b/drivers/scsi/fcoe/fcoe_sysfs.c
@@ -671,8 +671,20 @@ static const struct device_type fcoe_fcf_device_type = {
.release = fcoe_fcf_device_release,
 };
 
-static BUS_ATTR(ctlr_create, S_IWUSR, NULL, fcoe_ctlr_create_store);
-static BUS_ATTR(ctlr_destroy, S_IWUSR, NULL, fcoe_ctlr_destroy_store);
+static ssize_t ctlr_create_store(struct bus_type *bus, const char *buf,
+size_t count)
+{
+   return fcoe_ctlr_create_store(bus, buf, count);
+}
+
+static ssize_t ctlr_destroy_store(struct bus_type *bus, const char *buf,
+ size_t count)
+{
+   return fcoe_ctlr_destroy_store(bus, buf, count);
+}
+
+static BUS_ATTR_WO(ctlr_create);
+static BUS_ATTR_WO(ctlr_destroy);
 
 static struct attribute *fcoe_bus_attrs[] = {
_attr_ctlr_create.attr,



Re: [PATCH v5 7/8] clk: lochnagar: Add support for the Cirrus Logic Lochnagar

2018-12-21 Thread Charles Keepax
On Fri, Dec 21, 2018 at 01:50:37PM +, Charles Keepax wrote:
> On Thu, Nov 29, 2018 at 11:53:51PM -0800, Stephen Boyd wrote:
> > Quoting Charles Keepax (2018-11-20 06:16:30)
> > > +MODULE_AUTHOR("Charles Keepax ");
> > > +MODULE_DESCRIPTION("Clock driver for Cirrus Logic Lochnagar Board");
> > > +MODULE_LICENSE("GPL v2");
> > > +MODULE_ALIAS("platform:lochnagar-clk");
> > 
> > I think MODULE_ALIAS is not needed if it's this simple?
> > 
> 
> Not actually sure on this one, to be honest its mostly cargo
> culted from other drivers. I will investigate and see what I dig
> up but if has any pointers I would greatly appreciate it.
> 

>From what I can find out it looks like MODULE_ALIAS is indeed
redundant on DT only drivers, which these are at the moment so
will remove and give it a test.

Thanks,
Charles


Re: [PATCH 0/1] RFC: Revamp admin-guide/tainted-kernels.rst to make it more comprehensible

2018-12-21 Thread Thorsten Leemhuis
Hi! Am 17.12.18 um 19:24 schrieb Jonathan Corbet:
> On Mon, 17 Dec 2018 16:20:42 +0100
> Thorsten Leemhuis  wrote:
>
>> +might be relevant later when investigating problems. Don't worry
>> +yourself too much about this, most of the time it's not a problem to run
> s/yourself//

Thx for this and other suggestions or fixes, consider them implemented when
not mentioned in this mail. Find the current state of the text at the end of
this mail for reference.
 
> [...]
>> +At runtime, you can query the tainted state by reading
>> +``/proc/sys/kernel/tainted``. If that returns ``0``, the kernel is not
>> +tainted; any other number indicates the reasons why it is. You might
>> +find that number in below table if there was only one reason that got
>> +the kernel tainted. If there were multiple reasons you need to decode
>> +the number, as it is a bitfield, where each bit indicates the absence or
>> +presence of a particular type of taint. You can use the following python
>> +command to decode::
> Here's an idea if you feel like improving this: rather than putting an
> inscrutable program inline, add a taint_status script to scripts/ that
> prints out the status in fully human-readable form, with the explanation
> for every set bit.

I posted the script earlier today and noticed now that it prints only
the fully human-readable form, not if a bit it set or unset. Would you
prefer if it did that as well?

>> +===  ===  ==  
>> +Bit  Log Int  Reason that got the kernel tainted
>> +===  ===  ==  
>> + 1)  G/P   0  proprietary module got loaded
> I'd s/got/was/ throughout.  Also, this is the kernel, we start counting at
> zero! :)

Hehe, yeah :-D At first I actually started at zero, but that looked
odd as the old explanations (those already in the file) start to could at one.
Having a off-by-one within one document is just confusing, that's why I
decided against starting at zero here.

Another reason that came to my mind when reading your comment: Yes, this
is the kernel, but the document should be easy to understand even for
inexperienced users (e.g. people that know how to open and use command
line tools, but never learned programming). That's why I leaning towards
starting with one everywhere. But yes, that can be confusing, that's
why I added a note, albeit I'm not really happy with it yet:

"""
Note: This document is aimed at users and thus starts to count at one here and
in other places.  Use ``seq 0 17`` instead to start counting at zero, as it's
normal for developers.
"""

See below for full context. Anyway: I can change the text to start at zero if
you prefer it.

Ciao, Thorsten

---

Tainted kernels
---

The kernel will mark itself as 'tainted' when something occurs that might be
relevant later when investigating problems. Don't worry too much about this,
most of the time it's not a problem to run a tainted kernel; the information is
mainly of interest once someone wants to investigate some problem, as its real
cause might be the event that got the kernel tainted. That's why bug reports
from tainted kernels will often be ignored by developers, hence try to reproduce
problems with an untainted kernel.

Note the kernel will remain tainted even after you undo what caused the taint
(i.e. unload a proprietary kernel module), to indicate the kernel remains not
trustworthy. That's also why the kernel will print the tainted state when it
notices an internal problem (a 'kernel bug'), a recoverable error
('kernel oops') or a non-recoverable error ('kernel panic') and writes debug
information about this to the logs ``dmesg`` outputs. It's also possible to
check the tainted state at runtime through a file in ``/proc/``.


Tainted flag in bugs, oops or panics messages
~

You find the tainted state near the top in a line starting with 'CPU:'; if or
why the kernel is shown after the Process ID ('PID:') and a shortened name of
the command ('Comm:') that triggered the event:

BUG: unable to handle kernel NULL pointer dereference at 
Oops: 0002 [#1] SMP PTI
CPU: 0 PID: 4424 Comm: insmod Tainted: PW  O  4.20.0-0.rc6.fc30 #1
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
RIP: 0010:my_oops_init+0x13/0x1000 [kpanic]
[...]

You'll find a **'Not tainted: '** there if the kernel was not tainted at the
time of the event; if it was, then it will print **'Tainted: '** and characters
either letters or blanks. The meaning of those characters is explained in the
table below. In above example it's '``Tainted: PW  O ``' as as the
kernel got tainted earlier because a proprietary Module (``P``) was loaded, a
warning occurred (``W``), and an externally-built module was loaded (``O``).
To decode other letters use the table below.


Decoding tainted state at runtime
~

At runtime, you can query 

Re: [PATCH] blkcg: add rcu lock to bio_clone_blkg_association()

2018-12-21 Thread Jens Axboe
On 12/21/18 7:54 AM, Dennis Zhou wrote:
> I cleaned up blkg_tryget_closest() to require rcu_read_lock() earlier.
> However, this was a subtle case too which clearly was too subtle for me.
> The idea was the src bio should be holding a ref to the blkg so rcu
> wasn't technically needed. If it doesn't hold a ref, it should be %NULL
> and the blkg->parent pointers are unused.
> 
> This adds the appropriate read lock in bio_clone_blkg_association().

Shall I just fold this with the previous? I staged it in a
later-in-merge-cycle branch, so that's not an issue to amend.

-- 
Jens Axboe



[PATCH RT 0/9] Linux 3.18.129-rt111-rc1

2018-12-21 Thread Tom Zanussi
From: Tom Zanussi 

Hello RT Folks!

This is the RT stable review cycle of patch 3.18.129-rt111-rc1.

Please scream at me if I messed something up. Please test the
patches too.

The -rc release will be uploaded to kernel.org and will be
deleted when the final release is out. This is just a review
release (or release candidate).

The pre-releases will not be pushed to the git repository,
only the final release is.

If all goes well, this patch will be converted to the next
main release on 12/24/2018.

To build 3.18.129-rt111-rc1 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.18.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.18.129.xz

  
http://www.kernel.org/pub/linux/kernel/projects/rt/3.18/patch-3.18.129-rt111-rc1.patch.xz


You can also build from 3.18.129-rt110 by applying the incremental patch:

  
http://www.kernel.org/pub/linux/kernel/projects/rt/3.18/incr/patch-3.18.129-rt110-rt111-rc1.patch.xz

Enjoy!
   
   Tom

Changes from v3.18.129-rt110:
---
Daniel Bristot de Oliveira (1):
  sched/core: Avoid __schedule() being called twice in a row

Kurt Kanzenbach (1):
  tty: serial: pl011: explicitly initialize the flags variable

Lukas Wunner (1):
  pinctrl: bcm2835: Use raw spinlock for RT compatibility

Sebastian Andrzej Siewior (5):
  efi: Allow efi=runtime
  efi: Disable runtime services on RT
  crypto: cryptd - add a lock instead preempt_disable/local_bh_disable
  work-simple: drop a shit statement in SWORK_EVENT_PENDING
  drm/i915: disable tracing on -RT

Tom Zanussi (1):
  Linux 3.18.129-rt111-rc1

 crypto/cryptd.c   | 18 --
 drivers/firmware/efi/efi.c|  5 -
 drivers/gpu/drm/i915/i915_trace.h |  4 
 drivers/pinctrl/pinctrl-bcm2835.c | 16 
 drivers/tty/serial/amba-pl011.c   |  2 +-
 kernel/sched/core.c   |  9 +++--
 kernel/sched/work-simple.c|  2 +-
 localversion-rt   |  2 +-
 8 files changed, 34 insertions(+), 24 deletions(-)

-- 
2.14.1



[PATCH v3 8/9] ASoC: sun4i-i2s: Add set_tdm_slot functionality

2018-12-21 Thread codekipper
From: Marcus Cooper 

Some codecs require a different amount of a bit clocks per frame than
what is calculated by the sample width. Use the tdm slot bindings to
provide this mechanism.

Signed-off-by: Marcus Cooper 
---
 sound/soc/sunxi/sun4i-i2s.c | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index 8cec2f42c94e..cfcf427270fd 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -196,6 +196,9 @@ struct sun4i_i2s {
const struct sun4i_i2s_quirks   *variant;
 
bool bit_clk_master;
+
+   unsigned inttdm_slots;
+   unsigned intslot_width;
 };
 
 struct sun4i_i2s_clk_div {
@@ -385,7 +388,7 @@ static int sun4i_i2s_set_clk_rate(struct snd_soc_dai *dai,
if (i2s->variant->has_fmt_set_lrck_period)
regmap_update_bits(i2s->regmap, SUN4I_I2S_FMT0_REG,
   SUN8I_I2S_FMT0_LRCK_PERIOD_MASK,
-  SUN8I_I2S_FMT0_LRCK_PERIOD(32));
+  SUN8I_I2S_FMT0_LRCK_PERIOD(word_size));
 
/* Set sign extension to pad out LSB with 0 */
regmap_field_write(i2s->field_fmt_sext, 0);
@@ -498,7 +501,8 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream 
*substream,
   sr + i2s->variant->fmt_offset);
 
return sun4i_i2s_set_clk_rate(dai, params_rate(params),
- params_width(params));
+ i2s->tdm_slots ?
+ i2s->slot_width : params_width(params));
 }
 
 static int sun4i_i2s_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
@@ -749,11 +753,25 @@ static int sun4i_i2s_set_sysclk(struct snd_soc_dai *dai, 
int clk_id,
return 0;
 }
 
+static int sun4i_i2s_set_dai_tdm_slot(struct snd_soc_dai *dai,
+   unsigned int tx_mask, unsigned int rx_mask,
+   int slots, int width)
+{
+   struct sun4i_i2s *i2s = snd_soc_dai_get_drvdata(dai);
+
+   i2s->tdm_slots = slots;
+
+   i2s->slot_width = width;
+
+   return 0;
+}
+
 static const struct snd_soc_dai_ops sun4i_i2s_dai_ops = {
.hw_params  = sun4i_i2s_hw_params,
.set_fmt= sun4i_i2s_set_fmt,
.set_sysclk = sun4i_i2s_set_sysclk,
.trigger= sun4i_i2s_trigger,
+   .set_tdm_slot   = sun4i_i2s_set_dai_tdm_slot,
 };
 
 static int sun4i_i2s_dai_probe(struct snd_soc_dai *dai)
-- 
2.20.1



[PATCH v3 2/9] ASoC: sun4i-i2s: Add regmap field to sign extend sample

2018-12-21 Thread codekipper
From: Marcus Cooper 

On the newer SoCs this is set by default to transfer a 0 after
each sample in each slot. Add the regmap field to configure this
and set it so that it pads the sample with 0s.

Signed-off-by: Marcus Cooper 
---
 sound/soc/sunxi/sun4i-i2s.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index 64d073cb2aee..80bf29e0cc86 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -138,6 +138,7 @@
  * @field_fmt_bclk: regmap field to set clk polarity.
  * @field_fmt_lrclk: regmap field to set frame polarity.
  * @field_fmt_mode: regmap field to set the operational mode.
+ * @field_fmt_sext: regmap field to set the sign extension.
  * @field_txchanmap: location of the tx channel mapping register.
  * @field_rxchanmap: location of the rx channel mapping register.
  * @field_txchansel: location of the tx channel select bit fields.
@@ -163,6 +164,7 @@ struct sun4i_i2s_quirks {
struct reg_fieldfield_fmt_bclk;
struct reg_fieldfield_fmt_lrclk;
struct reg_fieldfield_fmt_mode;
+   struct reg_fieldfield_fmt_sext;
struct reg_fieldfield_txchanmap;
struct reg_fieldfield_rxchanmap;
struct reg_fieldfield_txchansel;
@@ -187,6 +189,7 @@ struct sun4i_i2s {
struct regmap_field *field_fmt_bclk;
struct regmap_field *field_fmt_lrclk;
struct regmap_field *field_fmt_mode;
+   struct regmap_field *field_fmt_sext;
struct regmap_field *field_txchanmap;
struct regmap_field *field_rxchanmap;
struct regmap_field *field_txchansel;
@@ -346,6 +349,9 @@ static int sun4i_i2s_set_clk_rate(struct snd_soc_dai *dai,
   SUN8I_I2S_FMT0_LRCK_PERIOD_MASK,
   SUN8I_I2S_FMT0_LRCK_PERIOD(32));
 
+   /* Set sign extension to pad out LSB with 0 */
+   regmap_field_write(i2s->field_fmt_sext, 0);
+
return 0;
 }
 
@@ -876,6 +882,7 @@ static const struct sun4i_i2s_quirks sun4i_a10_i2s_quirks = 
{
.field_fmt_lrclk= REG_FIELD(SUN4I_I2S_FMT0_REG, 7, 7),
.has_slave_select_bit   = true,
.field_fmt_mode = REG_FIELD(SUN4I_I2S_FMT0_REG, 0, 1),
+   .field_fmt_sext = REG_FIELD(SUN4I_I2S_FMT1_REG, 8, 8),
.field_txchanmap= REG_FIELD(SUN4I_I2S_TX_CHAN_MAP_REG, 0, 31),
.field_rxchanmap= REG_FIELD(SUN4I_I2S_RX_CHAN_MAP_REG, 0, 31),
.field_txchansel= REG_FIELD(SUN4I_I2S_TX_CHAN_SEL_REG, 0, 2),
@@ -893,6 +900,7 @@ static const struct sun4i_i2s_quirks sun6i_a31_i2s_quirks = 
{
.field_fmt_lrclk= REG_FIELD(SUN4I_I2S_FMT0_REG, 7, 7),
.has_slave_select_bit   = true,
.field_fmt_mode = REG_FIELD(SUN4I_I2S_FMT0_REG, 0, 1),
+   .field_fmt_sext = REG_FIELD(SUN4I_I2S_FMT1_REG, 8, 8),
.field_txchanmap= REG_FIELD(SUN4I_I2S_TX_CHAN_MAP_REG, 0, 31),
.field_rxchanmap= REG_FIELD(SUN4I_I2S_RX_CHAN_MAP_REG, 0, 31),
.field_txchansel= REG_FIELD(SUN4I_I2S_TX_CHAN_SEL_REG, 0, 2),
@@ -933,6 +941,7 @@ static const struct sun4i_i2s_quirks sun8i_h3_i2s_quirks = {
.field_fmt_bclk = REG_FIELD(SUN4I_I2S_FMT0_REG, 7, 7),
.field_fmt_lrclk= REG_FIELD(SUN4I_I2S_FMT0_REG, 19, 19),
.field_fmt_mode = REG_FIELD(SUN4I_I2S_CTRL_REG, 4, 5),
+   .field_fmt_sext = REG_FIELD(SUN4I_I2S_FMT1_REG, 4, 5),
.field_txchanmap= REG_FIELD(SUN8I_I2S_TX_CHAN_MAP_REG, 0, 31),
.field_rxchanmap= REG_FIELD(SUN8I_I2S_RX_CHAN_MAP_REG, 0, 31),
.field_txchansel= REG_FIELD(SUN8I_I2S_TX_CHAN_SEL_REG, 0, 2),
@@ -995,6 +1004,12 @@ static int sun4i_i2s_init_regmap_fields(struct device 
*dev,
if (IS_ERR(i2s->field_fmt_mode))
return PTR_ERR(i2s->field_fmt_mode);
 
+   i2s->field_fmt_sext =
+   devm_regmap_field_alloc(dev, i2s->regmap,
+   i2s->variant->field_fmt_sext);
+   if (IS_ERR(i2s->field_fmt_sext))
+   return PTR_ERR(i2s->field_fmt_sext);
+
i2s->field_txchanmap =
devm_regmap_field_alloc(dev, i2s->regmap,
i2s->variant->field_txchanmap);
-- 
2.20.1



[PATCH v3 6/9] ASoC: sun4i-i2s: Add multi-lane functionality

2018-12-21 Thread codekipper
From: Marcus Cooper 

The i2s block supports multi-lane i2s output however this functionality
is only possible in earlier SoCs where the pins are exposed and for
the i2s block used for HDMI audio on the later SoCs.

To enable this functionality, an optional property has been added to
the bindings.

Signed-off-by: Marcus Cooper 
---
 sound/soc/sunxi/sun4i-i2s.c | 37 -
 1 file changed, 32 insertions(+), 5 deletions(-)

diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index b31f84787218..e85789d84c0c 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -27,7 +27,7 @@
 
 #define SUN4I_I2S_CTRL_REG 0x00
 #define SUN4I_I2S_CTRL_SDO_EN_MASK GENMASK(11, 8)
-#define SUN4I_I2S_CTRL_SDO_EN(sdo) BIT(8 + (sdo))
+#define SUN4I_I2S_CTRL_SDO_EN(lines)   (((1 << lines) - 1) << 8)
 #define SUN4I_I2S_CTRL_MODE_MASK   BIT(5)
 #define SUN4I_I2S_CTRL_MODE_SLAVE  (1 << 5)
 #define SUN4I_I2S_CTRL_MODE_MASTER (0 << 5)
@@ -394,14 +394,23 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream 
*substream,
struct sun4i_i2s *i2s = snd_soc_dai_get_drvdata(dai);
int sr, wss, channels;
u32 width;
+   int lines;
 
channels = params_channels(params);
-   if (channels != 2) {
+   if ((channels > dai->driver->playback.channels_max) ||
+   (channels < dai->driver->playback.channels_min)) {
dev_err(dai->dev, "Unsupported number of channels: %d\n",
channels);
return -EINVAL;
}
 
+   lines = (channels + 1) / 2;
+
+   /* Enable the required output lines */
+   regmap_update_bits(i2s->regmap, SUN4I_I2S_CTRL_REG,
+  SUN4I_I2S_CTRL_SDO_EN_MASK,
+  SUN4I_I2S_CTRL_SDO_EN(lines));
+
if (i2s->variant->has_chcfg) {
regmap_update_bits(i2s->regmap, SUN8I_I2S_CHAN_CFG_REG,
   SUN8I_I2S_CHAN_CFG_TX_SLOT_NUM_MASK,
@@ -412,8 +421,19 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream 
*substream,
}
 
/* Map the channels for playback and capture */
-   regmap_field_write(i2s->field_txchanmap, 0x76543210);
regmap_field_write(i2s->field_rxchanmap, 0x3210);
+   regmap_field_write(i2s->field_txchanmap, 0x10);
+   if (i2s->variant->has_chsel_tx_chen) {
+   if (channels > 2)
+   regmap_write(i2s->regmap,
+SUN8I_I2S_TX_CHAN_MAP_REG+4, 0x32);
+   if (channels > 4)
+   regmap_write(i2s->regmap,
+SUN8I_I2S_TX_CHAN_MAP_REG+8, 0x54);
+   if (channels > 6)
+   regmap_write(i2s->regmap,
+SUN8I_I2S_TX_CHAN_MAP_REG+12, 0x76);
+   }
 
/* Configure the channels */
regmap_field_write(i2s->field_txchansel,
@@ -1094,9 +1114,10 @@ static int sun4i_i2s_init_regmap_fields(struct device 
*dev,
 static int sun4i_i2s_probe(struct platform_device *pdev)
 {
struct sun4i_i2s *i2s;
+   struct snd_soc_dai_driver *soc_dai;
struct resource *res;
void __iomem *regs;
-   int irq, ret;
+   int irq, ret, val;
 
i2s = devm_kzalloc(>dev, sizeof(*i2s), GFP_KERNEL);
if (!i2s)
@@ -1175,6 +1196,12 @@ static int sun4i_i2s_probe(struct platform_device *pdev)
soc_dai->capture.formats = SUN8I_FORMATS;
}
 
+   if (!of_property_read_u32(pdev->dev.of_node,
+ "allwinner,playback-channels", )) {
+   if (val >= 2 && val <= 8)
+   soc_dai->playback.channels_max = val;
+   }
+
pm_runtime_enable(>dev);
if (!pm_runtime_enabled(>dev)) {
ret = sun4i_i2s_runtime_resume(>dev);
@@ -1184,7 +1211,7 @@ static int sun4i_i2s_probe(struct platform_device *pdev)
 
ret = devm_snd_soc_register_component(>dev,
  _i2s_component,
- _i2s_dai, 1);
+ soc_dai, 1);
if (ret) {
dev_err(>dev, "Could not register DAI\n");
goto err_suspend;
-- 
2.20.1



Re: [PATCH v4 00/14] KVM/X86: Introduce a new guest mapping interface

2018-12-21 Thread Paolo Bonzini
On 03/12/18 10:30, KarimAllah Ahmed wrote:
> Guest memory can either be directly managed by the kernel (i.e. have a "struct
> page") or they can simply live outside kernel control (i.e. do not have a
> "struct page"). KVM mostly support these two modes, except in a few places
> where the code seems to assume that guest memory must have a "struct page".
> 
> This patchset introduces a new mapping interface to map guest memory into host
> kernel memory which also supports PFN-based memory (i.e. memory without 
> 'struct
> page'). It also converts all offending code to this interface or simply
> read/write directly from guest memory.
> 
> As far as I can see all offending code is now fixed except the APIC-access 
> page
> which I will handle in a seperate series along with dropping
> kvm_vcpu_gfn_to_page and kvm_vcpu_gpa_to_page from the internal KVM API.
> 
> The current implementation of the new API uses memremap to map memory that 
> does
> not have a "struct page". This proves to be very slow for high frequency
> mappings. Since this does not affect the normal use-case where a "struct page"
> is available, the performance of this API will be handled by a seperate patch
> series.
> 
> v3 -> v4:
> - Rebase
> - Add a new patch to also fix the newly introduced enhanced VMCS.

This will need a few more changes (especially given the review remarks
for patch 2), so please also add the separate dirty/clean unmap APIs in
the next revision.

In order to rebase against the vmx.c split, my suggestion is that you
first rebase to the last commit before nested.c was separated, then on
the immediately following one, and then on the top of the tree.  Most of
the time, "patch -p1 arch/x86/kvm/vmx/nested.c <
.git/rebase-apply/patch" will do the right thing.

Paolo

> v2 -> v3:
> - Rebase
> - Add a new patch to also fix the newly introduced shadow VMCS.
> 
> Filippo Sironi (1):
>   X86/KVM: Handle PFNs outside of kernel reach when touching GPTEs
> 
> KarimAllah Ahmed (13):
>   X86/nVMX: handle_vmon: Read 4 bytes from guest memory
>   X86/nVMX: handle_vmptrld: Copy the VMCS12 directly from guest memory
>   X86/nVMX: Update the PML table without mapping and unmapping the page
>   KVM: Introduce a new guest mapping API
>   KVM/nVMX: Use kvm_vcpu_map when mapping the L1 MSR bitmap
>   KVM/nVMX: Use kvm_vcpu_map when mapping the virtual APIC page
>   KVM/nVMX: Use kvm_vcpu_map when mapping the posted interrupt
> descriptor table
>   KVM/X86: Use kvm_vcpu_map in emulator_cmpxchg_emulated
>   KVM/X86: hyperv: Use kvm_vcpu_map in synic_clear_sint_msg_pending
>   KVM/X86: hyperv: Use kvm_vcpu_map in synic_deliver_msg
>   KVM/nSVM: Use the new mapping API for mapping guest memory
>   KVM/nVMX: Use kvm_vcpu_map for accessing the shadow VMCS
>   KVM/nVMX: Use kvm_vcpu_map for accessing the enhanced VMCS
> 
>  arch/x86/kvm/hyperv.c  |  28 +++
>  arch/x86/kvm/paging_tmpl.h |  38 ++---
>  arch/x86/kvm/svm.c |  97 +++
>  arch/x86/kvm/vmx.c | 189 
> +
>  arch/x86/kvm/x86.c |  13 ++--
>  include/linux/kvm_host.h   |   9 +++
>  virt/kvm/kvm_main.c|  50 
>  7 files changed, 228 insertions(+), 196 deletions(-)
> 



[PATCH v3 3/9] ASoc: sun4i-i2s: Add 20, 24 and 32 bit support

2018-12-21 Thread codekipper
From: Marcus Cooper 

Extend the functionality of the driver to include support of 20 and
24 bits per sample for the earlier SoCs.

Newer SoCs can also handle 32bit samples.

Signed-off-by: Marcus Cooper 
---
 sound/soc/sunxi/sun4i-i2s.c | 41 ++---
 1 file changed, 38 insertions(+), 3 deletions(-)

diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index 80bf29e0cc86..adb988ae9ac5 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -399,6 +399,11 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream 
*substream,
case 16:
width = DMA_SLAVE_BUSWIDTH_2_BYTES;
break;
+   case 20:
+   case 24:
+   case 32:
+   width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+   break;
default:
dev_err(dai->dev, "Unsupported physical sample width: %d\n",
params_physical_width(params));
@@ -411,7 +416,18 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream 
*substream,
sr = 0;
wss = 0;
break;
-
+   case 20:
+   sr = 1;
+   wss = 1;
+   break;
+   case 24:
+   sr = 2;
+   wss = 2;
+   break;
+   case 32:
+   sr = 4;
+   wss = 4;
+   break;
default:
dev_err(dai->dev, "Unsupported sample width: %d\n",
params_width(params));
@@ -687,6 +703,13 @@ static int sun4i_i2s_dai_probe(struct snd_soc_dai *dai)
return 0;
 }
 
+#define SUN4I_FORMATS  (SNDRV_PCM_FMTBIT_S16_LE | \
+SNDRV_PCM_FMTBIT_S20_3LE | \
+SNDRV_PCM_FMTBIT_S24_LE)
+
+#define SUN8I_FORMATS  (SUN4I_FORMATS | \
+SNDRV_PCM_FMTBIT_S32_LE)
+
 static struct snd_soc_dai_driver sun4i_i2s_dai = {
.probe = sun4i_i2s_dai_probe,
.capture = {
@@ -694,14 +717,14 @@ static struct snd_soc_dai_driver sun4i_i2s_dai = {
.channels_min = 2,
.channels_max = 2,
.rates = SNDRV_PCM_RATE_8000_192000,
-   .formats = SNDRV_PCM_FMTBIT_S16_LE,
+   .formats = SUN4I_FORMATS,
},
.playback = {
.stream_name = "Playback",
.channels_min = 2,
.channels_max = 2,
.rates = SNDRV_PCM_RATE_8000_192000,
-   .formats = SNDRV_PCM_FMTBIT_S16_LE,
+   .formats = SUN4I_FORMATS,
},
.ops = _i2s_dai_ops,
.symmetric_rates = 1,
@@ -1106,6 +1129,18 @@ static int sun4i_i2s_probe(struct platform_device *pdev)
i2s->capture_dma_data.addr = res->start + SUN4I_I2S_FIFO_RX_REG;
i2s->capture_dma_data.maxburst = 8;
 
+   soc_dai = devm_kmemdup(>dev, _i2s_dai,
+  sizeof(*soc_dai), GFP_KERNEL);
+   if (!soc_dai) {
+   ret = -ENOMEM;
+   goto err_pm_disable;
+   }
+
+   if (i2s->variant->has_fmt_set_lrck_period) {
+   soc_dai->playback.formats = SUN8I_FORMATS;
+   soc_dai->capture.formats = SUN8I_FORMATS;
+   }
+
pm_runtime_enable(>dev);
if (!pm_runtime_enabled(>dev)) {
ret = sun4i_i2s_runtime_resume(>dev);
-- 
2.20.1



[PATCH v3 7/9] ASoC: sun4i-i2s: Do not divide clocks when slave

2018-12-21 Thread codekipper
From: Marcus Cooper 

There is no need to set the clock and calculate the division of
the audio pll for the bclk and sync signals when they are not
required.

Signed-off-by: Marcus Cooper 
---
 sound/soc/sunxi/sun4i-i2s.c | 144 +++-
 1 file changed, 77 insertions(+), 67 deletions(-)

diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index e85789d84c0c..8cec2f42c94e 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -194,6 +194,8 @@ struct sun4i_i2s {
struct regmap_field *field_rxchansel;
 
const struct sun4i_i2s_quirks   *variant;
+
+   bool bit_clk_master;
 };
 
 struct sun4i_i2s_clk_div {
@@ -298,82 +300,86 @@ static int sun4i_i2s_set_clk_rate(struct snd_soc_dai *dai,
int bclk_div, mclk_div;
int ret;
 
-   switch (rate) {
-   case 176400:
-   case 88200:
-   case 44100:
-   case 22050:
-   case 11025:
-   clk_rate = 22579200;
-   break;
+   if (i2s->bit_clk_master) {
+   switch (rate) {
+   case 176400:
+   case 88200:
+   case 44100:
+   case 22050:
+   case 11025:
+   clk_rate = 22579200;
+   break;
 
-   case 192000:
-   case 128000:
-   case 96000:
-   case 64000:
-   case 48000:
-   case 32000:
-   case 24000:
-   case 16000:
-   case 12000:
-   case 8000:
-   clk_rate = 24576000;
-   break;
+   case 192000:
+   case 128000:
+   case 96000:
+   case 64000:
+   case 48000:
+   case 32000:
+   case 24000:
+   case 16000:
+   case 12000:
+   case 8000:
+   clk_rate = 24576000;
+   break;
 
-   default:
-   dev_err(dai->dev, "Unsupported sample rate: %u\n", rate);
-   return -EINVAL;
-   }
+   default:
+   dev_err(dai->dev, "Unsupported sample rate: %u\n", 
rate);
+   return -EINVAL;
+   }
 
-   ret = clk_set_rate(i2s->mod_clk, clk_rate);
-   if (ret)
-   return ret;
+   ret = clk_set_rate(i2s->mod_clk, clk_rate);
+   if (ret) {
+   dev_err(dai->dev, "Unable to set clock\n");
+   return ret;
+   }
 
-   oversample_rate = i2s->mclk_freq / rate;
-   if (!sun4i_i2s_oversample_is_valid(oversample_rate)) {
-   dev_err(dai->dev, "Unsupported oversample rate: %d\n",
-   oversample_rate);
-   return -EINVAL;
-   }
+   oversample_rate = i2s->mclk_freq / rate;
+   if (!sun4i_i2s_oversample_is_valid(oversample_rate)) {
+   dev_err(dai->dev, "Unsupported oversample rate: %d\n",
+   oversample_rate);
+   return -EINVAL;
+   }
 
-   if (i2s->variant->has_fmt_set_lrck_period)
-   bclk_div = sun4i_i2s_get_bclk_div(i2s, clk_rate / rate,
- word_size,
- sun8i_i2s_clk_div,
- 
ARRAY_SIZE(sun8i_i2s_clk_div));
-   else
-   bclk_div = sun4i_i2s_get_bclk_div(i2s, oversample_rate,
- word_size,
- sun4i_i2s_bclk_div,
- 
ARRAY_SIZE(sun4i_i2s_bclk_div));
-   if (bclk_div < 0) {
-   dev_err(dai->dev, "Unsupported BCLK divider: %d\n",
-   bclk_div);
-   return -EINVAL;
-   }
+   if (i2s->variant->has_fmt_set_lrck_period)
+   bclk_div = sun4i_i2s_get_bclk_div(i2s, clk_rate / rate,
+ word_size,
+ sun8i_i2s_clk_div,
+ 
ARRAY_SIZE(sun8i_i2s_clk_div));
+   else
+   bclk_div = sun4i_i2s_get_bclk_div(i2s, oversample_rate,
+ word_size,
+ sun4i_i2s_bclk_div,
+ 
ARRAY_SIZE(sun4i_i2s_bclk_div));
+   if (bclk_div < 0) {
+   dev_err(dai->dev, "Unsupported BCLK divider: %d\n",
+   bclk_div);
+   return -EINVAL;
+   }
 
 
-   if (i2s->variant->has_fmt_set_lrck_period)
-   mclk_div = sun4i_i2s_get_mclk_div(i2s, oversample_rate,
-   

[PATCH RT 1/9] efi: Allow efi=runtime

2018-12-21 Thread Tom Zanussi
v3.18.129-rt111 rt-stable review patch.  If anyone has any objections,
please let me know.

--
From: Sebastian Andrzej Siewior 

[ Upstream commit 71bef7da4112ed2677d4f10a58202a5a4638fb90 ]

In case the option "efi=noruntime" is default at built-time, the user
could overwrite its sate by `efi=runtime' and allow it again.

Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Tom Zanussi 
---
 drivers/firmware/efi/efi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 297066df6946..e47c522e1d8f 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -59,6 +59,9 @@ static int __init parse_efi_cmdline(char *str)
if (parse_option_str(str, "noruntime"))
disable_runtime = true;
 
+   if (parse_option_str(str, "runtime"))
+   disable_runtime = false;
+
return 0;
 }
 early_param("efi", parse_efi_cmdline);
-- 
2.14.1



[PATCH RT 5/9] work-simple: drop a shit statement in SWORK_EVENT_PENDING

2018-12-21 Thread Tom Zanussi
v3.18.129-rt111 rt-stable review patch.  If anyone has any objections,
please let me know.

--
From: Sebastian Andrzej Siewior 

[ Upstream commit 22f41ebe5579cc847a7bb6c71916be92c8926216 ]

Dan Carpenter reported
| smatch warnings:
|kernel/sched/swork.c:63 swork_kthread() warn: test_bit() takes a bit number

This is not a bug because we shift by zero (and use the same value in
both places).
Nevertheless I'm dropping that shift by zero to keep smatch quiet.

Cc: Daniel Wagner 
Signed-off-by: Sebastian Andrzej Siewior 
[ tom.zanussi: applied to work-simple.c instead of swork.c ]
Signed-off-by: Tom Zanussi 
---
 kernel/sched/work-simple.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/work-simple.c b/kernel/sched/work-simple.c
index c996f755dba6..4284dd37aebe 100644
--- a/kernel/sched/work-simple.c
+++ b/kernel/sched/work-simple.c
@@ -11,7 +11,7 @@
 #include 
 #include 
 
-#define SWORK_EVENT_PENDING (1 << 0)
+#define SWORK_EVENT_PENDING 1
 
 static DEFINE_MUTEX(worker_mutex);
 static struct sworker *glob_worker;
-- 
2.14.1



[PATCH RT 7/9] pinctrl: bcm2835: Use raw spinlock for RT compatibility

2018-12-21 Thread Tom Zanussi
v3.18.129-rt111 rt-stable review patch.  If anyone has any objections,
please let me know.

--
From: Lukas Wunner 

[Upstream rt-devel commit 55016fa934eb0d4e037beef2b2f503012dfebeac]

[Upstream commit 71dfaa749f2f7c1722ebf6716d3f797a04528cba]

The BCM2835 pinctrl driver acquires a spinlock in its ->irq_enable,
->irq_disable and ->irq_set_type callbacks.  Spinlocks become sleeping
locks with CONFIG_PREEMPT_RT_FULL=y, therefore invocation of one of the
callbacks in atomic context may cause a hard lockup if at least two GPIO
pins in the same bank are used as interrupts.  The issue doesn't occur
with just a single interrupt pin per bank because the lock is never
contended.  I'm experiencing such lockups with GPIO 8 and 28 used as
level-triggered interrupts, i.e. with ->irq_disable being invoked on
reception of every IRQ.

The critical section protected by the spinlock is very small (one bitop
and one RMW of an MMIO register), hence converting to a raw spinlock
seems a better trade-off than converting the driver to threaded IRQ
handling (which would increase latency to handle an interrupt).

Cc: Mathias Duckeck 
Signed-off-by: Lukas Wunner 
Acked-by: Julia Cartwright 
Signed-off-by: Linus Walleij 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Tom Zanussi 

 Conflicts:
drivers/pinctrl/bcm/pinctrl-bcm2835.c
---
 drivers/pinctrl/pinctrl-bcm2835.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-bcm2835.c 
b/drivers/pinctrl/pinctrl-bcm2835.c
index eabba02f71f9..9a975a12b8e3 100644
--- a/drivers/pinctrl/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/pinctrl-bcm2835.c
@@ -106,7 +106,7 @@ struct bcm2835_pinctrl {
struct pinctrl_gpio_range gpio_range;
 
struct bcm2835_gpio_irqdata irq_data[BCM2835_NUM_BANKS];
-   spinlock_t irq_lock[BCM2835_NUM_BANKS];
+   raw_spinlock_t irq_lock[BCM2835_NUM_BANKS];
 };
 
 static struct lock_class_key gpio_lock_class;
@@ -465,10 +465,10 @@ static void bcm2835_gpio_irq_enable(struct irq_data *data)
unsigned bank = GPIO_REG_OFFSET(gpio);
unsigned long flags;
 
-   spin_lock_irqsave(>irq_lock[bank], flags);
+   raw_spin_lock_irqsave(>irq_lock[bank], flags);
set_bit(offset, >enabled_irq_map[bank]);
bcm2835_gpio_irq_config(pc, gpio, true);
-   spin_unlock_irqrestore(>irq_lock[bank], flags);
+   raw_spin_unlock_irqrestore(>irq_lock[bank], flags);
 }
 
 static void bcm2835_gpio_irq_disable(struct irq_data *data)
@@ -479,10 +479,10 @@ static void bcm2835_gpio_irq_disable(struct irq_data 
*data)
unsigned bank = GPIO_REG_OFFSET(gpio);
unsigned long flags;
 
-   spin_lock_irqsave(>irq_lock[bank], flags);
+   raw_spin_lock_irqsave(>irq_lock[bank], flags);
bcm2835_gpio_irq_config(pc, gpio, false);
clear_bit(offset, >enabled_irq_map[bank]);
-   spin_unlock_irqrestore(>irq_lock[bank], flags);
+   raw_spin_unlock_irqrestore(>irq_lock[bank], flags);
 }
 
 static int __bcm2835_gpio_irq_set_type_disabled(struct bcm2835_pinctrl *pc,
@@ -584,14 +584,14 @@ static int bcm2835_gpio_irq_set_type(struct irq_data 
*data, unsigned int type)
unsigned long flags;
int ret;
 
-   spin_lock_irqsave(>irq_lock[bank], flags);
+   raw_spin_lock_irqsave(>irq_lock[bank], flags);
 
if (test_bit(offset, >enabled_irq_map[bank]))
ret = __bcm2835_gpio_irq_set_type_enabled(pc, gpio, type);
else
ret = __bcm2835_gpio_irq_set_type_disabled(pc, gpio, type);
 
-   spin_unlock_irqrestore(>irq_lock[bank], flags);
+   raw_spin_unlock_irqrestore(>irq_lock[bank], flags);
 
return ret;
 }
@@ -1004,7 +1004,7 @@ static int bcm2835_pinctrl_probe(struct platform_device 
*pdev)
pc->irq[i] = irq_of_parse_and_map(np, i);
pc->irq_data[i].pc = pc;
pc->irq_data[i].bank = i;
-   spin_lock_init(>irq_lock[i]);
+   raw_spin_lock_init(>irq_lock[i]);
 
len = strlen(dev_name(pc->dev)) + 16;
name = devm_kzalloc(pc->dev, len, GFP_KERNEL);
-- 
2.14.1



[PATCH RT 9/9] Linux 3.18.129-rt111-rc1

2018-12-21 Thread Tom Zanussi
v3.18.129-rt111 rt-stable review patch.  If anyone has any objections,
please let me know.

--
From: Tom Zanussi 

---
 localversion-rt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/localversion-rt b/localversion-rt
index b3e668a8fb94..ff68eff1428c 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt110
+-rt111-rc1
-- 
2.14.1



[PATCH RT 6/9] tty: serial: pl011: explicitly initialize the flags variable

2018-12-21 Thread Tom Zanussi
v3.18.129-rt111 rt-stable review patch.  If anyone has any objections,
please let me know.

--
From: Kurt Kanzenbach 

[ Upstream commit 3260983a587d528811a15fc00fa2a9e4473c4453 ]

Silence the following gcc warning:

drivers/tty/serial/amba-pl011.c: In function ‘pl011_console_write’:
./include/linux/spinlock.h:260:3: warning: ‘flags’ may be used uninitialized in 
this function [-Wmaybe-uninitialized]
   _raw_spin_unlock_irqrestore(lock, flags); \
   ^~~
drivers/tty/serial/amba-pl011.c:2214:16: note: ‘flags’ was declared here
  unsigned long flags;
^

The code is correct. Thus, initializing flags to zero doesn't change the
behavior and resolves the warning.

Signed-off-by: Kurt Kanzenbach 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Tom Zanussi 
---
 drivers/tty/serial/amba-pl011.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 5ef2c62bb904..dede68aa679e 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -1930,7 +1930,7 @@ pl011_console_write(struct console *co, const char *s, 
unsigned int count)
 {
struct uart_amba_port *uap = amba_ports[co->index];
unsigned int status, old_cr, new_cr;
-   unsigned long flags;
+   unsigned long flags = 0;
int locked = 1;
 
clk_enable(uap->clk);
-- 
2.14.1



[PATCH RT 4/9] sched/core: Avoid __schedule() being called twice in a row

2018-12-21 Thread Tom Zanussi
v3.18.129-rt111 rt-stable review patch.  If anyone has any objections,
please let me know.

--
From: Daniel Bristot de Oliveira 

[ Upstream commit 2bb94c48b2ffaabf8c15a51e5cc1b4c541988cab ]

If a worker invokes schedule() then we may have the call chain:
 schedule()
 -> sched_submit_work()
-> wq_worker_sleeping()
   -> wake_up_worker()
  -> wake_up_process().

The last wakeup may cause a schedule which is unnecessary because we are
already in schedule() and do it anyway.

Add a preempt_disable() + preempt_enable_no_resched() around
wq_worker_sleeping() so the context switch could be delayed until
__schedule().

Signed-off-by: Daniel Bristot de Oliveira 
Cc: Clark Williams 
Cc: Tommaso Cucinotta 
Cc: Romulo da Silva de Oliveira 
Cc: Sebastian Andrzej Siewior 
Cc: Steven Rostedt 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
[bigeasy: rewrite changelog]
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Tom Zanussi 
---
 kernel/sched/core.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index d5534f439b4a..500c319fcfc5 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3114,10 +3114,15 @@ static inline void sched_submit_work(struct task_struct 
*tsk)
/*
 * If a worker went to sleep, notify and ask workqueue whether
 * it wants to wake up a task to maintain concurrency.
+* As this function is called inside the schedule() context,
+* we disable preemption to avoid it calling schedule() again
+* in the possible wakeup of a kworker.
 */
-   if (tsk->flags & PF_WQ_WORKER)
+   if (tsk->flags & PF_WQ_WORKER) {
+   preempt_disable();
wq_worker_sleeping(tsk);
-
+   preempt_enable_no_resched();
+   }
 
if (tsk_is_pi_blocked(tsk))
return;
-- 
2.14.1



[PATCH RT 8/9] drm/i915: disable tracing on -RT

2018-12-21 Thread Tom Zanussi
v3.18.129-rt111 rt-stable review patch.  If anyone has any objections,
please let me know.

--
From: Sebastian Andrzej Siewior 

[Upstream commit 05cebb309b156646e61b898e92acc8e46c47ba75]

Luca Abeni reported this:
| BUG: scheduling while atomic: kworker/u8:2/15203/0x0003
| CPU: 1 PID: 15203 Comm: kworker/u8:2 Not tainted 4.19.1-rt3 #10
| Call Trace:
|  rt_spin_lock+0x3f/0x50
|  gen6_read32+0x45/0x1d0 [i915]
|  g4x_get_vblank_counter+0x36/0x40 [i915]
|  trace_event_raw_event_i915_pipe_update_start+0x7d/0xf0 [i915]

The tracing events use trace_i915_pipe_update_start() among other events
use functions acquire spin locks. A few trace points use
intel_get_crtc_scanline(), others use ->get_vblank_counter() wich also
might acquire a sleeping lock.

Based on this I don't see any other way than disable trace points on RT.

Cc: stable...@vger.kernel.org
Reported-by: Luca Abeni 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Tom Zanussi 
---
 drivers/gpu/drm/i915/i915_trace.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_trace.h 
b/drivers/gpu/drm/i915/i915_trace.h
index f5aa0067755a..3b37567b76c8 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -1,6 +1,10 @@
 #if !defined(_I915_TRACE_H_) || defined(TRACE_HEADER_MULTI_READ)
 #define _I915_TRACE_H_
 
+#ifdef CONFIG_PREEMPT_RT_BASE
+#define NOTRACE
+#endif
+
 #include 
 #include 
 #include 
-- 
2.14.1



[PATCH v3 1/9] ASoC: sun4i-i2s: Adjust regmap settings

2018-12-21 Thread codekipper
From: Marcus Cooper 

Bypass the regmap cache when flushing the i2s FIFOs and modify the tables
to reflect this.

Signed-off-by: Marcus Cooper 
---
 sound/soc/sunxi/sun4i-i2s.c | 29 +
 1 file changed, 9 insertions(+), 20 deletions(-)

diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index d5ec1a20499d..64d073cb2aee 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -548,9 +548,11 @@ static int sun4i_i2s_set_fmt(struct snd_soc_dai *dai, 
unsigned int fmt)
 static void sun4i_i2s_start_capture(struct sun4i_i2s *i2s)
 {
/* Flush RX FIFO */
+   regcache_cache_bypass(i2s->regmap, true);
regmap_update_bits(i2s->regmap, SUN4I_I2S_FIFO_CTRL_REG,
   SUN4I_I2S_FIFO_CTRL_FLUSH_RX,
   SUN4I_I2S_FIFO_CTRL_FLUSH_RX);
+   regcache_cache_bypass(i2s->regmap, false);
 
/* Clear RX counter */
regmap_write(i2s->regmap, SUN4I_I2S_RX_CNT_REG, 0);
@@ -569,9 +571,11 @@ static void sun4i_i2s_start_capture(struct sun4i_i2s *i2s)
 static void sun4i_i2s_start_playback(struct sun4i_i2s *i2s)
 {
/* Flush TX FIFO */
+   regcache_cache_bypass(i2s->regmap, true);
regmap_update_bits(i2s->regmap, SUN4I_I2S_FIFO_CTRL_REG,
   SUN4I_I2S_FIFO_CTRL_FLUSH_TX,
   SUN4I_I2S_FIFO_CTRL_FLUSH_TX);
+   regcache_cache_bypass(i2s->regmap, false);
 
/* Clear TX counter */
regmap_write(i2s->regmap, SUN4I_I2S_TX_CNT_REG, 0);
@@ -703,13 +707,7 @@ static const struct snd_soc_component_driver 
sun4i_i2s_component = {
 
 static bool sun4i_i2s_rd_reg(struct device *dev, unsigned int reg)
 {
-   switch (reg) {
-   case SUN4I_I2S_FIFO_TX_REG:
-   return false;
-
-   default:
-   return true;
-   }
+   return true;
 }
 
 static bool sun4i_i2s_wr_reg(struct device *dev, unsigned int reg)
@@ -728,6 +726,8 @@ static bool sun4i_i2s_volatile_reg(struct device *dev, 
unsigned int reg)
 {
switch (reg) {
case SUN4I_I2S_FIFO_RX_REG:
+   case SUN4I_I2S_FIFO_TX_REG:
+   case SUN4I_I2S_FIFO_STA_REG:
case SUN4I_I2S_INT_STA_REG:
case SUN4I_I2S_RX_CNT_REG:
case SUN4I_I2S_TX_CNT_REG:
@@ -738,23 +738,12 @@ static bool sun4i_i2s_volatile_reg(struct device *dev, 
unsigned int reg)
}
 }
 
-static bool sun8i_i2s_rd_reg(struct device *dev, unsigned int reg)
-{
-   switch (reg) {
-   case SUN8I_I2S_FIFO_TX_REG:
-   return false;
-
-   default:
-   return true;
-   }
-}
-
 static bool sun8i_i2s_volatile_reg(struct device *dev, unsigned int reg)
 {
if (reg == SUN8I_I2S_INT_STA_REG)
return true;
if (reg == SUN8I_I2S_FIFO_TX_REG)
-   return false;
+   return true;
 
return sun4i_i2s_volatile_reg(dev, reg);
 }
@@ -809,7 +798,7 @@ static const struct regmap_config sun8i_i2s_regmap_config = 
{
.reg_defaults   = sun8i_i2s_reg_defaults,
.num_reg_defaults   = ARRAY_SIZE(sun8i_i2s_reg_defaults),
.writeable_reg  = sun4i_i2s_wr_reg,
-   .readable_reg   = sun8i_i2s_rd_reg,
+   .readable_reg   = sun4i_i2s_rd_reg,
.volatile_reg   = sun8i_i2s_volatile_reg,
 };
 
-- 
2.20.1



[PATCH v3 0/9] ASoC: sun4i-i2s: Updates to the driver

2018-12-21 Thread codekipper
From: Marcus Cooper 

Hi All,

here is a patch series to add some improvements to the sun4i-i2s driver
found whilst getting slave clocking and hdmi audio working on the newer
SoCs. Since the last push there has been some activity getting surround
sound working and this is included.

The functionality included with the new patch set has been extended to
cover more sample resolutions, multi-lane data output for HDMI audio
and some bug fixes that have been discovered along the way.

I can see more usage of the tdm property since I last attempted to push
these patches and the examples currently in mainline sort of the opposite
to what I'm trying to achieve. When we first started looking at the i2s
driver, the codecs that we were using allowed for the frame width to be
determined based on the sampling resolution but in most use cases it
seems that a fixed width is required(my highest priority should be to get
HDMI audio support in). We're using the tdm property to override the old
way to calculate the frame width. What I've seen in what has already been
mainlined is that the i2s driver has a frame width that is fixed to 32
bits and this can be overridden using the tdm property.

Anyway, I've moved the more controversial patches to the top of the stack
as I'm expecting feedback.

Have a great Xmas and New Year,

BR,
CK

---

v3 changes compared to v2 are:
 - added back slave mode changes
 - added back the use of tdm properties
 - changes to regmap and caching
 - removed loopback functionality
 - fixes to the channel offset mask

v2 changes compared to v1 are:
 - removed slave mode changes which didn't set mclk and bclk div.
 - removed use of tdm and now use a dedicated property.
 - fix commit message to better explain reason for sign extending
 - add divider calculations for newer SoCs.
 - add support for multi-lane i2s data output.
 - add support for 20, 24 and 32 bit samples.
 - add loopback property so blocks can be tested without a codec.

---

Marcus Cooper (9):
  ASoC: sun4i-i2s: Adjust regmap settings
  ASoC: sun4i-i2s: Add regmap field to sign extend sample
  ASoc: sun4i-i2s: Add 20, 24 and 32 bit support
  ASoC: sun4i-i2s: Fix offset mask
  ASoC: sun4i-i2s: Correct divider calculations
  ASoC: sun4i-i2s: Add multi-lane functionality
  ASoC: sun4i-i2s: Do not divide clocks when slave
  ASoC: sun4i-i2s: Add set_tdm_slot functionality
  ASoC: sun4i-i2s: Add multichannel functionality

 sound/soc/sunxi/sun4i-i2s.c | 399 
 1 file changed, 267 insertions(+), 132 deletions(-)

-- 
2.20.1



[PATCH v3 9/9] ASoC: sun4i-i2s: Add multichannel functionality

2018-12-21 Thread codekipper
From: Marcus Cooper 

The i2s block can be used to pass PCM data over multiple channels
and is sometimes used for the audio side of an HDMI connection.

Signed-off-by: Marcus Cooper 
---
 sound/soc/sunxi/sun4i-i2s.c | 121 +++-
 1 file changed, 64 insertions(+), 57 deletions(-)

diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index cfcf427270fd..2be3a3e7a3c0 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -199,6 +199,7 @@ struct sun4i_i2s {
 
unsigned inttdm_slots;
unsigned intslot_width;
+   unsigned intoffset;
 };
 
 struct sun4i_i2s_clk_div {
@@ -406,56 +407,71 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream 
*substream,
int lines;
 
channels = params_channels(params);
-   if ((channels > dai->driver->playback.channels_max) ||
-   (channels < dai->driver->playback.channels_min)) {
-   dev_err(dai->dev, "Unsupported number of channels: %d\n",
-   channels);
-   return -EINVAL;
-   }
-
-   lines = (channels + 1) / 2;
+   if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
+   if ((channels > dai->driver->playback.channels_max) ||
+   (channels < dai->driver->playback.channels_min)) {
+   dev_err(dai->dev, "Unsupported number of channels: 
%d\n",
+   channels);
+   return -EINVAL;
+   }
 
-   /* Enable the required output lines */
-   regmap_update_bits(i2s->regmap, SUN4I_I2S_CTRL_REG,
-  SUN4I_I2S_CTRL_SDO_EN_MASK,
-  SUN4I_I2S_CTRL_SDO_EN(lines));
-
-   if (i2s->variant->has_chcfg) {
-   regmap_update_bits(i2s->regmap, SUN8I_I2S_CHAN_CFG_REG,
-  SUN8I_I2S_CHAN_CFG_TX_SLOT_NUM_MASK,
-  SUN8I_I2S_CHAN_CFG_TX_SLOT_NUM(channels));
-   regmap_update_bits(i2s->regmap, SUN8I_I2S_CHAN_CFG_REG,
-  SUN8I_I2S_CHAN_CFG_RX_SLOT_NUM_MASK,
-  SUN8I_I2S_CHAN_CFG_RX_SLOT_NUM(channels));
-   }
+   lines = (channels + 1) / 2;
 
-   /* Map the channels for playback and capture */
-   regmap_field_write(i2s->field_rxchanmap, 0x3210);
-   regmap_field_write(i2s->field_txchanmap, 0x10);
-   if (i2s->variant->has_chsel_tx_chen) {
-   if (channels > 2)
-   regmap_write(i2s->regmap,
-SUN8I_I2S_TX_CHAN_MAP_REG+4, 0x32);
-   if (channels > 4)
-   regmap_write(i2s->regmap,
-SUN8I_I2S_TX_CHAN_MAP_REG+8, 0x54);
-   if (channels > 6)
-   regmap_write(i2s->regmap,
-SUN8I_I2S_TX_CHAN_MAP_REG+12, 0x76);
+   /* Enable the required output lines */
+   regmap_update_bits(i2s->regmap, SUN4I_I2S_CTRL_REG,
+  SUN4I_I2S_CTRL_SDO_EN_MASK,
+  SUN4I_I2S_CTRL_SDO_EN(lines));
+
+   if (i2s->variant->has_chcfg)
+   regmap_update_bits(i2s->regmap, SUN8I_I2S_CHAN_CFG_REG,
+  SUN8I_I2S_CHAN_CFG_TX_SLOT_NUM_MASK,
+  
SUN8I_I2S_CHAN_CFG_TX_SLOT_NUM(channels));
+
+   regmap_field_write(i2s->field_txchanmap, 0x10);
+   /* Configure the channels */
+   regmap_field_write(i2s->field_txchansel, SUN4I_I2S_CHAN_SEL(2));
+
+   if (i2s->variant->has_chsel_tx_chen) {
+   u32 chan_sel = SUN8I_I2S_TX_CHAN_OFFSET(i2s->offset) | 
0x1;
+   regmap_write(i2s->regmap, SUN8I_I2S_TX_CHAN_SEL_REG,
+chan_sel | 0x30);
+
+   if (channels > 2) {
+   regmap_write(i2s->regmap,
+SUN8I_I2S_TX_CHAN_MAP_REG+4, 0x32);
+   regmap_write(i2s->regmap, 
SUN8I_I2S_TX_CHAN_SEL_REG+4,
+chan_sel | 0x30);
+   }
+   if (channels > 4) {
+   regmap_write(i2s->regmap,
+SUN8I_I2S_TX_CHAN_MAP_REG+8, 0x54);
+   regmap_write(i2s->regmap, 
SUN8I_I2S_TX_CHAN_SEL_REG+8,
+chan_sel | 0x30);
+   }
+   if (channels > 6) {
+   regmap_write(i2s->regmap,
+SUN8I_I2S_TX_CHAN_MAP_REG+12, 
0x76);
+   regmap_write(i2s->regmap, 
SUN8I_I2S_TX_CHAN_SEL_REG+12,

[PATCH RT 2/9] efi: Disable runtime services on RT

2018-12-21 Thread Tom Zanussi
v3.18.129-rt111 rt-stable review patch.  If anyone has any objections,
please let me know.

--
From: Sebastian Andrzej Siewior 

[ Upstream commit 55544e1d5eb0d7608e2b41452729649c8ea1607a ]

Based on meassurements the EFI functions get_variable /
get_next_variable take up to 2us which looks okay.
The functions get_time, set_time take around 10ms. Those 10ms are too
much. Even one ms would be too much.
Ard mentioned that SetVariable might even trigger larger latencies if
the firware will erase flash blocks on NOR.

The time-functions are used by efi-rtc and can be triggered during
runtimed (either via explicit read/write or ntp sync).

The variable write could be used by pstore.
These functions can be disabled without much of a loss. The poweroff /
reboot hooks may be provided by PSCI.

Disable EFI's runtime wrappers.

This was observed on "EFI v2.60 by SoftIron Overdrive 1000".

Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Tom Zanussi 

 Conflicts:
drivers/firmware/efi/efi.c
---
 drivers/firmware/efi/efi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index e47c522e1d8f..f2be407247e5 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -41,7 +41,7 @@ struct efi __read_mostly efi = {
 };
 EXPORT_SYMBOL(efi);
 
-static bool disable_runtime;
+static bool disable_runtime = IS_ENABLED(CONFIG_PREEMPT_RT_BASE);
 static int __init setup_noefi(char *arg)
 {
disable_runtime = true;
-- 
2.14.1



[PATCH RT 3/9] crypto: cryptd - add a lock instead preempt_disable/local_bh_disable

2018-12-21 Thread Tom Zanussi
v3.18.129-rt111 rt-stable review patch.  If anyone has any objections,
please let me know.

--
From: Sebastian Andrzej Siewior 

[ Upstream commit 21aedb30d85979697f79a72a084e5d781e323663 ]

cryptd has a per-CPU lock which protected with local_bh_disable() and
preempt_disable().
Add an explicit spin_lock to make the locking context more obvious and
visible to lockdep. Since it is a per-CPU lock, there should be no lock
contention on the actual spinlock.
There is a small race-window where we could be migrated to another CPU
after the cpu_queue has been obtain. This is not a problem because the
actual ressource is protected by the spinlock.

Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Tom Zanussi 

 Conflicts:
crypto/cryptd.c
---
 crypto/cryptd.c | 18 --
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/crypto/cryptd.c b/crypto/cryptd.c
index 828ead458c09..ec32d9bf4651 100644
--- a/crypto/cryptd.c
+++ b/crypto/cryptd.c
@@ -36,6 +36,7 @@
 struct cryptd_cpu_queue {
struct crypto_queue queue;
struct work_struct work;
+   spinlock_t qlock;
 };
 
 struct cryptd_queue {
@@ -97,6 +98,7 @@ static int cryptd_init_queue(struct cryptd_queue *queue,
cpu_queue = per_cpu_ptr(queue->cpu_queue, cpu);
crypto_init_queue(_queue->queue, max_cpu_qlen);
INIT_WORK(_queue->work, cryptd_queue_worker);
+   spin_lock_init(_queue->qlock);
}
return 0;
 }
@@ -119,11 +121,12 @@ static int cryptd_enqueue_request(struct cryptd_queue 
*queue,
int cpu, err;
struct cryptd_cpu_queue *cpu_queue;
 
-   cpu = get_cpu();
-   cpu_queue = this_cpu_ptr(queue->cpu_queue);
+   cpu_queue = raw_cpu_ptr(queue->cpu_queue);
+   spin_lock_bh(_queue->qlock);
+   cpu = smp_processor_id();
err = crypto_enqueue_request(_queue->queue, request);
queue_work_on(cpu, kcrypto_wq, _queue->work);
-   put_cpu();
+   spin_unlock_bh(_queue->qlock);
 
return err;
 }
@@ -139,16 +142,11 @@ static void cryptd_queue_worker(struct work_struct *work)
cpu_queue = container_of(work, struct cryptd_cpu_queue, work);
/*
 * Only handle one request at a time to avoid hogging crypto workqueue.
-* preempt_disable/enable is used to prevent being preempted by
-* cryptd_enqueue_request(). local_bh_disable/enable is used to prevent
-* cryptd_enqueue_request() being accessed from software interrupts.
 */
-   local_bh_disable();
-   preempt_disable();
+   spin_lock_bh(_queue->qlock);
backlog = crypto_get_backlog(_queue->queue);
req = crypto_dequeue_request(_queue->queue);
-   preempt_enable();
-   local_bh_enable();
+   spin_unlock_bh(_queue->qlock);
 
if (!req)
return;
-- 
2.14.1



[PATCH v3 5/9] ASoC: sun4i-i2s: Correct divider calculations

2018-12-21 Thread codekipper
From: Marcus Cooper 

The clock division circuitry is different on the H3 and later SoCs.
The division of bclk is now based on pll2.

Signed-off-by: Marcus Cooper 
---
 sound/soc/sunxi/sun4i-i2s.c | 82 +
 1 file changed, 56 insertions(+), 26 deletions(-)

diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index 93a484d7e228..b31f84787218 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -129,10 +129,10 @@
  * @has_chsel_offset: SoC uses offset for selecting dai operational mode.
  * @reg_offset_txdata: offset of the tx fifo.
  * @sun4i_i2s_regmap: regmap config to use.
- * @mclk_offset: Value by which mclkdiv needs to be adjusted.
- * @bclk_offset: Value by which bclkdiv needs to be adjusted.
  * @fmt_offset: Value by which wss and sr needs to be adjusted.
  * @field_clkdiv_mclk_en: regmap field to enable mclk output.
+ * @field_clkdiv_mclk: regmap field for mclkdiv.
+ * @field_clkdiv_bclk: regmap field for bclkdiv.
  * @field_fmt_wss: regmap field to set word select size.
  * @field_fmt_sr: regmap field to set sample resolution.
  * @field_fmt_bclk: regmap field to set clk polarity.
@@ -153,8 +153,6 @@ struct sun4i_i2s_quirks {
boolhas_chsel_offset;
unsigned intreg_offset_txdata;  /* TX FIFO */
const struct regmap_config  *sun4i_i2s_regmap;
-   unsigned intmclk_offset;
-   unsigned intbclk_offset;
unsigned intfmt_offset;
 
/* Register fields for i2s */
@@ -210,7 +208,25 @@ static const struct sun4i_i2s_clk_div sun4i_i2s_bclk_div[] 
= {
{ .div = 8, .val = 3 },
{ .div = 12, .val = 4 },
{ .div = 16, .val = 5 },
-   /* TODO - extend divide ratio supported by newer SoCs */
+};
+
+static const struct sun4i_i2s_clk_div sun8i_i2s_clk_div[] = {
+   { .div = 0, .val = 0 },
+   { .div = 1, .val = 1 },
+   { .div = 2, .val = 2 },
+   { .div = 4, .val = 3 },
+   { .div = 6, .val = 4 },
+   { .div = 8, .val = 5 },
+   { .div = 12, .val = 6 },
+   { .div = 16, .val = 7 },
+   { .div = 24, .val = 8 },
+   { .div = 32, .val = 9 },
+   { .div = 48, .val = 10 },
+   { .div = 64, .val = 11 },
+   { .div = 96, .val = 12 },
+   { .div = 128, .val = 13 },
+   { .div = 176, .val = 14 },
+   { .div = 192, .val = 15 },
 };
 
 static const struct sun4i_i2s_clk_div sun4i_i2s_mclk_div[] = {
@@ -222,21 +238,21 @@ static const struct sun4i_i2s_clk_div 
sun4i_i2s_mclk_div[] = {
{ .div = 12, .val = 5 },
{ .div = 16, .val = 6 },
{ .div = 24, .val = 7 },
-   /* TODO - extend divide ratio supported by newer SoCs */
 };
 
 static int sun4i_i2s_get_bclk_div(struct sun4i_i2s *i2s,
  unsigned int oversample_rate,
- unsigned int word_size)
+ unsigned int word_size,
+ const struct sun4i_i2s_clk_div *bdiv,
+ unsigned int size)
 {
int div = oversample_rate / word_size / 2;
int i;
 
-   for (i = 0; i < ARRAY_SIZE(sun4i_i2s_bclk_div); i++) {
-   const struct sun4i_i2s_clk_div *bdiv = _i2s_bclk_div[i];
-
+   for (i = 0; i < size; i++) {
if (bdiv->div == div)
return bdiv->val;
+   bdiv++;
}
 
return -EINVAL;
@@ -245,16 +261,17 @@ static int sun4i_i2s_get_bclk_div(struct sun4i_i2s *i2s,
 static int sun4i_i2s_get_mclk_div(struct sun4i_i2s *i2s,
  unsigned int oversample_rate,
  unsigned int module_rate,
- unsigned int sampling_rate)
+ unsigned int sampling_rate,
+ const struct sun4i_i2s_clk_div *mdiv,
+ unsigned int size)
 {
int div = module_rate / sampling_rate / oversample_rate;
int i;
 
-   for (i = 0; i < ARRAY_SIZE(sun4i_i2s_mclk_div); i++) {
-   const struct sun4i_i2s_clk_div *mdiv = _i2s_mclk_div[i];
-
+   for (i = 0; i < size; i++) {
if (mdiv->div == div)
return mdiv->val;
+   mdiv++;
}
 
return -EINVAL;
@@ -319,24 +336,39 @@ static int sun4i_i2s_set_clk_rate(struct snd_soc_dai *dai,
return -EINVAL;
}
 
-   bclk_div = sun4i_i2s_get_bclk_div(i2s, oversample_rate,
- word_size);
+   if (i2s->variant->has_fmt_set_lrck_period)
+   bclk_div = sun4i_i2s_get_bclk_div(i2s, clk_rate / rate,
+ word_size,
+ sun8i_i2s_clk_div,
+ 

[PATCH v3 4/9] ASoC: sun4i-i2s: Fix offset mask

2018-12-21 Thread codekipper
From: Marcus Cooper 

Also add offset to RX channel select

Signed-off-by: Marcus Cooper 
---
 sound/soc/sunxi/sun4i-i2s.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index adb988ae9ac5..93a484d7e228 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -110,7 +110,7 @@
 
 #define SUN8I_I2S_TX_CHAN_MAP_REG  0x44
 #define SUN8I_I2S_TX_CHAN_SEL_REG  0x34
-#define SUN8I_I2S_TX_CHAN_OFFSET_MASK  GENMASK(13, 11)
+#define SUN8I_I2S_TX_CHAN_OFFSET_MASK  GENMASK(13, 12)
 #define SUN8I_I2S_TX_CHAN_OFFSET(offset)   (offset << 12)
 #define SUN8I_I2S_TX_CHAN_EN_MASK  GENMASK(11, 4)
 #define SUN8I_I2S_TX_CHAN_EN(num_chan) (((1 << num_chan) - 1) << 4)
@@ -482,6 +482,10 @@ static int sun4i_i2s_set_fmt(struct snd_soc_dai *dai, 
unsigned int fmt)
regmap_update_bits(i2s->regmap, SUN8I_I2S_TX_CHAN_SEL_REG,
   SUN8I_I2S_TX_CHAN_OFFSET_MASK,
   SUN8I_I2S_TX_CHAN_OFFSET(offset));
+
+   regmap_update_bits(i2s->regmap, SUN8I_I2S_RX_CHAN_SEL_REG,
+  SUN8I_I2S_TX_CHAN_OFFSET_MASK,
+  SUN8I_I2S_TX_CHAN_OFFSET(offset));
}
 
regmap_field_write(i2s->field_fmt_mode, val);
-- 
2.20.1



[PATCH v4] include/linux/nodemask.h: Use nr_node_ids (not MAX_NUMNODES) in __nodemask_pr_numnodes()

2018-12-21 Thread Waiman Long
When viewing the /proc//status file, one can see output lines like

  Cpus_allowed: ,,
  Cpus_allowed_list:0-95
  Mems_allowed: 
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,000f
  Mems_allowed_list:0-3

The "Mems_allowed" line uses the "%*pb" format string while the
"Mems_allowed_list" line uses the "%*pbl" format string together with
the nodemask_pr_args() macro.

The "Mems_allowed" looks insane compared with the others.  It is because
the nodemask_pr_args() macro uses MAX_NUMNODES as the number of nodes
to iterate. The cpumask_pr_args() macro uses nr_cpu_ids instead of
MAX_CPUS. For nodes, there is a corresponding nr_node_ids.  So it makes
sense to use nr_node_ids instead to be consistent with "Cpus_allowed:".

With that change, the "Mems_allowed" line becomes sane again.

  Mems_allowed: f

There are currently 10 call sites of nodemask_pr_args() in the kernel.
Of them, only cpuset_task_status_allowed() in kernel/cgroup/cpuset.c
uses the "%*pb" format string that will be affected by this change. That
cpuset function is called by proc_pid_status() only.

 v4: Fix build problem with MAX_NUMNODES=1.

Signed-off-by: Waiman Long 
---
 include/linux/nodemask.h | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/include/linux/nodemask.h b/include/linux/nodemask.h
index 5a30ad5..2fc99ac 100644
--- a/include/linux/nodemask.h
+++ b/include/linux/nodemask.h
@@ -98,6 +98,14 @@
 typedef struct { DECLARE_BITMAP(bits, MAX_NUMNODES); } nodemask_t;
 extern nodemask_t _unused_nodemask_arg_;
 
+#if MAX_NUMNODES > 1
+extern int nr_node_ids;
+extern int nr_online_nodes;
+#else
+#define nr_node_ids1
+#define nr_online_nodes1
+#endif
+
 /**
  * nodemask_pr_args - printf args to output a nodemask
  * @maskp: nodemask to be printed
@@ -108,7 +116,7 @@
__nodemask_pr_bits(maskp)
 static inline unsigned int __nodemask_pr_numnodes(const nodemask_t *m)
 {
-   return m ? MAX_NUMNODES : 0;
+   return m ? nr_node_ids : 0;
 }
 static inline const unsigned long *__nodemask_pr_bits(const nodemask_t *m)
 {
@@ -444,9 +452,6 @@ static inline int next_memory_node(int nid)
return next_node(nid, node_states[N_MEMORY]);
 }
 
-extern int nr_node_ids;
-extern int nr_online_nodes;
-
 static inline void node_set_online(int nid)
 {
node_set_state(nid, N_ONLINE);
@@ -485,8 +490,6 @@ static inline int num_node_state(enum node_states state)
 #define first_online_node  0
 #define first_memory_node  0
 #define next_online_node(nid)  (MAX_NUMNODES)
-#define nr_node_ids1
-#define nr_online_nodes1
 
 #define node_set_online(node) node_set_state((node), N_ONLINE)
 #define node_set_offline(node)node_clear_state((node), N_ONLINE)
-- 
1.8.3.1



Re: [PATCH v4 02/14] X86/nVMX: handle_vmptrld: Copy the VMCS12 directly from guest memory

2018-12-21 Thread Paolo Bonzini
On 06/12/18 00:10, Jim Mattson wrote:
> On Mon, Dec 3, 2018 at 1:31 AM KarimAllah Ahmed  wrote:
>>
>> Copy the VMCS12 directly from guest memory instead of the map->copy->unmap
>> sequence. This also avoids using kvm_vcpu_gpa_to_page() and kmap() which
>> assumes that there is a "struct page" for guest memory.
>>
>> Signed-off-by: KarimAllah Ahmed 
>> ---
>> v3 -> v4:
>> - Return VMXERR_VMPTRLD_INCORRECT_VMCS_REVISION_ID on failure (jmattson@)
>> v1 -> v2:
>> - Massage commit message a bit.
>> ---
>>  arch/x86/kvm/vmx.c | 24 
>>  1 file changed, 12 insertions(+), 12 deletions(-)
>>
>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>> index b84f230..75817cb 100644
>> --- a/arch/x86/kvm/vmx.c
>> +++ b/arch/x86/kvm/vmx.c
>> @@ -9301,20 +9301,22 @@ static int handle_vmptrld(struct kvm_vcpu *vcpu)
>> return 1;
>>
>> if (vmx->nested.current_vmptr != vmptr) {
>> -   struct vmcs12 *new_vmcs12;
>> -   struct page *page;
>> -   page = kvm_vcpu_gpa_to_page(vcpu, vmptr);
>> -   if (is_error_page(page))
>> -   return nested_vmx_failInvalid(vcpu);
>> +   struct vmcs12 *new_vmcs12 = (struct vmcs12 
>> *)__get_free_page(GFP_KERNEL);
>> +
>> +   if (!new_vmcs12 ||
>> +   kvm_read_guest(vcpu->kvm, vmptr, new_vmcs12,
>> +  sizeof(*new_vmcs12))) {
> 
> Isn't this a lot slower than kmap() when there is a struct page?

It wouldn't be slower if he read directly into cached_vmcs12.  However,
as it is now, it's doing two reads instead of one.  By doing this, the
ENOMEM case also disappears.

Paolo


Re: [PATCH] x86/cpu: sort cpuinfo flags

2018-12-21 Thread Dave Hansen
On 12/21/18 5:04 AM, Borislav Petkov wrote:
> 
> $ grep -m 1 flags /proc/cpuinfo | tr " " "\n" | sort | xargs
> 
> and there probably is even a simpler way to do that.
> 
> Or add a shell alias for that or a small script or ...

I don't always look at these through the shell.  I got a screenshot the
other day, or someone pasted the flags into a spreadsheet.

/proc/cpuinfo is supposed to be human-readable.  But, the flags field,
as it stands, is not.  You've further proved my point by having to
machine post-process it to make it usable by humans. :)



Re: A weird problem of Realtek r8168 after resume from S3

2018-12-21 Thread Chris Chiu
On Fri, Dec 21, 2018 at 3:22 AM Heiner Kallweit  wrote:
>
> On 20.12.2018 10:43, Chris Chiu wrote:
> > On Thu, Dec 20, 2018 at 3:41 AM Heiner Kallweit  
> > wrote:
> >>
> >> On 19.12.2018 16:32, Chris Chiu wrote:
> >>> On Wed, Dec 19, 2018 at 4:28 AM Heiner Kallweit  
> >>> wrote:
> 
>  On 18.12.2018 14:25, Chris Chiu wrote:
> > On Tue, Dec 18, 2018 at 3:08 AM Heiner Kallweit  
> > wrote:
> >>
> >> On 17.12.2018 14:25, Chris Chiu wrote:
> >>> On Fri, Dec 14, 2018 at 3:37 PM Heiner Kallweit 
> >>>  wrote:
> 
>  On 14.12.2018 04:33, Chris Chiu wrote:
> > On Thu, Dec 13, 2018 at 10:20 AM Chris Chiu  
> > wrote:
> >>
> >> Hi,
> >> We got an acer laptop which has a problem with ethernet 
> >> networking after
> >> resuming from S3. The ethernet is popular realtek r8168. The lspci 
> >> shows as
> >> follows.
> >> 02:00.1 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
> >> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller 
> >> [10ec:8168] (rev 12)
> >>
>  Helpful would be a "dmesg | grep r8169", especially chip name + XID.
> 
> >>> [   22.362774] r8169 :02:00.1 (unnamed net_device)
> >>> (uninitialized): mac_version = 0x2b
> >>> [   22.365580] libphy: r8169: probed
> >>> [   22.365958] r8169 :02:00.1 eth0: RTL8411, 00:e0:b8:1f:cb:83,
> >>> XID 5c800800, IRQ 38
> >>> [   22.365961] r8169 :02:00.1 eth0: jumbo features [frames: 9200
> >>> bytes, tx checksumming: ko]
> >>>
> >> Thanks for the info.
> >>
> >> The problem is the ethernet is not accessible after resume. 
> >> Pinging via
> >> ethernet always shows the response `Destination Host Unreachable`. 
> >> However,
> >> the interesting part is, when I run tcpdump to monitor the 
> >> problematic ethernet
> >> interface, the networking is back to alive. But it's dead again 
> >> after
> >> I stop tcpdump.
> >> One more thing, if I ping the problematic machine from others, it 
> >> achieves the
> >> same effect as above tcpdump. Maybe it's about the register 
> >> setting for RX path?
> >>
>  You could compare the register dumps (ethtool -d) before and after 
>  S3 sleep
>  to find out whether there's a difference.
> 
> >>>
> >>> Actually, I just found I lead the wrong direction. The S3 suspend does
> >>> help to reproduce,
> >>> but it's not necessary. All I need to do is ping around 5 mins and the
> >>> network connection
> >>> fails.  And I also find one thing interesting, disabling the  MSI-X
> >>> interrupt like commit
> >>> [d49c88d7677ba737e9d2759a87db0402d5ab2607] can fix this problem.
> >>> Although I don't
> >>> understand the root cause. Anything I can do to help?
> >>>
> >> This is indeed very, very weird. You say switching from MSI-X to MSI 
> >> fixes
> >> the issue, but also pinging the machine from outside brings back the 
> >> network.
> >> Both actions affect totally different corners.
> >>
> >> The commit and related issue you mention was a workaround in the 
> >> driver,
> >> the root cause was a MSI-X-related  issue with certain Intel chipsets 
> >> deep
> >> in the PCI core. After this was fixed we removed the workaround again.
> >> This shouldn't be related to your issue.
> >>
> >> Hard to say for now is whether the issue is:
> >> - a driver issue
> >> - a hardware issue in the RTL8411
> >> - an issue with the chipset on your mainboard
> >>
> >> According to your description it doesn't take a special scenario to 
> >> trigger
> >> the issue, so most likely also other users of Acer notebooks with 
> >> RTL8411
> >> should be affected (after briefly checking this should be at least 
> >> Aspire
> >> F15, V15, V7). Therefore I wonder why there aren't more reports.
> >>
> >> This commit added MSI-X support: 6c6aa15fdea5 ("r8169: improve 
> >> interrupt handling")
> >> So you could test this revision and the one before.
> >>
> >> Eventually, if the issue really should be caused by a side effect of 
> >> using
> >> MSI-X, then the question is whether we need to disable MSI-X for 
> >> RTL8411
> >> in general or just for RTL8411 and a certain subsystem id.
> >>
> >
> > I tried the kernel with the head on 6c6aa15fdea5 ("r8169: improve
> > interrupt handling"),
> > the problem still there. Then I revert to the previous revision, the
> > problem goes away.
> > So I think it's pretty much the side effect of MSI-X. However, as you
> > mentioned that
> > you didn't hit this problem, I'll ask the vendor to verify if this
> > problem also happens 

[PATCH net-next 2/4] bridge: simplify ip_mc_check_igmp() and ipv6_mc_check_mld() internals

2018-12-21 Thread Linus Lüssing
With this patch the internal use of the skb_trimmed is reduced to
the ICMPv6/IGMP checksum verification. And for the length checks
the newly introduced helper functions are used instead of calculating
and checking with skb->len directly.

These changes should hopefully make it easier to verify that length
checks are performed properly.

Signed-off-by: Linus Lüssing 
---
 net/ipv4/igmp.c| 51 ++---
 net/ipv6/mcast_snoop.c | 62 --
 2 files changed, 52 insertions(+), 61 deletions(-)

diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index b1f6d93282d7..a40e48ded10d 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -1493,22 +1493,22 @@ static int ip_mc_check_igmp_reportv3(struct sk_buff 
*skb)
 
len += sizeof(struct igmpv3_report);
 
-   return pskb_may_pull(skb, len) ? 0 : -EINVAL;
+   return ip_mc_may_pull(skb, len) ? 0 : -EINVAL;
 }
 
 static int ip_mc_check_igmp_query(struct sk_buff *skb)
 {
-   unsigned int len = skb_transport_offset(skb);
-
-   len += sizeof(struct igmphdr);
-   if (skb->len < len)
-   return -EINVAL;
+   unsigned int transport_len = ip_transport_len(skb);
+   unsigned int len;
 
/* IGMPv{1,2}? */
-   if (skb->len != len) {
+   if (transport_len != sizeof(struct igmphdr)) {
/* or IGMPv3? */
-   len += sizeof(struct igmpv3_query) - sizeof(struct igmphdr);
-   if (skb->len < len || !pskb_may_pull(skb, len))
+   if (transport_len < sizeof(struct igmpv3_query))
+   return -EINVAL;
+
+   len = skb_transport_offset(skb) + sizeof(struct igmpv3_query);
+   if (!ip_mc_may_pull(skb, len))
return -EINVAL;
}
 
@@ -1544,35 +1544,24 @@ static inline __sum16 ip_mc_validate_checksum(struct 
sk_buff *skb)
return skb_checksum_simple_validate(skb);
 }
 
-static int __ip_mc_check_igmp(struct sk_buff *skb)
-
+static int ip_mc_check_igmp_csum(struct sk_buff *skb)
 {
-   struct sk_buff *skb_chk;
-   unsigned int transport_len;
unsigned int len = skb_transport_offset(skb) + sizeof(struct igmphdr);
-   int ret = -EINVAL;
+   unsigned int transport_len = ip_transport_len(skb);
+   struct sk_buff *skb_chk;
 
-   transport_len = ntohs(ip_hdr(skb)->tot_len) - ip_hdrlen(skb);
+   if (!ip_mc_may_pull(skb, len))
+   return -EINVAL;
 
skb_chk = skb_checksum_trimmed(skb, transport_len,
   ip_mc_validate_checksum);
if (!skb_chk)
-   goto err;
+   return -EINVAL;
 
-   if (!pskb_may_pull(skb_chk, len))
-   goto err;
-
-   ret = ip_mc_check_igmp_msg(skb_chk);
-   if (ret)
-   goto err;
-
-   ret = 0;
-
-err:
-   if (skb_chk && skb_chk != skb)
+   if (skb_chk != skb)
kfree_skb(skb_chk);
 
-   return ret;
+   return 0;
 }
 
 /**
@@ -1600,7 +1589,11 @@ int ip_mc_check_igmp(struct sk_buff *skb)
if (ip_hdr(skb)->protocol != IPPROTO_IGMP)
return -ENOMSG;
 
-   return __ip_mc_check_igmp(skb);
+   ret = ip_mc_check_igmp_csum(skb);
+   if (ret < 0)
+   return ret;
+
+   return ip_mc_check_igmp_msg(skb);
 }
 EXPORT_SYMBOL(ip_mc_check_igmp);
 
diff --git a/net/ipv6/mcast_snoop.c b/net/ipv6/mcast_snoop.c
index 1a917dc80d5e..a72ddfc40eb3 100644
--- a/net/ipv6/mcast_snoop.c
+++ b/net/ipv6/mcast_snoop.c
@@ -77,27 +77,27 @@ static int ipv6_mc_check_mld_reportv2(struct sk_buff *skb)
 
len += sizeof(struct mld2_report);
 
-   return pskb_may_pull(skb, len) ? 0 : -EINVAL;
+   return ipv6_mc_may_pull(skb, len) ? 0 : -EINVAL;
 }
 
 static int ipv6_mc_check_mld_query(struct sk_buff *skb)
 {
+   unsigned int transport_len = ipv6_transport_len(skb);
struct mld_msg *mld;
-   unsigned int len = skb_transport_offset(skb);
+   unsigned int len;
 
/* RFC2710+RFC3810 (MLDv1+MLDv2) require link-local source addresses */
if (!(ipv6_addr_type(_hdr(skb)->saddr) & IPV6_ADDR_LINKLOCAL))
return -EINVAL;
 
-   len += sizeof(struct mld_msg);
-   if (skb->len < len)
-   return -EINVAL;
-
/* MLDv1? */
-   if (skb->len != len) {
+   if (transport_len != sizeof(struct mld_msg)) {
/* or MLDv2? */
-   len += sizeof(struct mld2_query) - sizeof(struct mld_msg);
-   if (skb->len < len || !pskb_may_pull(skb, len))
+   if (transport_len < sizeof(struct mld2_query))
+   return -EINVAL;
+
+   len = skb_transport_offset(skb) + sizeof(struct mld2_query);
+   if (!ipv6_mc_may_pull(skb, len))
return -EINVAL;
}
 
@@ -115,7 +115,13 @@ static int ipv6_mc_check_mld_query(struct sk_buff *skb)
 
 static int 

[PATCH net-next 1/4] bridge: simplify ip_mc_check_igmp() and ipv6_mc_check_mld() calls

2018-12-21 Thread Linus Lüssing
This patch refactors ip_mc_check_igmp(), ipv6_mc_check_mld() and
their callers (more precisely, the Linux bridge) to not rely on
the skb_trimmed parameter anymore.

An skb with its tail trimmed to the IP packet length was initially
introduced for the following three reasons:

1) To be able to verify the ICMPv6 checksum.
2) To be able to distinguish the version of an IGMP or MLD query.
   They are distinguishable only by their size.
3) To avoid parsing data for an IGMPv3 or MLDv2 report that is
   beyond the IP packet but still within the skb.

The first case still uses a cloned and potentially trimmed skb to
verfiy. However, there is no need to propagate it to the caller.
For the second and third case explicit IP packet length checks were
added.

This hopefully makes ip_mc_check_igmp() and ipv6_mc_check_mld() easier
to read and verfiy, as well as easier to use.

Signed-off-by: Linus Lüssing 
---
 include/linux/igmp.h   | 11 -
 include/linux/ip.h |  5 
 include/linux/ipv6.h   |  6 +
 include/net/addrconf.h | 12 +-
 net/batman-adv/multicast.c |  4 ++--
 net/bridge/br_multicast.c  | 57 +++---
 net/ipv4/igmp.c| 23 ---
 net/ipv6/mcast_snoop.c | 24 ---
 8 files changed, 70 insertions(+), 72 deletions(-)

diff --git a/include/linux/igmp.h b/include/linux/igmp.h
index 119f53941c12..8b4348f69bc5 100644
--- a/include/linux/igmp.h
+++ b/include/linux/igmp.h
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -106,6 +107,14 @@ struct ip_mc_list {
 #define IGMPV3_QQIC(value) IGMPV3_EXP(0x80, 4, 3, value)
 #define IGMPV3_MRC(value) IGMPV3_EXP(0x80, 4, 3, value)
 
+static inline int ip_mc_may_pull(struct sk_buff *skb, unsigned int len)
+{
+   if (skb_transport_offset(skb) + ip_transport_len(skb) < len)
+   return -EINVAL;
+
+   return pskb_may_pull(skb, len);
+}
+
 extern int ip_check_mc_rcu(struct in_device *dev, __be32 mc_addr, __be32 
src_addr, u8 proto);
 extern int igmp_rcv(struct sk_buff *);
 extern int ip_mc_join_group(struct sock *sk, struct ip_mreqn *imr);
@@ -130,6 +139,6 @@ extern void ip_mc_unmap(struct in_device *);
 extern void ip_mc_remap(struct in_device *);
 extern void ip_mc_dec_group(struct in_device *in_dev, __be32 addr);
 extern void ip_mc_inc_group(struct in_device *in_dev, __be32 addr);
-int ip_mc_check_igmp(struct sk_buff *skb, struct sk_buff **skb_trimmed);
+int ip_mc_check_igmp(struct sk_buff *skb);
 
 #endif
diff --git a/include/linux/ip.h b/include/linux/ip.h
index 492bc6513533..482b7b7c9f30 100644
--- a/include/linux/ip.h
+++ b/include/linux/ip.h
@@ -34,4 +34,9 @@ static inline struct iphdr *ipip_hdr(const struct sk_buff 
*skb)
 {
return (struct iphdr *)skb_transport_header(skb);
 }
+
+static inline unsigned int ip_transport_len(const struct sk_buff *skb)
+{
+   return ntohs(ip_hdr(skb)->tot_len) - skb_network_header_len(skb);
+}
 #endif /* _LINUX_IP_H */
diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
index 495e834c1367..6d45ce784bea 100644
--- a/include/linux/ipv6.h
+++ b/include/linux/ipv6.h
@@ -104,6 +104,12 @@ static inline struct ipv6hdr *ipipv6_hdr(const struct 
sk_buff *skb)
return (struct ipv6hdr *)skb_transport_header(skb);
 }
 
+static inline unsigned int ipv6_transport_len(const struct sk_buff *skb)
+{
+   return ntohs(ipv6_hdr(skb)->payload_len) + sizeof(struct ipv6hdr) -
+  skb_network_header_len(skb);
+}
+
 /* 
This structure contains results of exthdrs parsing
as offsets from skb->nh.
diff --git a/include/net/addrconf.h b/include/net/addrconf.h
index 1656c5978498..daf11dcb0f70 100644
--- a/include/net/addrconf.h
+++ b/include/net/addrconf.h
@@ -49,6 +49,7 @@ struct prefix_info {
struct in6_addr prefix;
 };
 
+#include 
 #include 
 #include 
 #include 
@@ -201,6 +202,15 @@ u32 ipv6_addr_label(struct net *net, const struct in6_addr 
*addr,
 /*
  * multicast prototypes (mcast.c)
  */
+static inline int ipv6_mc_may_pull(struct sk_buff *skb,
+  unsigned int len)
+{
+   if (skb_transport_offset(skb) + ipv6_transport_len(skb) < len)
+   return -EINVAL;
+
+   return pskb_may_pull(skb, len);
+}
+
 int ipv6_sock_mc_join(struct sock *sk, int ifindex,
  const struct in6_addr *addr);
 int ipv6_sock_mc_drop(struct sock *sk, int ifindex,
@@ -219,7 +229,7 @@ void ipv6_mc_unmap(struct inet6_dev *idev);
 void ipv6_mc_remap(struct inet6_dev *idev);
 void ipv6_mc_init_dev(struct inet6_dev *idev);
 void ipv6_mc_destroy_dev(struct inet6_dev *idev);
-int ipv6_mc_check_mld(struct sk_buff *skb, struct sk_buff **skb_trimmed);
+int ipv6_mc_check_mld(struct sk_buff *skb);
 void addrconf_dad_failure(struct sk_buff *skb, struct inet6_ifaddr *ifp);
 
 bool ipv6_chk_mcast_addr(struct net_device *dev, const struct in6_addr *group,
diff --git a/net/batman-adv/multicast.c 

[PATCH net-next 0/4] bridge: implement Multicast Router Discovery (RFC4286)

2018-12-21 Thread Linus Lüssing
Hi,

This patchset adds initial Multicast Router Discovery support to
the Linux bridge (RFC4286). With MRD it is possible to detect multicast
routers and mark bridge ports and forward multicast packets to such routers
accordingly.

So far, multicast routers are detected via IGMP/MLD queries and PIM
messages in the Linux bridge. As there is only one active, selected
querier at a time RFC4541 ("Considerations for Internet Group Management
Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches") section 2.1.1.a) recommends snooping Multicast Router
Advertisements as provided by MRD (RFC4286).


The first two patches are refactoring some existing code which is reused
for parsing the Multicast Router Advertisements later in the fourth
patch. The third patch lets the bridge join the all-snoopers multicast
address to be able to reliably receive the Multicast Router
Advertisements.


What is not implemented yet from RFC4286 yet:

* Sending Multicast Router Solicitations:
  -> RFC4286: "[...] may be sent when [...] an interface is
 (re-)initialized [or] MRD is enabled"
* Snooping Multicast Router Terminations:
  -> currently this only relies on our own timeouts
* Adjusting timeouts with the values provided in the announcements


Regards, Linus





[PATCH net-next 4/4] bridge: Snoop Multicast Router Advertisements

2018-12-21 Thread Linus Lüssing
When multiple multicast routers are present in a broadcast domain then
only one of them will be detectable via IGMP/MLD query snooping. The
multicast router with the lowest IP address will become the selected and
active querier while all other multicast routers will then refrain from
sending queries.

To detect such rather silent multicast routers, too, RFC4286
("Multicast Router Discovery") provides a standardized protocol to
detect multicast routers for multicast snooping switches.

This patch implements the necessary MRD Advertisement message parsing
and after successful processing adds such routers to the internal
multicast router list.

Signed-off-by: Linus Lüssing 
---
 include/linux/in.h  |  5 +
 include/net/addrconf.h  | 15 +
 include/uapi/linux/icmpv6.h |  2 ++
 include/uapi/linux/igmp.h   |  1 +
 net/bridge/br_multicast.c   | 55 +
 net/ipv6/mcast_snoop.c  |  5 -
 6 files changed, 82 insertions(+), 1 deletion(-)

diff --git a/include/linux/in.h b/include/linux/in.h
index 31b493734763..435e7f2a513a 100644
--- a/include/linux/in.h
+++ b/include/linux/in.h
@@ -60,6 +60,11 @@ static inline bool ipv4_is_lbcast(__be32 addr)
return addr == htonl(INADDR_BROADCAST);
 }
 
+static inline bool ipv4_is_all_snoopers(__be32 addr)
+{
+   return addr == htonl(INADDR_ALLSNOOPERS_GROUP);
+}
+
 static inline bool ipv4_is_zeronet(__be32 addr)
 {
return (addr & htonl(0xff00)) == htonl(0x);
diff --git a/include/net/addrconf.h b/include/net/addrconf.h
index daf11dcb0f70..20d523ee2fec 100644
--- a/include/net/addrconf.h
+++ b/include/net/addrconf.h
@@ -229,6 +229,7 @@ void ipv6_mc_unmap(struct inet6_dev *idev);
 void ipv6_mc_remap(struct inet6_dev *idev);
 void ipv6_mc_init_dev(struct inet6_dev *idev);
 void ipv6_mc_destroy_dev(struct inet6_dev *idev);
+int ipv6_mc_check_icmpv6(struct sk_buff *skb);
 int ipv6_mc_check_mld(struct sk_buff *skb);
 void addrconf_dad_failure(struct sk_buff *skb, struct inet6_ifaddr *ifp);
 
@@ -499,6 +500,20 @@ static inline bool ipv6_addr_is_solict_mult(const struct 
in6_addr *addr)
 #endif
 }
 
+static inline bool ipv6_addr_is_all_snoopers(const struct in6_addr *addr)
+{
+#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) && BITS_PER_LONG == 64
+   __be64 *p = (__be64 *)addr;
+
+   return ((p[0] ^ cpu_to_be64(0xff02UL)) |
+   (p[1] ^ cpu_to_be64(0x6a))) == 0UL;
+#else
+   return ((addr->s6_addr32[0] ^ htonl(0xff02)) |
+   addr->s6_addr32[1] | addr->s6_addr32[2] |
+   (addr->s6_addr32[3] ^ htonl(0x006a))) == 0;
+#endif
+}
+
 #ifdef CONFIG_PROC_FS
 int if6_proc_init(void);
 void if6_proc_exit(void);
diff --git a/include/uapi/linux/icmpv6.h b/include/uapi/linux/icmpv6.h
index caf8dc019250..325395f56bfa 100644
--- a/include/uapi/linux/icmpv6.h
+++ b/include/uapi/linux/icmpv6.h
@@ -108,6 +108,8 @@ struct icmp6hdr {
 #define ICMPV6_MOBILE_PREFIX_SOL   146
 #define ICMPV6_MOBILE_PREFIX_ADV   147
 
+#define ICMPV6_MRDISC_ADV  151
+
 /*
  * Codes for Destination Unreachable
  */
diff --git a/include/uapi/linux/igmp.h b/include/uapi/linux/igmp.h
index 7e44ac02ca18..90c28bc466c6 100644
--- a/include/uapi/linux/igmp.h
+++ b/include/uapi/linux/igmp.h
@@ -93,6 +93,7 @@ struct igmpv3_query {
 #define IGMP_MTRACE_RESP   0x1e
 #define IGMP_MTRACE0x1f
 
+#define IGMP_MRDISC_ADV0x30/* From RFC4286 */
 
 /*
  * Use the BSD names for these for compatibility
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 2366f4a2780e..2c46c7aca571 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -29,10 +30,12 @@
 #include 
 #include 
 #if IS_ENABLED(CONFIG_IPV6)
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #endif
 
 #include "br_private.h"
@@ -1583,6 +1586,19 @@ static void br_multicast_pim(struct net_bridge *br,
br_multicast_mark_router(br, port);
 }
 
+static int br_ip4_multicast_mrd_rcv(struct net_bridge *br,
+   struct net_bridge_port *port,
+   struct sk_buff *skb)
+{
+   if (ip_hdr(skb)->protocol != IPPROTO_IGMP ||
+   igmp_hdr(skb)->type != IGMP_MRDISC_ADV)
+   return -ENOMSG;
+
+   br_multicast_mark_router(br, port);
+
+   return 0;
+}
+
 static int br_multicast_ipv4_rcv(struct net_bridge *br,
 struct net_bridge_port *port,
 struct sk_buff *skb,
@@ -1600,7 +1616,15 @@ static int br_multicast_ipv4_rcv(struct net_bridge *br,
} else if (pim_ipv4_all_pim_routers(ip_hdr(skb)->daddr)) {
if (ip_hdr(skb)->protocol == IPPROTO_PIM)
br_multicast_pim(br, port, skb);
+  

[PATCH net-next 3/4] bridge: join all-snoopers multicast address

2018-12-21 Thread Linus Lüssing
Next to snooping IGMP/MLD queries RFC4541, section 2.1.1.a) recommends
to snoop multicast router advertisements to detect multicast routers.

Multicast router advertisements are sent to an "all-snoopers"
multicast address. To be able to receive them reliably, we need to
join this group.

Otherwise other snooping switches might refrain from forwarding these
advertisements to us.

Signed-off-by: Linus Lüssing 
---
 include/uapi/linux/in.h   |  9 +++---
 net/bridge/br_multicast.c | 72 ++-
 net/ipv6/mcast.c  |  2 ++
 3 files changed, 78 insertions(+), 5 deletions(-)

diff --git a/include/uapi/linux/in.h b/include/uapi/linux/in.h
index f6052e70bf40..7ab685cacb8f 100644
--- a/include/uapi/linux/in.h
+++ b/include/uapi/linux/in.h
@@ -292,10 +292,11 @@ struct sockaddr_in {
 #defineIN_LOOPBACK(a)  long int) (a)) & 0xff00) == 
0x7f00)
 
 /* Defines for Multicast INADDR */
-#define INADDR_UNSPEC_GROUP0xe000U /* 224.0.0.0   */
-#define INADDR_ALLHOSTS_GROUP  0xe001U /* 224.0.0.1   */
-#define INADDR_ALLRTRS_GROUP0xe002U/* 224.0.0.2 */
-#define INADDR_MAX_LOCAL_GROUP  0xe0ffU/* 224.0.0.255 */
+#define INADDR_UNSPEC_GROUP0xe000U /* 224.0.0.0   */
+#define INADDR_ALLHOSTS_GROUP  0xe001U /* 224.0.0.1   */
+#define INADDR_ALLRTRS_GROUP   0xe002U /* 224.0.0.2 */
+#define INADDR_ALLSNOOPERS_GROUP   0xe06aU /* 224.0.0.106 */
+#define INADDR_MAX_LOCAL_GROUP 0xe0ffU /* 224.0.0.255 */
 #endif
 
 /*  contains the htonl type stuff.. */
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 156c4905639e..2366f4a2780e 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1780,6 +1780,68 @@ void br_multicast_init(struct net_bridge *br)
INIT_HLIST_HEAD(>mdb_list);
 }
 
+static void br_ip4_multicast_join_snoopers(struct net_bridge *br)
+{
+   struct in_device *in_dev = in_dev_get(br->dev);
+
+   if (!in_dev)
+   return;
+
+   ip_mc_inc_group(in_dev, htonl(INADDR_ALLSNOOPERS_GROUP));
+   in_dev_put(in_dev);
+}
+
+#if IS_ENABLED(CONFIG_IPV6)
+static void br_ip6_multicast_join_snoopers(struct net_bridge *br)
+{
+   struct in6_addr addr;
+
+   ipv6_addr_set(, htonl(0xff02), 0, 0, htonl(0x6a));
+   ipv6_dev_mc_inc(br->dev, );
+}
+#else
+static inline void br_ip6_multicast_join_snoopers(struct net_bridge *br)
+{
+}
+#endif
+
+static void br_multicast_join_snoopers(struct net_bridge *br)
+{
+   br_ip4_multicast_join_snoopers(br);
+   br_ip6_multicast_join_snoopers(br);
+}
+
+static void br_ip4_multicast_leave_snoopers(struct net_bridge *br)
+{
+   struct in_device *in_dev = in_dev_get(br->dev);
+
+   if (WARN_ON(!in_dev))
+   return;
+
+   ip_mc_dec_group(in_dev, htonl(INADDR_ALLSNOOPERS_GROUP));
+   in_dev_put(in_dev);
+}
+
+#if IS_ENABLED(CONFIG_IPV6)
+static void br_ip6_multicast_leave_snoopers(struct net_bridge *br)
+{
+   struct in6_addr addr;
+
+   ipv6_addr_set(, htonl(0xff02), 0, 0, htonl(0x6a));
+   ipv6_dev_mc_dec(br->dev, );
+}
+#else
+static inline void br_ip6_multicast_leave_snoopers(struct net_bridge *br)
+{
+}
+#endif
+
+static void br_multicast_leave_snoopers(struct net_bridge *br)
+{
+   br_ip4_multicast_leave_snoopers(br);
+   br_ip6_multicast_leave_snoopers(br);
+}
+
 static void __br_multicast_open(struct net_bridge *br,
struct bridge_mcast_own_query *query)
 {
@@ -1793,6 +1855,9 @@ static void __br_multicast_open(struct net_bridge *br,
 
 void br_multicast_open(struct net_bridge *br)
 {
+   if (br_opt_get(br, BROPT_MULTICAST_ENABLED))
+   br_multicast_join_snoopers(br);
+
__br_multicast_open(br, >ip4_own_query);
 #if IS_ENABLED(CONFIG_IPV6)
__br_multicast_open(br, >ip6_own_query);
@@ -1808,6 +1873,9 @@ void br_multicast_stop(struct net_bridge *br)
del_timer_sync(>ip6_other_query.timer);
del_timer_sync(>ip6_own_query.timer);
 #endif
+
+   if (br_opt_get(br, BROPT_MULTICAST_ENABLED))
+   br_multicast_leave_snoopers(br);
 }
 
 void br_multicast_dev_del(struct net_bridge *br)
@@ -1943,8 +2011,10 @@ int br_multicast_toggle(struct net_bridge *br, unsigned 
long val)
 
br_mc_disabled_update(br->dev, val);
br_opt_toggle(br, BROPT_MULTICAST_ENABLED, !!val);
-   if (!br_opt_get(br, BROPT_MULTICAST_ENABLED))
+   if (!br_opt_get(br, BROPT_MULTICAST_ENABLED)) {
+   br_multicast_leave_snoopers(br);
goto unlock;
+   }
 
if (!netif_running(br->dev))
goto unlock;
diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index 21f6deb2aec9..42f3f5cd349f 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -940,6 +940,7 @@ int ipv6_dev_mc_inc(struct net_device *dev, const struct 
in6_addr *addr)
 {
return 

Re: [PATCH v2 2/2] arm64: uaccess: Implement unsafe accessors

2018-12-21 Thread James Morse
Hi Julien,

On 03/12/2018 13:55, Julien Thierry wrote:
> Current implementation of get/put_user_unsafe default to get/put_user
> which toggle PAN before each access, despite having been told by the caller
> that multiple accesses to user memory were about to happen.
> 
> Provide implementations for user_access_begin/end to turn PAN off/on and
> implement unsafe accessors that assume PAN was already turned off.

> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> index 842fb95..4e6477b 100644
> --- a/arch/arm64/include/asm/sysreg.h
> +++ b/arch/arm64/include/asm/sysreg.h
> @@ -108,6 +108,8 @@
>  #define SYS_DC_CSW   sys_insn(1, 0, 7, 10, 2)
>  #define SYS_DC_CISW  sys_insn(1, 0, 7, 14, 2)
>  
> +#define SYS_PSTATE_PAN   sys_reg(3, 0, 4, 2, 3)

Nit: Could we keep this list in encoding order please.
(it makes conflicts easier to resolve in the future)

>  #define SYS_OSDTRRX_EL1  sys_reg(2, 0, 0, 0, 2)
>  #define SYS_MDCCINT_EL1  sys_reg(2, 0, 0, 2, 0)
>  #define SYS_MDSCR_EL1sys_reg(2, 0, 0, 2, 2)
> diff --git a/arch/arm64/include/asm/uaccess.h 
> b/arch/arm64/include/asm/uaccess.h
> index 07c3408..cabfcae 100644
> --- a/arch/arm64/include/asm/uaccess.h
> +++ b/arch/arm64/include/asm/uaccess.h
> @@ -233,6 +233,23 @@ static inline void uaccess_enable_not_uao(void)
>   __uaccess_enable(ARM64_ALT_PAN_NOT_UAO);
>  }
>  
> +#define unsafe_user_region_activeuaccess_region_active
> +static inline bool uaccess_region_active(void)
> +{
> + if (system_uses_ttbr0_pan()) {
> + u64 ttbr;
> +
> + ttbr = read_sysreg(ttbr1_el1);
> + return ttbr & TTBR_ASID_MASK;
> + } else if (cpus_have_const_cap(ARM64_ALT_PAN_NOT_UAO)) {
> + return (read_sysreg(sctlr_el1) & SCTLR_EL1_SPAN) ?
> + false :
> + !read_sysreg_s(SYS_PSTATE_PAN);
> + }
> +
> + return false;
> +}

(Reading the SCTLR bit is a bit of a heavy-hammer, as suggested elsewhere on the
thread, can we use alternatives_applied here?)

It may be worth splitting this into three patches, so the 'unsafe' bits can be
merged without the debug option.


Either way, for the unsafe parts:
Reviewed-by: James Morse 


Thanks!

James


Re: [PATCH 1/1] x86/gart/kcore: Exclude GART aperture from kcore

2018-12-21 Thread Jiri Bohac
On Fri, Dec 21, 2018 at 09:38:12AM +0800, Kairui Song wrote:
> On machines where the GART aperture is mapped over physical RAM,
> /proc/kcore contains the GART aperture range and reading it may lead
> to kernel panic.
> 
> In 'commit 2a3e83c6f96c ("x86/gart: Exclude GART aperture from vmcore")',
> a special workaround is applied for vmcore to let /proc/vmcore return
> zeroes when attempting to read the aperture region, as vmcore and kcore
> have the same issue, and after 'commit 707d4eefbdb3 ("Revert "[PATCH]
> Insert GART region into resource map"")', userspace tools can't detect and
> exclude GART region.
> 
> This patch applies the same workaround for kcore. Let /proc/kcore return
> zeroes too when trying to read the aperture region to fix the issue that
> reading GART region may raise unexpected exceptions.
> 
> This applies to both first and second kernels as GART may get
> initialized in the first and second kernels.
> 
> To get the same workaround work for kcore, this patch implement a hook
> infrastructure for kcore which is same as the hook infrastructure for
> vmcore introduced in 'commit 997c136f518c ("fs/proc/vmcore.c: add hook
> to read_from_oldmem() to check for non-ram pages")'', and reuses the
> checking function gart_oldmem_pfn_is_ram introduced in
> 'commit 2a3e83c6f96c ("x86/gart: Exclude GART aperture from vmcore"),'
> as the hook function, but rename to gart_mem_pfn_is_ram as now it's
> for a more generic use.
> 
> Suggested-by: Baoquan He 
> Signed-off-by: Kairui Song 

Reviewed-by: Jiri Bohac 

> ---
>  arch/x86/kernel/aperture_64.c |  6 --
>  fs/proc/kcore.c   | 34 ++
>  include/linux/kcore.h |  3 +++
>  3 files changed, 41 insertions(+), 2 deletions(-)

-- 
Jiri Bohac 
SUSE Labs, Prague, Czechia



Re: [PATCH v2 2/2] arm64: uaccess: Implement unsafe accessors

2018-12-21 Thread James Morse
Hi guys,

On 10/12/2018 14:59, Catalin Marinas wrote:
> On Fri, Dec 07, 2018 at 08:38:11AM +, Julien Thierry wrote:
>> On 12/06/2018 06:25 PM, Catalin Marinas wrote:
>>> On Mon, Dec 03, 2018 at 01:55:18PM +, Julien Thierry wrote:
 diff --git a/arch/arm64/include/asm/uaccess.h 
 b/arch/arm64/include/asm/uaccess.h
 index 07c3408..cabfcae 100644
 --- a/arch/arm64/include/asm/uaccess.h
 +++ b/arch/arm64/include/asm/uaccess.h
 @@ -233,6 +233,23 @@ static inline void uaccess_enable_not_uao(void)
 +#define unsafe_user_region_active uaccess_region_active
 +static inline bool uaccess_region_active(void)
 +{
 +  if (system_uses_ttbr0_pan()) {

 +  } else if (cpus_have_const_cap(ARM64_ALT_PAN_NOT_UAO)) {
 +  return (read_sysreg(sctlr_el1) & SCTLR_EL1_SPAN) ?
 +  false :
 +  !read_sysreg_s(SYS_PSTATE_PAN);
 +  }
>>>
>>> ARM64_ALT_PAN_NOT_UAO implies ARM64_HAS_PAN which implies SCTLR_EL1.SPAN
>>> is 0 at run-time. Is this to cope with the case of being called prior to
>>> cpu_enable_pan()?
>>>
>>
>> Yes, the issue I can into is that for cpufeatures, .cpu_enable() callbacks
>> are called inside stop_machine() which obviously might_sleep and so attempts
>> to check whether user_access is on. But for features that get enabled before
>> PAN, the PAN bit will be set.
> 
> OK, so the PSTATE.PAN bit only makes sense when SCTLR_EL1.SPAN is 0, IOW
> the PAN hardware feature has been enabled. Maybe you could write it
> (together with some comment):
> 
>   } else if (cpus_have_const_cap(ARM64_ALT_PAN_NOT_UAO) &&
>!(read_sysreg(sctlr_el1) & SCTLR_EL1_SPAN)) {
>/* only if PAN is present and enabled */
>   return !read_sysreg_s(SYS_PSTATE_PAN)
>   }
> 
> On the cpufeature.c side of things, it seems that we enable the
> static_branch before calling the cpu_enable. I wonder whether changing
> the order here would help with avoid the SCTLR_EL1 read (not sure what
> else it would break; cc'ing Suzuki).

Avoiding the system-register read would be good. Can we check
alternatives_applied? It gets set later, and is obviously connected to the PAN
alternatives being patched in to the uaccess routines.


Thanks,

James


Re: [PATCH v2 1/4] mfd: exynos-lpass: Enable UART module support

2018-12-21 Thread Lee Jones
On Fri, 21 Dec 2018, Marek Szyprowski wrote:

> From: Beomho Seo 
> 
> This patch enables proper interrupts routing between UART module
> in Exynos Audio SubSystem and the rest of the SoC. This routing is
> completely transparent for UART device and CPU/GIC. UART driver requests
> interrupts from the respective controller and enables/masks/handles it
> by itself via standard methods.
> 
> There are boards (for example TM2), which use UART module in Exynos Audio
> SubStem for communication with BlueTooth chip.
> 
> Signed-off-by: Beomho Seo 
> [mszyprow: rephrased commit message, added UART reset]
> Signed-off-by: Marek Szyprowski 
> Reviewed-by: Sylwester Nawrocki 
> ---
> Changelog
> v2:
> - rephrased and extended commit message
> ---
>  drivers/mfd/exynos-lpass.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

Applied, thanks.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


[PATCH] blkcg: add rcu lock to bio_clone_blkg_association()

2018-12-21 Thread Dennis Zhou
I cleaned up blkg_tryget_closest() to require rcu_read_lock() earlier.
However, this was a subtle case too which clearly was too subtle for me.
The idea was the src bio should be holding a ref to the blkg so rcu
wasn't technically needed. If it doesn't hold a ref, it should be %NULL
and the blkg->parent pointers are unused.

This adds the appropriate read lock in bio_clone_blkg_association().

Fixes: 80fd3c272c1a ("blkcg: clean up blkg_tryget_closest()")
Reported-by: syzbot+a36a3ba92bea3b315...@syzkaller.appspotmail.com
Signed-off-by: Dennis Zhou 
---
 block/bio.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/block/bio.c b/block/bio.c
index c288b9057042..9194d8ad3d5e 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -2096,8 +2096,12 @@ EXPORT_SYMBOL_GPL(bio_associate_blkg);
  */
 void bio_clone_blkg_association(struct bio *dst, struct bio *src)
 {
+   rcu_read_lock();
+
if (src->bi_blkg)
__bio_associate_blkg(dst, src->bi_blkg);
+
+   rcu_read_unlock();
 }
 EXPORT_SYMBOL_GPL(bio_clone_blkg_association);
 #endif /* CONFIG_BLK_CGROUP */
-- 
2.17.1



Re: [PATCH] mfd: mc13xxx: fix a missing check of a register-read failure

2018-12-21 Thread Lee Jones
On Thu, 20 Dec 2018, Kangjie Lu wrote:

> When mc13xxx_reg_read() fails, "old_adc0" is uninitialized and will
> contain random value. Further execution uses "old_adc0" even when
> mc13xxx_reg_read() fails.
> The fix checks the return value of mc13xxx_reg_read(), and exits
> the execution when it fails.
> 
> Signed-off-by: Kangjie Lu 
> ---
>  drivers/mfd/mc13xxx-core.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

Applied, thanks.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


Re: [PATCH 01/10] i2c: add suspended flag and accessors for i2c adapters

2018-12-21 Thread Wolfram Sang

> > > I think this might be as simple as adding:
> > > 
> > >   if (WARN_ON(adap->dev.parent->power.is_suspended))
> > >   return -ESHUTDOWN;

Peter, I think this should work for muxes, too, or? The i2c_transfer()
call to the mux will not be rejected, but it will be later when we reach
the root adapter. And then the error code will be pushed down the tree
until we arrive at the mux again. So, the rejection will not happen at
the earliest time, but it will happen. Is my understanding correct?

> > I have seen this flag but decided against it. One reason is because it
> > is marked as "PM core only".
> 
> Right and we definitely should not be touching it, but reading it should
> be fine.

Seems like it. So far, no rejection from the other PM people :)

> No you are right, there is a race here, but I don't think we are likely to
> hit that race. Normally there won't be any ongoing i2c-transfers during
> a system suspend and more over, the goal of adding this check is to help
> find problems, so even if the check sometimes does not trigger because
> of the race that is not really a big deal.

You are right that the impact of a missed detection is not fatal. That
helps. The low likeliness was not an argument for me, though, because
detecting rare things is very important IMO. Because, well, they are
rare and especially hard to debug.

> I think we need to get really unlucky to have both a suspend ordering
> problem in the first case (already a somewhat rare thing) combined with
> hitting this race in such a way *each time* that we don't trigger the
> WARN_ON.

And here you convinced me: even if we miss a detection once, I agree it
is super super unlikely to hit the race every time.

> To me this seems a case of perfect being the enemy of good. When we
> first started discussing this you wanted to not have to modify the
> adapter/bus drivers for the check, using adap->dev.parent->power.is_suspended
> gives us that and it will also work for complex cases like
> the i2c-designware case, so I believe the benefits outway the downsides.

I'll try it.



signature.asc
Description: PGP signature


Re: [PATCH 3/3] sched/fair: fix unnecessary increase of balance interval

2018-12-21 Thread Vincent Guittot
On Thu, 20 Dec 2018 at 18:24, Valentin Schneider
 wrote:
>
> On 20/12/2018 14:50, Vincent Guittot wrote:
> [...]
> >> So now  we reset the interval for all active balances (expect last active
> >> balance case), even when it is done as a last resort because all other
> >> tasks were pinned.
> >>
> >> Arguably the current code isn't much better (always increase the interval
> >> when active balancing), but at least it covers this case. It would be a
> >> waste not to take this into account when we can detect this scenario
> >
> > So i'd like to remind the $subject of this patchset: fix some known
> > issues for asym_packing.
> > While looking at this, we have added few other voluntary active
> > balances because it was "obvious" that this active migration were
> > voluntary one. But in fact, we don't have any UC which show a problem
> > for those additional UC so far.
> >
> > The default behavior for active migration is to increase the interval
> > Now you want to extend the exception to others active migration UC
> > whereas it's not clear that we don't fall in the default active
> > migration UC and we should not increase the interval.
>
> Well if we stick to the rule of only increasing balance_interval when
> pinned tasks get in the way, it's clear to me that this use case shouldn't
> be segregated from the others.
>
> I do agree however that it's not entirely clear if that balance_interval
> increase was also intended to slow down the nr_balance_failed migrations.
>
> I had a look at the history and stumbled on:
>
> 8102679447da ("[PATCH] sched: improve load balancing pinned tasks")
>
> Which explains the reasoning behind the active_balance balance_interval
> increase:
>
> """
> this one attempts to work out whether the balancing failure has
> been due to too many tasks pinned on the runqueue.  This allows it
> to be basically invisible to the regular blancing paths (ie. when
> there are no pinned tasks).
> """
>
> So AFAICT that is indeed the rule we should be following, and I would only
> increase the balance_interval when there are pinned tasks, not because
> of active_balance categories. So here it's a matter of fixing that
> condition into what it was meant to be doing.

After looking at shed.c at this sha1,  (sd->nr_balance_failed >
sd->cache_nice_tries+2) was the only condition for doing active
migration and as a result it was the only reason for doubling
sd->balance_interval.
My patch keeps exactly the same behavior for this condition
'sd->nr_balance_failed > sd->cache_nice_tries+2). And, I'm even more
convinced to exclude (sd->nr_balance_failed > sd->cache_nice_tries+2)
condition because it's the condition that has introduced the doubling
of the interval.

As said previously, you can argue that this behavior is not optimal
and discuss its validity, but the sha1 that you mentioned above,
introduced the current policy for (sd->nr_balance_failed >
sd->cache_nice_tries+2) condition.
Reverting such behavior would need more studies, tests and cares which
are out of the scope of this patchset and more related to a whole
refactoring of load_balance and calculte_imbalance; FYI, I have
submitted a topic on the subject for the next OSPM

>
> > What you want is changing the behavior of the scheduler for UC that
> > haven't raised any problem where asym_packing has known problem/
> >
> > Changing default behavior for active migration is not subject of this
> > patchset and should be treated in another one like the one discussed
> > with peter few days ago
> > >> (I'll reiterate my LBF_ALL_PINNED suggestion).
> >>
> >>>   /* We were unbalanced, so reset the balancing interval */
> >>>   sd->balance_interval = sd->min_interval;
> >>>   } else {
> >>>


Re: [PATCH v6 07/27] elf-em.h: add EM_CSKY

2018-12-21 Thread Guo Ren
On Fri, Dec 21, 2018 at 05:35:52AM +0300, Dmitry V. Levin wrote:
> Hi,
> 
> On Fri, Dec 14, 2018 at 12:43:08PM +0800, Guo Ren wrote:
> > Reviewed-by: Guo Ren 
> 
> Given that the whole series is going to be pinged for quite some
> time yet, would you mind taking this patch into the csky tree?
Ok

Best Regards
 Guo Ren
> 
> Thanks.
> 
> > On Thu, Dec 13, 2018 at 08:22:00PM +0300, Dmitry V. Levin wrote:
> > > The uapi/linux/audit.h header is going to use EM_CSKY in order
> > > to define AUDIT_ARCH_CSKY which is needed to implement
> > > syscall_get_arch() which in turn is required to extend
> > > the generic ptrace API with PTRACE_GET_SYSCALL_INFO request.
> > > 
> > > The value for EM_CSKY has been taken from arch/csky/include/asm/elf.h
> > > and confirmed by binutils:include/elf/common.h
> > > 
> > > Cc: Guo Ren 
> > > Cc: Oleg Nesterov 
> > > Cc: Andy Lutomirski 
> > > Cc: Elvira Khabirova 
> > > Cc: Eugene Syromyatnikov 
> > > Signed-off-by: Dmitry V. Levin 
> > > ---
> > > 
> > > Notes:
> > > v6: unchanged
> > > 
> > >  include/uapi/linux/elf-em.h | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/include/uapi/linux/elf-em.h b/include/uapi/linux/elf-em.h
> > > index 42b7546352a6..ee0b26ab92b0 100644
> > > --- a/include/uapi/linux/elf-em.h
> > > +++ b/include/uapi/linux/elf-em.h
> > > @@ -45,6 +45,7 @@
> > >  #define EM_ARCV2 195 /* ARCv2 Cores */
> > >  #define EM_RISCV 243 /* RISC-V */
> > >  #define EM_BPF   247 /* Linux BPF - in-kernel virtual 
> > > machine */
> > > +#define EM_CSKY  252 /* C-SKY processor family */
> > >  #define EM_FRV   0x5441  /* Fujitsu FR-V */
> > >  
> > >  /*
> > > -- 
> > > ldv
> 
> -- 
> ldv




Re: [PATCH] mm: Refactor readahead defines in mm.h

2018-12-21 Thread Matthew Wilcox
On Fri, Dec 21, 2018 at 04:40:53PM +0200, Nikolay Borisov wrote:
> All users of VM_MAX_READAHEAD actually convert it to kbytes and then to
> pages. Define the macro explicitly as (SZ_128K / PAGE_SIZE). This
> simplifies the expression in every filesystem. Also rename the macro to
> VM_READAHEAD_PAGES to properly convey its meaning. Finally remove unused
> VM_MIN_READAHEAD
> 
> Signed-off-by: Nikolay Borisov 

Reviewed-by: Matthew Wilcox 


Re: [PATCH v6 08/27] csky: define syscall_get_arch()

2018-12-21 Thread Guo Ren
On Fri, Dec 21, 2018 at 05:36:41AM +0300, Dmitry V. Levin wrote:
> Hi,
> 
> On Fri, Dec 14, 2018 at 12:44:12PM +0800, Guo Ren wrote:
> > Thx Dmitry,
> > 
> > Reviewed-by: Guo Ren 
> 
> Given that the whole series is going to be pinged for quite some
> time yet, would you mind taking this patch into the csky tree?
OK.

Best Regards
 Guo Ren

>  
> Thanks.
> 
> > On Thu, Dec 13, 2018 at 08:22:07PM +0300, Dmitry V. Levin wrote:
> > > syscall_get_arch() is required to be implemented on all architectures
> > > in order to extend the generic ptrace API with PTRACE_GET_SYSCALL_INFO
> > > request.
> > > 
> > > Cc: Guo Ren 
> > > Cc: Paul Moore 
> > > Cc: Eric Paris 
> > > Cc: Oleg Nesterov 
> > > Cc: Andy Lutomirski 
> > > Cc: Elvira Khabirova 
> > > Cc: Eugene Syromyatnikov 
> > > Cc: linux-au...@redhat.com
> > > Signed-off-by: Dmitry V. Levin 
> > > ---
> > > 
> > > Notes:
> > > v6: unchanged
> > > 
> > >  arch/csky/include/asm/syscall.h | 7 +++
> > >  include/uapi/linux/audit.h  | 1 +
> > >  2 files changed, 8 insertions(+)
> > > 
> > > diff --git a/arch/csky/include/asm/syscall.h 
> > > b/arch/csky/include/asm/syscall.h
> > > index 926a64a8b4ee..d637445737b7 100644
> > > --- a/arch/csky/include/asm/syscall.h
> > > +++ b/arch/csky/include/asm/syscall.h
> > > @@ -6,6 +6,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  
> > >  static inline int
> > >  syscall_get_nr(struct task_struct *task, struct pt_regs *regs)
> > > @@ -68,4 +69,10 @@ syscall_set_arguments(struct task_struct *task, struct 
> > > pt_regs *regs,
> > >   memcpy(>a1 + i * sizeof(regs->a1), args, n * sizeof(regs->a0));
> > >  }
> > >  
> > > +static inline int
> > > +syscall_get_arch(void)
> > > +{
> > > + return AUDIT_ARCH_CSKY;
> > > +}
> > > +
> > >  #endif   /* __ASM_SYSCALL_H */
> > > diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
> > > index 72aeea0a740d..55904a40d768 100644
> > > --- a/include/uapi/linux/audit.h
> > > +++ b/include/uapi/linux/audit.h
> > > @@ -384,6 +384,7 @@ enum {
> > >  #define AUDIT_ARCH_C6X   (EM_TI_C6000|__AUDIT_ARCH_LE)
> > >  #define AUDIT_ARCH_C6XBE (EM_TI_C6000)
> > >  #define AUDIT_ARCH_CRIS  (EM_CRIS|__AUDIT_ARCH_LE)
> > > +#define AUDIT_ARCH_CSKY  (EM_CSKY|__AUDIT_ARCH_LE)
> > >  #define AUDIT_ARCH_FRV   (EM_FRV)
> > >  #define AUDIT_ARCH_I386  (EM_386|__AUDIT_ARCH_LE)
> > >  #define AUDIT_ARCH_IA64  
> > > (EM_IA_64|__AUDIT_ARCH_64BIT|__AUDIT_ARCH_LE)
> > > -- 
> > > ldv
> 
> -- 
> ldv




Hello My Beloved One

2018-12-21 Thread Aisha Gaddafi
Assalamu alaikum,
I came across your e-mail contact prior a private search while in need 
of a 
trusted person. My name is Mrs. Aisha Gaddafi, a single Mother and a 
Widow 
with three Children. I am the only biological Daughter of late Libyan 
President (Late Colonel Muammar Gaddafi)I have a business Proposal for 
you 
worth $5.8Million dollars and I need mutual respect, trust, honesty, 
transparency, adequate support and assistance, Hope to hear from you 
for 
more details.
Warmest regards
Mrs Aisha Gaddafi


Re: [PATCH v9 07/12] dt-bindings: mfd: Add a document for PECI client MFD

2018-12-21 Thread Lee Jones
On Tue, 18 Dec 2018, Jae Hyun Yoo wrote:

> This commit adds a dt-bindings document for PECI client MFD.
> 
> Cc: Lee Jones 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: Andrew Jeffery 
> Cc: James Feist 
> Cc: Jason M Biils 
> Cc: Joel Stanley 
> Cc: Vernon Mauery 
> Signed-off-by: Jae Hyun Yoo 
> Reviewed-by: Rob Herring 
> ---
>  .../bindings/mfd/intel-peci-client.txt| 34 +++
>  1 file changed, 34 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/mfd/intel-peci-client.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/intel-peci-client.txt 
> b/Documentation/devicetree/bindings/mfd/intel-peci-client.txt
> new file mode 100644
> index ..5d1d5d0a552f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/intel-peci-client.txt
> @@ -0,0 +1,34 @@
> +* Intel PECI client bindings
> +
> +PECI (Platform Environment Control Interface) is a one-wire bus interface 
> that
> +provides a communication channel from PECI clients in Intel processors and
> +chipset components to external monitoring or control devices. PECI is 
> designed
> +to support the following sideband functions:
> +
> +- Processor and DRAM thermal management
> +- Platform Manageability
> +- Processor Interface Tuning and Diagnostics
> +- Failure Analysis
> +
> +Required properties:
> +- compatible : Should be "intel,peci-client".
> +- reg: Should contain address of a client CPU. According to the PECI
> +specification, client addresses start from 0x30.
> +
> +Example:
> + peci-bus@0 {
> + compatible = "vendor,soc-peci";
> + reg = <0x0 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + peci-client@30 {
> + compatible = "intel,peci-client";
> + reg = <0x30>;
> + };
> +
> + peci-client@31 {
> + compatible = "intel,peci-client";
> + reg = <0x31>;
> + };

The PECI Client driver (masquerading as an MFD driver in this set)
doesn't actually do anything special.  Instead of detailing it here,
register the child devices directly instead.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


Re: [PATCH v9 08/12] mfd: intel-peci-client: Add PECI client MFD driver

2018-12-21 Thread Lee Jones
On Tue, 18 Dec 2018, Jae Hyun Yoo wrote:

> This commit adds PECI client MFD driver.
> 
> Cc: Lee Jones 
> Cc: Randy Dunlap 
> Cc: Rob Herring 
> Cc: Andrew Jeffery 
> Cc: James Feist 
> Cc: Jason M Biils 
> Cc: Joel Stanley 
> Cc: Vernon Mauery 
> Signed-off-by: Jae Hyun Yoo 
> ---
>  drivers/mfd/Kconfig   |  14 +++
>  drivers/mfd/Makefile  |   1 +
>  drivers/mfd/intel-peci-client.c   | 150 ++
>  include/linux/mfd/intel-peci-client.h | 110 +++
>  4 files changed, 275 insertions(+)
>  create mode 100644 drivers/mfd/intel-peci-client.c
>  create mode 100644 include/linux/mfd/intel-peci-client.h
> 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 8c5dfdce4326..d021aa8dfa99 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -604,6 +604,20 @@ config MFD_INTEL_MSIC
> Passage) chip. This chip embeds audio, battery, GPIO, etc.
> devices used in Intel Medfield platforms.
>  
> +config MFD_INTEL_PECI_CLIENT
> + bool "Intel PECI client"
> + depends on (PECI || COMPILE_TEST)
> + select MFD_CORE
> + help
> +   If you say yes to this option, support will be included for the
> +   Intel PECI (Platform Environment Control Interface) client. PECI is a
> +   one-wire bus interface that provides a communication channel from PECI
> +   clients in Intel processors and chipset components to external
> +   monitoring or control devices.

This driver doesn't appear to actually do anything that can't be done
in a header file i.e. match some static data with a CPU ID.  The child
devices can be registered by whatever registers this device.

It seems superfluous.  Why do you need it?

> +   Additional drivers must be enabled in order to use the functionality
> +   of the device.
> +
>  config MFD_IPAQ_MICRO
>   bool "Atmel Micro ASIC (iPAQ h3100/h3600/h3700) Support"
>   depends on SA1100_H3100 || SA1100_H3600
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 12980a4ad460..b8c1da8e748b 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -204,6 +204,7 @@ obj-$(CONFIG_MFD_INTEL_LPSS)  += intel-lpss.o
>  obj-$(CONFIG_MFD_INTEL_LPSS_PCI) += intel-lpss-pci.o
>  obj-$(CONFIG_MFD_INTEL_LPSS_ACPI)+= intel-lpss-acpi.o
>  obj-$(CONFIG_MFD_INTEL_MSIC) += intel_msic.o
> +obj-$(CONFIG_MFD_INTEL_PECI_CLIENT)  += intel-peci-client.o
>  obj-$(CONFIG_MFD_PALMAS) += palmas.o
>  obj-$(CONFIG_MFD_VIPERBOARD)+= viperboard.o
>  obj-$(CONFIG_MFD_RC5T583)+= rc5t583.o rc5t583-irq.o
> diff --git a/drivers/mfd/intel-peci-client.c b/drivers/mfd/intel-peci-client.c
> new file mode 100644
> index ..d53e4f1078ac
> --- /dev/null
> +++ b/drivers/mfd/intel-peci-client.c
> @@ -0,0 +1,150 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (c) 2018 Intel Corporation
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Alphabetical.

> +#define CPU_ID_MODEL_MASK  GENMASK(7, 4)
> +#define CPU_ID_FAMILY_MASK GENMASK(11, 8)
> +#define CPU_ID_EXT_MODEL_MASK  GENMASK(19, 16)
> +#define CPU_ID_EXT_FAMILY_MASK GENMASK(27, 20)
> +
> +#define LOWER_NIBBLE_MASK  GENMASK(3, 0)
> +#define UPPER_NIBBLE_MASK  GENMASK(7, 4)
> +#define LOWER_BYTE_MASKGENMASK(7, 0)
> +#define UPPER_BYTE_MASKGENMASK(16, 8)
> +
> +enum cpu_gens {
> + CPU_GEN_HSX = 0, /* Haswell Xeon */
> + CPU_GEN_BRX, /* Broadwell Xeon */
> + CPU_GEN_SKX, /* Skylake Xeon */
> +};

This is unused.

> +static struct mfd_cell peci_functions[] = {
> + { .name = "peci-cputemp", },
> + { .name = "peci-dimmtemp", },
> + /* TODO: Add additional PECI sideband functions into here */
> +};
> +
> +static const struct cpu_gen_info cpu_gen_info_table[] = {
> + [CPU_GEN_HSX] = {
> + .family= 6, /* Family code */
> + .model = INTEL_FAM6_HASWELL_X,
> + .core_max  = CORE_MAX_ON_HSX,
> + .chan_rank_max = CHAN_RANK_MAX_ON_HSX,
> + .dimm_idx_max  = DIMM_IDX_MAX_ON_HSX },
> + [CPU_GEN_BRX] = {
> + .family= 6, /* Family code */
> + .model = INTEL_FAM6_BROADWELL_X,
> + .core_max  = CORE_MAX_ON_BDX,
> + .chan_rank_max = CHAN_RANK_MAX_ON_BDX,
> + .dimm_idx_max  = DIMM_IDX_MAX_ON_BDX },
> + [CPU_GEN_SKX] = {
> + .family= 6, /* Family code */
> + .model = INTEL_FAM6_SKYLAKE_X,
> + .core_max  = CORE_MAX_ON_SKX,
> + .chan_rank_max = CHAN_RANK_MAX_ON_SKX,
> + .dimm_idx_max  = DIMM_IDX_MAX_ON_SKX },
> +};
> +
> +static int peci_client_get_cpu_gen_info(struct peci_client_manager *priv)
> +{
> + u32 cpu_id;
> + u16 family;
> + u8 model;
> + int rc;

ret is almost ubiquitous in the kernel.  Please use it instead.

> + int i;
> +
> + rc = 

Re: [PATCH v6 4/7] mtd: spi-nor: add octal read flag for flash mt35xu512aba

2018-12-21 Thread Tudor.Ambarus


On 12/19/2018 12:12 PM, Yogesh Narayan Gaur wrote:
> Add octal read flag for flash mt35xu512aba.
> This flash, mt35xu512aba, is only complaint to SFDP JESD216B and does
> not seem to support newer JESD216C standard that provides auto
> detection of Octal mode capabilities and opcodes. Therefore, this
> capability is manually added using new SPI_NOR_OCTAL_READ flag.
> 
> Signed-off-by: Vignesh R 
> Signed-off-by: Yogesh Narayan Gaur 

Reviewed-by: Tudor Ambarus 

> ---
> Changes for v6:
> - Correct S-o-b tag with full author name as 'Yogesh Narayan Gaur'.
> Changes for v5:
> - Modified string 'octo' with 'octal'.
> Changes for v4:
> - None
> Changes for v3:
> - Modified string 'octal' with 'octo'.
> Changes for v2:
> - Incorporated review comments of Boris and Vignesh
> 
>  drivers/mtd/spi-nor/spi-nor.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index 872d707..53a3bcc 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -1877,7 +1877,8 @@ static const struct flash_info spi_nor_ids[] = {
>   /* Micron */
>   {
>   "mt35xu512aba", INFO(0x2c5b1a, 0, 128 * 1024, 512,
> - SECT_4K | USE_FSR | SPI_NOR_4B_OPCODES)
> + SECT_4K | USE_FSR | SPI_NOR_OCTAL_READ |
> + SPI_NOR_4B_OPCODES)
>   },
>  
>   /* PMC */
> 


Re: [PATCH v5] Input: i8042 add i8042_is_mr_coffee() helper to avoid refconut leak

2018-12-21 Thread Frank Lee
On Fri, Dec 21, 2018 at 4:42 PM Dmitry Torokhov
 wrote:
>
> On Sat, Dec 15, 2018 at 04:08:46AM -0500, Yangtao Li wrote:
> > of_find_node_by_path() acquires a reference to the node returned by
> > it and that reference needs to be dropped by its caller. Add
> > i8042_is_mr_coffee() helper to avoid refconut leak.
> >
> > Signed-off-by: Yangtao Li 
> > ---
> > changes in v5:
> > -fix typo
>
> Has this at least been actually compiled by you?
Sure!!!
On ubuntu 18 machine.

MBR,
Yangtao


Re: [PATCH v6 3/7] mtd: spi-nor: add opcodes for octal Read/Write commands

2018-12-21 Thread Tudor.Ambarus


On 12/19/2018 12:12 PM, Yogesh Narayan Gaur wrote:
> - Add opcodes for octal I/O commands
>   * Read  : 1-1-8 and 1-8-8 protocol
>   * Write : 1-1-8 and 1-8-8 protocol

I verified that the above opcodes are compliant with the MT35X Public datasheet.

>   * opcodes for 4-byte address mode command

opcodes compliant with jesd216c.

> 
> - Entry of macros in _convert_3to4_xxx function
> 
> - Add flag specifying flash support octal read commands.

It would be nicer to explain the need of this flag, similar to what you did in
patch's 4/7 commit message.

> 
> Signed-off-by: Vignesh R 
> Signed-off-by: Yogesh Narayan Gaur 

Looks good:

Reviewed-by: Tudor Ambarus 

> ---
> Changes for v6:
> - Correct S-o-b tag with full author name as 'Yogesh Narayan Gaur'.
> Changes for v5:
> - Modified string 'octo' with 'octal'.
> Changes for v4:
> - None
> Changes for v3:
> - Modified string 'octal' with 'octo'.
> Changes for v2:
> - Incorporated review comments of Boris and Vignesh
> 
>  drivers/mtd/spi-nor/spi-nor.c | 16 ++--
>  include/linux/mtd/spi-nor.h   | 16 
>  2 files changed, 26 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index 6e13bbd..872d707 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -68,7 +68,7 @@ enum spi_nor_read_command_index {
>   SNOR_CMD_READ_4_4_4,
>   SNOR_CMD_READ_1_4_4_DTR,
>  
> - /* Octo SPI */
> + /* Octal SPI */
>   SNOR_CMD_READ_1_1_8,
>   SNOR_CMD_READ_1_8_8,
>   SNOR_CMD_READ_8_8_8,
> @@ -85,7 +85,7 @@ enum spi_nor_pp_command_index {
>   SNOR_CMD_PP_1_4_4,
>   SNOR_CMD_PP_4_4_4,
>  
> - /* Octo SPI */
> + /* Octal SPI */
>   SNOR_CMD_PP_1_1_8,
>   SNOR_CMD_PP_1_8_8,
>   SNOR_CMD_PP_8_8_8,
> @@ -278,6 +278,7 @@ struct flash_info {
>  #define NO_CHIP_ERASEBIT(12) /* Chip does not support chip 
> erase */
>  #define SPI_NOR_SKIP_SFDPBIT(13) /* Skip parsing of SFDP tables */
>  #define USE_CLSR BIT(14) /* use CLSR command */
> +#define SPI_NOR_OCTAL_READ   BIT(15) /* Flash supports Octal Read */
>  
>   /* Part specific fixup hooks. */
>   const struct spi_nor_fixups *fixups;
> @@ -398,6 +399,8 @@ static u8 spi_nor_convert_3to4_read(u8 opcode)
>   { SPINOR_OP_READ_1_2_2, SPINOR_OP_READ_1_2_2_4B },
>   { SPINOR_OP_READ_1_1_4, SPINOR_OP_READ_1_1_4_4B },
>   { SPINOR_OP_READ_1_4_4, SPINOR_OP_READ_1_4_4_4B },
> + { SPINOR_OP_READ_1_1_8, SPINOR_OP_READ_1_1_8_4B },
> + { SPINOR_OP_READ_1_8_8, SPINOR_OP_READ_1_8_8_4B },
>  
>   { SPINOR_OP_READ_1_1_1_DTR, SPINOR_OP_READ_1_1_1_DTR_4B },
>   { SPINOR_OP_READ_1_2_2_DTR, SPINOR_OP_READ_1_2_2_DTR_4B },
> @@ -414,6 +417,8 @@ static u8 spi_nor_convert_3to4_program(u8 opcode)
>   { SPINOR_OP_PP, SPINOR_OP_PP_4B },
>   { SPINOR_OP_PP_1_1_4,   SPINOR_OP_PP_1_1_4_4B },
>   { SPINOR_OP_PP_1_4_4,   SPINOR_OP_PP_1_4_4_4B },
> + { SPINOR_OP_PP_1_1_8,   SPINOR_OP_PP_1_1_8_4B },
> + { SPINOR_OP_PP_1_8_8,   SPINOR_OP_PP_1_8_8_4B },
>   };
>  
>   return spi_nor_convert_opcode(opcode, spi_nor_3to4_program,
> @@ -3591,6 +3596,13 @@ static int spi_nor_init_params(struct spi_nor *nor,
> SNOR_PROTO_1_1_4);
>   }
>  
> + if (info->flags & SPI_NOR_OCTAL_READ) {
> + params->hwcaps.mask |= SNOR_HWCAPS_READ_1_1_8;
> + spi_nor_set_read_settings(>reads[SNOR_CMD_READ_1_1_8],
> +   0, 8, SPINOR_OP_READ_1_1_8,
> +   SNOR_PROTO_1_1_8);
> + }
> +
>   /* Page Program settings. */
>   params->hwcaps.mask |= SNOR_HWCAPS_PP;
>   spi_nor_set_pp_settings(>page_programs[SNOR_CMD_PP],
> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> index fa2d89e..2353af8 100644
> --- a/include/linux/mtd/spi-nor.h
> +++ b/include/linux/mtd/spi-nor.h
> @@ -46,9 +46,13 @@
>  #define SPINOR_OP_READ_1_2_2 0xbb/* Read data bytes (Dual I/O SPI) */
>  #define SPINOR_OP_READ_1_1_4 0x6b/* Read data bytes (Quad Output SPI) */
>  #define SPINOR_OP_READ_1_4_4 0xeb/* Read data bytes (Quad I/O SPI) */
> +#define SPINOR_OP_READ_1_1_8 0x8b/* Read data bytes (Octal Output SPI) */
> +#define SPINOR_OP_READ_1_8_8 0xcb/* Read data bytes (Octal I/O SPI) */
>  #define SPINOR_OP_PP 0x02/* Page program (up to 256 bytes) */
>  #define SPINOR_OP_PP_1_1_4   0x32/* Quad page program */
>  #define SPINOR_OP_PP_1_4_4   0x38/* Quad page program */
> +#define SPINOR_OP_PP_1_1_8   0x82/* Octal page program */
> +#define SPINOR_OP_PP_1_8_8   0xc2/* Octal page program */
>  #define SPINOR_OP_BE_4K  0x20/* Erase 4KiB block */
>  #define SPINOR_OP_BE_4K_PMC  0xd7/* Erase 4KiB block on PMC chips */
>  

Re: 4.20-rc6: WARNING: CPU: 30 PID: 197360 at net/core/flow_dissector.c:764 __skb_flow_dissect

2018-12-21 Thread Willem de Bruijn
On Fri, Dec 21, 2018 at 1:45 AM Christian Borntraeger
 wrote:
>
>
>
> On 20.12.2018 18:23, Willem de Bruijn wrote:
> > On Thu, Dec 20, 2018 at 11:17 AM Ido Schimmel  wrote:
> >>
> >> On Thu, Dec 20, 2018 at 03:09:22PM +0100, Christian Borntraeger wrote:
> >>> On 20.12.2018 10:12, Ido Schimmel wrote:
>  +Willem
> 
>  On Thu, Dec 20, 2018 at 08:45:40AM +0100, Christian Borntraeger wrote:
> > Folks,
> >
> > I got this warning today. I cant tell when and why this happened, so I 
> > do not know yet how to reproduce.
> > Maybe someone has a quick idea.
> >
> > [85109.572032] WARNING: CPU: 30 PID: 197360 at 
> > net/core/flow_dissector.c:764 __skb_flow_dissect+0x1f0/0x1318
> 
>  I managed to trigger this warning as well the other day, but from a
>  different call path:
> >>>
> >>> FWIW, it also seems to happen on 4.20-rc1. 4.19.0 seems fine. bisect seem 
> >>> to have failed so
> >>> my reproducer is not reliable.
> >>
> >> Yes, it is caused by commit d0e13a1488ad ("flow_dissector: lookup netns
> >> by skb->sk if skb->dev is NULL")
> >>
> >> $ git tag --contains d0e13a1488ad
> >> v4.20-rc1
> >> v4.20-rc2
> >> v4.20-rc3
> >> v4.20-rc4
> >> v4.20-rc5
> >> v4.20-rc6
> >
> > That tap_get_user_xdp path is also new for 4.20-rc1:
> >
> > commit 0efac27791ee068075d80f07c55a229b1335ce12
> > tap: accept an array of XDP buffs through sendmsg()
> >
> > $ git describe --contains 0efac27791ee
> > v4.20-rc1~14^2~382^2~1
> >
> > In v4.19 and before all packets went through tap_get_user.
>
> Hmmm, so maybe my bisect wasnt broken at all? It pointed to
>
> commit 105bc1306e9b29c2aa2783b9524f7aec9b5a5b1f
> Merge: 3475372ff60e4 d0e13a1488ad3
> Author: David S. Miller 
> AuthorDate: Tue Sep 25 20:29:38 2018 -0700
> Commit: David S. Miller 
> CommitDate: Tue Sep 25 20:29:38 2018 -0700
>
> Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next

Yes, that's the right commit. The flow dissector change went in
through bpf-next.


Re: [PATCH] hwmon: lm80: fix a missing check of return value

2018-12-21 Thread Guenter Roeck

On 12/20/18 10:13 PM, Kangjie Lu wrote:

If lm80_read_value() fails, it returns a negative number instead of the
correct read data. Therefore, we should avoid using the data if it
fails.

The fix checks if lm80_read_value() fails, and if so, returns with the
error number.

Signed-off-by: Kangjie Lu 
---
  drivers/hwmon/lm80.c | 15 ++-
  1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/hwmon/lm80.c b/drivers/hwmon/lm80.c
index 08e3945a6fbf..fca6363cd77f 100644
--- a/drivers/hwmon/lm80.c
+++ b/drivers/hwmon/lm80.c
@@ -360,9 +360,11 @@ static ssize_t set_fan_div(struct device *dev, struct 
device_attribute *attr,
struct i2c_client *client = data->client;
unsigned long min, val;
u8 reg;
-   int err = kstrtoul(buf, 10, );
-   if (err < 0)
-   return err;
+   int ret;
+


In the other patch you are using 'rv'. Please use consistent variable names.

Also, please use "hwmon: (lm80) " as subject, and use different 
subjects
for both patches so we can distinguish them without looking into each patch 
itself.

This applies to the other patch as well.

Thanks,
Guenter


+   ret = kstrtoul(buf, 10, );
+   if (ret < 0)
+   return ret;
  
  	/* Save fan_min */

mutex_lock(>update_lock);
@@ -390,8 +392,11 @@ static ssize_t set_fan_div(struct device *dev, struct 
device_attribute *attr,
return -EINVAL;
}
  
-	reg = (lm80_read_value(client, LM80_REG_FANDIV) &

-  ~(3 << (2 * (nr + 1 | (data->fan_div[nr] << (2 * (nr + 1)));
+   ret = lm80_read_value(client, LM80_REG_FANDIV);
+   if (ret < 0)
+   return ret;
+   reg = (ret & ~(3 << (2 * (nr + 1
+ | (data->fan_div[nr] << (2 * (nr + 1)));
lm80_write_value(client, LM80_REG_FANDIV, reg);
  
  	/* Restore fan_min */






[PATCH] soc: fsl: qbman: avoid race in clearing QMan interrupt

2018-12-21 Thread Madalin Bucur
By clearing all interrupt sources, not only those that
already occurred, the existing code may acknowledge by
mistake interrupts that occurred after the code checks
for them.

Signed-off-by: Madalin Bucur 
Signed-off-by: Roy Pledge 
---
 drivers/soc/fsl/qbman/qman.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/soc/fsl/qbman/qman.c b/drivers/soc/fsl/qbman/qman.c
index 52c153cd795a..636f83f781f5 100644
--- a/drivers/soc/fsl/qbman/qman.c
+++ b/drivers/soc/fsl/qbman/qman.c
@@ -1143,18 +1143,19 @@ static void qm_mr_process_task(struct work_struct 
*work);
 static irqreturn_t portal_isr(int irq, void *ptr)
 {
struct qman_portal *p = ptr;
-
-   u32 clear = QM_DQAVAIL_MASK | p->irq_sources;
u32 is = qm_in(>p, QM_REG_ISR) & p->irq_sources;
+   u32 clear = 0;
 
if (unlikely(!is))
return IRQ_NONE;
 
/* DQRR-handling if it's interrupt-driven */
-   if (is & QM_PIRQ_DQRI)
+   if (is & QM_PIRQ_DQRI) {
__poll_portal_fast(p, QMAN_POLL_LIMIT);
+   clear = QM_DQAVAIL_MASK | QM_PIRQ_DQRI;
+   }
/* Handling of anything else that's interrupt-driven */
-   clear |= __poll_portal_slow(p, is);
+   clear |= __poll_portal_slow(p, is) & QM_PIRQ_SLOW;
qm_out(>p, QM_REG_ISR, clear);
return IRQ_HANDLED;
 }
-- 
2.1.0



[PATCH] mm: Refactor readahead defines in mm.h

2018-12-21 Thread Nikolay Borisov
All users of VM_MAX_READAHEAD actually convert it to kbytes and then to
pages. Define the macro explicitly as (SZ_128K / PAGE_SIZE). This
simplifies the expression in every filesystem. Also rename the macro to
VM_READAHEAD_PAGES to properly convey its meaning. Finally remove unused
VM_MIN_READAHEAD

Signed-off-by: Nikolay Borisov 
---
 block/blk-core.c   | 3 +--
 fs/9p/vfs_super.c  | 2 +-
 fs/afs/super.c | 2 +-
 fs/btrfs/disk-io.c | 2 +-
 fs/fuse/inode.c| 2 +-
 include/linux/mm.h | 4 ++--
 6 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/block/blk-core.c b/block/blk-core.c
index deb56932f8c4..d25c8564a117 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1031,8 +1031,7 @@ struct request_queue *blk_alloc_queue_node(gfp_t 
gfp_mask, int node_id,
if (!q->stats)
goto fail_stats;
 
-   q->backing_dev_info->ra_pages =
-   (VM_MAX_READAHEAD * 1024) / PAGE_SIZE;
+   q->backing_dev_info->ra_pages = VM_READAHEAD_PAGES;
q->backing_dev_info->capabilities = BDI_CAP_CGROUP_WRITEBACK;
q->backing_dev_info->name = "block";
q->node = node_id;
diff --git a/fs/9p/vfs_super.c b/fs/9p/vfs_super.c
index 48ce50484e80..10d3bd3f534b 100644
--- a/fs/9p/vfs_super.c
+++ b/fs/9p/vfs_super.c
@@ -92,7 +92,7 @@ v9fs_fill_super(struct super_block *sb, struct 
v9fs_session_info *v9ses,
return ret;
 
if (v9ses->cache)
-   sb->s_bdi->ra_pages = (VM_MAX_READAHEAD * 1024)/PAGE_SIZE;
+   sb->s_bdi->ra_pages = VM_READAHEAD_PAGES;
 
sb->s_flags |= SB_ACTIVE | SB_DIRSYNC;
if (!v9ses->cache)
diff --git a/fs/afs/super.c b/fs/afs/super.c
index dcd07fe99871..e684f6769b15 100644
--- a/fs/afs/super.c
+++ b/fs/afs/super.c
@@ -399,7 +399,7 @@ static int afs_fill_super(struct super_block *sb,
ret = super_setup_bdi(sb);
if (ret)
return ret;
-   sb->s_bdi->ra_pages = VM_MAX_READAHEAD * 1024 / PAGE_SIZE;
+   sb->s_bdi->ra_pages = VM_READAHEAD_PAGES;
 
/* allocate the root inode and dentry */
if (as->dyn_root) {
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 6d776717d8b3..ee47d8b5b50c 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -2900,7 +2900,7 @@ int open_ctree(struct super_block *sb,
sb->s_bdi->congested_fn = btrfs_congested_fn;
sb->s_bdi->congested_data = fs_info;
sb->s_bdi->capabilities |= BDI_CAP_CGROUP_WRITEBACK;
-   sb->s_bdi->ra_pages = VM_MAX_READAHEAD * SZ_1K / PAGE_SIZE;
+   sb->s_bdi->ra_pages = VM_READAHEAD_PAGES;
sb->s_bdi->ra_pages *= btrfs_super_num_devices(disk_super);
sb->s_bdi->ra_pages = max(sb->s_bdi->ra_pages, SZ_4M / PAGE_SIZE);
 
diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
index 568abed20eb2..d3eab53a29b7 100644
--- a/fs/fuse/inode.c
+++ b/fs/fuse/inode.c
@@ -1009,7 +1009,7 @@ static int fuse_bdi_init(struct fuse_conn *fc, struct 
super_block *sb)
if (err)
return err;
 
-   sb->s_bdi->ra_pages = (VM_MAX_READAHEAD * 1024) / PAGE_SIZE;
+   sb->s_bdi->ra_pages = VM_READAHEAD_PAGES;
/* fuse does it's own writeback accounting */
sb->s_bdi->capabilities = BDI_CAP_NO_ACCT_WB | BDI_CAP_STRICTLIMIT;
 
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 5411de93a363..1579082af177 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct mempolicy;
 struct anon_vma;
@@ -2396,8 +2397,7 @@ int __must_check write_one_page(struct page *page);
 void task_dirty_inc(struct task_struct *tsk);
 
 /* readahead.c */
-#define VM_MAX_READAHEAD   128 /* kbytes */
-#define VM_MIN_READAHEAD   16  /* kbytes (includes current page) */
+#define VM_READAHEAD_PAGES (SZ_128K / PAGE_SIZE)
 
 int force_page_cache_readahead(struct address_space *mapping, struct file 
*filp,
pgoff_t offset, unsigned long nr_to_read);
-- 
2.17.1



Re: [PATCH v2] mfd: tqmx86: IO controller with i2c, wachdog and gpio

2018-12-21 Thread Lee Jones
On Tue, 18 Dec 2018, Andrew Lunn wrote:

> The QMX86 is a PLD present on some TQ-Systems ComExpress modules. It
> provides 1 or 2 I2C bus masters, 8 GPIOs and a watchdog timer. Add an
> MFD which will instantiate the individual drivers.
> 
> Signed-off-by: Andrew Lunn 
> ---
> v2:
> 
> Drop setting i2c bus speed, which removes the build dependencies on
> the i2c ocores patches. This can be added back later.
> ---
>  drivers/mfd/Kconfig  |   8 +
>  drivers/mfd/Makefile |   1 +
>  drivers/mfd/tqmx86.c | 404 +++
>  3 files changed, 413 insertions(+)
>  create mode 100644 drivers/mfd/tqmx86.c
> 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 8c5dfdce4326..8c86a2a215e8 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1676,6 +1676,14 @@ config MFD_TC6393XB
>   help
> Support for Toshiba Mobile IO Controller TC6393XB
>  
> +config MFD_TQMX86
> +   tristate "TQ-Systems IO controller TQMX86"
> +   select MFD_CORE
> +   help
> +   Say yes here to enable support for various functions of the
> +   TQ-Systems IO controller and watchdog device, found on their
> +   ComExpress CPU modules

The help should be indented.

Nit: You're missing a full stop.

>  config MFD_VX855
>   tristate "VIA VX855/VX875 integrated south bridge"
>   depends on PCI
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 12980a4ad460..7f4790662988 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -36,6 +36,7 @@ obj-$(CONFIG_MFD_TC3589X)   += tc3589x.o
>  obj-$(CONFIG_MFD_T7L66XB)+= t7l66xb.o tmio_core.o
>  obj-$(CONFIG_MFD_TC6387XB)   += tc6387xb.o tmio_core.o
>  obj-$(CONFIG_MFD_TC6393XB)   += tc6393xb.o tmio_core.o
> +obj-$(CONFIG_MFD_TQMX86) += tqmx86.o
>  
>  obj-$(CONFIG_MFD_ARIZONA)+= arizona-core.o
>  obj-$(CONFIG_MFD_ARIZONA)+= arizona-irq.o
> diff --git a/drivers/mfd/tqmx86.c b/drivers/mfd/tqmx86.c
> new file mode 100644
> index ..4eca166db000
> --- /dev/null
> +++ b/drivers/mfd/tqmx86.c
> @@ -0,0 +1,404 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * TQ-Systems PLD MFD core driver
> + *
> + * Copyright (c) 2015 TQ-Systems GmbH

Copyright is out of date.

> + * 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.

You shouldn't need this now that you have the SPDX above.

> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Alphabetical.

> +#define TQMX86_IOBASE0x160
> +#define TQMX86_IOSIZE0x3f
> +#define TQMX86_CLK   33000   /* default */

Why don't you call this TQMX86_DEFAULT_CLK_RATE ?

Then drop the comment.

> +/* Registers offsets */

Register

> +#define TQMX86_BID   0x20/* Board ID */
> +#define TQMX86_BREV  0x21/* Board and PLD Revisions */
> +#define TQMX86_IOEIC 0x26/* I/O Extension Interrupt Configuration */
> +#define TQMX86_I2C_DET   0x47/* I2C controller detection register */
> +#define TQMX86_I2C_IEN   0x49/* machxo2 I2C nterrupt enable register 
> */

All them, TQMX86_REG_*, then drop the header comment.

If your #defines were named well, they should not need comments.

> +struct tqmx86_info {
> + u32 board_id;
> + u32 board_rev;
> + u32 pld_rev;
> + u32 i2c_type;
> +};

Why not just add these to ddata?

> +#define I2C_KIND_SOFT1   /* Ocores soft controller */
> +#define I2C_KIND_HARD2   /* Machxo2 hard controller */

What is a soft/hard controller?

These should be grouped with your other defines.

> +/**
> + * struct tqmx86_device_data - Internal representation of the PLD device
> + * @io_base: Pointer to the IO memory
> + * @pld_clock:   PLD clock frequency

pid_clk_rate

> + * @dev: Pointer to kernel device structure
> + */
> +struct tqmx86_device_data {

s/data/ddata/

> + void __iomem*io_base;
> + u32 pld_clock;
> + struct device   *dev;

You don't need this.

Just pass pdev as the first argument to tqmx86_detect_device().

> + struct tqmx86_info  info;
> +};
> +
> +/**
> + * struct tqmx86_platform_data - PLD hardware configuration structure
> + * @pld_clock:   PLD clock frequency
> + * @ioresource:  IO addresses of the PLD
> + */
> +struct tqmx86_platform_data {
> + u32 pld_clock;
> + struct resource *ioresource;

Too many tabs.

> +};
> +
> +static uint gpio_irq;
> +module_param(gpio_irq, uint, 0);
> +MODULE_PARM_DESC(gpio_irq, "GPIO IRQ number (7, 9, 12)");

I have never seen anything like this.

This should be set by platform data, not a module parameter.

> +static u8 

[PATCH v2 1/4] mfd: exynos-lpass: Enable UART module support

2018-12-21 Thread Marek Szyprowski
From: Beomho Seo 

This patch enables proper interrupts routing between UART module
in Exynos Audio SubSystem and the rest of the SoC. This routing is
completely transparent for UART device and CPU/GIC. UART driver requests
interrupts from the respective controller and enables/masks/handles it
by itself via standard methods.

There are boards (for example TM2), which use UART module in Exynos Audio
SubStem for communication with BlueTooth chip.

Signed-off-by: Beomho Seo 
[mszyprow: rephrased commit message, added UART reset]
Signed-off-by: Marek Szyprowski 
Reviewed-by: Sylwester Nawrocki 
---
Changelog
v2:
- rephrased and extended commit message
---
 drivers/mfd/exynos-lpass.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/exynos-lpass.c b/drivers/mfd/exynos-lpass.c
index ca829f85672f..2713de989f05 100644
--- a/drivers/mfd/exynos-lpass.c
+++ b/drivers/mfd/exynos-lpass.c
@@ -82,11 +82,13 @@ static void exynos_lpass_enable(struct exynos_lpass *lpass)
 LPASS_INTR_SFR | LPASS_INTR_DMA | LPASS_INTR_I2S);
 
regmap_write(lpass->top, SFR_LPASS_INTR_CPU_MASK,
-LPASS_INTR_SFR | LPASS_INTR_DMA | LPASS_INTR_I2S);
+LPASS_INTR_SFR | LPASS_INTR_DMA | LPASS_INTR_I2S |
+LPASS_INTR_UART);
 
exynos_lpass_core_sw_reset(lpass, LPASS_I2S_SW_RESET);
exynos_lpass_core_sw_reset(lpass, LPASS_DMA_SW_RESET);
exynos_lpass_core_sw_reset(lpass, LPASS_MEM_SW_RESET);
+   exynos_lpass_core_sw_reset(lpass, LPASS_UART_SW_RESET);
 }
 
 static void exynos_lpass_disable(struct exynos_lpass *lpass)
-- 
2.17.1



Re: [PATCH 0/2] docs/mm-api: link kernel-doc comments from slab_common.c

2018-12-21 Thread Mike Rapoport



On December 20, 2018 5:34:23 PM GMT+02:00, Jonathan Corbet  
wrote:
>On Thu, 20 Dec 2018 09:59:13 +0200
>Mike Rapoport  wrote:
>
>> ping?
>
>Sorry, been traveling,

No problem, I just wanted to make sure it didn't fall between the cracks.

> and I still don't really know what to do with
>patches that are more mm/ than Documentation/. 

Well, these seem to be quite documentation, although they touch mm files ;-)

> I've just applied these, though.

Thanks!

>Thanks,
>
>jon

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.



Re: [PATCH 0/7] ARM: hacks for link-time optimization

2018-12-21 Thread Paul E. McKenney
On Tue, Dec 18, 2018 at 11:00:14AM +0100, Peter Zijlstra wrote:
> On Tue, Dec 18, 2018 at 10:18:24AM +0100, Peter Zijlstra wrote:
> > In particular turning an address-dependency into a control-dependency,
> > which is something allowed by the C language, since it doesn't recognise
> > these concepts as such.
> > 
> > The 'optimization' is allowed currently, but LTO will make it much more
> > likely since it will have a much wider view of things. Esp. when combined
> > with PGO.
> > 
> > Specifically; if you have something like:
> > 
> > int idx;
> > struct object objs[2];
> > 
> > the statement:
> > 
> >   val = objs[idx & 1].ponies;
> > 
> > which you 'need' to be translated like:
> > 
> >   struct object *obj = objs;
> >   obj += (idx & 1);
> >   val = obj->ponies;
> > 
> > Such that the load of obj->ponies depends on the load of idx. However
> > our dear compiler is allowed to make it:
> > 
> >   if (idx & 1)
> > obj = [1];
> >   else
> > obj = [0];
> > 
> >   val = obj->ponies;
> > 
> > Because C doesn't recognise this as being different. However this is
> > utterly broken, because in this translation we can speculate the load
> > of obj->ponies such that it no longer depends on the load of idx, which
> > breaks RCU.

Hence the following in Documentation/RCU/rcu_dereference.txt:

You are only permitted to use rcu_dereference on pointer values.
The compiler simply knows too much about integral values to
trust it to carry dependencies through integer operations.

I got rid of the carrying of dependencies via non-pointers in 2014.
You are telling me that they have crept back?  Sigh!!!  :-/

Thanx, Paul

> > Note that further 'optimization' is possible and the compiler could even
> > make it:
> > 
> >   if (idx & 1)
> > val = objs[1].ponies;
> >   else
> > val = objs[0].ponies;
> 
> A variant that is actually broken on x86 too (due to issuing the loads
> in the 'wrong' order):
> 
>   val = objs[0].ponies;
>   if (idx & 1)
> val = objs[1].ponies;
> 
> Which is a translation that makes sense if we either marked
> unlikely(idx & 1) or if PGO found the same.
> 
> > Now, granted, this is a fairly artificial example, but it does
> > illustrate the exact problem.
> > 
> > The more the compiler can see of the complete program, the more likely
> > it can make inferrences like this, esp. when coupled with PGO.
> > 
> > Now, we're (usually) very careful to wrap things in READ_ONCE() and
> > rcu_dereference() and the like, which makes it harder on the compiler
> > (because 'volatile' is special), but nothing really stops it from doing
> > this.
> > 
> > Paul has been trying to beat clue into the language people, but given
> > he's been at it for 10 years now, and there's no resolution, I figure we
> > ought to get compiler implementations to give us a knob.
> 



Re: [PATCH] binderfs: implement sysctls

2018-12-21 Thread Christian Brauner
On Fri, Dec 21, 2018 at 02:55:09PM +0100, Greg KH wrote:
> On Fri, Dec 21, 2018 at 02:39:09PM +0100, Christian Brauner wrote:
> > This implements three sysctls that have very specific goals:
> 
> Ick, why?
> 
> What are these going to be used for?  Who will "control" them?  As you

Only global root in the initial user namespace. See the reasons below. :)

> are putting them in the "global" namespace, that feels like something
> that binderfs was trying to avoid in the first place.

There are a couple of reason imho:
- Global root needs a way to restrict how many binder devices can be
  allocated across all user + ipc namespace pairs.
  One obvious reason is that otherwise userns root in a non-initial user
  namespace can allocate a huge number of binder devices (pick a random
  number say 10.000) and use up a lot of kernel memory.
  In addition they can pound on the binder.c code causing a lot of
  contention for the remaining global lock in there.
  We should let global root explicitly restrict non-initial namespaces
  in this respect. Imho, that's just good security design. :)
- The reason for having a number of reserved devices is when the initial
  binderfs mount needs to bump the number of binder devices after the
  initial allocation done during say boot (e.g. it could've removed
  devices and wants to reallocate new ones but all binder minor numbers
  have been given out or just needs additional devices). By reserving an
  initial pool of binder devices this can be easily accounted for and
  future proofs userspace. This is to say: global root in the initial
  userns + ipcns gets dibs on however many devices it wants. :)
- The fact that we have a single shared pool of binder device minor
  numbers for all namespaces imho makes it necessary for the global root
  user in the initial ipc + user namespace to manage device allocation
  and delegation.

The binderfs sysctl stuff is really small code-wise and adds a lot of
security without any performance impact on the code itself. So we
actually very strictly adhere to the requirement to not blindly
sacrifice performance for security. :)

> 
> > 1. /proc/sys/fs/binder/max:
> >Allow global root to globally limit the number of allocatable binder
> >devices.
> 
> Why?  Who cares?  Memory should be your only limit here, and when you
> run into that limit, you will start failing :)
> 
> > 2. /proc/sys/fs/binder/nr:
> >Allow global root to easily detect how many binder devices are currently
> >in use across all binderfs mounts.
> 
> Why?  Again, who cares?
> 
> > 3. /proc/sys/fs/binder/reserved:
> >Ensure that global root can reserve binder devices for the initial
> >binderfs mount in the initial ipc namespace to prevent DOS attacks.
> 
> Huh?  Can't you just create your "global root" devices first?  Doesn't
> the code do that already anyway?
> 
> And what kind of DoS attack could this ever prevent from anyway?
> 
> > This is equivalent to sysctls of devpts.
> 
> devpts isn't exactly the best thing to emulate :)

It's one of its saner design choices though. :)

> 
> > 
> > Signed-off-by: Christian Brauner 
> > ---
> >  drivers/android/binderfs.c | 81 +-
> >  1 file changed, 79 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/android/binderfs.c b/drivers/android/binderfs.c
> > index 7496b10532aa..5ff015f82314 100644
> > --- a/drivers/android/binderfs.c
> > +++ b/drivers/android/binderfs.c
> > @@ -64,6 +64,71 @@ struct binderfs_info {
> >  
> >  };
> >  
> > +/* Global default limit on the number of binder devices. */
> > +static int device_limit = 4096;
> > +
> > +/*
> > + * Number of binder devices reserved for the initial binderfs mount in the
> > + * initial ipc namespace.
> > + */
> > +static int device_reserve = 1024;
> > +
> > +/* Dummy sysctl minimum. */
> > +static int device_limit_min;
> > +
> > +/* Cap sysctl at BINDERFS_MAX_MINOR. */
> > +static int device_limit_max = BINDERFS_MAX_MINOR;
> > +
> > +/* Current number of allocated binder devices. */
> > +static atomic_t device_count = ATOMIC_INIT(0);
> 
> You have a lock you are using, just rely on that, don't create
> yet-another-type-of-unneeded-lock with an atomic here.
> 
> Anyway, I really don't see the need for any of this just yet, so I
> didn't read beyond this point in the code :)
> 
> thanks,
> 
> greg k-h


Re: [PATCH] ata: pata_macio: add of_node_put()

2018-12-21 Thread Jens Axboe
On 12/20/18 6:09 PM, Frank Lee wrote:
> On Fri, Dec 21, 2018 at 2:01 AM Jens Axboe  wrote:
>>
>> On 12/20/18 10:03 AM, Bartlomiej Zolnierkiewicz wrote:
>>>
>>> On 11/21/2018 02:04 PM, Yangtao Li wrote:
 of_find_node_by_path() acquires a reference to the node
 returned by it and that reference needs to be dropped by its caller.
 bl_idle_init() doesn't do that, so fix it.

 Signed-off-by: Yangtao Li 
>>>
>>> Acked-by: Bartlomiej Zolnierkiewicz 
>>
>> Yangtao, were you going to resend this one?
> Actually,I've rensent the v2 at  Nov 22.And  I just changed the changelog.
> Can you pick it up?

I missed that, sorry. I'll pick it up.

-- 
Jens Axboe



[PATCH] drm/amd/powerplay/polaris10_smumgr: Remove duplicate

2018-12-21 Thread Brajeswar Ghosh
Remove ppatomctrl.h which is included more than once

Signed-off-by: Brajeswar Ghosh 
---
 drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c
index 872d3824337b..2b2c26616902 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c
@@ -44,7 +44,6 @@
 
 #include "smu7_hwmgr.h"
 #include "hardwaremanager.h"
-#include "ppatomctrl.h"
 #include "atombios.h"
 #include "pppcielanes.h"
 
-- 
2.17.1



Re: [PATCH] mm: Define VM_(MAX|MIN)_READAHEAD via sizes.h constants

2018-12-21 Thread Nikolay Borisov



On 21.12.18 г. 15:24 ч., Matthew Wilcox wrote:
> On Fri, Dec 21, 2018 at 02:53:14PM +0200, Nikolay Borisov wrote:
>> All users of the aformentioned macros convert them to kbytes by
>> multplying. Instead, directly define the macros via the aptly named
>> SZ_16K/SZ_128K ones. Also remove the now redundant comments explaining
>> that VM_* are defined in kbytes it's obvious. No functional changes.
> 
> Actually, all users of these constants convert them to pages!
> 
>> +q->backing_dev_info->ra_pages = VM_MAX_READAHEAD / PAGE_SIZE;
>> +sb->s_bdi->ra_pages = VM_MAX_READAHEAD / PAGE_SIZE;
>> +sb->s_bdi->ra_pages = VM_MAX_READAHEAD / PAGE_SIZE;
>> +sb->s_bdi->ra_pages = VM_MAX_READAHEAD / PAGE_SIZE;
>> +sb->s_bdi->ra_pages = VM_MAX_READAHEAD / PAGE_SIZE;
> 
>> -#define VM_MAX_READAHEAD128 /* kbytes */
>> -#define VM_MIN_READAHEAD16  /* kbytes (includes current page) */
>> +#define VM_MAX_READAHEADSZ_128K
>> +#define VM_MIN_READAHEADSZ_16K  /* includes current page */
> 
> So perhaps:
> 
> #define VM_MAX_READAHEAD  (SZ_128K / PAGE_SIZE)
> 
> VM_MIN_READAHEAD isn't used, so just delete it?

I thought about that but didn't know if people will complain that some
times in the future we might need it.

> 


Re: [PATCH V7 0/10] KVM: X86: Introducing ROE Protection Kernel Hardening

2018-12-21 Thread Ahmed Soliman
Hello,

> > I don't  understand why this path needs to be optimized. To me it seems, a 
> > straight-
> > forward userspace implementation with no additional code in the kernel 
> > achieves
> > the same feature. Can you elaborate?

I was doing some benchmarking to figure out the overhead introduced by
ROE, I think I can add more
details about the overhead I am talking about, first I will explain
the existing paths for a memory write
attempts:
[1] Normal memory write is done directly in guest kernel space.
[2] Writing into Fully ROE protected page (The write operation will fail).
[3] Writing into Partial ROE protected region (The write operation will fail).
[4] Writing into writable memory in a page that contains Partial ROE
protected region (The write operation is committed to memory).

Path [1] is the normal write... guest kernel will not have to switch
to guest and the performance was almost the same between host and
guest, Writing 1 MB (a byte at a time) took no more than 4
milliseconds. This will not be affected by whether ROE is done from
users pace or kernel space.

Path [2] will switch between guest's kernel to host kernel, then the
host kernel switches to user space to decide what should be done.  The
guest host ->host kernel -> host user space switch is done on ever
separate write attempt (which is approx 100 in this case) It took
~5000 milliseconds to fail the 1M write attempt. and as the above one
user space ROE will not affect this one that much and I am not aware
of any possible optimization, yet ideas are welcomed.

Path [3] will also switch between guest kernel to host kernel to host
users pace...However the time taken to attempt 1M write took ~5000
when the guest had less than 32 protected chunks system wide, as the
number of chunks increased, the time also increased in a linear
fashion till it reached 20 seconds took to do 1M write attempt when
the system had about separate 2048 protected chunks. For this
benchmark I allocated a page and protected every other byte :). I
think this can be optimized by replacing the linked list used to keep
track of chunks with maybe skip-list or Red Black tree. and It will be
available in the next patch set. as the previous cases user space VS
kernel space will not affect performance here at all.

Path [4] The guest kernel switches to host kernel and the write
operation is done in the host kernel (note we saved a switch from host
kernel to host user space)
The host kernel emulates the write operation and get back to guest
kernel. The writing speed was notably slow but on average twice the
speed at Path[3] (~2900 ms for less than 32 chunks and it went up to
11 seconds for 2048 chunks. Path [4] can be optimized the same way
path [3].

Note that the dominating factor here is how many switches are done, If
ROE was implemented in user-space, Path [4] which will be at least as
slow as Path [3] which is about 2x slower.

I hope it is less ambiguous now.

Thanks,

--
Ahmed.
Junior Researcher, IoT and Cyber Security lab, SmartCI, Alexandria
University, & CIS @  VMI


Re: [PATCH 1/2] mm: vmscan: skip KSM page in direct reclaim if priority is low

2018-12-21 Thread Andrea Arcangeli
Hello Yang,

On Thu, Dec 20, 2018 at 10:33:26PM -0800, Yang Shi wrote:
> 
> 
> On 12/20/18 10:04 PM, Hugh Dickins wrote:
> > On Thu, 20 Dec 2018, Andrew Morton wrote:
> >> Is anyone interested in reviewing this?  Seems somewhat serious.
> >> Thanks.
> > Somewhat serious, but no need to rush.
> >
> >> From: Yang Shi 
> >> Subject: mm: vmscan: skip KSM page in direct reclaim if priority is low
> >>
> >> When running a stress test, we occasionally run into the below hang issue:
> > Artificial load presumably.
> >
> >> INFO: task ksmd:205 blocked for more than 360 seconds.
> >>Tainted: GE 
> >> 4.9.128-001.ali3000_nightly_20180925_264.alios7.x86_64 #1
> > 4.9-stable does not contain Andrea's 4.13 commit 2c653d0ee2ae
> > ("ksm: introduce ksm_max_page_sharing per page deduplication limit").
> >
> > The patch below is more economical than Andrea's, but I don't think
> > a second workaround should be added, unless Andrea's is shown to be
> > insufficient, even with its ksm_max_page_sharing tuned down to suit.
> >
> > Yang, please try to reproduce on upstream, or backport Andrea's to
> > 4.9-stable - thanks.

I think it's reasonable to backport it and it should be an easy
backport. Just make sure to backport
b4fecc67cc569b14301f5a363d5818b8da5e too which was the only bug
there was in the initial patch and it happened with
"merge_across_nodes = 0" (not the default).

We shipped it in production years ago and it was pretty urgent for
those workloads that initially run into this issue.

> 
> I believe Andrea's commit could workaround this problem too by limiting 
> the number of sharing pages.
> 
> However, IMHO, even though we just have a few hundred pages share one 
> KSM page, it still sounds not worth reclaiming it in direct reclaim in 
> low priority. According to Andrea's commit log, it still takes a few 

You've still to walk the entire chain for compaction and memory
hotplug, otherwise the KSM page becomes practically
unmovable. Allowing the rmap chain to grow to infinitely is still not
ok.

If the page should be reclaimed or not in direct reclaim is already
told by page_referenced(), the more mappings there are the more likely
at least one was touched and has the young bit set in the pte.

> msec to walk the rmap for 256 shared pages.

Those ~2.5msec was in the context of page migration: in the previous
sentence I specified it takes 10usec for the IPI and all other stuff
page migration has to do (which also largely depends on multiple
factors like the total number of CPUs).

page_referenced() doesn't flush the TLB during the rmap walk when it
clears the accessed bit, so it's orders of magnitude faster than the
real page migration at walking the KSM rmap chain.

If the page migration latency of 256 max mappings is a concern the max
sharing can be configured at runtime or the default max sharing can be
reduced to 10 to give a max latency of ~100usec and it would still
give a fairly decent x10 compression ratio. That's a minor detail to
change if that's a concern.

The only difference compared to all other page types is KSM pages can
occasionally merge very aggressively and the apps have no way to limit
the merging or even avoid it. We simply can't ask the app to create
fewer equal pages..

This is why the max sharing has to be limited inside KSM, then we
don't need anything special in the VM anymore to threat KSM pages.

As opposed the max sharing of COW anon memory post fork is limited by
the number of fork invocations, for MAP_SHARED the sharing is limited
by the number of mmaps, those don't tend to escalate to the million or
they would run into other limits first. It's reasonable to expect the
developer to optimize the app to create fewer mmaps or to use thread
instead of processes to reduce the VM overhead in general (which will
improve the rmap walks too).

Note the MAP_SHARED/PRIVATE/anon-COW sharing can exceed 256 mappings
too, you've just to fork 257 times in a row or much more realistically
mmap the same glibc library 257 times in a row, so if something KSM is
now less of a concern for occasional page_referenced worst case
latencies, than all the rest of the page types.

KSM by enforcing the max sharing is now the most RMAP walk
computational complexity friendly of all the page types out there. So
there's no need to threat it specially at low priority reclaim scans.

Thanks,
Andrea


Re: [PATCH] mmc: sdhci-esdhc-imx: Constify driver data

2018-12-21 Thread Adrian Hunter
On 19/12/18 1:26 AM, Andrey Smirnov wrote:
> Variant specific driver data doesn't change at run-time, so mark it as
> const to reflect that.
> 
> Signed-off-by: Andrey Smirnov 

Acked-by: Adrian Hunter 

> ---
>  drivers/mmc/host/sdhci-esdhc-imx.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c 
> b/drivers/mmc/host/sdhci-esdhc-imx.c
> index f44e49014a44..39ace4f1036b 100644
> --- a/drivers/mmc/host/sdhci-esdhc-imx.c
> +++ b/drivers/mmc/host/sdhci-esdhc-imx.c
> @@ -148,38 +148,38 @@ struct esdhc_soc_data {
>   u32 flags;
>  };
>  
> -static struct esdhc_soc_data esdhc_imx25_data = {
> +static const struct esdhc_soc_data esdhc_imx25_data = {
>   .flags = ESDHC_FLAG_ERR004536,
>  };
>  
> -static struct esdhc_soc_data esdhc_imx35_data = {
> +static const struct esdhc_soc_data esdhc_imx35_data = {
>   .flags = ESDHC_FLAG_ERR004536,
>  };
>  
> -static struct esdhc_soc_data esdhc_imx51_data = {
> +static const struct esdhc_soc_data esdhc_imx51_data = {
>   .flags = 0,
>  };
>  
> -static struct esdhc_soc_data esdhc_imx53_data = {
> +static const struct esdhc_soc_data esdhc_imx53_data = {
>   .flags = ESDHC_FLAG_MULTIBLK_NO_INT,
>  };
>  
> -static struct esdhc_soc_data usdhc_imx6q_data = {
> +static const struct esdhc_soc_data usdhc_imx6q_data = {
>   .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_MAN_TUNING,
>  };
>  
> -static struct esdhc_soc_data usdhc_imx6sl_data = {
> +static const struct esdhc_soc_data usdhc_imx6sl_data = {
>   .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
>   | ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_ERR004536
>   | ESDHC_FLAG_HS200,
>  };
>  
> -static struct esdhc_soc_data usdhc_imx6sx_data = {
> +static const struct esdhc_soc_data usdhc_imx6sx_data = {
>   .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
>   | ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200,
>  };
>  
> -static struct esdhc_soc_data usdhc_imx7d_data = {
> +static const struct esdhc_soc_data usdhc_imx7d_data = {
>   .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
>   | ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200
>   | ESDHC_FLAG_HS400,
> 



linux-next: Signed-off-by missing for commit in the kvm tree

2018-12-21 Thread Stephen Rothwell
Hi all,

Commits

  8cee58161eff ("kvm: selftests: aarch64: dirty_log_test: support greater than 
40-bit IPAs")
  cdbd24284824 ("kvm: selftests: add pa-48/va-48 VM modes")
  696ade770f08 ("kvm: selftests: dirty_log_test: improve mode param management")
  fd3f6f813976 ("kvm: selftests: dirty_log_test: reset guest test phys offset")
  6498e1da84da ("kvm: selftests: dirty_log_test: always use -t")
  d4df5a15602e ("kvm: selftests: dirty_log_test: don't identity map the test 
mem")
  b442324b5815 ("kvm: selftests: x86_64: dirty_log_test: fix -t")
  bdd303cb1bdb ("KVM: fix some typos")
  649472a1694f ("x86/kvmclock: convert to SPDX identifiers")
  9b7ebff23cb8 ("KVM: x86: Remove KF() macro placeholder")
  788fc1e9ad8e ("kvm: vmx: Allow guest read access to IA32_TSC")
  9ebdfe5230f2 ("kvm: nVMX: NMI-window and interrupt-window exiting should wake 
L2 from HLT")
  e081354d6aa7 ("KVM: nSVM: Fix nested guest support for PAUSE filtering.")
  7a86dab8cf2f ("kvm: Change offset in kvm_write_guest_offset_cached to 
unsigned")
  f1b9dd5eb86c ("kvm: Disallow wraparound in kvm_gfn_to_hva_cache_init")
  ba7424b200d3 ("KVM: VMX: Remove duplicated include from vmx.c")
  b85c32dd2749 ("selftests: kvm: report failed stage when exit reason is 
unexpected")
  e87555e550ce ("KVM: x86: svm: report MSR_IA32_MCG_EXT_CTL as unsupported")

are missing a Signed-off-by from their committer.

-- 
Cheers,
Stephen Rothwell


pgpB9Kp9fp1f_.pgp
Description: OpenPGP digital signature


Re: [PATCH] binderfs: implement sysctls

2018-12-21 Thread Greg KH
On Fri, Dec 21, 2018 at 02:39:09PM +0100, Christian Brauner wrote:
> This implements three sysctls that have very specific goals:

Ick, why?

What are these going to be used for?  Who will "control" them?  As you
are putting them in the "global" namespace, that feels like something
that binderfs was trying to avoid in the first place.

> 1. /proc/sys/fs/binder/max:
>Allow global root to globally limit the number of allocatable binder
>devices.

Why?  Who cares?  Memory should be your only limit here, and when you
run into that limit, you will start failing :)

> 2. /proc/sys/fs/binder/nr:
>Allow global root to easily detect how many binder devices are currently
>in use across all binderfs mounts.

Why?  Again, who cares?

> 3. /proc/sys/fs/binder/reserved:
>Ensure that global root can reserve binder devices for the initial
>binderfs mount in the initial ipc namespace to prevent DOS attacks.

Huh?  Can't you just create your "global root" devices first?  Doesn't
the code do that already anyway?

And what kind of DoS attack could this ever prevent from anyway?

> This is equivalent to sysctls of devpts.

devpts isn't exactly the best thing to emulate :)

> 
> Signed-off-by: Christian Brauner 
> ---
>  drivers/android/binderfs.c | 81 +-
>  1 file changed, 79 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/android/binderfs.c b/drivers/android/binderfs.c
> index 7496b10532aa..5ff015f82314 100644
> --- a/drivers/android/binderfs.c
> +++ b/drivers/android/binderfs.c
> @@ -64,6 +64,71 @@ struct binderfs_info {
>  
>  };
>  
> +/* Global default limit on the number of binder devices. */
> +static int device_limit = 4096;
> +
> +/*
> + * Number of binder devices reserved for the initial binderfs mount in the
> + * initial ipc namespace.
> + */
> +static int device_reserve = 1024;
> +
> +/* Dummy sysctl minimum. */
> +static int device_limit_min;
> +
> +/* Cap sysctl at BINDERFS_MAX_MINOR. */
> +static int device_limit_max = BINDERFS_MAX_MINOR;
> +
> +/* Current number of allocated binder devices. */
> +static atomic_t device_count = ATOMIC_INIT(0);

You have a lock you are using, just rely on that, don't create
yet-another-type-of-unneeded-lock with an atomic here.

Anyway, I really don't see the need for any of this just yet, so I
didn't read beyond this point in the code :)

thanks,

greg k-h


Re: [PATCH v5 7/8] clk: lochnagar: Add support for the Cirrus Logic Lochnagar

2018-12-21 Thread Charles Keepax
On Thu, Nov 29, 2018 at 11:53:51PM -0800, Stephen Boyd wrote:
> Quoting Charles Keepax (2018-11-20 06:16:30)

Apologies for the delay on this we have been very swamped at this
end lately.

> > diff --git a/drivers/clk/clk-lochnagar.c b/drivers/clk/clk-lochnagar.c
> > new file mode 100644
> > index ..8b2a78689715
> > --- /dev/null
> > +++ b/drivers/clk/clk-lochnagar.c
> > @@ -0,0 +1,360 @@
> [...]
> > +
> > +static int lochnagar_regmap_set_parent(struct clk_hw *hw, u8 index)
> > +{
> > +   struct lochnagar_clk *lclk = lochnagar_hw_to_lclk(hw);
> > +   struct lochnagar_clk_priv *priv = lclk->priv;
> > +   struct regmap *regmap = priv->regmap;
> > +   int ret;
> > +
> > +   /*
> > +* Some clocks on Lochnagar can either generate a clock themselves
> > +* or accept an external clock, these default to generating the 
> > clock
> > +* themselves. If we set a parent however we should update the 
> > dir_mask
> > +* to indicate to the hardware that this clock will now be 
> > receiving an
> > +* external clock.
> 
> Hmm ok. So the plan is to configure parents in DT or from driver code if
> the configuration is to accept an external clk? I guess this works.
> 

Actually from further discussions on the hardware side it seems
this is handled automatically by the hardware so we no longer
need to set these direction bits. As such I will remove them in
the next spin.

> > +*/
> > +   if (lclk->dir_mask) {
> > +   ret = regmap_update_bits(regmap, lclk->cfg_reg,
> > +lclk->dir_mask, lclk->dir_mask);
> > +   if (ret < 0) {
> > +   dev_err(priv->dev, "Failed to set %s direction: 
> > %d\n",
> > +   lclk->name, ret);
> > +   return ret;
> > +   }
> > +   }
> > +
> > +   ret = regmap_update_bits(regmap, lclk->src_reg, lclk->src_mask, 
> > index);
> > +   if (ret < 0)
> > +   dev_err(priv->dev, "Failed to reparent %s: %d\n",
> > +   lclk->name, ret);
> > +
> > +   return ret;
> > +}
> > +
> > +static u8 lochnagar_regmap_get_parent(struct clk_hw *hw)
> > +{
> > +   struct lochnagar_clk *lclk = lochnagar_hw_to_lclk(hw);
> > +   struct lochnagar_clk_priv *priv = lclk->priv;
> > +   struct regmap *regmap = priv->regmap;
> > +   unsigned int val;
> > +   int ret;
> > +
> > +   ret = regmap_read(regmap, lclk->src_reg, );
> > +   if (ret < 0) {
> > +   dev_err(priv->dev, "Failed to read parent of %s: %d\n",
> > +   lclk->name, ret);
> 
> The error messages in the above functions could be spammy. Just let
> drivers who fail when using these clks ops print errors and maybe
> downgrade these to debug? If you don't agree with this it's fine, I'll
> just hope to never see these prints change to debug in the future.
> 

Seems reasonable to me I will change them to debug prints.

> > +   return priv->nparents;
> > +   }
> > +
> > +   val &= lclk->src_mask;
> > +
> > +   return val;
> > +}
> > +
> > +static const struct clk_ops lochnagar_clk_regmap_ops = {
> > +   .prepare = lochnagar_regmap_prepare,
> > +   .unprepare = lochnagar_regmap_unprepare,
> > +   .set_parent = lochnagar_regmap_set_parent,
> > +   .get_parent = lochnagar_regmap_get_parent,
> 
> Is regmap important to have in the name of these functions and struct?
> I'd prefer it was just clk instead of regmap.
> 

Again no objection happy to rename.

> > +};
> > +
> > +static int lochnagar_init_parents(struct lochnagar_clk_priv *priv)
> > +{
> > +   struct device_node *np = priv->dev->of_node;
> > +   int i, j;
> > +
> > +   switch (priv->type) {
> > +   case LOCHNAGAR1:
> > +   memcpy(priv->lclks, lochnagar1_clks, 
> > sizeof(lochnagar1_clks));
> > +
> > +   priv->nparents = ARRAY_SIZE(lochnagar1_clk_parents);
> > +   priv->parents = devm_kmemdup(priv->dev, 
> > lochnagar1_clk_parents,
> > +sizeof(lochnagar1_clk_parents),
> > +GFP_KERNEL);
> > +   break;
> > +   case LOCHNAGAR2:
> > +   memcpy(priv->lclks, lochnagar2_clks, 
> > sizeof(lochnagar2_clks));
> > +
> > +   priv->nparents = ARRAY_SIZE(lochnagar2_clk_parents);
> > +   priv->parents = devm_kmemdup(priv->dev, 
> > lochnagar2_clk_parents,
> > +sizeof(lochnagar2_clk_parents),
> > +GFP_KERNEL);
> 
> Why do we need to kmemdup it? The clk framework already deep copies
> everything from clk_init structure.
> 

The copy is needed for the updates to the list down below.

> > +   break;
> > +   default:
> > +   dev_err(priv->dev, "Unknown Lochnagar type: %d\n", 

Re: x86/sgx: uapi change proposal

2018-12-21 Thread Jarkko Sakkinen
On Thu, Dec 20, 2018 at 04:06:38PM -0600, Dr. Greg wrote:
> On Thu, Dec 20, 2018 at 12:34:00PM +0200, Jarkko Sakkinen wrote:
> 
> Good afternoon to everyone.
> 
> > On Wed, Dec 19, 2018 at 08:43:43AM -0600, Dr. Greg wrote:
> > > I believe it is a silent response to the issues we were
> > > prosecuting 4-5 weeks ago, regarding the requirement for an SGX
> > > driver on an FLC hardware platform to have some semblance of
> > > policy management to be relevant from a security/privacy
> > > perspective.  It would have certainly been collegial to include a
> > > reference to our discussions and concerns in the changelog.
> > >
> > > See 364f68f5a3c in Jarkko's next/master.
> > >
> > > The changeset addresses enclave access to the PROVISION key but is
> > > still insufficient to deliver guarantees that are consistent with
> > > the SGX security model.  In order to achieve that, policy
> > > management needs to embrace the use of MRSIGNER values, which is
> > > what our SFLC patchset uses.
> > >
> > > The noted changeset actually implements most of the 'kernel bloat'
> > > that our SFLC patchset needs to bolt onto.
> > >
> > > As of yesterday afternoon next/master still won't initialize a
> > > non-trivial enclave.  Since there now appears to be a wholesale
> > > change in the driver architecture and UAPI we are sitting on the
> > > sidelines waiting for an indication all of that has some hope of
> > > working before we introduce our approach.
> > >
> > > Part of SFLC won't be popular but it is driven by clients who are
> > > actually paying for SGX security engineering and architectures.
> 
> > How many of these people are actually posting here?
> 
> None that I know of.
> 
> The individuals I was referring to are CISO's and security risk
> managers of multi-billion dollar corporations and/or 3-letter
> entities.  It has been my own personal observation that they don't
> have time to post to the Linux Kernel Mailing List.
> 
> The time they do spend on this technology seems to involve sitting in
> meetings and making decisions on whether or not to authorize capital
> expenditure budgets for Intel processors and chipsets, based on
> whether or not an SGX security stack can definably implement the
> security controls that are being imposed on their organizations by the
> government and/or their liability carriers.
> 
> Such issues may be out of mainstream kernel concerns but hopefully not
> conceptually elusive with respect to their implications.

Well, the process is anyway what it is. I'm sending v18 and you are free
to comment the code change associated with the provision.

/Jarkko


[PATCH v5 2/8] mfd: stmpe: Move ADC related defines to header of mfd

2018-12-21 Thread Philippe Schenker
From: Philippe Schenker 

Move defines that are ADC related to the header of the overlying mfd,
so they can be used from multiple sub-devices.

Signed-off-by: Philippe Schenker 
Acked-by: Lee Jones 
Acked-by: Dmitry Torokhov 

---

Changes in v5:
 - Changed author of commit to use correct email

Changes in v4:
 - Added Lee Jone's Ack
 - Added Dmitry Torokhov's Ack

Changes in v3: None
Changes in v2:
 - This is a new added commit. Separate commit for moving the defines
   out of drivers/input/touchscreen/stmpe-ts.c to overlying mfd-device
   drivers/mfd/stmpe.c
 - Pre-fix defines with STMPE_

 drivers/input/touchscreen/stmpe-ts.c | 34 +++-
 include/linux/mfd/stmpe.h| 11 +
 2 files changed, 24 insertions(+), 21 deletions(-)

diff --git a/drivers/input/touchscreen/stmpe-ts.c 
b/drivers/input/touchscreen/stmpe-ts.c
index 2a78e27b4495..c5d9006588a2 100644
--- a/drivers/input/touchscreen/stmpe-ts.c
+++ b/drivers/input/touchscreen/stmpe-ts.c
@@ -49,17 +49,6 @@
 
 #define STMPE_IRQ_TOUCH_DET0
 
-#define SAMPLE_TIME(x) ((x & 0xf) << 4)
-#define MOD_12B(x) ((x & 0x1) << 3)
-#define REF_SEL(x) ((x & 0x1) << 1)
-#define ADC_FREQ(x)(x & 0x3)
-#define AVE_CTRL(x)((x & 0x3) << 6)
-#define DET_DELAY(x)   ((x & 0x7) << 3)
-#define SETTLING(x)(x & 0x7)
-#define FRACTION_Z(x)  (x & 0x7)
-#define I_DRIVE(x) (x & 0x1)
-#define OP_MODE(x) ((x & 0x7) << 1)
-
 #define STMPE_TS_NAME  "stmpe-ts"
 #define XY_MASK0xfff
 
@@ -213,9 +202,10 @@ static int stmpe_init_hw(struct stmpe_touch *ts)
return ret;
}
 
-   adc_ctrl1 = SAMPLE_TIME(ts->sample_time) | MOD_12B(ts->mod_12b) |
-   REF_SEL(ts->ref_sel);
-   adc_ctrl1_mask = SAMPLE_TIME(0xff) | MOD_12B(0xff) | REF_SEL(0xff);
+   adc_ctrl1 = STMPE_SAMPLE_TIME(ts->sample_time) |
+   STMPE_MOD_12B(ts->mod_12b) | STMPE_REF_SEL(ts->ref_sel);
+   adc_ctrl1_mask = STMPE_SAMPLE_TIME(0xff) | STMPE_MOD_12B(0xff) |
+STMPE_REF_SEL(0xff);
 
ret = stmpe_set_bits(stmpe, STMPE_REG_ADC_CTRL1,
adc_ctrl1_mask, adc_ctrl1);
@@ -225,15 +215,17 @@ static int stmpe_init_hw(struct stmpe_touch *ts)
}
 
ret = stmpe_set_bits(stmpe, STMPE_REG_ADC_CTRL2,
-   ADC_FREQ(0xff), ADC_FREQ(ts->adc_freq));
+   STMPE_ADC_FREQ(0xff), STMPE_ADC_FREQ(ts->adc_freq));
if (ret) {
dev_err(dev, "Could not setup ADC\n");
return ret;
}
 
-   tsc_cfg = AVE_CTRL(ts->ave_ctrl) | DET_DELAY(ts->touch_det_delay) |
-   SETTLING(ts->settling);
-   tsc_cfg_mask = AVE_CTRL(0xff) | DET_DELAY(0xff) | SETTLING(0xff);
+   tsc_cfg = STMPE_AVE_CTRL(ts->ave_ctrl) |
+ STMPE_DET_DELAY(ts->touch_det_delay) |
+ STMPE_SETTLING(ts->settling);
+   tsc_cfg_mask = STMPE_AVE_CTRL(0xff) | STMPE_DET_DELAY(0xff) |
+  STMPE_SETTLING(0xff);
 
ret = stmpe_set_bits(stmpe, STMPE_REG_TSC_CFG, tsc_cfg_mask, tsc_cfg);
if (ret) {
@@ -242,14 +234,14 @@ static int stmpe_init_hw(struct stmpe_touch *ts)
}
 
ret = stmpe_set_bits(stmpe, STMPE_REG_TSC_FRACTION_Z,
-   FRACTION_Z(0xff), FRACTION_Z(ts->fraction_z));
+   STMPE_FRACTION_Z(0xff), 
STMPE_FRACTION_Z(ts->fraction_z));
if (ret) {
dev_err(dev, "Could not config touch\n");
return ret;
}
 
ret = stmpe_set_bits(stmpe, STMPE_REG_TSC_I_DRIVE,
-   I_DRIVE(0xff), I_DRIVE(ts->i_drive));
+   STMPE_I_DRIVE(0xff), STMPE_I_DRIVE(ts->i_drive));
if (ret) {
dev_err(dev, "Could not config touch\n");
return ret;
@@ -263,7 +255,7 @@ static int stmpe_init_hw(struct stmpe_touch *ts)
}
 
ret = stmpe_set_bits(stmpe, STMPE_REG_TSC_CTRL,
-   OP_MODE(0xff), OP_MODE(OP_MOD_XYZ));
+   STMPE_OP_MODE(0xff), STMPE_OP_MODE(OP_MOD_XYZ));
if (ret) {
dev_err(dev, "Could not set mode\n");
return ret;
diff --git a/include/linux/mfd/stmpe.h b/include/linux/mfd/stmpe.h
index 4a827af17e59..c0353f6431f9 100644
--- a/include/linux/mfd/stmpe.h
+++ b/include/linux/mfd/stmpe.h
@@ -10,6 +10,17 @@
 
 #include 
 
+#define STMPE_SAMPLE_TIME(x)   ((x & 0xf) << 4)
+#define STMPE_MOD_12B(x)   ((x & 0x1) << 3)
+#define STMPE_REF_SEL(x)   ((x & 0x1) << 1)
+#define STMPE_ADC_FREQ(x)  (x & 0x3)
+#define STMPE_AVE_CTRL(x)  ((x & 0x3) << 6)
+#define STMPE_DET_DELAY(x) ((x & 0x7) << 3)
+#define STMPE_SETTLING(x)  (x & 0x7)
+#define STMPE_FRACTION_Z(x)(x & 0x7)

[PATCH v5 3/8] mfd: stmpe: preparations for STMPE ADC driver

2018-12-21 Thread Philippe Schenker
From: Stefan Agner 

This prepares the MFD for the STMPE ADC driver. This commit introduces
devicetree settings that are used by the ADC and adds an init function.
Common ADC settings that are shared with the touchscreen driver can now
reside in the overlying MFD.

Signed-off-by: Stefan Agner 
Signed-off-by: Max Krummenacher 
Signed-off-by: Philippe Schenker 
Acked-for-MFD-by: Lee Jones 

---

Changes in v5:
 - Added Lee Jone's Ack
 - Changed author of commit. Previous patch versions author was wrong
   by mistake.

Changes in v4:
 - New patch: split mfd changes into this precursor patch
 - Export the added stmpe811_adc_commmon_init function
 - Disabling adc when mfd is removed

Changes in v3: None
Changes in v2:
 - Move code to setup ADC to MFD device, as it is used by both drivers
   adc and touchscreen

 drivers/mfd/Kconfig   |  3 +-
 drivers/mfd/stmpe.c   | 68 +++
 include/linux/mfd/stmpe.h | 10 ++
 3 files changed, 80 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 8c5dfdce4326..bba159e8eaa4 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1204,7 +1204,7 @@ config MFD_STMPE
 
  Currently supported devices are:
 
-   STMPE811: GPIO, Touchscreen
+   STMPE811: GPIO, Touchscreen, ADC
STMPE1601: GPIO, Keypad
STMPE1801: GPIO, Keypad
STMPE2401: GPIO, Keypad
@@ -1217,6 +1217,7 @@ config MFD_STMPE
GPIO: stmpe-gpio
Keypad: stmpe-keypad
Touchscreen: stmpe-ts
+   ADC: stmpe-adc
 
 menu "STMicroelectronics STMPE Interface Drivers"
 depends on MFD_STMPE
diff --git a/drivers/mfd/stmpe.c b/drivers/mfd/stmpe.c
index 566caca4efd8..f582531a8f3e 100644
--- a/drivers/mfd/stmpe.c
+++ b/drivers/mfd/stmpe.c
@@ -463,6 +463,28 @@ static const struct mfd_cell stmpe_ts_cell = {
.num_resources  = ARRAY_SIZE(stmpe_ts_resources),
 };
 
+/*
+ * ADC (STMPE811)
+ */
+
+static struct resource stmpe_adc_resources[] = {
+   {
+   .name   = "STMPE_TEMP_SENS",
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .name   = "STMPE_ADC",
+   .flags  = IORESOURCE_IRQ,
+   },
+};
+
+static const struct mfd_cell stmpe_adc_cell = {
+   .name   = "stmpe-adc",
+   .of_compatible  = "st,stmpe-adc",
+   .resources  = stmpe_adc_resources,
+   .num_resources  = ARRAY_SIZE(stmpe_adc_resources),
+};
+
 /*
  * STMPE811 or STMPE610
  */
@@ -497,6 +519,11 @@ static struct stmpe_variant_block stmpe811_blocks[] = {
.irq= STMPE811_IRQ_TOUCH_DET,
.block  = STMPE_BLOCK_TOUCHSCREEN,
},
+   {
+   .cell   = _adc_cell,
+   .irq= STMPE811_IRQ_TEMP_SENS,
+   .block  = STMPE_BLOCK_ADC,
+   },
 };
 
 static int stmpe811_enable(struct stmpe *stmpe, unsigned int blocks,
@@ -517,6 +544,35 @@ static int stmpe811_enable(struct stmpe *stmpe, unsigned 
int blocks,
enable ? 0 : mask);
 }
 
+int stmpe811_adc_common_init(struct stmpe *stmpe)
+{
+   int ret;
+   u8 adc_ctrl1, adc_ctrl1_mask;
+
+   adc_ctrl1 = STMPE_SAMPLE_TIME(stmpe->sample_time) |
+   STMPE_MOD_12B(stmpe->mod_12b) |
+   STMPE_REF_SEL(stmpe->ref_sel);
+   adc_ctrl1_mask = STMPE_SAMPLE_TIME(0xff) | STMPE_MOD_12B(0xff) |
+STMPE_REF_SEL(0xff);
+
+   ret = stmpe_set_bits(stmpe, STMPE811_REG_ADC_CTRL1,
+   adc_ctrl1_mask, adc_ctrl1);
+   if (ret) {
+   dev_err(stmpe->dev, "Could not setup ADC\n");
+   return ret;
+   }
+
+   ret = stmpe_set_bits(stmpe, STMPE811_REG_ADC_CTRL2,
+   STMPE_ADC_FREQ(0xff), STMPE_ADC_FREQ(stmpe->adc_freq));
+   if (ret) {
+   dev_err(stmpe->dev, "Could not setup ADC\n");
+   return ret;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(stmpe811_adc_common_init);
+
 static int stmpe811_get_altfunc(struct stmpe *stmpe, enum stmpe_block block)
 {
/* 0 for touchscreen, 1 for GPIO */
@@ -1325,6 +1381,7 @@ int stmpe_probe(struct stmpe_client_info *ci, enum 
stmpe_partnum partnum)
struct device_node *np = ci->dev->of_node;
struct stmpe *stmpe;
int ret;
+   u32 val;
 
pdata = devm_kzalloc(ci->dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
@@ -1342,6 +1399,15 @@ int stmpe_probe(struct stmpe_client_info *ci, enum 
stmpe_partnum partnum)
mutex_init(>irq_lock);
mutex_init(>lock);
 
+   if (!of_property_read_u32(np, "st,sample-time", ))
+   stmpe->sample_time = val;
+   if (!of_property_read_u32(np, "st,mod-12b", ))
+   stmpe->mod_12b = val;
+   if (!of_property_read_u32(np, "st,ref-sel", ))
+   stmpe->ref_sel = val;
+   if (!of_property_read_u32(np, 

[PATCH v5 4/8] Input: stmpe-ts: preparations for STMPE ADC driver

2018-12-21 Thread Philippe Schenker
From: Philippe Schenker 

This patch removes common ADC settings in favor to use
stmpe811_adc_common_init that is present in MFD. This is necessary in
preparation for the stmpe-adc driver, because those two drivers have
common settings for the ADC.

Signed-off-by: Philippe Schenker 

---

Changes in v5:
 - Changed author of commit to use correct email.

Changes in v4:
 - New patch: Split changes in stmpe-ts.c to a separate commit
 - Remove common adc settings from init and call the
   stmpe811_adc_common_init function

Changes in v3:
 - Undo ADC-settings related code-deletions in stmpe-ts.c that the code
   is backwards-compatible to older devicetrees.

Changes in v2: None

 drivers/input/touchscreen/stmpe-ts.c | 42 +---
 1 file changed, 7 insertions(+), 35 deletions(-)

diff --git a/drivers/input/touchscreen/stmpe-ts.c 
b/drivers/input/touchscreen/stmpe-ts.c
index c5d9006588a2..cf9c9aa39f6e 100644
--- a/drivers/input/touchscreen/stmpe-ts.c
+++ b/drivers/input/touchscreen/stmpe-ts.c
@@ -30,8 +30,6 @@
  * with touchscreen controller
  */
 #define STMPE_REG_INT_STA  0x0B
-#define STMPE_REG_ADC_CTRL10x20
-#define STMPE_REG_ADC_CTRL20x21
 #define STMPE_REG_TSC_CTRL 0x40
 #define STMPE_REG_TSC_CFG  0x41
 #define STMPE_REG_FIFO_TH  0x4A
@@ -58,15 +56,6 @@
  * @idev: registered input device
  * @work: a work item used to scan the device
  * @dev: a pointer back to the MFD cell struct device*
- * @sample_time: ADC converstion time in number of clock.
- * (0 -> 36 clocks, 1 -> 44 clocks, 2 -> 56 clocks, 3 -> 64 clocks,
- * 4 -> 80 clocks, 5 -> 96 clocks, 6 -> 144 clocks),
- * recommended is 4.
- * @mod_12b: ADC Bit mode (0 -> 10bit ADC, 1 -> 12bit ADC)
- * @ref_sel: ADC reference source
- * (0 -> internal reference, 1 -> external reference)
- * @adc_freq: ADC Clock speed
- * (0 -> 1.625 MHz, 1 -> 3.25 MHz, 2 || 3 -> 6.5 MHz)
  * @ave_ctrl: Sample average control
  * (0 -> 1 sample, 1 -> 2 samples, 2 -> 4 samples, 3 -> 8 samples)
  * @touch_det_delay: Touch detect interrupt delay
@@ -88,10 +77,6 @@ struct stmpe_touch {
struct input_dev *idev;
struct delayed_work work;
struct device *dev;
-   u8 sample_time;
-   u8 mod_12b;
-   u8 ref_sel;
-   u8 adc_freq;
u8 ave_ctrl;
u8 touch_det_delay;
u8 settling;
@@ -192,7 +177,7 @@ static irqreturn_t stmpe_ts_handler(int irq, void *data)
 static int stmpe_init_hw(struct stmpe_touch *ts)
 {
int ret;
-   u8 adc_ctrl1, adc_ctrl1_mask, tsc_cfg, tsc_cfg_mask;
+   u8 tsc_cfg, tsc_cfg_mask;
struct stmpe *stmpe = ts->stmpe;
struct device *dev = ts->dev;
 
@@ -202,22 +187,9 @@ static int stmpe_init_hw(struct stmpe_touch *ts)
return ret;
}
 
-   adc_ctrl1 = STMPE_SAMPLE_TIME(ts->sample_time) |
-   STMPE_MOD_12B(ts->mod_12b) | STMPE_REF_SEL(ts->ref_sel);
-   adc_ctrl1_mask = STMPE_SAMPLE_TIME(0xff) | STMPE_MOD_12B(0xff) |
-STMPE_REF_SEL(0xff);
-
-   ret = stmpe_set_bits(stmpe, STMPE_REG_ADC_CTRL1,
-   adc_ctrl1_mask, adc_ctrl1);
-   if (ret) {
-   dev_err(dev, "Could not setup ADC\n");
-   return ret;
-   }
-
-   ret = stmpe_set_bits(stmpe, STMPE_REG_ADC_CTRL2,
-   STMPE_ADC_FREQ(0xff), STMPE_ADC_FREQ(ts->adc_freq));
+   ret = stmpe811_adc_common_init(stmpe);
if (ret) {
-   dev_err(dev, "Could not setup ADC\n");
+   stmpe_disable(stmpe, STMPE_BLOCK_TOUCHSCREEN | STMPE_BLOCK_ADC);
return ret;
}
 
@@ -295,13 +267,13 @@ static void stmpe_ts_get_platform_info(struct 
platform_device *pdev,
 
if (np) {
if (!of_property_read_u32(np, "st,sample-time", ))
-   ts->sample_time = val;
+   ts->stmpe->sample_time = val;
if (!of_property_read_u32(np, "st,mod-12b", ))
-   ts->mod_12b = val;
+   ts->stmpe->mod_12b = val;
if (!of_property_read_u32(np, "st,ref-sel", ))
-   ts->ref_sel = val;
+   ts->stmpe->ref_sel = val;
if (!of_property_read_u32(np, "st,adc-freq", ))
-   ts->adc_freq = val;
+   ts->stmpe->adc_freq = val;
if (!of_property_read_u32(np, "st,ave-ctrl", ))
ts->ave_ctrl = val;
if (!of_property_read_u32(np, "st,touch-det-delay", ))
-- 
2.19.2



[PATCH v5 0/8] Adding support for STMPE811 ADC

2018-12-21 Thread Philippe Schenker
From: Philippe Schenker 

Hello everyone,

This patchset is adding an ADC driver for STMPE811. The STMPE811 is a
Multi-Frontend-Device that supports a touchscreen, ADC, GPIO and a
temperature sensor.

For Touchscreen and GPIO there are already existing drivers in
mainline. This patchset will add support, to read out the ADC and
temperature sensor.
This patchset is also reformatting device tree bindings, so they are
easier to read (PATCH 1/1).
To be able to add this ADC driver it is necessary to move some defines
from the touchscreen driver to the mfd device (PATCH 2/8) so they are
also accessible by mfd and adc driver.
Because the touchscreen driver is also using the internal ADC it makes
sense to put the common adc settings of stmpe-ts.c and stmpe_adc.c to
the MFD. In the MFD there is then also an initialisation for the common
settings of ADC done. The existing initialisation in touchscreen driver
is kept for backwards-compatibility. All of this MFD related changes
are in PATCH 3/8.
In PATCH 4/8 then these settings are removed from stmpe-ts and grabbed
from MFD.
PATCH 5/8 is actually adding the ADC driver that also supports the
built-in temperature sensor.
PATCH 6/8 is then adding the needed devicetree bindings.
PATCH 7/8 and 8/8 is lastly adding the stmpe_adc DT-nodes as found on
Toradex boards.

Changes in v5:
 - Made a one column list
 - Added lee's Acked-for-MFD
 - Changed author of commit to use correct email.
 - Changed author of commit to use correct email
 - Added Lee Jone's Ack
 - Changed author of commit. Previous patch versions author was wrong
   by mistake.
 - Changed author of commit to use correct email.
 - Removed devm_add_action_or_reset
 - Changed iio_device_register to devm_iio_device_register
 - Added Jonathan Cameron's Reviewed-by
 - Added correct author of commit, as this changed by accident
 - Made a one column list
 - Cleared note about precedence
 - Changed example to a full STMPE811 device with MFD, touchscreen, and the new
   stmpe_adc driver.
 - Added Jonathan Cameron's Reviewed-by

Changes in v4:
 - New separate precursor patch for holding reformatting
 - Added Lee Jone's Ack
 - Added Dmitry Torokhov's Ack
 - New patch: split mfd changes into this precursor patch
 - Export the added stmpe811_adc_commmon_init function
 - Disabling adc when mfd is removed
 - New patch: Split changes in stmpe-ts.c to a separate commit
 - Remove common adc settings from init and call the
   stmpe811_adc_common_init function
 - Moved MFD changes to a precursor patch
 - Moved stmpe-ts changes to a precursor patch
 - Created stmpe_read_temp and stmpe_read_voltage functions to make
   read_raw more readable
 - Added local lock instead of using indio_dev's mlock
 - Use be16_to_cpu() macro instead of bitshifting
 - Added stmpe_enable again to stmpe_adc_init_hw
 - Use devm_add_action_or_reset to get rid of the remove function
   (I tested if that actually works)
 - Put reformatting in a separate precursor patch.
 - Moved T30 devicetree settings to separate commit
 - New separate commit to hold T30 devicetree changes

Changes in v3:
 - Undo ADC-settings related code-deletions in stmpe-ts.c that the code
   is backwards-compatible to older devicetrees.
 - Removed COMPILE_TEST from dependings in Kconfig
 - Removed stmpe_adc_get_platform_info() function and integrated the
   few code lines in the other function
 - Reformatted documentation for touchscreen to use tabs and have a better
   overview of the settings.
 - Added note which adc-settings will take precedence.
 - changed typo in sample-time setting from 144 clocks to 124 clocks, as stated
   in the datasheet.
 - None

Changes in v2:
 - This is a new added commit. Separate commit for moving the defines
   out of drivers/input/touchscreen/stmpe-ts.c to overlying mfd-device
   drivers/mfd/stmpe.c
 - Pre-fix defines with STMPE_
 - Move code to setup ADC to MFD device, as it is used by both drivers
   adc and touchscreen
 - Code formatting
 - Removed unused includes
 - Defined the macro STMPE_START_ONE_TEMP_CONV with other macros.
 - Added new macro that defines the channel of the temperature sensor.
   Took new name for STMPE_MAX_ADC->STMPE_ADC_LAST_NR and used it
   throughout the code for better readability.
 - Added mutex_unlock where missing.
 - Moved the bindings for ADC to the overlying mfd.
 - Reformatted for better readability
 - Put common ADC settings in mfd

Philippe Schenker (5):
  dt-bindings: stmpe: reformatting parameter list and use tabs only
  mfd: stmpe: Move ADC related defines to header of mfd
  Input: stmpe-ts: preparations for STMPE ADC driver
  ARM: dts: Add stmpe-adc DT node to Toradex iMX6 modules
  ARM: dts: Add stmpe-adc DT node to Toradex T30 modules

Stefan Agner (3):
  mfd: stmpe: preparations for STMPE ADC driver
  iio: adc: add STMPE ADC driver using IIO framework
  iio: adc: add STMPE ADC devicetree bindings

 .../devicetree/bindings/iio/adc/stmpe-adc.txt |  21 +
 .../bindings/input/touchscreen/stmpe.txt  | 116 --

[PATCH v5 8/8] ARM: dts: Add stmpe-adc DT node to Toradex T30 modules

2018-12-21 Thread Philippe Schenker
From: Philippe Schenker 

Add the stmpe-adc DT node as found on Toradex T30 modules

Signed-off-by: Philippe Schenker 

---

Changes in v5: None
Changes in v4:
 - New separate commit to hold T30 devicetree changes

Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/tegra30-apalis.dtsi  | 22 ++
 arch/arm/boot/dts/tegra30-colibri.dtsi | 22 ++
 2 files changed, 28 insertions(+), 16 deletions(-)

diff --git a/arch/arm/boot/dts/tegra30-apalis.dtsi 
b/arch/arm/boot/dts/tegra30-apalis.dtsi
index 7f112f192fe9..850b0d13549a 100644
--- a/arch/arm/boot/dts/tegra30-apalis.dtsi
+++ b/arch/arm/boot/dts/tegra30-apalis.dtsi
@@ -976,11 +976,18 @@
id = <0>;
blocks = <0x5>;
irq-trigger = <0x1>;
+   /* 3.25 MHz ADC clock speed */
+   st,adc-freq = <1>;
+   /* 12-bit ADC */
+   st,mod-12b = <1>;
+   /* internal ADC reference */
+   st,ref-sel = <0>;
+   /* ADC converstion time: 80 clocks */
+   st,sample-time = <4>;
+   /* forbid to use ADC channels 3-0 (touch) */
 
stmpe_touchscreen {
compatible = "st,stmpe-ts";
-   /* 3.25 MHz ADC clock speed */
-   st,adc-freq = <1>;
/* 8 sample average control */
st,ave-ctrl = <3>;
/* 7 length fractional part in z */
@@ -990,17 +997,16 @@
 * current limit value
 */
st,i-drive = <1>;
-   /* 12-bit ADC */
-   st,mod-12b = <1>;
-   /* internal ADC reference */
-   st,ref-sel = <0>;
-   /* ADC converstion time: 80 clocks */
-   st,sample-time = <4>;
/* 1 ms panel driver settling time */
st,settling = <3>;
/* 5 ms touch detect interrupt delay */
st,touch-det-delay = <5>;
};
+
+   stmpe_adc {
+   compatible = "st,stmpe-adc";
+   st,norequest-mask = <0x0F>;
+   };
};
 
/*
diff --git a/arch/arm/boot/dts/tegra30-colibri.dtsi 
b/arch/arm/boot/dts/tegra30-colibri.dtsi
index 35af03ca9e90..1f9198bb24ff 100644
--- a/arch/arm/boot/dts/tegra30-colibri.dtsi
+++ b/arch/arm/boot/dts/tegra30-colibri.dtsi
@@ -845,11 +845,18 @@
id = <0>;
blocks = <0x5>;
irq-trigger = <0x1>;
+   /* 3.25 MHz ADC clock speed */
+   st,adc-freq = <1>;
+   /* 12-bit ADC */
+   st,mod-12b = <1>;
+   /* internal ADC reference */
+   st,ref-sel = <0>;
+   /* ADC converstion time: 80 clocks */
+   st,sample-time = <4>;
+   /* forbid to use ADC channels 3-0 (touch) */
 
stmpe_touchscreen {
compatible = "st,stmpe-ts";
-   /* 3.25 MHz ADC clock speed */
-   st,adc-freq = <1>;
/* 8 sample average control */
st,ave-ctrl = <3>;
/* 7 length fractional part in z */
@@ -859,17 +866,16 @@
 * current limit value
 */
st,i-drive = <1>;
-   /* 12-bit ADC */
-   st,mod-12b = <1>;
-   /* internal ADC reference */
-   st,ref-sel = <0>;
-   /* ADC converstion time: 80 clocks */
-   st,sample-time = <4>;
/* 1 ms panel driver settling time */
st,settling = <3>;
/* 5 ms touch detect interrupt delay */
st,touch-det-delay = <5>;
};
+
+   stmpe_adc {
+   compatible = "st,stmpe-adc";
+   st,norequest-mask = <0x0F>;
+   };
};
 
/*
-- 
2.19.2



[PATCH v5 5/8] iio: adc: add STMPE ADC driver using IIO framework

2018-12-21 Thread Philippe Schenker
From: Stefan Agner 

This adds an ADC driver for the STMPE device using the industrial
input/output interface. The driver supports raw reading of values.
The driver depends on the MFD STMPE driver. If the touchscreen
block is enabled too, only four of the 8 ADC channels are available.

Signed-off-by: Stefan Agner 
Signed-off-by: Max Krummenacher 
Signed-off-by: Philippe Schenker 
Reviewed-by: Jonathan Cameron 

---

Changes in v5:
 - Removed devm_add_action_or_reset
 - Changed iio_device_register to devm_iio_device_register
 - Added Jonathan Cameron's Reviewed-by
 - Added correct author of commit, as this changed by accident

Changes in v4:
 - Moved MFD changes to a precursor patch
 - Moved stmpe-ts changes to a precursor patch
 - Created stmpe_read_temp and stmpe_read_voltage functions to make
   read_raw more readable
 - Added local lock instead of using indio_dev's mlock
 - Use be16_to_cpu() macro instead of bitshifting
 - Added stmpe_enable again to stmpe_adc_init_hw
 - Use devm_add_action_or_reset to get rid of the remove function
   (I tested if that actually works)

Changes in v3:
 - Removed COMPILE_TEST from dependings in Kconfig
 - Removed stmpe_adc_get_platform_info() function and integrated the
   few code lines in the other function

Changes in v2:
 - Code formatting
 - Removed unused includes
 - Defined the macro STMPE_START_ONE_TEMP_CONV with other macros.
 - Added new macro that defines the channel of the temperature sensor.
   Took new name for STMPE_MAX_ADC->STMPE_ADC_LAST_NR and used it
   throughout the code for better readability.
 - Added mutex_unlock where missing.

 drivers/iio/adc/Kconfig |   7 +
 drivers/iio/adc/Makefile|   1 +
 drivers/iio/adc/stmpe-adc.c | 363 
 3 files changed, 371 insertions(+)
 create mode 100644 drivers/iio/adc/stmpe-adc.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index a52fea8749a9..224f2067494d 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -734,6 +734,13 @@ config STM32_DFSDM_ADC
  This driver can also be built as a module.  If so, the module
  will be called stm32-dfsdm-adc.
 
+config STMPE_ADC
+   tristate "STMicroelectronics STMPE ADC driver"
+   depends on OF && MFD_STMPE
+   help
+ Say yes here to build support for ST Microelectronics STMPE
+ built-in ADC block (stmpe811).
+
 config STX104
tristate "Apex Embedded Systems STX104 driver"
depends on PC104 && X86
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index a6e6a0b659e2..cba889c30bf9 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -69,6 +69,7 @@ obj-$(CONFIG_STM32_ADC_CORE) += stm32-adc-core.o
 obj-$(CONFIG_STM32_ADC) += stm32-adc.o
 obj-$(CONFIG_STM32_DFSDM_CORE) += stm32-dfsdm-core.o
 obj-$(CONFIG_STM32_DFSDM_ADC) += stm32-dfsdm-adc.o
+obj-$(CONFIG_STMPE_ADC) += stmpe-adc.o
 obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
 obj-$(CONFIG_TI_ADC0832) += ti-adc0832.o
 obj-$(CONFIG_TI_ADC084S021) += ti-adc084s021.o
diff --git a/drivers/iio/adc/stmpe-adc.c b/drivers/iio/adc/stmpe-adc.c
new file mode 100644
index ..37f4b74a5d32
--- /dev/null
+++ b/drivers/iio/adc/stmpe-adc.c
@@ -0,0 +1,363 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *  STMicroelectronics STMPE811 IIO ADC Driver
+ *
+ *  4 channel, 10/12-bit ADC
+ *
+ *  Copyright (C) 2013-2018 Toradex AG 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define STMPE_REG_INT_STA  0x0B
+#define STMPE_REG_ADC_INT_EN   0x0E
+#define STMPE_REG_ADC_INT_STA  0x0F
+
+#define STMPE_REG_ADC_CTRL10x20
+#define STMPE_REG_ADC_CTRL20x21
+#define STMPE_REG_ADC_CAPT 0x22
+#define STMPE_REG_ADC_DATA_CH(channel) (0x30 + 2 * (channel))
+
+#define STMPE_REG_TEMP_CTRL0x60
+#define STMPE_TEMP_CTRL_ENABLE BIT(0)
+#define STMPE_TEMP_CTRL_ACQBIT(1)
+#define STMPE_TEMP_CTRL_THRES_EN   BIT(3)
+#define STMPE_START_ONE_TEMP_CONV  (STMPE_TEMP_CTRL_ENABLE | \
+   STMPE_TEMP_CTRL_ACQ | \
+   STMPE_TEMP_CTRL_THRES_EN)
+#define STMPE_REG_TEMP_DATA0x61
+#define STMPE_REG_TEMP_TH  0x63
+#define STMPE_ADC_LAST_NR  7
+#define STMPE_TEMP_CHANNEL (STMPE_ADC_LAST_NR + 1)
+
+#define STMPE_ADC_CH(channel)  ((1 << (channel)) & 0xff)
+
+#define STMPE_ADC_TIMEOUT  msecs_to_jiffies(1000)
+
+struct stmpe_adc {
+   struct stmpe *stmpe;
+   struct clk *clk;
+   struct device *dev;
+   struct mutex lock;
+
+   /* We are allocating plus one for the temperature channel */
+   struct iio_chan_spec stmpe_adc_iio_channels[STMPE_ADC_LAST_NR + 2];
+
+   struct completion completion;
+
+   u8 channel;
+   u32 value;
+};
+
+static int stmpe_read_voltage(struct stmpe_adc 

[PATCH v5 6/8] iio: adc: add STMPE ADC devicetree bindings

2018-12-21 Thread Philippe Schenker
From: Stefan Agner 

This adds the devicetree bindings for the STMPE ADC. This also corrects
a typo in st,sample-time it is rather "6 -> 124 clocks" according
to the datasheet and not 144.
We need to use the naming stmpe_adc in devicetree because this is given
by the mfd device.

Signed-off-by: Stefan Agner 
Signed-off-by: Max Krummenacher 
Signed-off-by: Philippe Schenker 
Reviewed-by: Jonathan Cameron 

---

Changes in v5:
 - Made a one column list
 - Cleared note about precedence
 - Changed example to a full STMPE811 device with MFD, touchscreen, and the new
   stmpe_adc driver.
 - Added Jonathan Cameron's Reviewed-by

Changes in v4:
 - Put reformatting in a separate precursor patch.

Changes in v3:
 - Reformatted documentation for touchscreen to use tabs and have a better
   overview of the settings.
 - Added note which adc-settings will take precedence.
 - changed typo in sample-time setting from 144 clocks to 124 clocks, as stated
   in the datasheet.

Changes in v2:
 - Moved the bindings for ADC to the overlying mfd.
 - Reformatted for better readability

 .../devicetree/bindings/iio/adc/stmpe-adc.txt | 21 +
 .../bindings/input/touchscreen/stmpe.txt  | 88 +--
 .../devicetree/bindings/mfd/stmpe.txt | 14 +++
 3 files changed, 98 insertions(+), 25 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt

diff --git a/Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt 
b/Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
new file mode 100644
index ..480e66422625
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
@@ -0,0 +1,21 @@
+STMPE ADC driver
+
+
+Required properties:
+ - compatible: "st,stmpe-adc"
+
+Optional properties:
+Note that the ADC is shared with the STMPE touchscreen. ADC related settings
+have to be done in the mfd.
+- st,norequest-mask: bitmask specifying which ADC channels should _not_ be
+  requestable due to different usage (e.g. touch)
+
+Node name must be stmpe_adc and should be child node of stmpe node to
+which it belongs.
+
+Example:
+
+   stmpe_adc {
+   compatible = "st,stmpe-adc";
+   st,norequest-mask = <0x0F>; /* dont use ADC CH3-0 */
+   };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt 
b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
index bf66a55a7de5..c549924603d2 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
@@ -5,24 +5,6 @@ Required properties:
  - compatible: "st,stmpe-ts"
 
 Optional properties:
-- st,sample-time   : ADC conversion time in number of clock.
-   0 -> 36 clocks
-   1 -> 44 clocks
-   2 -> 56 clocks
-   3 -> 64 clocks
-   4 -> 80 clocks (recommended)
-   5 -> 96 clocks
-   6 -> 144 clocks
-- st,mod-12b   : ADC Bit mode
-   0 -> 10bit ADC
-   1 -> 12bit ADC
-- st,ref-sel   : ADC reference source
-   0 -> internal
-   1 -> external
-- st,adc-freq  : ADC Clock speed
-   0 -> 1.625 MHz
-   1 -> 3.25 MHz
-   2 || 3 -> 6.5 MHz
 - st,ave-ctrl  : Sample average control
0 -> 1 sample
1 -> 2 samples
@@ -52,20 +34,76 @@ Optional properties:
0 -> 20 mA (typical 35mA max)
1 -> 50 mA (typical 80 mA max)
 
+Optional properties common with MFD (deprecated):
+ - st,sample-time  : ADC conversion time in number of clock.
+   0 -> 36 clocks
+   1 -> 44 clocks
+   2 -> 56 clocks
+   3 -> 64 clocks
+   4 -> 80 clocks (recommended)
+   5 -> 96 clocks
+   6 -> 124 clocks
+ - st,mod-12b  : ADC Bit mode
+   0 -> 10bit ADC
+   1 -> 12bit ADC
+ - st,ref-sel  : ADC reference source
+   0 -> internal
+   1 -> external
+ - st,adc-freq : ADC Clock speed
+   0 -> 1.625 MHz
+   1 -> 3.25 MHz
+   2 || 3 -> 6.5 MHz
+
 Node name must be stmpe_touchscreen and should be child node of stmpe node to
 which it belongs.
 
+Note that common ADC settings of stmpe_touchscreen (child) will take precedence
+over the settings done in MFD.
+
 Example:

[PATCH v5 7/8] ARM: dts: Add stmpe-adc DT node to Toradex iMX6 modules

2018-12-21 Thread Philippe Schenker
From: Philippe Schenker 

Add the stmpe-adc DT node as found on Toradex iMX6 modules

Signed-off-by: Philippe Schenker 

---

Changes in v5: None
Changes in v4:
 - Moved T30 devicetree settings to separate commit

Changes in v3:
 - None

Changes in v2:
 - Put common ADC settings in mfd

 arch/arm/boot/dts/imx6qdl-apalis.dtsi  | 22 ++
 arch/arm/boot/dts/imx6qdl-colibri.dtsi | 23 +++
 2 files changed, 29 insertions(+), 16 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi 
b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
index 3dc99dd8dde1..8db476d8978d 100644
--- a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
@@ -331,11 +331,18 @@
id = <0>;
blocks = <0x5>;
irq-trigger = <0x1>;
+   /* 3.25 MHz ADC clock speed */
+   st,adc-freq = <1>;
+   /* 12-bit ADC */
+   st,mod-12b = <1>;
+   /* internal ADC reference */
+   st,ref-sel = <0>;
+   /* ADC converstion time: 80 clocks */
+   st,sample-time = <4>;
+   /* forbid to use ADC channels 3-0 (touch) */
 
stmpe_touchscreen {
compatible = "st,stmpe-ts";
-   /* 3.25 MHz ADC clock speed */
-   st,adc-freq = <1>;
/* 8 sample average control */
st,ave-ctrl = <3>;
/* 7 length fractional part in z */
@@ -345,17 +352,16 @@
 * current limit value
 */
st,i-drive = <1>;
-   /* 12-bit ADC */
-   st,mod-12b = <1>;
-   /* internal ADC reference */
-   st,ref-sel = <0>;
-   /* ADC converstion time: 80 clocks */
-   st,sample-time = <4>;
/* 1 ms panel driver settling time */
st,settling = <3>;
/* 5 ms touch detect interrupt delay */
st,touch-det-delay = <5>;
};
+
+   stmpe_adc {
+   compatible = "st,stmpe-adc";
+   st,norequest-mask = <0x0F>;
+   };
};
 };
 
diff --git a/arch/arm/boot/dts/imx6qdl-colibri.dtsi 
b/arch/arm/boot/dts/imx6qdl-colibri.dtsi
index 87e15e7cb32b..2e303d79c7f8 100644
--- a/arch/arm/boot/dts/imx6qdl-colibri.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-colibri.dtsi
@@ -262,11 +262,18 @@
id = <0>;
blocks = <0x5>;
irq-trigger = <0x1>;
+   /* 3.25 MHz ADC clock speed */
+   st,adc-freq = <1>;
+   /* 12-bit ADC */
+   st,mod-12b = <1>;
+   /* internal ADC reference */
+   st,ref-sel = <0>;
+   /* ADC converstion time: 80 clocks */
+   st,sample-time = <4>;
+   /* forbid to use ADC channels 3-0 (touch) */
 
stmpe_touchscreen {
compatible = "st,stmpe-ts";
-   /* 3.25 MHz ADC clock speed */
-   st,adc-freq = <1>;
/* 8 sample average control */
st,ave-ctrl = <3>;
/* 7 length fractional part in z */
@@ -276,17 +283,17 @@
 * current limit value
 */
st,i-drive = <1>;
-   /* 12-bit ADC */
-   st,mod-12b = <1>;
-   /* internal ADC reference */
-   st,ref-sel = <0>;
-   /* ADC converstion time: 80 clocks */
-   st,sample-time = <4>;
/* 1 ms panel driver settling time */
st,settling = <3>;
/* 5 ms touch detect interrupt delay */
st,touch-det-delay = <5>;
};
+
+   stmpe_adc {
+   compatible = "st,stmpe-adc";
+   /* 3.25 MHz ADC clock speed */
+   st,norequest-mask = <0x0F>;
+   };
};
 };
 
-- 
2.19.2



[PATCH v5 1/8] dt-bindings: stmpe: reformatting parameter list and use tabs only

2018-12-21 Thread Philippe Schenker
From: Philippe Schenker 

This patch reformats the parameter list for stmpe device in a
table-style so it is more clear to read.

Signed-off-by: Philippe Schenker 
Acked-for-MFD-by: Lee Jones 

---

Changes in v5:
 - Made a one column list
 - Added lee's Acked-for-MFD
 - Changed author of commit to use correct email.

Changes in v4:
 - New separate precursor patch for holding reformatting

Changes in v3: None
Changes in v2: None

 .../bindings/input/touchscreen/stmpe.txt  | 64 +--
 .../devicetree/bindings/mfd/stmpe.txt | 14 ++--
 2 files changed, 53 insertions(+), 25 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt 
b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
index 127baa31a77a..bf66a55a7de5 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
@@ -5,24 +5,52 @@ Required properties:
  - compatible: "st,stmpe-ts"
 
 Optional properties:
-- st,sample-time: ADC converstion time in number of clock.  (0 -> 36 clocks, 1 
->
-  44 clocks, 2 -> 56 clocks, 3 -> 64 clocks, 4 -> 80 clocks, 5 -> 96 clocks, 6
-  -> 144 clocks), recommended is 4.
-- st,mod-12b: ADC Bit mode (0 -> 10bit ADC, 1 -> 12bit ADC)
-- st,ref-sel: ADC reference source (0 -> internal reference, 1 -> external
-  reference)
-- st,adc-freq: ADC Clock speed (0 -> 1.625 MHz, 1 -> 3.25 MHz, 2 || 3 -> 6.5 
MHz)
-- st,ave-ctrl: Sample average control (0 -> 1 sample, 1 -> 2 samples, 2 -> 4
-  samples, 3 -> 8 samples)
-- st,touch-det-delay: Touch detect interrupt delay (0 -> 10 us, 1 -> 50 us, 2 
->
-  100 us, 3 -> 500 us, 4-> 1 ms, 5 -> 5 ms, 6 -> 10 ms, 7 -> 50 ms) recommended
-  is 3
-- st,settling: Panel driver settling time (0 -> 10 us, 1 -> 100 us, 2 -> 500 
us, 3
-  -> 1 ms, 4 -> 5 ms, 5 -> 10 ms, 6 for 50 ms, 7 -> 100 ms) recommended is 2
-- st,fraction-z: Length of the fractional part in z (fraction-z ([0..7]) = 
Count of
-  the fractional part) recommended is 7
-- st,i-drive: current limit value of the touchscreen drivers (0 -> 20 mA 
typical 35
-  mA max, 1 -> 50 mA typical 80 mA max)
+- st,sample-time   : ADC conversion time in number of clock.
+   0 -> 36 clocks
+   1 -> 44 clocks
+   2 -> 56 clocks
+   3 -> 64 clocks
+   4 -> 80 clocks (recommended)
+   5 -> 96 clocks
+   6 -> 144 clocks
+- st,mod-12b   : ADC Bit mode
+   0 -> 10bit ADC
+   1 -> 12bit ADC
+- st,ref-sel   : ADC reference source
+   0 -> internal
+   1 -> external
+- st,adc-freq  : ADC Clock speed
+   0 -> 1.625 MHz
+   1 -> 3.25 MHz
+   2 || 3 -> 6.5 MHz
+- st,ave-ctrl  : Sample average control
+   0 -> 1 sample
+   1 -> 2 samples
+   2 -> 4 samples
+   3 -> 8 samples
+- st,touch-det-delay   : Touch detect interrupt delay (recommended is 3)
+   0 -> 10 us
+   1 -> 50 us
+   2 -> 100 us
+   3 -> 500 us
+   4 -> 1 ms
+   5 -> 5 ms
+   6 -> 10 ms
+   7 -> 50 ms
+- st,settling  : Panel driver settling time (recommended is 2)
+   0 -> 10 us
+   1 -> 100 us
+   2 -> 500 us
+   3 -> 1 ms
+   4 -> 5 ms
+   5 -> 10 ms
+   6 -> 50 ms
+   7 -> 100 ms
+- st,fraction-z: Length of the fractional part in z 
(recommended is 7)
+ (fraction-z ([0..7]) = Count of the fractional part)
+- st,i-drive   : current limit value of the touchscreen drivers
+   0 -> 20 mA (typical 35mA max)
+   1 -> 50 mA (typical 80 mA max)
 
 Node name must be stmpe_touchscreen and should be child node of stmpe node to
 which it belongs.
diff --git a/Documentation/devicetree/bindings/mfd/stmpe.txt 
b/Documentation/devicetree/bindings/mfd/stmpe.txt
index c797c05cd3c2..a46e7177195d 100644
--- a/Documentation/devicetree/bindings/mfd/stmpe.txt
+++ b/Documentation/devicetree/bindings/mfd/stmpe.txt
@@ -4,15 +4,15 @@ STMPE is an MFD device which may expose the following inbuilt 
devices: gpio,
 keypad, touchscreen, adc, pwm, rotator.
 
 Required properties:
- - compatible

Re: [PATCH V2 1/2] mmc: sdhci: Fix O2 Host PLL and card detect issue

2018-12-21 Thread Adrian Hunter
On 18/12/18 1:40 PM, Ernest Zhang(WH) wrote:
> From: "Ernest Zhang" 
> 
> 1. O2 Host Controller PLL lock status is not in compliance with
> CLOCK_CONTROL register bit 1
> 2. O2 Host Controller card detect function only work when PLL is
> enabled and locked
> 
> Signed-off-by: Ernest Zhang 

If you put the other patch first, then this patch will need some minor
modifications, otherwise I have no further comments.

> ---
> Change in V2:
>   1. Remove unused sdhci_ops function pointer
>   2. Change kind of timeout check, get the time first
>   3. Rename CARD PRESENT register bit16 and bit 18 macro
> 
> Change in V1:
>   N/A
> ---
>  drivers/mmc/host/sdhci-pci-core.c|   9 +++
>  drivers/mmc/host/sdhci-pci-o2micro.c | 121 
> ++-
>  drivers/mmc/host/sdhci-pci.h |   1 +
>  drivers/mmc/host/sdhci.h |   4 ++
>  4 files changed, 132 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci-pci-core.c 
> b/drivers/mmc/host/sdhci-pci-core.c
> index 2a6eba74b94e..fc4f35653602 100644
> --- a/drivers/mmc/host/sdhci-pci-core.c
> +++ b/drivers/mmc/host/sdhci-pci-core.c
> @@ -1257,6 +1257,14 @@ static int jmicron_resume(struct sdhci_pci_chip *chip)
>  }
>  #endif
>  
> +static const struct sdhci_ops sdhci_pci_o2_ops = {
> + .set_clock = sdhci_pci_o2_set_clock,
> + .enable_dma = sdhci_pci_enable_dma,
> + .set_bus_width = sdhci_set_bus_width,
> + .reset = sdhci_reset,
> + .set_uhs_signaling = sdhci_set_uhs_signaling,
> +};
> +
>  static const struct sdhci_pci_fixes sdhci_o2 = {
>   .probe = sdhci_pci_o2_probe,
>   .quirks = SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC,
> @@ -1265,6 +1273,7 @@ static const struct sdhci_pci_fixes sdhci_o2 = {
>  #ifdef CONFIG_PM_SLEEP
>   .resume = sdhci_pci_o2_resume,
>  #endif
> + .ops = _pci_o2_ops,
>  };
>  
>  static const struct sdhci_pci_fixes sdhci_jmicron = {
> diff --git a/drivers/mmc/host/sdhci-pci-o2micro.c 
> b/drivers/mmc/host/sdhci-pci-o2micro.c
> index cc3ffeffd7a2..506b93e5dcd8 100644
> --- a/drivers/mmc/host/sdhci-pci-o2micro.c
> +++ b/drivers/mmc/host/sdhci-pci-o2micro.c
> @@ -60,6 +60,13 @@
>  #define O2_SD_VENDOR_SETTING20x1C8
>  #define O2_SD_HW_TUNING_DISABLE  BIT(4)
>  
> +#define O2_PLL_WDT_CONTROL1  0x1CC
> +#define  O2_PLL_FORCE_ACTIVE BIT(18)
> +#define  O2_PLL_LOCK_STATUS  BIT(14)
> +#define  O2_PLL_SOFT_RESET   BIT(12)
> +
> +#define O2_SD_DETECT_SETTING 0x324
> +
>  static void sdhci_o2_set_tuning_mode(struct sdhci_host *host)
>  {
>   u16 reg;
> @@ -283,6 +290,113 @@ static void sdhci_pci_o2_enable_msi(struct 
> sdhci_pci_chip *chip,
>   host->irq = pci_irq_vector(chip->pdev, 0);
>  }
>  
> +static void sdhci_o2_wait_card_detect_stable(struct sdhci_host *host)
> +{
> + ktime_t timeout;
> + u32 scratch32;
> +
> + /* Wait max 50 ms */
> + timeout = ktime_add_ms(ktime_get(), 50);
> + while (1) {
> + bool timedout = ktime_after(ktime_get(), timeout);
> +
> + scratch32 = sdhci_readl(host, SDHCI_PRESENT_STATE);
> + if ((scratch32 & SDHCI_CARD_PRESENT) >> SDHCI_CARD_PRES_SHIFT
> + == (scratch32 & SDHCI_CD_LVL) >> SDHCI_CD_LVL_SHIFT)
> + break;
> +
> + if (timedout) {
> + pr_err("%s: Card Detect debounce never finished.\n",
> +mmc_hostname(host->mmc));
> + sdhci_dumpregs(host);
> + return;
> + }
> + udelay(10);
> + }
> +}
> +
> +static void sdhci_o2_enable_internal_clock(struct sdhci_host *host)
> +{
> + ktime_t timeout;
> + u16 scratch;
> + u32 scratch32;
> +
> + /* PLL software reset */
> + scratch32 = sdhci_readl(host, O2_PLL_WDT_CONTROL1);
> + scratch32 |= O2_PLL_SOFT_RESET;
> + sdhci_writel(host, scratch32, O2_PLL_WDT_CONTROL1);
> + udelay(1);
> + scratch32 &= ~(O2_PLL_SOFT_RESET);
> + sdhci_writel(host, scratch32, O2_PLL_WDT_CONTROL1);
> +
> + /* PLL force active */
> + scratch32 |= O2_PLL_FORCE_ACTIVE;
> + sdhci_writel(host, scratch32, O2_PLL_WDT_CONTROL1);
> +
> + /* Wait max 20 ms */
> + timeout = ktime_add_ms(ktime_get(), 20);
> + while (1) {
> + bool timedout = ktime_after(ktime_get(), timeout);
> +
> + scratch = sdhci_readw(host, O2_PLL_WDT_CONTROL1);
> + if (scratch & O2_PLL_LOCK_STATUS)
> + break;
> + if (timedout) {
> + pr_err("%s: Internal clock never stabilised.\n",
> +mmc_hostname(host->mmc));
> + sdhci_dumpregs(host);
> + goto out;
> + }
> + udelay(10);
> + }
> +
> + /* Wait for card detect finish */
> + udelay(1);
> + sdhci_o2_wait_card_detect_stable(host);
> +
> +out:
> + /* Cancel PLL force active */
> + scratch32 = sdhci_readl(host, 

Applied "regulator: mcp16502: Select REGMAP_I2C to fix build error" to the regulator tree

2018-12-21 Thread Mark Brown
The patch

   regulator: mcp16502: Select REGMAP_I2C to fix build error

has been applied to the regulator tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 77ea906082dcfa63ad8a07ace6d5033d30c4175b Mon Sep 17 00:00:00 2001
From: Axel Lin 
Date: Fri, 21 Dec 2018 10:49:29 +0800
Subject: [PATCH] regulator: mcp16502: Select REGMAP_I2C to fix build error

Fix build error when CONFIG_REGMAP_I2C=m && CONFIG_REGULATOR_MCP16502=y.

drivers/regulator/mcp16502.o: In function `mcp16502_probe':
mcp16502.c:(.text+0xca): undefined reference to `__devm_regmap_init_i2c'

Signed-off-by: Axel Lin 
Signed-off-by: Mark Brown 
---
 drivers/regulator/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 719d9d660e56..ee60a222f5eb 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -570,6 +570,7 @@ config REGULATOR_MC13892
 config REGULATOR_MCP16502
tristate "Microchip MCP16502 PMIC"
depends on I2C && OF
+   select REGMAP_I2C
help
  Say y here to support the MCP16502 PMIC. This driver supports
  basic operations (get/set voltage, get/set operating mode)
-- 
2.20.1



Applied "regulator: tps65910: fix a missing check of return value" to the regulator tree

2018-12-21 Thread Mark Brown
The patch

   regulator: tps65910: fix a missing check of return value

has been applied to the regulator tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From cd07e3701fa6a4c68f8493ee1d12caa18d46ec6a Mon Sep 17 00:00:00 2001
From: Kangjie Lu 
Date: Fri, 21 Dec 2018 00:29:19 -0600
Subject: [PATCH] regulator: tps65910: fix a missing check of return value

tps65910_reg_set_bits() may fail. The fix checks if it fails, and if so,
returns with its error code.

Signed-off-by: Kangjie Lu 
Signed-off-by: Mark Brown 
---
 drivers/regulator/tps65910-regulator.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/regulator/tps65910-regulator.c 
b/drivers/regulator/tps65910-regulator.c
index 02ccdaa226a7..5ebb6ee73f07 100644
--- a/drivers/regulator/tps65910-regulator.c
+++ b/drivers/regulator/tps65910-regulator.c
@@ -1102,8 +1102,10 @@ static int tps65910_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, pmic);
 
/* Give control of all register to control port */
-   tps65910_reg_set_bits(pmic->mfd, TPS65910_DEVCTRL,
+   err = tps65910_reg_set_bits(pmic->mfd, TPS65910_DEVCTRL,
DEVCTRL_SR_CTL_I2C_SEL_MASK);
+   if (err < 0)
+   return err;
 
switch (tps65910_chip_id(tps65910)) {
case TPS65910:
-- 
2.20.1



Re: [PATCH] drm: add capability DRM_CAP_ASYNC_UPDATE

2018-12-21 Thread Daniel Vetter
On Fri, Dec 21, 2018 at 12:51:05PM +0900, Tomasz Figa wrote:
> On Thu, Dec 20, 2018 at 7:47 PM Daniel Vetter  wrote:
> >
> > On Thu, Dec 20, 2018 at 10:07 AM Tomasz Figa  wrote:
> > >
> > > Hi Helen,
> > >
> > > On Fri, Dec 14, 2018 at 10:35 AM Helen Koike  
> > > wrote:
> > > >
> > > > Hi Tomasz,
> > > >
> > > > On 12/13/18 2:02 AM, Tomasz Figa wrote:
> > > > > On Thu, Dec 6, 2018 at 1:12 AM Helen Koike 
> > > > >  wrote:
> > > > >>
> > > > >> Hi Ville
> > > > >>
> > > > >> On 11/27/18 11:34 AM, Ville Syrjälä wrote:
> > > > >>> On Fri, Nov 23, 2018 at 07:53:26PM -0200, Helen Koike wrote:
> > > >  Allow userspace to identify if the driver supports async update.
> > > > >>>
> > > > >>> And what exactly is an "async update"?
> > > > >>
> > > > >> I agree we are lacking docs on this, I'll send in the next version as
> > > > >> soon as we agree on a name (please see below).
> > > > >>
> > > > >> For reference:
> > > > >> https://lists.freedesktop.org/archives/dri-devel/2017-April/138586.html
> > > > >>
> > > > >>>
> > > > >>> I keep asking people to come up with the a better name for this, 
> > > > >>> and to
> > > > >>> document what it actually means. Recently I've been think we should
> > > > >>> maybe just adopt the vulkan terminology (immediate/fifo/mailbox) to
> > > > >>> avoid introducing yet another set of names for the same thing. We'd
> > > > >>> still want to document things properly though.
> > > > >>
> > > > >> Another name it was suggested was "atomic amend", this feature 
> > > > >> basically
> > > > >> allows userspace to complement an update previously sent (i.e. its in
> > > > >> the queue and wasn't commited yet), it allows adding a plane update 
> > > > >> to
> > > > >> the next commit. So what do you think in renaming it to "atomic 
> > > > >> amend"?
> > > > >
> > > > > Note that it doesn't seem to be what the code currently is doing. For
> > > > > example, for cursor updates, it doesn't seem to be working on the
> > > > > currently pending commit, but just directly issues an atomic async
> > > > > update call to the planes. The code actually seems to fall back to a
> > > > > normal sync commit, if there is an already pending commit touching the
> > > > > same plane or including a modeset.
> > > >
> > > > It should fail as discussed at:
> > > > https://patchwork.freedesktop.org/patch/243088/
> > > >
> > > > There was the following code inside the drm_atomic_helper_async_check()
> > > > in the previous patch which would fallback to a normal commit if there
> > > > isn't any pending commit to amend:
> > > >
> > > > +   if (!old_plane_state->commit)
> > > > +   return -EINVAL;
> > > >
> > > > In the v2 of the patch https://patchwork.freedesktop.org/patch/263712/
> > > > this got removed, but which means that async update will be enabled
> > > > anyway. So the following code is wrong:
> > > >
> > > > -   if (state->legacy_cursor_update)
> > > > +   if (state->async_update || state->legacy_cursor_update)
> > > > state->async_update = 
> > > > !drm_atomic_helper_async_check(dev, state);
> > > >
> > > > Does it make sense? If yes I'll fix this in the next version of the
> > > > Atomic IOCTL patch (and also those two patches should be in the same
> > > > series, I'll send them together next time).
> > > >
> > > > Thanks for pointing this out.
> > > >
> > > > Please let me know if you still don't agree on the name "atomic amend",
> > > > or if I am missing something.
> > >
> > > I'll defer it to the DRM maintainers. From Chrome OS perspective, we
> > > need a way to commit the cursor plane asynchronously from other
> > > commits any time the cursor changes its position or framebuffer. As
> > > long as the new API allows that and the maintainers are fine with it,
> > > I think I should be okay with it too.
> >
> > If this is just about the cursor, why is the current legacy cursor
> > ioctl not good enough? It's 2 ioctls instead of one, but I'm not sure
> > if we want to support having a normal atomic commit and a cursor
> > update in the same atomic ioctl, coming up with reasonable semantics
> > for that will be complicated.
> >
> > Pointer to code that uses this would be better ofc.
> 
> Sorry, let me clarify that I was mostly referring to the respective
> kernel functionality here, not the userspace extension.
> 
> As far as I know, Chromium still uses the legacy cursor ioctls and we
> have our drivers implement them directly, bypassing the atomic commit
> mechanism. However, it sounds like this async commit could let us
> remove the custom implementations from the drivers and have a common
> helper for it, which would be a good step forward.

Yup, that was at least the motivation for merging it. Unfortunately that
upstream effort got stalled, and there's still a few custom
implementations, and not many drivers using the async plane update stuff
yet.

> Daniel, Daniele, Sean, Stephane, could you clarify what are our needs
> for this userspace 

[PATCH] binderfs: implement sysctls

2018-12-21 Thread Christian Brauner
This implements three sysctls that have very specific goals:

1. /proc/sys/fs/binder/max:
   Allow global root to globally limit the number of allocatable binder
   devices.
2. /proc/sys/fs/binder/nr:
   Allow global root to easily detect how many binder devices are currently
   in use across all binderfs mounts.
3. /proc/sys/fs/binder/reserved:
   Ensure that global root can reserve binder devices for the initial
   binderfs mount in the initial ipc namespace to prevent DOS attacks.

This is equivalent to sysctls of devpts.

Signed-off-by: Christian Brauner 
---
 drivers/android/binderfs.c | 81 +-
 1 file changed, 79 insertions(+), 2 deletions(-)

diff --git a/drivers/android/binderfs.c b/drivers/android/binderfs.c
index 7496b10532aa..5ff015f82314 100644
--- a/drivers/android/binderfs.c
+++ b/drivers/android/binderfs.c
@@ -64,6 +64,71 @@ struct binderfs_info {
 
 };
 
+/* Global default limit on the number of binder devices. */
+static int device_limit = 4096;
+
+/*
+ * Number of binder devices reserved for the initial binderfs mount in the
+ * initial ipc namespace.
+ */
+static int device_reserve = 1024;
+
+/* Dummy sysctl minimum. */
+static int device_limit_min;
+
+/* Cap sysctl at BINDERFS_MAX_MINOR. */
+static int device_limit_max = BINDERFS_MAX_MINOR;
+
+/* Current number of allocated binder devices. */
+static atomic_t device_count = ATOMIC_INIT(0);
+
+static struct ctl_table binderfs_table[] = {
+   {
+   .procname   = "max",
+   .maxlen = sizeof(int),
+   .mode   = 0644,
+   .data   = _limit,
+   .proc_handler   = proc_dointvec_minmax,
+   .extra1 = _limit_min,
+   .extra2 = _limit_max,
+   },
+   {
+   .procname   = "reserve",
+   .maxlen = sizeof(int),
+   .mode   = 0644,
+   .data   = _reserve,
+   .proc_handler   = proc_dointvec_minmax,
+   .extra1 = _limit_min,
+   .extra2 = _limit_max,
+   },
+   {
+   .procname   = "nr",
+   .maxlen = sizeof(int),
+   .mode   = 0444,
+   .data   = _count,
+   .proc_handler   = proc_dointvec,
+   },
+   {}
+};
+
+static struct ctl_table binderfs_fs_table[] = {
+   {
+   .procname   = "binder",
+   .mode   = 0555,
+   .child  = binderfs_table,
+   },
+   {}
+};
+
+static struct ctl_table binderfs_root_table[] = {
+   {
+   .procname   = "fs",
+   .mode   = 0555,
+   .child  = binderfs_fs_table,
+   },
+   {}
+};
+
 static inline struct binderfs_info *BINDERFS_I(const struct inode *inode)
 {
return inode->i_sb->s_fs_info;
@@ -107,13 +172,21 @@ static int binderfs_binder_device_create(struct inode 
*ref_inode,
struct inode *inode = NULL;
struct super_block *sb = ref_inode->i_sb;
struct binderfs_info *info = sb->s_fs_info;
+   bool use_reserved = (info->ipc_ns == _ipc_ns);
 
/* Reserve new minor number for the new device. */
mutex_lock(_minors_mutex);
-   minor = ida_alloc_max(_minors, BINDERFS_MAX_MINOR, GFP_KERNEL);
+   if (atomic_inc_return(_count) <
+   (device_limit - (use_reserved ? 0 : device_reserve)))
+   minor = ida_alloc_max(_minors, BINDERFS_MAX_MINOR,
+ GFP_KERNEL);
+   else
+   minor = -ENOSPC;
mutex_unlock(_minors_mutex);
-   if (minor < 0)
+   if (minor < 0) {
+   atomic_dec(_count);
return minor;
+   }
 
ret = -ENOMEM;
device = kzalloc(sizeof(*device), GFP_KERNEL);
@@ -187,6 +260,7 @@ static int binderfs_binder_device_create(struct inode 
*ref_inode,
kfree(name);
kfree(device);
mutex_lock(_minors_mutex);
+   atomic_dec(_count);
ida_free(_minors, minor);
mutex_unlock(_minors_mutex);
iput(inode);
@@ -239,6 +313,7 @@ static void binderfs_evict_inode(struct inode *inode)
return;
 
mutex_lock(_minors_mutex);
+   atomic_dec(_count);
ida_free(_minors, device->miscdev.minor);
mutex_unlock(_minors_mutex);
 
@@ -536,6 +611,8 @@ static int __init init_binderfs(void)
binderfs_mnt = NULL;
unregister_filesystem(_fs_type);
unregister_chrdev_region(binderfs_dev, BINDERFS_MAX_MINOR);
+   } else {
+   register_sysctl_table(binderfs_root_table);
}
 
return ret;
-- 
2.19.1



Re: [PATCH V2 2/2] mmc: sdhci: Moving sdhci_o2 into sdhci-pci-o2micro.c

2018-12-21 Thread Adrian Hunter
On 18/12/18 1:40 PM, Ernest Zhang(WH) wrote:
> Moving sdhci_o2 into sdhci-pci-o2micro.c
> 
> Signed-off-by: Ernest Zhang 

It would be more logical to make this the first patch, rather than put the
ops in one file, and then move them to another.

> ---
> Change in V2:
>   1. Moving sdhci_o2 into sdhci-pci-o2micro.c
> 
> Change in V1:
>   N/A
> ---
>  drivers/mmc/host/sdhci-pci-core.c| 19 ---
>  drivers/mmc/host/sdhci-pci-o2micro.c | 19 +++
>  drivers/mmc/host/sdhci-pci.h |  1 +
>  3 files changed, 20 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci-pci-core.c 
> b/drivers/mmc/host/sdhci-pci-core.c
> index fc4f35653602..99b0fec2836b 100644
> --- a/drivers/mmc/host/sdhci-pci-core.c
> +++ b/drivers/mmc/host/sdhci-pci-core.c
> @@ -1257,25 +1257,6 @@ static int jmicron_resume(struct sdhci_pci_chip *chip)
>  }
>  #endif
>  
> -static const struct sdhci_ops sdhci_pci_o2_ops = {
> - .set_clock = sdhci_pci_o2_set_clock,
> - .enable_dma = sdhci_pci_enable_dma,
> - .set_bus_width = sdhci_set_bus_width,
> - .reset = sdhci_reset,
> - .set_uhs_signaling = sdhci_set_uhs_signaling,
> -};
> -
> -static const struct sdhci_pci_fixes sdhci_o2 = {
> - .probe = sdhci_pci_o2_probe,
> - .quirks = SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC,
> - .quirks2 = SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD,
> - .probe_slot = sdhci_pci_o2_probe_slot,
> -#ifdef CONFIG_PM_SLEEP
> - .resume = sdhci_pci_o2_resume,
> -#endif
> - .ops = _pci_o2_ops,
> -};
> -
>  static const struct sdhci_pci_fixes sdhci_jmicron = {
>   .probe  = jmicron_probe,
>  
> diff --git a/drivers/mmc/host/sdhci-pci-o2micro.c 
> b/drivers/mmc/host/sdhci-pci-o2micro.c
> index 506b93e5dcd8..7f11cee71db1 100644
> --- a/drivers/mmc/host/sdhci-pci-o2micro.c
> +++ b/drivers/mmc/host/sdhci-pci-o2micro.c
> @@ -665,3 +665,22 @@ int sdhci_pci_o2_resume(struct sdhci_pci_chip *chip)
>   return sdhci_pci_resume_host(chip);
>  }
>  #endif
> +
> +static const struct sdhci_ops sdhci_pci_o2_ops = {
> + .set_clock = sdhci_pci_o2_set_clock,
> + .enable_dma = sdhci_pci_enable_dma,
> + .set_bus_width = sdhci_set_bus_width,
> + .reset = sdhci_reset,
> + .set_uhs_signaling = sdhci_set_uhs_signaling,
> +};
> +
> +const struct sdhci_pci_fixes sdhci_o2 = {
> + .probe = sdhci_pci_o2_probe,
> + .quirks = SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC,
> + .quirks2 = SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD,
> + .probe_slot = sdhci_pci_o2_probe_slot,
> +#ifdef CONFIG_PM_SLEEP
> + .resume = sdhci_pci_o2_resume,
> +#endif
> + .ops = _pci_o2_ops,
> +};
> diff --git a/drivers/mmc/host/sdhci-pci.h b/drivers/mmc/host/sdhci-pci.h
> index e41a85f0b40a..0e08021179a8 100644
> --- a/drivers/mmc/host/sdhci-pci.h
> +++ b/drivers/mmc/host/sdhci-pci.h
> @@ -188,5 +188,6 @@ void sdhci_pci_o2_set_clock(struct sdhci_host *host, 
> unsigned int clock);
>  
>  extern const struct sdhci_pci_fixes sdhci_arasan;
>  extern const struct sdhci_pci_fixes sdhci_snps;
> +extern const struct sdhci_pci_fixes sdhci_o2;

Then the other o2 declarations in sdhci-pci.h are not needed.
i.e. these ones:
 int sdhci_pci_o2_probe_slot(struct sdhci_pci_slot *slot);
 int sdhci_pci_o2_probe(struct sdhci_pci_chip *chip);
 #ifdef CONFIG_PM_SLEEP
 int sdhci_pci_o2_resume(struct sdhci_pci_chip *chip);
 #endif
 void sdhci_pci_o2_set_clock(struct sdhci_host *host, unsigned int clock);

>  
>  #endif /* __SDHCI_PCI_H */
> 



Re: [PATCH 2/2] ARC: show_regs: fix lockdep splat for good

2018-12-21 Thread Michal Hocko
On Fri 21-12-18 14:04:04, Michal Hocko wrote:
[...]
> Yes, but you are building on a broken concept I believe. What
> implications does re-enabling really have? Now you could reschedule and
> you can move to another CPU. Is this really safe? I believe that yes
> because the preemption disabling is simply bogus. Which doesn't sound
> like a proper justification, does it?

Well, thinking about it a bit more. What is the result of calling
preempt_enable outside of preempt_disabled section? E.g. __warn which
doesn't disable preemption AFAICS.
-- 
Michal Hocko
SUSE Labs


Re: [Intel-gfx] [PATCH v5 2/3] drm/i915: Move on the new pm runtime interface

2018-12-21 Thread Vincent Guittot
On Fri, 21 Dec 2018 at 12:33, Tvrtko Ursulin
 wrote:
>
>
> Hi,
>
> On 21/12/2018 10:33, Vincent Guittot wrote:
> > Use the new pm runtime interface to get the accounted suspended time:
> > pm_runtime_suspended_time().
> > This new interface helps to simplify and cleanup the code that computes
> > __I915_SAMPLE_RC6_ESTIMATED and to remove direct access to internals of
> > PM runtime.
> >
> > Reviewed-by: Ulf Hansson 
> > Signed-off-by: Vincent Guittot 
> > ---
> >   drivers/gpu/drm/i915/i915_pmu.c | 16 ++--
> >   drivers/gpu/drm/i915/i915_pmu.h |  4 ++--
> >   2 files changed, 8 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_pmu.c 
> > b/drivers/gpu/drm/i915/i915_pmu.c
> > index d6c8f8f..3f76f60 100644
> > --- a/drivers/gpu/drm/i915/i915_pmu.c
> > +++ b/drivers/gpu/drm/i915/i915_pmu.c
> > @@ -5,6 +5,7 @@
> >*/
> >
> >   #include 
> > +#include 
> >   #include "i915_pmu.h"
> >   #include "intel_ringbuffer.h"
> >   #include "i915_drv.h"
> > @@ -478,7 +479,6 @@ static u64 get_rc6(struct drm_i915_private *i915)
> >* counter value.
> >*/
> >   spin_lock_irqsave(>pmu.lock, flags);
> > - spin_lock(>power.lock);
> >
> >   /*
> >* After the above branch intel_runtime_pm_get_if_in_use 
> > failed
> > @@ -491,16 +491,13 @@ static u64 get_rc6(struct drm_i915_private *i915)
> >* suspended and if not we cannot do better than report the 
> > last
> >* known RC6 value.
> >*/
> > - if (kdev->power.runtime_status == RPM_SUSPENDED) {
> > - if 
> > (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
> > - i915->pmu.suspended_jiffies_last =
> > -   
> > kdev->power.suspended_jiffies;
> > + if (pm_runtime_status_suspended(kdev)) {
> > + val = pm_runtime_suspended_time(kdev);
>
> There is a race condition between the status check and timestamp access
> which the existing code solves by holding the power.lock over it. But I
> don't exactly remember how this issue was manifesting. Is
> kdev->power.suspended_jiffies perhaps reset on exit from runtime
> suspend, which was then underflowing the val, not sure.
>
> Anyways, is the new way of doing this safe with regards to this race? In

AFAICT it is safe.
The current version does:
1-take lock,
2-test if dev is suspended
3-read some internals field to computed an up-to-date suspended time
4-update __I915_SAMPLE_RC6_ESTIMATED
5-release lock

The new version does:
1-test if dev is suspended
2-get an up-to-date  suspended time with pm_runtime_suspended_time.
This is atomic and monotonic
3-update __I915_SAMPLE_RC6_ESTIMATED

A change from suspended to another states that happens just before
step 1 is ok for both as we will run the else if
No change of the state can happen after step 1 in current code and the
estimated suspended time will be the time up to step2. In parallel,
Any state change will have to wait step5 to continue
If a change from suspended to another state happens after step 1 in
new code, the suspended time return by PM core will be the time up to
this change. So I would say you don't delay state transition and you
get a more accurate estimated suspended time (even if the difference
should be small).
If a change from suspended to another state happens after step 2 in
new code, the suspended time return by PM core will be the time up to
step 2 so there is no changes


> other words is the value pm_runtime_suspended_time always monotonic,
> even when not suspended? If not we have to handle the race somehow.

Yes pm_runtime_suspended_time is monotonic and stays unchanged when
not suspended

>
> If it is always monotonic, then worst case we report one wrong sample,
> which I guess is still not ideal since someone could be querying the PMU
> with quite low frequency.
>
> There are tests which probably can hit this, but to run them
> automatically your patches would need to be rebased on drm-tip and maybe
> sent to our trybot. I can do that after the holiday break if you are
> okay with having the series waiting until then.

yes looks good to me

Thanks,
Vincent

>
> Regards,
>
> Tvrtko
>
> >
> > - val = kdev->power.suspended_jiffies -
> > -   i915->pmu.suspended_jiffies_last;
> > - val += jiffies - kdev->power.accounting_timestamp;
> > + if 
> > (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
> > + i915->pmu.suspended_time_last = val;
> >
> > - val = jiffies_to_nsecs(val);
> > + val -= i915->pmu.suspended_time_last;
> >   val += i915->pmu.sample[__I915_SAMPLE_RC6].cur;
> >
> >   i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = 
> > val;
> > @@ -510,7 +507,6 @@ static u64 

<    1   2   3   4   5   6   7   8   >