Re: [RFC PATCH] driver core: Stop driver bind on NOTIFY_BAD

[Greg KH]

On Mon, Jun 26, 2017 at 01:35:50PM -0600, Alex Williamson wrote:
> Allow participants in the BUS_NOTIFY_BIND_DRIVER to prevent driver
> binding with a NOTIFY_BAD.  An example case where this might be useful
> is when we're dealing with IOMMU groups and userspace drivers.  We've
> defined that devices within the same IOMMU group are not necessarily
> DMA isolated from one another and therefore allowing those devices to
> be split between host and user drivers may compromise the kernel.  The
> vfio driver currently handles this with a BUG_ON when such a condition
> occurs.  A better solution is to prevent the case from occurring,
> which this change enables.
> 
> Signed-off-by: Alex Williamson 
> Suggested-by: Russell King 
> ---
>  drivers/base/dd.c |8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> For due diligence, none of the current notifier blocks registered with
> bus_register_notifier() return anything other than { 0, NOTIFY_OK,
> NOTIFY_DONE } except for the case of BUS_NOTIFY_ADD_DEVICE, where
> NOTIFY_BAD is possible for NULL data in keystone_platform_notifier()
> and an errno return is possible from tce_iommu_bus_notifier() and
> i2cdev_notifier_call().  device_add() also ignores the call chain
> return value, so these three cases are all ineffective at preventing
> anything.
> 
> If this is acceptable, I'll re-spin https://lkml.org/lkml/2017/6/20/681
> dropping the last 3 patches, instead using the patch below, plumbing
> the IOMMU group notifier to percolate notifier block returns, and
> simply return NOTIFY_BAD from vfio rather than mucking with
> driver_override.  Thanks
> 
> Alex 
> 
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index 4882f06d12df..32c1d841e8d9 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -265,9 +265,11 @@ static int driver_sysfs_add(struct device *dev)
>  {
>   int ret;
>  
> - if (dev->bus)
> - blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
> -  BUS_NOTIFY_BIND_DRIVER, dev);
> + if (dev->bus) {
> + if (blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
> + BUS_NOTIFY_BIND_DRIVER, dev) == NOTIFY_BAD)
> + return -EINVAL;
> + }

Ick, this seems really hacky.  Right now we do not do anything on any of
the bus notifiers, so why start doing it now?

How is this ever being called anyway?  Your driver should have rejected
being bound to the device at all, much earlier in your probe function.

Or are you somehow trying to keep userspace from manually binding the
driver to the device?  If so, why not just disable that functionality
for it (there is a bit somewhere for that...)

thanks,

greg k-h

Re: mmotm 2017-06-23-15-03 uploaded

[Vlastimil Babka]

On 06/27/2017 08:45 AM, huang ying wrote:
> On Sat, Jun 24, 2017 at 6:04 AM,   wrote:
>> * mm-page_allocc-eliminate-unsigned-confusion-in-__rmqueue_fallback.patch
> 
> After git bisecting, find the above patch will cause the following bug
> on i386 with memory eater + swap.
> 
> [   10.657876] BUG: unable to handle kernel paging request at 001fe2b8
> [   10.658412] IP: set_pfnblock_flags_mask+0x50/0x80
> [   10.658779] *pde = 
> [   10.658779]
> [   10.659126] Oops:  [#1] SMP
> [   10.659372] CPU: 0 PID: 1403 Comm: usemem Not tainted 4.12.0-rc6-mm1+ #12
> [   10.659888] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS 1.10.2-1 04/01/2014
> [   10.660522] task: f54a4c40 task.stack: f54ee000
> [   10.660878] EIP: set_pfnblock_flags_mask+0x50/0x80
> [   10.661246] EFLAGS: 00010006 CPU: 0
> [   10.661517] EAX: 0007f8ae EBX:  ECX: 0009 EDX: 0200
> [   10.661994] ESI: 001fe2b8 EDI: 0e00 EBP: f54efd8c ESP: f54efd80
> [   10.662473]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> [   10.662891] CR0: 80050033 CR2: 001fe2b8 CR3: 356a3000 CR4: 0690
> [   10.663378] Call Trace:
> [   10.663577]  set_pageblock_migratetype+0x31/0x40
> [   10.663933]  __rmqueue+0x367/0x560
> [   10.664197]  get_page_from_freelist+0x5b7/0x8e0
> [   10.664546]  __alloc_pages_nodemask+0x31a/0x1000
> [   10.664913]  ? handle_mm_fault+0x1e8/0x840
> [   10.665230]  handle_mm_fault+0x71d/0x840
> [   10.665537]  __do_page_fault+0x175/0x400
> [   10.665848]  ? vmalloc_sync_all+0x190/0x190
> [   10.666173]  do_page_fault+0xb/0x10
> [   10.666446]  common_exception+0x64/0x6a
> [   10.666742] EIP: 0x8005e04c
> [   10.666959] EFLAGS: 00010246 CPU: 0
> [   10.667229] EAX: 07d47400 EBX: 80063000 ECX: bfc964d8 EDX: 67179000
> [   10.667705] ESI: 07d47400 EDI: 07d47400 EBP:  ESP: bfc962cc
> [   10.668180]  DS: 007b ES: 007b FS:  GS: 0033 SS: 007b
> [   10.668595]  ? vmalloc_sync_all+0x190/0x190
> [   10.668922] Code: 8b 5b 28 25 00 fc ff ff 29 c1 89 c8 b9 1f 00 00
> 00 2b 4d 08 c1 e8 0a c1 e0 02 89 c6 c1 e8 05 83 e6 1f 29 f1 8d 34 83
> d3 e7 d3 e2 <8b> 1e f7 d7 eb 0c 8d 76 00 8d bc 27 00 00 00 00 89 c3 89
> d9 89
> [   10.670369] EIP: set_pfnblock_flags_mask+0x50/0x80 SS:ESP: 0068:f54efd80
> [   10.670881] CR2: 001fe2b8
> [   10.671140] ---[ end trace f51518af57e6b531 ]---
> 
> I think this comes from the signed and unsigned int comparison on
> i386.  The gcc version is,

Yes, the unsigned vs signed comparison is wrong, and effectively the
same problem as the previous wrong attempt, which removed the order >= 0
condition. Thanks for the report.

However, the patch in mmotm seems to be missing this crucial hunk that
Rasmus had in the patch he sent [1]:

-__rmqueue_fallback(struct zone *zone, unsigned int order, int
start_migratetype)
+__rmqueue_fallback(struct zone *zone, int order, int start_migratetype)

which makes this a signed vs signed comparison.

What happened to it? Andrew?

[1] http://lkml.kernel.org/r/20170621185529.2265-1-li...@rasmusvillemoes.dk

> gcc (Debian 6.3.0-18) 6.3.0 20170516
> 
> Best Regards,
> Huang, Ying
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org 
> 

Re: [PATCHSET for-4.13] cgroup: implement cgroup2 thread mode, v2

[Peter Zijlstra]

I'm slowly getting back to things...

On Mon, Jun 12, 2017 at 05:27:53PM -0400, Tejun Heo wrote:

> > > * Root cgroup can enable thread mode anytime and a first level child
> > >   can opt-in to that thread subtree anchored at root by writing "join"
> > >   to "cgroup.threads" files, start its own thread subtree or just be a
> > >   normal cgroup.
> > 
> > Yuck... this again is a consequence of tagging the 'wrong' thing. Again,
> > the primary construct is the resource domain.
> > 
> > If you use that as a tag, you don't need this weird join crap. Because
> > as soon as you clear the 'resource domain' flag on a group, it instantly
> > becomes a thread group and 'obviously' connects to the first parent that
> > is a resource domain.
> 
> It has nothing to do with whether we mark domain or threaded subtrees.
> It is solely from whether you wanna express cases where a thread root
> is right below another thread root.  Tn's are member cgroup of thread
> subtrees where the same number means the same threaded subtree, D's
> are of domain cgroups.
> 
> The following is straight forward.
> 
> T0
>/  \
>   T0   D
> 
> The following is too.
> 
> T0
>/  \
>   T0   D
> \
>  T1
> 
> The question is whether to allow something like the following.
> 
> T0
>/  \
>   T0  T1
> 
> That's where the "join" thing comes from because we wanna be able to
> tell apart whether a cgroup is gonna be a part of the existing thread
> subtree or starting its own thread subtree.  There sure are multiple
> ways to express that but one way or the other, if you wanna support
> topologies like the last one, you have to distinguish the two.

Hmm,.. I had not considered that. I was strictly considering the root to
always be a resource domain. What use-case or scenario did you have
to want to do this?

That is, what is the meaning of having T1 be a separate 'root' if its
not also a resource domain?

> > And, as per the last time, this threaded marker isn't uniquely
> > identifying things, so it hard prohibits from ever extending the model
> > to allow resource domains nested in a thread subtree. Now I understand
> > why you don't implement that now -- you were struggling with the views
> > API, but that is no excuse to create an API that permanently disables
> > that feature.
> 
> Hmmm?  We can just allow disabling thread mode if we ever get to that.
> We can't make arbitrary graphs out of these nodes.  Whatever mode we
> put them in, they have to fall in with the overall tree structure, so
> I don't think the interface is unnecessarily restricting in that
> direction.

IIRC the problem with the 'threaded' marker is that it doesn't clearly
capture what a resource domain is.

That is, assuming that a thread root is always a resource domain, we get
the following problem:

If we set 'threaded' on the root group in order to create a thread
(sub)group. If we then want to create another domain group, we'd have to
clear 'threaded' on that.

R (t=1)
   / \
(t=1) T   D (t=0)

So far so good. However, now we want to create another thread group
under our domain group D, so we have to set its 'threaded' marker again:

R (t=1)
   / \
(t=1) T   D (t=1)
 /
T (t=1)

And we can no longer identify D as a resource domain. If OTOH we mark
'domain' we get:

R (d=1)
   / \
(d=0) T   D (d=1)
 /
T (d=0)

Which clearly identifies the domains and the thread only groups.


Your objections to doing this were representing the resource controllers
in the intermediate thread-only groups like:

   R
\
 T  -- what to do with eg. memcg here?
  \
   D
\
 T

I suggested having all resource controllers represented with a soft-link
back into the (thread-root) resource domain. But you were not convinced
and worried people were going to be confused.


Your current proposal treats the resource controllers as disabled in
thread subgroups -- which is perfectly fine given the constraint that we
cannot have new domains in a thread sub-tree. My worry is that we don't
paint ourselves in a corner and create an interface where we can never
extend to allow this.

The immediate use-case for wanting this would be allowing tasks in a
thread-group to start a VM or container (which would then want a
(sub) resource domain).


> > So I really regret the 'shares' interface; we really should have done a
> > nice thing.
> > 
> >   
> > https://lkml.kernel.org/r/20170410073622.2y6tnpcd2ssuo...@hirez.programming.kicks-ass.net
> > 
> > So I would like to change to that instead of the weird 100 thing.
> 
> Is it?  Relative weights are pretty fundamental and clearly defined in
> expressing work-conserving resource distribution.  Do you have more
> details on what you have on mind?

I'm not wanting to change the relative weight thing. I merely wish to
change the interface for setting the group weight to match that of the
task weig

Re: [PATCH 2/3] Turn bitmap_set and bitmap_clear into memset when possible

[Matthew Wilcox]

On Wed, Jun 07, 2017 at 11:16:37PM +0200, Rasmus Villemoes wrote:
> On Wed, Jun 07 2017, Matthew Wilcox  wrote:
> > @@ -319,6 +319,9 @@ static __always_inline void bitmap_set(unsigned long 
> > *map, unsigned int start,
> >  {
> > if (__builtin_constant_p(nbits) && nbits == 1)
> > __set_bit(start, map);
> > +   else if (__builtin_constant_p(start & 7) && IS_ALIGNED(start, 8) &&
> > +__builtin_constant_p(nbits & 7) && IS_ALIGNED(nbits, 8))
> > +   memset(map + start / 8, 0xff, nbits / 8);
> > else
> 
> Isn't the pointer arithmetic wrong here? I think you need to cast map to
> (char*).

Good catch.  I've added a test case to test_bitmap.c and it catches
the problem.

> Do you have an example of how the generated code changes, both in the
> case of actual constants and a case where gcc can see that start and
> nbits are byte-aligned without knowing their actual values?

Here's an example of start == 0 and nbits being clearly a multiple of 8,
courtesy of btrfs's extent-io-tests.c.

Before:
  f1:   48 8b 5c 24 10  mov0x10(%rsp),%rbx
  f6:   4c 8b 3c 24 mov(%rsp),%r15
  fa:   31 f6   xor%esi,%esi
  fc:   44 8d 34 dd 00 00 00lea0x0(,%rbx,8),%r14d
 103:   00 
 104:   4c 8d 2c dd 00 00 00lea0x0(,%rbx,8),%r13
 10b:   00 
 10c:   4c 89 ffmov%r15,%rdi
 10f:   44 89 f2mov%r14d,%edx
 112:   e8 00 00 00 00  callq  117 <__test_eb_bitmaps+0x77>
113: R_X86_64_PC32  bitmap_set-0x4
 117:   31 d2   xor%edx,%edx
 119:   31 f6   xor%esi,%esi
 11b:   4c 89 e9mov%r13,%rcx
 11e:   4c 89 e7mov%r12,%rdi
 121:   e8 00 00 00 00  callq  126 <__test_eb_bitmaps+0x86>
122: R_X86_64_PC32  extent_buffer_bitmap_set-0x4

After:
  f1:   4c 8b 7c 24 10  mov0x10(%rsp),%r15
  f6:   be ff 00 00 00  mov$0xff,%esi
  fb:   48 89 dfmov%rbx,%rdi
  fe:   4d 89 femov%r15,%r14
 101:   4e 8d 2c fd 00 00 00lea0x0(,%r15,8),%r13
 108:   00 
 109:   41 81 e6 ff ff ff 1fand$0x1fff,%r14d
 110:   4c 89 f2mov%r14,%rdx
 113:   e8 00 00 00 00  callq  118 <__test_eb_bitmaps+0x78>
114: R_X86_64_PC32  memset-0x4
 118:   48 8b 2c 24 mov(%rsp),%rbp
 11c:   31 d2   xor%edx,%edx
 11e:   31 f6   xor%esi,%esi
 120:   4c 89 e9mov%r13,%rcx
 123:   48 89 efmov%rbp,%rdi
 126:   e8 00 00 00 00  callq  12b <__test_eb_bitmaps+0x8b>
127: R_X86_64_PC32  extent_buffer_bitmap_set-0x4

It's actually slightly less efficient in the caller (although obviously
memset() is going to execute faster than bitmap_set()).  Partly because
x86 made some odd choices about the behaviour of an 8-bit move instruction
(it leaves the upper 24 bits intact, rather than zeroing them, so gcc
has to use a 32-bit move instruction to put 0xff into the second argument
to memset()), and partly because gcc is seeing us do:

unsigned long len;
len = len * 8 / 8;

so it's (very reasonably) transforming that into len &= 0x1fff''';
That's partly a quirk of how this particular function is written.

Re: mmotm 2017-06-23-15-03 uploaded

[Vlastimil Babka]

[+CC Rasmus, sorry]

On 06/27/2017 09:01 AM, Vlastimil Babka wrote:
> On 06/27/2017 08:45 AM, huang ying wrote:
>> On Sat, Jun 24, 2017 at 6:04 AM,   wrote:
>>> * mm-page_allocc-eliminate-unsigned-confusion-in-__rmqueue_fallback.patch
>>
>> After git bisecting, find the above patch will cause the following bug
>> on i386 with memory eater + swap.
>>
>> [   10.657876] BUG: unable to handle kernel paging request at 001fe2b8
>> [   10.658412] IP: set_pfnblock_flags_mask+0x50/0x80
>> [   10.658779] *pde = 
>> [   10.658779]
>> [   10.659126] Oops:  [#1] SMP
>> [   10.659372] CPU: 0 PID: 1403 Comm: usemem Not tainted 4.12.0-rc6-mm1+ #12
>> [   10.659888] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
>> BIOS 1.10.2-1 04/01/2014
>> [   10.660522] task: f54a4c40 task.stack: f54ee000
>> [   10.660878] EIP: set_pfnblock_flags_mask+0x50/0x80
>> [   10.661246] EFLAGS: 00010006 CPU: 0
>> [   10.661517] EAX: 0007f8ae EBX:  ECX: 0009 EDX: 0200
>> [   10.661994] ESI: 001fe2b8 EDI: 0e00 EBP: f54efd8c ESP: f54efd80
>> [   10.662473]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
>> [   10.662891] CR0: 80050033 CR2: 001fe2b8 CR3: 356a3000 CR4: 0690
>> [   10.663378] Call Trace:
>> [   10.663577]  set_pageblock_migratetype+0x31/0x40
>> [   10.663933]  __rmqueue+0x367/0x560
>> [   10.664197]  get_page_from_freelist+0x5b7/0x8e0
>> [   10.664546]  __alloc_pages_nodemask+0x31a/0x1000
>> [   10.664913]  ? handle_mm_fault+0x1e8/0x840
>> [   10.665230]  handle_mm_fault+0x71d/0x840
>> [   10.665537]  __do_page_fault+0x175/0x400
>> [   10.665848]  ? vmalloc_sync_all+0x190/0x190
>> [   10.666173]  do_page_fault+0xb/0x10
>> [   10.666446]  common_exception+0x64/0x6a
>> [   10.666742] EIP: 0x8005e04c
>> [   10.666959] EFLAGS: 00010246 CPU: 0
>> [   10.667229] EAX: 07d47400 EBX: 80063000 ECX: bfc964d8 EDX: 67179000
>> [   10.667705] ESI: 07d47400 EDI: 07d47400 EBP:  ESP: bfc962cc
>> [   10.668180]  DS: 007b ES: 007b FS:  GS: 0033 SS: 007b
>> [   10.668595]  ? vmalloc_sync_all+0x190/0x190
>> [   10.668922] Code: 8b 5b 28 25 00 fc ff ff 29 c1 89 c8 b9 1f 00 00
>> 00 2b 4d 08 c1 e8 0a c1 e0 02 89 c6 c1 e8 05 83 e6 1f 29 f1 8d 34 83
>> d3 e7 d3 e2 <8b> 1e f7 d7 eb 0c 8d 76 00 8d bc 27 00 00 00 00 89 c3 89
>> d9 89
>> [   10.670369] EIP: set_pfnblock_flags_mask+0x50/0x80 SS:ESP: 0068:f54efd80
>> [   10.670881] CR2: 001fe2b8
>> [   10.671140] ---[ end trace f51518af57e6b531 ]---
>>
>> I think this comes from the signed and unsigned int comparison on
>> i386.  The gcc version is,
> 
> Yes, the unsigned vs signed comparison is wrong, and effectively the
> same problem as the previous wrong attempt, which removed the order >= 0
> condition. Thanks for the report.
> 
> However, the patch in mmotm seems to be missing this crucial hunk that
> Rasmus had in the patch he sent [1]:
> 
> -__rmqueue_fallback(struct zone *zone, unsigned int order, int
> start_migratetype)
> +__rmqueue_fallback(struct zone *zone, int order, int start_migratetype)
> 
> which makes this a signed vs signed comparison.
> 
> What happened to it? Andrew?
> 
> [1] http://lkml.kernel.org/r/20170621185529.2265-1-li...@rasmusvillemoes.dk
> 
>> gcc (Debian 6.3.0-18) 6.3.0 20170516
>>
>> Best Regards,
>> Huang, Ying
>>
>> --
>> To unsubscribe, send a message with 'unsubscribe linux-mm' in
>> the body to majord...@kvack.org.  For more info on Linux MM,
>> see: http://www.linux-mm.org/ .
>> Don't email: mailto:"d...@kvack.org";> em...@kvack.org 
>>
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org 
> 

Re: [PATCH] ib_isert: prevent NULL pointer dereference in isert_login_recv_done()

[Sagi Grimberg]

Hi Andrea & Robert,


Hi Andrea, Robert, Nic and Co


We have hit this four times today. Any ideas?

[  169.382113] BUG: unable to handle kernel NULL pointer dereference at 
  (null)
[  169.382152] IP: [] isert_login_recv_done+0x28/0x170 
[ib_isert]


So, we spent more time to track down this bug.

It seems that at login time an error is happening, not sure exactly what
kind of error, but isert_connect_error() is called and isert_conn->cm_id
is set to NULL.

Later, isert_login_recv_done() is trying to access
isert_conn->cm_id->device and we get the NULL pointer dereference.

Following there's the patch that we have applied to track down this
problem.

And this is what we see in dmesg with this patch applied:

  [  658.633188] isert: isert_connect_error: conn 887f2209c000 error
  [  658.633226] isert: isert_login_recv_done: login with broken rdma_cm_id

As we can see isert_connect_error() is called before isert_login_recv_done
and at that point isert_conn->cm_id is NULL.

Obviously simply checking if the pointer is NULL, returning and ignoring
the error in isert_login_recv_done() is not the best fix ever and I'm
not sure if I'm breaking something else doing so (even if with this
patch the kernel doesn't crash and I've not seen any problem so far).

Maybe a better way is to tear down the whole connection when this
particular case is happening? Suggestions?


That is an accurate analysis of what is going on, good job!


So I assume isert_cma_handler() -> isert_connect_error() getting called
to clear isert_conn->cm_id before connection established, and
subsequently isert_conn->login_req_buf->rx_cqe.done() ->
isert_login_recv_done() still getting invoked after connection failure
is new RDMA API behavior..


That is correct, but its not really a new behavior, and absolutely
not introduced by the new RDMA API. We will _always_ see the
completion of _all_ recv wrs posted on the qp (given that we assigned
a ->done handler), this is a FLUSH error completion, we just don't
get to verify that because we deref NULL before.

The issue here, as you indicated was the assumption that dereferencing
the connection cm_id is always safe, which is not true since:

commit 4a579da2586bd3b79b025947ea24ede2bbfede62
Author: Sagi Grimberg 
Date:   Sun Mar 29 15:52:04 2015 +0300

iser-target: Fix possible deadlock in RDMA_CM connection error

Before we reach to connection established we may get an
error event. In this case the core won't teardown this
connection (never established it), so we take care of freeing
it ourselves.

Signed-off-by: Sagi Grimberg 
Cc:  # v3.10+
Signed-off-by: Nicholas Bellinger 

As I see it, we have a direct reference to the isert_device from
isert_conn which is the one-liner fix that we actually need (like
we do in isert_rdma_read_done, isert_rdma_write_done),  guess we
also need it in isert_login_send_done, isert_send_done (although
it can't really happen, but better safe and consistent than sorry).


@@ -1452,7 +1452,7 @@
  isert_login_recv_done(struct ib_cq *cq, struct ib_wc *wc)
  {
struct isert_conn *isert_conn = wc->qp->qp_context;
-   struct ib_device *ib_dev = isert_conn->cm_id->device;
+   struct ib_device *ib_dev = isert_conn->device->ib_device;
  
  	if (unlikely(wc->status != IB_WC_SUCCESS)) {

isert_print_wc(wc, "login recv");


That's the one...

Re: [PATCH] kref: Avoid null pointer dereference after WARN

[Greg Kroah-Hartman]

On Mon, Jun 26, 2017 at 08:52:15PM -0700, Kees Cook wrote:
> From: Daniel Micay 
> 
> The WARN_ON() checking for a NULL release pointer should be a BUG()
> since continuing with a NULL release pointer will lead to a NULL
> pointer dereference anyway.
> 
> The kref_put() case is extracted from PaX, and Kees Cook noted it should
> be extended to the other two cases.
> 
> Signed-off-by: Daniel Micay 
> [kees: clarify commit log]
> Signed-off-by: Kees Cook 
> ---
>  include/linux/kref.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/kref.h b/include/linux/kref.h
> index f4156f88f557..82a2c225eae3 100644
> --- a/include/linux/kref.h
> +++ b/include/linux/kref.h
> @@ -66,7 +66,7 @@ static inline void kref_get(struct kref *kref)
>   */
>  static inline int kref_put(struct kref *kref, void (*release)(struct kref 
> *kref))
>  {
> - WARN_ON(release == NULL);
> + BUG_ON(release == NULL);

I remember one complaint was that WARN_ON was "huge" and this bloated
the kernel code a lot.  But then that got fixed up.  Is BUG_ON going to
cause the same complaint again?

thanks,

greg k-h

Re: [RFC PATCH] userfaultfd: Add feature to request for a signal delivery

[Michal Hocko]

This is an user visible API so let's CC linux-api mailing list.

On Mon 26-06-17 12:46:13, Prakash Sangappa wrote:
> In some cases, userfaultfd mechanism should just deliver a SIGBUS signal
> to the faulting process, instead of the page-fault event. Dealing with
> page-fault event using a monitor thread can be an overhead in these
> cases. For example applications like the database could use the signaling
> mechanism for robustness purpose.

this is rather confusing. What is the reason that the monitor would be
slower than signal delivery and handling?

> Database uses hugetlbfs for performance reason. Files on hugetlbfs
> filesystem are created and huge pages allocated using fallocate() API.
> Pages are deallocated/freed using fallocate() hole punching support.
> These files are mmapped and accessed by many processes as shared memory.
> The database keeps track of which offsets in the hugetlbfs file have
> pages allocated.
> 
> Any access to mapped address over holes in the file, which can occur due
> to bugs in the application, is considered invalid and expect the process
> to simply receive a SIGBUS.  However, currently when a hole in the file is
> accessed via the mapped address, kernel/mm attempts to automatically
> allocate a page at page fault time, resulting in implicitly filling the
> hole in the file. This may not be the desired behavior for applications
> like the database that want to explicitly manage page allocations of
> hugetlbfs files.

So you register UFFD_FEATURE_SIGBUS on each region tha you are unmapping
and than just let those offenders die?

> Using userfaultfd mechanism, with this support to get a signal, database
> application can prevent pages from being allocated implicitly when
> processes access mapped address over holes in the file.
> 
> This patch adds the feature to request for a SIGBUS signal to userfaultfd
> mechanism.
> 
> See following for previous discussion about the database requirement
> leading to this proposal as suggested by Andrea.
> 
> http://www.spinics.net/lists/linux-mm/msg129224.html

Please make those requirements part of the changelog.

> Signed-off-by: Prakash 
> ---
>  fs/userfaultfd.c |  5 +
>  include/uapi/linux/userfaultfd.h | 10 +-
>  2 files changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
> index 1d622f2..5686d6d2 100644
> --- a/fs/userfaultfd.c
> +++ b/fs/userfaultfd.c
> @@ -371,6 +371,11 @@ int handle_userfault(struct vm_fault *vmf, unsigned
> long reason)
>  VM_BUG_ON(reason & ~(VM_UFFD_MISSING|VM_UFFD_WP));
>  VM_BUG_ON(!(reason & VM_UFFD_MISSING) ^ !!(reason & VM_UFFD_WP));
> 
> +if (ctx->features & UFFD_FEATURE_SIGBUS) {
> +goto out;
> +}
> +
>  /*
>   * If it's already released don't get it. This avoids to loop
>   * in __get_user_pages if userfaultfd_release waits on the
> diff --git a/include/uapi/linux/userfaultfd.h
> b/include/uapi/linux/userfaultfd.h
> index 3b05953..d39d5db 100644
> --- a/include/uapi/linux/userfaultfd.h
> +++ b/include/uapi/linux/userfaultfd.h
> @@ -23,7 +23,8 @@
> UFFD_FEATURE_EVENT_REMOVE |\
> UFFD_FEATURE_EVENT_UNMAP |\
> UFFD_FEATURE_MISSING_HUGETLBFS |\
> -   UFFD_FEATURE_MISSING_SHMEM)
> +   UFFD_FEATURE_MISSING_SHMEM |\
> +   UFFD_FEATURE_SIGBUS)
>  #define UFFD_API_IOCTLS\
>  ((__u64)1 << _UFFDIO_REGISTER |\
>   (__u64)1 << _UFFDIO_UNREGISTER |\
> @@ -153,6 +154,12 @@ struct uffdio_api {
>   * UFFD_FEATURE_MISSING_SHMEM works the same as
>   * UFFD_FEATURE_MISSING_HUGETLBFS, but it applies to shmem
>   * (i.e. tmpfs and other shmem based APIs).
> + *
> + * UFFD_FEATURE_SIGBUS feature means no page-fault
> + * (UFFD_EVENT_PAGEFAULT) event will be delivered, instead
> + * a SIGBUS signal will be sent to the faulting process.
> + * The application process can enable this behavior by adding
> + * it to uffdio_api.features.
>   */
>  #define UFFD_FEATURE_PAGEFAULT_FLAG_WP(1<<0)
>  #define UFFD_FEATURE_EVENT_FORK(1<<1)
> @@ -161,6 +168,7 @@ struct uffdio_api {
>  #define UFFD_FEATURE_MISSING_HUGETLBFS(1<<4)
>  #define UFFD_FEATURE_MISSING_SHMEM(1<<5)
>  #define UFFD_FEATURE_EVENT_UNMAP(1<<6)
> +#define UFFD_FEATURE_SIGBUS(1<<7)
>  __u64 features;
> 
>  __u64 ioctls;
> -- 
> 2.7.4
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org 

-- 
Michal Hocko
SUSE Labs

Re: [PATCH for 4.12] Revert "pinctrl: rockchip: avoid hardirq-unsafe functions in irq_chip"

[Brian Norris]

On Mon, Jun 26, 2017 at 11:24:09PM -0700, Tony Lindgren wrote:
> Hmm so how come drivers/bluetooth/btusb.c can't use the generic
> dev_pm_set_dedicated_wake_irq()? Can you please take a look?

I took a look previously, and last time I did, there were too many bugs
for it to be useful. You may have fixed the ones I reported w.r.t.
assumptions about runtime PM.

I also recall there being some difficulty with supporting
level-triggered interrupts that way. (This signal has no device-level
mask, and it triggers for all sorts of BT activity. There may not be a
relevant "edge".)

> If there are issues remaining let's rather fix them so we can get rid
> of the custom tinkering of wake-up events in the drivers.

That's nice, but that doesn't answer my questions. Perhaps that's a side
project. The point is that we're clearly violating the documented APIs.

Brian

Re: next-20170620 BUG in do_page_fault / do_huge_pmd_wp_page

[Vlastimil Babka]

+CC Kirill, those 512 numbers smell like THP related.

On 06/23/2017 07:48 AM, Naresh Kamboju wrote:
> Hi Valdis,
> 
> On 23 June 2017 at 08:56,   wrote:
>> Saw this at boot of next-20170620.  Not sure how I managed to hit 4 BUG in a 
>> row...
>>
>> Looked in 'git log -- mm/' but not seeing anything blatantly obvious.
>>
>> This ringing any bells?  I'm not in a position to recreate or bisect this 
>> until
>> the weekend.
>>
>> [  315.409076] BUG: Bad rss-counter state mm:8a223deb4640 idx:0 val:-512
>> [  315.412889] BUG: Bad rss-counter state mm:8a223deb4640 idx:1 val:512
>> [  315.416694] BUG: non-zero nr_ptes on freeing mm: 1
>> [  315.436098] BUG: Bad page state in process gdm  pfn:3e8400
>> [  315.439802] page:e8af0fa1 count:-1 mapcount:0 mapping:  
>> (null) index:0x1
>> [  315.443264] flags: 0x4000()
>> [  315.446715] raw: 4000  0001 
>> 
>> [  315.450181] raw: dead0100 dead0200  
>> 
>> [  315.453628] page dumped because: nonzero _count
>> [  315.457023] Modules linked in: ts_bm nf_log_ipv4 xt_string nf_log_ipv6 
>> nf_log_common xt_LOG sunrpc vfat fat brcmsmac cordic brcmutil dell
>> _wmi x86_pkg_temp_thermal crct10dif_pclmul dell_laptop crc32_pclmul 
>> crc32c_intel dell_smbios ghash_clmulni_intel dell_smm_hwmon cryptd bcma
>> mei_wdt dell_smo8800 dell_rbtn sch_fq tcp_bbr
>> [  315.457116] CPU: 3 PID: 6684 Comm: gdm Not tainted 
>> 4.12.0-rc6-next-20170620 #506
>> [  315.457119] Hardware name: Dell Inc. Latitude E6530/07Y85M, BIOS A19 
>> 01/04/2017
>> [  315.457122] Call Trace:
>> [  315.457131]  dump_stack+0x83/0xd1
>> [  315.457141]  bad_page+0x10c/0x1b0
>> [  315.457151]  check_new_page_bad+0x12e/0x180
>> [  315.457159]  get_page_from_freelist+0x756/0x1840
>> [  315.457170]  ? native_sched_clock+0x80/0xf0
>> [  315.457184]  ? find_held_lock+0x38/0x160
>> [  315.457194]  __alloc_pages_nodemask+0x145/0x5a0
>> [  315.457211]  do_huge_pmd_wp_page+0x58d/0x1380
>> [  315.457217]  ? cyc2ns_read_begin+0x82/0xb0
>> [  315.457224]  ? cyc2ns_read_end+0x22/0x40
>> [  315.457229]  ? native_sched_clock+0x80/0xf0
>> [  315.457236]  ? native_sched_clock+0x80/0xf0
>> [  315.457247]  __handle_mm_fault+0x831/0x14e0
>> [  315.457253]  ? sched_clock_cpu+0x1b/0x1e0
>> [  315.457273]  handle_mm_fault+0x23c/0x6f0
>> [  315.457283]  __do_page_fault+0x460/0x950
>> [  315.457298]  do_page_fault+0xc/0x10
>> [  315.457305]  page_fault+0x22/0x30
>> [  315.457310] RIP: 0033:0x7fe15390e5c1
>> [  315.457314] RSP: 002b:7ffd2acdca30 EFLAGS: 00010202
>> [  315.457320] RAX:  RBX: 7ffd2acdca50 RCX: 
>> 
>> [  315.457324] RDX: 00801000 RSI: 7fe14bfff9c0 RDI: 
>> 7fe14b7fec10
>> [  315.457328] RBP: 7ffd2acdcac0 R08: 7fe14b7fed10 R09: 
>> 7fe153b22030
>> [  315.457331] R10: 7fe155346900 R11: 0202 R12: 
>> 
>> [  315.457335] R13:  R14: 0001 R15: 
>> 7fe155413000
>> [  315.457354] Disabling lock debugging due to kernel taint
>>
>>
>>
> 
> 
> This bug occurred on HiKey (arm64) while booting.
> Here is the boot log,
> 
> Linux version:
> ---
> Linux version 4.12.0-rc6-next-20170622 (buildslave@x86-64-08) (gcc
> version 6.2.1 20161016 (Linaro GCC 6.2-2016.11)) #1 SMP PREEMPT Thu
> Jun 22 15:54:05 UTC 2017
> 
> Error log:
> -
> [8.759348] BUG: Bad page state in process dockerd  pfn:6f800
> [8.765806] page:7e0001be count:-1 mapcount:0 mapping:
> (null) index:0x1
> [8.774115] flags: 0xfffc000()
> [8.777970] raw: 0fffc000  0001
> 
> [8.785915] raw: dead0100 dead0200 
> 
> [8.793857] page dumped because: nonzero _count
> [8.798506] Modules linked in: asix usbnet adv7511 dw_drm_dsi
> kirin_drm drm_kms_helper drm fuse
> [8.812369] CPU: 6 PID: 2419 Comm: dockerd Not tainted
> 4.12.0-rc6-next-20170622 #1
> [8.825053] Hardware name: HiKey Development Board (DT)
> [8.835330] Call trace:
> [8.842735] [] dump_backtrace+0x0/0x230
> [8.853141] [] show_stack+0x14/0x20
> [8.863121] [] dump_stack+0xb8/0xf0
> [8.873018] [] bad_page+0xe4/0x148
> [8.882766] [] check_new_page_bad+0x64/0xa0
> [8.893262] [] get_page_from_freelist+0xab4/0xca0
> [8.904251] [] __alloc_pages_nodemask+0x10c/0x1328
> [8.915273] [] alloc_pages_current+0x80/0xe8
> [8.925737] [] __page_cache_alloc+0xf8/0x128
> [8.936138] [] __do_page_cache_readahead+0x128/0x340
> [8.947212] [] filemap_fault+0x328/0x6c8
> [8.957166] [] ext4_filemap_fault+0x30/0x50
> [8.967394] [] __do_fault+0x20/0x88
> [8.976907] [] __handle_mm_fault+0x97c/0x10d0
> [8.987311] [] handle_mm_fault+0x1a8/0x338
> [8.997385] [] do_page_fault+0x2c0/0x3d0
> [9.007222] [] do_mem_abort+0x40/0x98
> [9.016720]

Re: [GIT PULL 0/1] perf/urgent fix

[Ingo Molnar]

* Arnaldo Carvalho de Melo  wrote:

> Hi Ingo,
> 
>   Please consider pulling,
> 
> - Arnaldo
> 
> Test results at the end of this message, as usual.
> 
> The following changes since commit 977282ed17a0213c84d59498a1e3f7088e211470:
> 
>   Merge tag 'perf-urgent-for-mingo-4.12-20170622' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent 
> (2017-06-23 10:03:27 +0200)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
> tags/perf-urgent-for-mingo-4.12-20170626
> 
> for you to fetch changes up to 3f938ee2f6c4fff8d95b24636a0964b5a93cf547:
> 
>   perf machine: Fix segfault for kernel.kptr_restrict=2 (2017-06-26 11:52:37 
> -0300)
> 
> 
> perf/urgent fix:
> 
> - Fix segfault for kernel.kptr_restrict=2 (Jiri Olsa)
> 
> Signed-off-by: Arnaldo Carvalho de Melo 
> 
> 
> Jiri Olsa (1):
>   perf machine: Fix segfault for kernel.kptr_restrict=2
> 
>  tools/perf/util/machine.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)

Pulled, thanks a lot Arnaldo!

Ingo

Re: linux-next: BUG: Bad page state in process ip6tables-save pfn:1499f4

[Vlastimil Babka]

On 06/24/2017 05:08 PM, Andrei Vagin wrote:
> On Fri, Jun 23, 2017 at 05:17:44PM -0700, Andrei Vagin wrote:
>> On Thu, Jun 22, 2017 at 11:21:03PM -0700, Andrei Vagin wrote:
>>> Hello,
>>>
>>> We run CRIU tests for linux-next and today they triggered a kernel
>>> bug. I want to mention that this kernel is built with kasan. This bug
>>> was triggered in travis-ci. I can't reproduce it on my host. Without
>>> kasan, kernel crashed but it is impossible to get a kernel log for
>>> this case.
>>
>> We use this tree
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/
>>
>> This issue isn't reproduced on the akpm-base branch and
>> it is reproduced each time on the akpm branch. I didn't
>> have time today to bisect it, will do on Monday.
> 
> c3aab7b2d4e8434d53bc81770442c14ccf0794a8 is the first bad commit
> 
> commit c3aab7b2d4e8434d53bc81770442c14ccf0794a8
> Merge: 849c34f 93a7379
> Author: Stephen Rothwell
> Date:   Fri Jun 23 16:40:07 2017 +1000
> 
> Merge branch 'akpm-current/current'

Hm is it really the merge of mmotm itself and not one of the patches in
mmotm?
Anyway smells like THP, adding Kirill.

>>
>> The problem is reproduced on the kernel without kasan too: 
>> https://goo.gl/Dxsv4R
>>
>> [  337.289845] BUG: Bad page state in process criu  pfn:19c601
>> [  337.295726] page:df4cc6718040 count:0 mapcount:1 
>> mapping:dead index:0x2ab1a9801 compound_mapcount: 1
>> [  337.306595] flags: 0x17fff80()
>> [  337.312251] raw: 017fff80 dead  
>> 
>> [  337.321756] raw: df4cc6718001 00090003  
>> 
>> [  337.335768] page dumped because: nonzero compound_mapcount
>> [  337.342082] Modules linked in:
>> [  337.342089] CPU: 1 PID: 22242 Comm: criu Not tainted 
>> 4.12.0-rc6-next-20170623 #1
>> [  337.342091] Hardware name: Google Google Compute Engine/Google Compute 
>> Engine, BIOS Google 01/01/2011
>> [  337.342094] Call Trace:
>> [  337.342106]  dump_stack+0x85/0xc7
>> [  337.342113]  bad_page+0xc1/0x120
>> [  337.342119]  __free_pages_ok+0x3ab/0x570
>> [  337.342127]  free_compound_page+0x1b/0x20
>> [  337.342132]  free_transhuge_page+0xa4/0xb0
>> [  337.342138]  __put_compound_page+0x30/0x50
>> [  337.342143]  __put_page+0x2c/0x150
>> [  337.342148]  page_cache_pipe_buf_release+0x3a/0x60
>> [  337.342151]  iter_file_splice_write+0x2fc/0x3d0
>> [  337.342169]  SyS_splice+0x331/0x810
>> [  337.342174]  ? trace_hardirqs_on_caller+0x11f/0x190
>> [  337.342186]  entry_SYSCALL_64_fastpath+0x23/0xc2
>> [  337.342190] RIP: 0033:0x2b94bad9d9a3
>> [  337.342192] RSP: 002b:7ffdfac31d98 EFLAGS: 0246 ORIG_RAX: 
>> 0113
>> [  337.342196] RAX: ffda RBX:  RCX: 
>> 2b94bad9d9a3
>> [  337.342198] RDX: 000c RSI:  RDI: 
>> 0015
>> [  337.342200] RBP: 7ffdfac31970 R08: 0020 R09: 
>> 0001
>> [  337.342202] R10:  R11: 0246 R12: 
>> 
>> [  337.342204] R13: 0001 R14: 0001 R15: 
>> 
>> [  337.342241] Disabling lock debugging due to kernel taint
>> [  337.342253] page:df4cc671ff40 count:0 mapcount:0 mapping:  
>> (null) index:0x0
>> [  337.352360] flags: 0x17fff80()
>> [  337.357600] raw: 017fff80   
>> 
>> [  337.366628] raw:  df4cc671ff60  
>> 
>> [  337.375506] page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) == 0)
>> [  337.390656] [ cut here ]
>> [  337.390658] kernel BUG at ./include/linux/mm.h:466!
>> [  337.406508] invalid opcode:  [#1] SMP
>> [  337.410958] Modules linked in:
>> [  337.414135] CPU: 1 PID: 22242 Comm: criu Tainted: GB   
>> 4.12.0-rc6-next-20170623 #1
>> [  337.424254] Hardware name: Google Google Compute Engine/Google Compute 
>> Engine, BIOS Google 01/01/2011
>> [  337.433596] task: 88f233f230c0 task.stack: af8f01d3
>> [  337.441023] RIP: 0010:page_cache_pipe_buf_release+0x50/0x60
>> [  337.446712] RSP: 0018:af8f01d33de8 EFLAGS: 00010246
>> [  337.453440] RAX: 003e RBX:  RCX: 
>> 
>> [  337.460716] RDX: 88f29fd152c0 RSI:  RDI: 
>> 88f29fd0cfd8
>> [  337.469356] RBP: af8f01d33df0 R08: 0001 R09: 
>> 
>> [  337.476613] R10:  R11: 8e11138a R12: 
>> 88f2286fcfd8
>> [  337.485277] R13: 88f29183c448 R14: 1000 R15: 
>> 000fe000
>> [  337.492540] FS:  2b94ba04f040() GS:88f29fd0() 
>> knlGS:
>> [  337.502144] CS:  0010 DS:  ES:  CR0: 80050033
>> [  337.508019] CR2: 7f9e8e153024 CR3: 0001c7e8f000 CR4: 
>> 001406e0
>> [  337.516665] Call Trace:
>> [  337.519243]  iter_file_sp

Re: [Nouveau] [PATCH v2 00/14] improve the fb_setcmap helper

[Daniel Vetter]

On Tue, Jun 27, 2017 at 05:50:38AM +1000, Dave Airlie wrote:
> >
> > I'm traveling and cannot make progress this week. The merge window is
> > also real close so this series will therefore probably miss it unless
> > something unexpected happens...
> 
> Don't worry you missed the merge window for drm already, we don't merge
> things after -rc6. Please remember the Linus merge window is for maintainers
> to merge stuff to Linus, things need to be ready long before it, and for drm
> you shouldn't really tie yourself to the merge cycle.

Yeah, drm-misc is open for refactorings like this all the time, and
maintainers make sure the code will get into upstream asap, without
interferring with the upstream merge window schedules. Like Dave said,
don't worry.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[tip:x86/urgent] x86/mm/hotplug: Fix BUG_ON() after hot-remove by not freeing PUD

[tip-bot for Jérôme Glisse]

Commit-ID:  98fe3633c5a44e5ee3d642907739eb0210407886
Gitweb: http://git.kernel.org/tip/98fe3633c5a44e5ee3d642907739eb0210407886
Author: Jérôme Glisse 
AuthorDate: Sat, 24 Jun 2017 14:05:14 -0400
Committer:  Ingo Molnar 
CommitDate: Mon, 26 Jun 2017 11:44:19 +0200

x86/mm/hotplug: Fix BUG_ON() after hot-remove by not freeing PUD

Since commit:

  af2cf278ef4f ("x86/mm/hotplug: Don't remove PGD entries in 
remove_pagetable()")

we no longer free PUDs so that we do not have to synchronize
all PGDs on hot-remove/vfree().

But the new 5-level page table patchset reverted that for 4-level
page tables, in the following commit:

  f2a6a7050109: ("x86: Convert the rest of the code to support p4d_t")

This patch restores the damage and disables free_pud() if we are in the
4-level page table case, thus avoiding BUG_ON() after hot-remove.

Signed-off-by: Jérôme Glisse 
[ Clarified the changelog and the code comments. ]
Reviewed-by: Kirill A. Shutemov 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Linus Torvalds 
Cc: Logan Gunthorpe 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux...@kvack.org
Link: http://lkml.kernel.org/r/20170624180514.3821-1-jgli...@redhat.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/mm/init_64.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 95651dc..0a59daf 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -990,7 +990,13 @@ remove_p4d_table(p4d_t *p4d_start, unsigned long addr, 
unsigned long end,
 
pud_base = pud_offset(p4d, 0);
remove_pud_table(pud_base, addr, next, direct);
-   free_pud_table(pud_base, p4d);
+   /*
+* For 4-level page tables we do not want to free PUDs, but in 
the
+* 5-level case we should free them. This code will have to 
change
+* to adapt for boot-time switching between 4 and 5 level page 
tables.
+*/
+   if (CONFIG_PGTABLE_LEVELS == 5)
+   free_pud_table(pud_base, p4d);
}
 
if (direct)

[tip:perf/urgent] perf machine: Fix segfault for kernel.kptr_restrict=2

[tip-bot for Jiri Olsa]

Commit-ID:  3f938ee2f6c4fff8d95b24636a0964b5a93cf547
Gitweb: http://git.kernel.org/tip/3f938ee2f6c4fff8d95b24636a0964b5a93cf547
Author: Jiri Olsa 
AuthorDate: Mon, 26 Jun 2017 11:51:53 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 26 Jun 2017 11:52:37 -0300

perf machine: Fix segfault for kernel.kptr_restrict=2

Michael reported the segfault when kernel.kptr_restrict=2 is set.

  $ perf record ls
  ...
  perf: Segmentation fault
  Obtained 16 stack frames.
  ./perf(dump_stack+0x2d) [0x5068df]
  ./perf(sighandler_dump_stack+0x2d) [0x5069bf]
  ./perf() [0x43e47b]
  /lib64/libc.so.6(+0x3594f) [0x7f762004794f]
  /lib64/libc.so.6(strlen+0x26) [0x7f762009ef86]
  /lib64/libc.so.6(__strdup+0xd) [0x7f762009ecbd]
  ./perf(maps__set_kallsyms_ref_reloc_sym+0x4d) [0x51590f]
  ./perf(machine__create_kernel_maps+0x136) [0x50a7de]
  ./perf(perf_session__create_kernel_maps+0x2c) [0x510a81]
  ./perf(perf_session__new+0x13d) [0x510e23]
  ./perf() [0x43fd61]
  ./perf(cmd_record+0x704) [0x441823]
  ./perf() [0x4bc1a0]
  ./perf() [0x4bc40d]
  ./perf() [0x4bc55f]
  ./perf(main+0x2d5) [0x4bc939]
  Segmentation fault (core dumped)

The reason is that with kernel.kptr_restrict=2, we don't get
the symbol from machine__get_running_kernel_start, which we
want to use in maps__set_kallsyms_ref_reloc_sym and we crash.

Check the symbol name value before calling
maps__set_kallsyms_ref_reloc_sym() and succeed without ref_reloc_sym
being set. It's safe because we check its existence before we use it.

Reported-by: Michael Petlan 
Signed-off-by: Jiri Olsa 
Tested-by: Arnaldo Carvalho de Melo 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20170626095153.553-1-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/machine.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index d7f31cb..5de2b86 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -1209,10 +1209,12 @@ int machine__create_kernel_maps(struct machine *machine)
 */
map_groups__fixup_end(&machine->kmaps);
 
-   if (machine__get_running_kernel_start(machine, &name, &addr)) {
-   } else if (maps__set_kallsyms_ref_reloc_sym(machine->vmlinux_maps, 
name, addr)) {
-   machine__destroy_kernel_maps(machine);
-   return -1;
+   if (!machine__get_running_kernel_start(machine, &name, &addr)) {
+   if (name &&
+   maps__set_kallsyms_ref_reloc_sym(machine->vmlinux_maps, 
name, addr)) {
+   machine__destroy_kernel_maps(machine);
+   return -1;
+   }
}
 
return 0;

Re: [PATCH v5] trace: ras: add ARM processor error information trace event

[Borislav Petkov]

On Tue, Jun 27, 2017 at 02:51:22PM +0800, Xie XiuQi wrote:
> How about we report the full info via arm_err_info_event which just for 
> someone
> who want the detail information, and leave arm_event closed. If someone do not
> care the error detail, who could just open arm_event.

So the way I read the spec is, an error event is being described by the
Processor Error section and then it "may contain multiple instances of
error information structures associated to a single error event."

So you can't leave the arm_event thing closed because it describes the
event.

If you want to merge the two, then sure, by all means, change arm_event
to contain some of the processor error info structure.

It wouldn't matter too much as this tracepoint is not fully cast in
stone yet.

Bottomline is, you want to carry as much information to userspace as
possible in order to handle the error properly. But not more - you don't
need redundant information because then that bloats the whole machinery
around transporting and processing error records and you don't want that
in critical situations where you want to act as quickly and as lean as
possible.

And "handle properly" means any and all actions which the kernel or
user needs to do to prolong the system lifetime or be able to reliably
schedule maintenance as to replace the faulty hw component. And so on
and so on...

So it all comes down to what RAS actions you guys wanna do on ARM.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

[PATCH 00/14] staging: ccree: coding style fixes

[Gilad Ben-Yossef]

Fix a bunch of coding style across the whole ccree driver

Gilad Ben-Yossef (14):
  staging: ccree: fix missing or redundant spaces
  staging: ccree: drop comparsion to true/false
  staging: ccree: fix else placement
  staging: ccree: remove redundant blank lines
  staging: ccree: no need for braces for single statements
  staging: ccree: fix unmatched if/else braces
  staging: ccree: remove comparisons to NULL
  staging: ccree: fix pointer location
  staging: ccree: remove custom type tdes_keys_t
  staging: ccree: remove custom type ssi_fips_error_t
  staging: ccree: remove custom type ssi_fips_state_t
  staging: ccree: remove unused type CCFipsSyncStatus_t
  staging: ccree: remove/add (un)needed blank lines
  staging: ccree: fix block comment style

 drivers/staging/ccree/Kconfig|   2 +-
 drivers/staging/ccree/cc_hw_queue_defs.h |   8 +-
 drivers/staging/ccree/ssi_aead.c | 142 ++-
 drivers/staging/ccree/ssi_aead.h |  20 +-
 drivers/staging/ccree/ssi_buffer_mgr.c   | 301 +++
 drivers/staging/ccree/ssi_buffer_mgr.h   |   1 -
 drivers/staging/ccree/ssi_cipher.c   | 124 +
 drivers/staging/ccree/ssi_cipher.h   |   6 -
 drivers/staging/ccree/ssi_driver.c   |  50 +++--
 drivers/staging/ccree/ssi_driver.h   |   4 +-
 drivers/staging/ccree/ssi_fips.c |  16 +-
 drivers/staging/ccree/ssi_fips.h |  15 +-
 drivers/staging/ccree/ssi_fips_data.h|  20 +-
 drivers/staging/ccree/ssi_fips_ext.c |  20 +-
 drivers/staging/ccree/ssi_fips_ll.c  | 101 +--
 drivers/staging/ccree/ssi_fips_local.c   | 107 +--
 drivers/staging/ccree/ssi_fips_local.h   |  20 +-
 drivers/staging/ccree/ssi_hash.c | 101 +--
 drivers/staging/ccree/ssi_hash.h |   6 +-
 drivers/staging/ccree/ssi_ivgen.c|   9 +-
 drivers/staging/ccree/ssi_ivgen.h|   1 -
 drivers/staging/ccree/ssi_pm.c   |  25 +--
 drivers/staging/ccree/ssi_pm.h   |   5 +-
 drivers/staging/ccree/ssi_request_mgr.c  | 102 +--
 drivers/staging/ccree/ssi_request_mgr.h  |   6 +-
 drivers/staging/ccree/ssi_sram_mgr.c |   4 +-
 drivers/staging/ccree/ssi_sram_mgr.h |   1 -
 drivers/staging/ccree/ssi_sysfs.c|  66 ---
 drivers/staging/ccree/ssi_sysfs.h|   1 +
 29 files changed, 550 insertions(+), 734 deletions(-)

-- 
2.1.4

[PATCH 01/14] staging: ccree: fix missing or redundant spaces

[Gilad Ben-Yossef]

Add and/or remove redundant and/or missing spaces in ccree source

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/Kconfig   |   2 +-
 drivers/staging/ccree/ssi_aead.c|  38 
 drivers/staging/ccree/ssi_aead.h|  12 +--
 drivers/staging/ccree/ssi_buffer_mgr.c  | 158 
 drivers/staging/ccree/ssi_cipher.c  |  44 -
 drivers/staging/ccree/ssi_driver.c  |  18 ++--
 drivers/staging/ccree/ssi_driver.h  |   4 +-
 drivers/staging/ccree/ssi_fips_data.h   |  12 +--
 drivers/staging/ccree/ssi_fips_ll.c |  12 +--
 drivers/staging/ccree/ssi_fips_local.c  |   8 +-
 drivers/staging/ccree/ssi_fips_local.h  |  18 ++--
 drivers/staging/ccree/ssi_hash.c|  38 
 drivers/staging/ccree/ssi_pm.c  |  16 ++--
 drivers/staging/ccree/ssi_pm.h  |   2 +-
 drivers/staging/ccree/ssi_request_mgr.c |  62 ++---
 drivers/staging/ccree/ssi_request_mgr.h |   6 +-
 drivers/staging/ccree/ssi_sysfs.c   |  56 +--
 17 files changed, 253 insertions(+), 253 deletions(-)

diff --git a/drivers/staging/ccree/Kconfig b/drivers/staging/ccree/Kconfig
index ec3749d..36a87c6 100644
--- a/drivers/staging/ccree/Kconfig
+++ b/drivers/staging/ccree/Kconfig
@@ -18,7 +18,7 @@ config CRYPTO_DEV_CCREE
select CRYPTO_CTR
select CRYPTO_XTS
help
- Say 'Y' to enable a driver for the Arm TrustZone CryptoCell 
+ Say 'Y' to enable a driver for the Arm TrustZone CryptoCell
  C7xx. Currently only the CryptoCell 712 REE is supported.
  Choose this if you wish to use hardware acceleration of
  cryptographic operations on the system REE.
diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index c70e450..2e8dc3f 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -238,8 +238,8 @@ static void ssi_aead_complete(struct device *dev, void 
*ssi_req, void __iomem *c
} else { /*ENCRYPT*/
if (unlikely(areq_ctx->is_icv_fragmented == true))
ssi_buffer_mgr_copy_scatterlist_portion(
-   areq_ctx->mac_buf, areq_ctx->dstSgl, 
areq->cryptlen+areq_ctx->dstOffset,
-   areq->cryptlen+areq_ctx->dstOffset + 
ctx->authsize, SSI_SG_FROM_BUF);
+   areq_ctx->mac_buf, areq_ctx->dstSgl, 
areq->cryptlen + areq_ctx->dstOffset,
+   areq->cryptlen + areq_ctx->dstOffset + 
ctx->authsize, SSI_SG_FROM_BUF);
 
/* If an IV was generated, copy it back to the user provided 
buffer. */
if (areq_ctx->backup_giv != NULL) {
@@ -1561,7 +1561,7 @@ static int config_ccm_adata(struct aead_request *req)
(req->cryptlen - ctx->authsize);
int rc;
memset(req_ctx->mac_buf, 0, AES_BLOCK_SIZE);
-   memset(req_ctx->ccm_config, 0, AES_BLOCK_SIZE*3);
+   memset(req_ctx->ccm_config, 0, AES_BLOCK_SIZE * 3);
 
/* taken from crypto/ccm.c */
/* 2 <= L <= 8, so 1 <= L' <= 7. */
@@ -1585,12 +1585,12 @@ static int config_ccm_adata(struct aead_request *req)
 /* END of "taken from crypto/ccm.c" */
 
/* l(a) - size of associated data. */
-   req_ctx->ccm_hdr_size = format_ccm_a0 (a0, req->assoclen);
+   req_ctx->ccm_hdr_size = format_ccm_a0(a0, req->assoclen);
 
memset(req->iv + 15 - req->iv[0], 0, req->iv[0] + 1);
req->iv[15] = 1;
 
-   memcpy(ctr_count_0, req->iv, AES_BLOCK_SIZE) ;
+   memcpy(ctr_count_0, req->iv, AES_BLOCK_SIZE);
ctr_count_0[15] = 0;
 
return 0;
@@ -1858,7 +1858,7 @@ static inline void ssi_aead_dump_gcm(
SSI_LOG_DEBUG("%s\n", title);
}
 
-   SSI_LOG_DEBUG("cipher_mode %d, authsize %d, enc_keylen %d, assoclen %d, 
cryptlen %d \n", \
+   SSI_LOG_DEBUG("cipher_mode %d, authsize %d, enc_keylen %d, assoclen %d, 
cryptlen %d\n", \
 ctx->cipher_mode, ctx->authsize, 
ctx->enc_keylen, req->assoclen, req_ctx->cryptlen);
 
if (ctx->enckey != NULL) {
@@ -1878,12 +1878,12 @@ static inline void ssi_aead_dump_gcm(
dump_byte_array("gcm_len_block", req_ctx->gcm_len_block.lenA, 
AES_BLOCK_SIZE);
 
if (req->src != NULL && req->cryptlen) {
-   dump_byte_array("req->src", sg_virt(req->src), 
req->cryptlen+req->assoclen);
+   dump_byte_array("req->src", sg_virt(req->src), req->cryptlen + 
req->assoclen);
}
 
if (req->dst != NULL) {
-   dump_byte_array("req->dst", sg_virt(req->dst), 
req->cryptlen+ctx->authsize+req->assoclen);
-}
+   dump_byte_array("req->dst", sg_virt(req->dst), req->cryptlen + 
ctx->authsize + req->assoclen);
+   }
 }
 #endif
 
@@ -1899,7 +1899,7 @@ static int config_gcm_context(struct aead_request *req)
(req->cryptlen - ctx->authsize);
__be

[PATCH 1/2] iommu/dma: Respect __GFP_DMA and __GFP_DMA32 in incoming GFP flags

[Tomasz Figa]

Current implementation of __iommu_dma_alloc_pages() keeps adding
__GFP_HIGHMEM to GFP flags regardless of whether other zone flags are
already included in the incoming flags. If __GFP_DMA or __GFP_DMA32 is
set at the same time as __GFP_HIGHMEM, the allocation fails due to
invalid zone flag combination.

Fix this by checking for __GFP_DMA and __GFP_DMA32 in incoming GFP flags
and adding __GFP_HIGHMEM only if they are not present.

Signed-off-by: Tomasz Figa 
---
 drivers/iommu/dma-iommu.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 9d1cebe7f6cb..29965a092a69 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -445,8 +445,14 @@ static struct page **__iommu_dma_alloc_pages(unsigned int 
count,
if (!pages)
return NULL;
 
-   /* IOMMU can map any pages, so himem can also be used here */
-   gfp |= __GFP_NOWARN | __GFP_HIGHMEM;
+   /*
+* IOMMU can map any pages, so himem can also be used here,
+* unless another DMA zone is explicitly requested.
+*/
+   if (!(gfp & (__GFP_DMA | __GFP_DMA32)))
+   gfp |= __GFP_HIGHMEM;
+
+   gfp |= __GFP_NOWARN;
 
while (count) {
struct page *page = NULL;
-- 
2.13.1.611.g7e3b11ae1-goog

[PATCH 07/14] staging: ccree: remove comparisons to NULL

[Gilad Ben-Yossef]

Remove explicit comparisons to NULL in ccree driver.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_aead.c| 34 -
 drivers/staging/ccree/ssi_buffer_mgr.c  | 44 -
 drivers/staging/ccree/ssi_cipher.c  | 12 -
 drivers/staging/ccree/ssi_driver.c  | 20 +++
 drivers/staging/ccree/ssi_fips.c|  4 +--
 drivers/staging/ccree/ssi_fips_ext.c|  4 +--
 drivers/staging/ccree/ssi_fips_local.c  | 10 
 drivers/staging/ccree/ssi_hash.c| 12 -
 drivers/staging/ccree/ssi_ivgen.c   |  4 +--
 drivers/staging/ccree/ssi_request_mgr.c |  8 +++---
 drivers/staging/ccree/ssi_sram_mgr.c|  2 +-
 drivers/staging/ccree/ssi_sysfs.c   |  2 +-
 12 files changed, 78 insertions(+), 78 deletions(-)

diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index fdb257d..53105dd 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -98,7 +98,7 @@ static void ssi_aead_exit(struct crypto_aead *tfm)
 
dev = &ctx->drvdata->plat_dev->dev;
/* Unmap enckey buffer */
-   if (ctx->enckey != NULL) {
+   if (ctx->enckey) {
dma_free_coherent(dev, AES_MAX_KEY_SIZE, ctx->enckey, 
ctx->enckey_dma_addr);
SSI_LOG_DEBUG("Freed enckey DMA buffer 
enckey_dma_addr=0x%llX\n",
(unsigned long long)ctx->enckey_dma_addr);
@@ -107,7 +107,7 @@ static void ssi_aead_exit(struct crypto_aead *tfm)
}
 
if (ctx->auth_mode == DRV_HASH_XCBC_MAC) { /* XCBC authetication */
-   if (ctx->auth_state.xcbc.xcbc_keys != NULL) {
+   if (ctx->auth_state.xcbc.xcbc_keys) {
dma_free_coherent(dev, CC_AES_128_BIT_KEY_SIZE * 3,
ctx->auth_state.xcbc.xcbc_keys,
ctx->auth_state.xcbc.xcbc_keys_dma_addr);
@@ -117,7 +117,7 @@ static void ssi_aead_exit(struct crypto_aead *tfm)
ctx->auth_state.xcbc.xcbc_keys_dma_addr = 0;
ctx->auth_state.xcbc.xcbc_keys = NULL;
} else if (ctx->auth_mode != DRV_HASH_NULL) { /* HMAC auth. */
-   if (ctx->auth_state.hmac.ipad_opad != NULL) {
+   if (ctx->auth_state.hmac.ipad_opad) {
dma_free_coherent(dev, 2 * MAX_HMAC_DIGEST_SIZE,
ctx->auth_state.hmac.ipad_opad,
ctx->auth_state.hmac.ipad_opad_dma_addr);
@@ -126,7 +126,7 @@ static void ssi_aead_exit(struct crypto_aead *tfm)
ctx->auth_state.hmac.ipad_opad_dma_addr = 0;
ctx->auth_state.hmac.ipad_opad = NULL;
}
-   if (ctx->auth_state.hmac.padded_authkey != NULL) {
+   if (ctx->auth_state.hmac.padded_authkey) {
dma_free_coherent(dev, MAX_HMAC_BLOCK_SIZE,
ctx->auth_state.hmac.padded_authkey,
ctx->auth_state.hmac.padded_authkey_dma_addr);
@@ -160,7 +160,7 @@ static int ssi_aead_init(struct crypto_aead *tfm)
/* Allocate key buffer, cache line aligned */
ctx->enckey = dma_alloc_coherent(dev, AES_MAX_KEY_SIZE,
&ctx->enckey_dma_addr, GFP_KERNEL);
-   if (ctx->enckey == NULL) {
+   if (!ctx->enckey) {
SSI_LOG_ERR("Failed allocating key buffer\n");
goto init_failed;
}
@@ -174,7 +174,7 @@ static int ssi_aead_init(struct crypto_aead *tfm)
ctx->auth_state.xcbc.xcbc_keys = dma_alloc_coherent(dev,
CC_AES_128_BIT_KEY_SIZE * 3,
&ctx->auth_state.xcbc.xcbc_keys_dma_addr, GFP_KERNEL);
-   if (ctx->auth_state.xcbc.xcbc_keys == NULL) {
+   if (!ctx->auth_state.xcbc.xcbc_keys) {
SSI_LOG_ERR("Failed allocating buffer for XCBC keys\n");
goto init_failed;
}
@@ -183,7 +183,7 @@ static int ssi_aead_init(struct crypto_aead *tfm)
ctx->auth_state.hmac.ipad_opad = dma_alloc_coherent(dev,
2 * MAX_HMAC_DIGEST_SIZE,
&ctx->auth_state.hmac.ipad_opad_dma_addr, GFP_KERNEL);
-   if (ctx->auth_state.hmac.ipad_opad == NULL) {
+   if (!ctx->auth_state.hmac.ipad_opad) {
SSI_LOG_ERR("Failed allocating IPAD/OPAD buffer\n");
goto init_failed;
}
@@ -193,7 +193,7 @@ static int ssi_aead_init(struct crypto_aead *tfm)
ctx->auth_state.hmac.padded_authkey = dma_alloc_coherent(dev,
MAX_HMAC_BLOCK_SIZE,
&ctx->auth_state.hmac.padded_authkey_dma_addr, 
GFP_KERNEL);
-   if (ctx->auth_state.hmac.padded_authkey == NULL) {
+   if (!ctx->auth_state.hmac.padded_authkey) {
 

[PATCH 02/14] staging: ccree: drop comparsion to true/false

[Gilad Ben-Yossef]

Fix cases in ccree where explicit comparsion to true/false
was made.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_aead.c   | 18 +-
 drivers/staging/ccree/ssi_buffer_mgr.c | 20 ++--
 drivers/staging/ccree/ssi_cipher.c |  2 +-
 drivers/staging/ccree/ssi_driver.c |  4 ++--
 4 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 2e8dc3f..00375b6 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -236,7 +236,7 @@ static void ssi_aead_complete(struct device *dev, void 
*ssi_req, void __iomem *c
err = -EBADMSG;
}
} else { /*ENCRYPT*/
-   if (unlikely(areq_ctx->is_icv_fragmented == true))
+   if (unlikely(areq_ctx->is_icv_fragmented))
ssi_buffer_mgr_copy_scatterlist_portion(
areq_ctx->mac_buf, areq_ctx->dstSgl, 
areq->cryptlen + areq_ctx->dstOffset,
areq->cryptlen + areq_ctx->dstOffset + 
ctx->authsize, SSI_SG_FROM_BUF);
@@ -790,7 +790,7 @@ ssi_aead_process_authenc_data_desc(
ssi_sram_addr_t mlli_addr = areq_ctx->assoc.sram_addr;
u32 mlli_nents = areq_ctx->assoc.mlli_nents;
 
-   if (likely(areq_ctx->is_single_pass == true)) {
+   if (likely(areq_ctx->is_single_pass)) {
if (direct == DRV_CRYPTO_DIRECTION_ENCRYPT) {
mlli_addr = areq_ctx->dst.sram_addr;
mlli_nents = areq_ctx->dst.mlli_nents;
@@ -1173,7 +1173,7 @@ static inline void ssi_aead_load_mlli_to_sram(
if (unlikely(
(req_ctx->assoc_buff_type == SSI_DMA_BUF_MLLI) ||
(req_ctx->data_buff_type == SSI_DMA_BUF_MLLI) ||
-   (req_ctx->is_single_pass == false))) {
+   !req_ctx->is_single_pass)) {
SSI_LOG_DEBUG("Copy-to-sram: mlli_dma=%08x, mlli_size=%u\n",
(unsigned int)ctx->drvdata->mlli_sram_addr,
req_ctx->mlli_params.mlli_len);
@@ -1228,7 +1228,7 @@ static inline void ssi_aead_hmac_authenc(
unsigned int data_flow_mode = ssi_aead_get_data_flow_mode(
direct, ctx->flow_mode, req_ctx->is_single_pass);
 
-   if (req_ctx->is_single_pass == true) {
+   if (req_ctx->is_single_pass) {
/**
 * Single-pass flow
 */
@@ -1282,7 +1282,7 @@ ssi_aead_xcbc_authenc(
unsigned int data_flow_mode = ssi_aead_get_data_flow_mode(
direct, ctx->flow_mode, req_ctx->is_single_pass);
 
-   if (req_ctx->is_single_pass == true) {
+   if (req_ctx->is_single_pass) {
/**
 * Single-pass flow
 */
@@ -1341,7 +1341,7 @@ static int validate_data_size(struct ssi_aead_ctx *ctx,
if (ctx->cipher_mode == DRV_CIPHER_CCM)
break;
if (ctx->cipher_mode == DRV_CIPHER_GCTR) {
-   if (areq_ctx->plaintext_authenticate_only == true)
+   if (areq_ctx->plaintext_authenticate_only)
areq_ctx->is_single_pass = false;
break;
}
@@ -1715,7 +1715,7 @@ static inline void ssi_aead_gcm_setup_gctr_desc(
set_flow_mode(&desc[idx], S_DIN_to_AES);
idx++;
 
-   if ((req_ctx->cryptlen != 0) && (req_ctx->plaintext_authenticate_only 
== false)) {
+   if ((req_ctx->cryptlen != 0) && 
(!req_ctx->plaintext_authenticate_only)) {
/* load AES/CTR initial CTR value inc by 2*/
hw_desc_init(&desc[idx]);
set_cipher_mode(&desc[idx], DRV_CIPHER_GCTR);
@@ -1815,7 +1815,7 @@ static inline int ssi_aead_gcm(
 
 
//in RFC4543 no data to encrypt. just copy data from src to dest.
-   if (req_ctx->plaintext_authenticate_only == true) {
+   if (req_ctx->plaintext_authenticate_only) {
ssi_aead_process_cipher_data_desc(req, BYPASS, desc, seq_size);
ssi_aead_gcm_setup_ghash_desc(req, desc, seq_size);
/* process(ghash) assoc data */
@@ -1913,7 +1913,7 @@ static int config_gcm_context(struct aead_request *req)
memcpy(req_ctx->gcm_iv_inc1, req->iv, 16);
 
 
-   if (req_ctx->plaintext_authenticate_only == false) {
+   if (!req_ctx->plaintext_authenticate_only) {
__be64 temp64;
temp64 = cpu_to_be64(req->assoclen * 8);
memcpy(&req_ctx->gcm_len_block.lenA, &temp64, sizeof(temp64));
diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c 
b/drivers/staging/ccree/ssi_buffer_mgr.c
index 00d95c1..5c46145 100644
--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -798,7 +798,7 @@ static inline int ssi_buffer_mgr_aea

[PATCH 12/14] staging: ccree: remove unused type CCFipsSyncStatus_t

[Gilad Ben-Yossef]

The CCFipsSyncStatus_t type was not being used in the code.
Remove it.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_fips_local.h | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/staging/ccree/ssi_fips_local.h 
b/drivers/staging/ccree/ssi_fips_local.h
index 0fbb1e0..4bc7f37 100644
--- a/drivers/staging/ccree/ssi_fips_local.h
+++ b/drivers/staging/ccree/ssi_fips_local.h
@@ -23,16 +23,6 @@
 #include "ssi_fips.h"
 struct ssi_drvdata;
 
-// IG - how to make 1 file for TEE and REE
-typedef enum CC_FipsSyncStatus {
-   CC_FIPS_SYNC_MODULE_OK  = 0x0,
-   CC_FIPS_SYNC_MODULE_ERROR   = 0x1,
-   CC_FIPS_SYNC_REE_STATUS = 0x4,
-   CC_FIPS_SYNC_TEE_STATUS = 0x8,
-   CC_FIPS_SYNC_STATUS_RESERVE32B  = S32_MAX
-} CCFipsSyncStatus_t;
-
-
 #define CHECK_AND_RETURN_UPON_FIPS_ERROR() {\
if (ssi_fips_check_fips_error() != 0) {\
return -ENOEXEC;\
-- 
2.1.4

[PATCH 09/14] staging: ccree: remove custom type tdes_keys_t

[Gilad Ben-Yossef]

Replace references to type tdes_keys_t with struct tdes_keys.
_
Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_cipher.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/ccree/ssi_cipher.c 
b/drivers/staging/ccree/ssi_cipher.c
index b4fc9a6..eb3e8e6 100644
--- a/drivers/staging/ccree/ssi_cipher.c
+++ b/drivers/staging/ccree/ssi_cipher.c
@@ -253,11 +253,11 @@ static void ssi_blkcipher_exit(struct crypto_tfm *tfm)
 }
 
 
-typedef struct tdes_keys {
+struct tdes_keys {
u8  key1[DES_KEY_SIZE];
u8  key2[DES_KEY_SIZE];
u8  key3[DES_KEY_SIZE];
-} tdes_keys_t;
+};
 
 static const u8 zero_buff[] = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
@@ -268,7 +268,7 @@ static const u8 zero_buff[] = { 0x0, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x0, 0x0,
 static int ssi_fips_verify_3des_keys(const u8 *key, unsigned int keylen)
 {
 #ifdef CCREE_FIPS_SUPPORT
-   tdes_keys_t *tdes_key = (tdes_keys_t *)key;
+   struct tdes_keys *tdes_key = (struct tdes_keys *)key;
 
/* verify key1 != key2 and key3 != key2*/
if (unlikely((memcmp((u8 *)tdes_key->key1, (u8 *)tdes_key->key2, 
sizeof(tdes_key->key1)) == 0) ||
-- 
2.1.4

[PATCH 14/14] staging: ccree: fix block comment style

[Gilad Ben-Yossef]

Align block comments according to coding style.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/cc_hw_queue_defs.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/ccree/cc_hw_queue_defs.h 
b/drivers/staging/ccree/cc_hw_queue_defs.h
index f11487a..e6b8cea 100644
--- a/drivers/staging/ccree/cc_hw_queue_defs.h
+++ b/drivers/staging/ccree/cc_hw_queue_defs.h
@@ -23,8 +23,8 @@
 #include 
 
 /**
-*  DEFINITIONS
-**/
+ * DEFINITIONS
+ 
**/
 
 #define HW_DESC_SIZE_WORDS 6
 #define HW_QUEUE_SLOTS_MAX  15 /* Max. available slots in HW queue 
*/
@@ -70,8 +70,8 @@
 #define WORD5_DOUT_ADDR_HIGH   CC_GENMASK(5, DOUT_ADDR_HIGH)
 
 /**
-*  TYPE DEFINITIONS
-**/
+ * TYPE DEFINITIONS
+ 
**/
 
 struct cc_hw_desc {
union {
-- 
2.1.4

[PATCH 13/14] staging: ccree: remove/add (un)needed blank lines

[Gilad Ben-Yossef]

Remove or add blank lines as needed to match coding style.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_aead.c| 20 +--
 drivers/staging/ccree/ssi_aead.h|  4 
 drivers/staging/ccree/ssi_buffer_mgr.c  |  7 ---
 drivers/staging/ccree/ssi_buffer_mgr.h  |  1 -
 drivers/staging/ccree/ssi_cipher.c  | 17 +++-
 drivers/staging/ccree/ssi_cipher.h  |  6 --
 drivers/staging/ccree/ssi_driver.c  |  4 +---
 drivers/staging/ccree/ssi_fips.c|  2 --
 drivers/staging/ccree/ssi_fips.h|  3 ---
 drivers/staging/ccree/ssi_fips_data.h   |  8 
 drivers/staging/ccree/ssi_fips_ext.c|  2 --
 drivers/staging/ccree/ssi_fips_ll.c | 35 +
 drivers/staging/ccree/ssi_fips_local.c  | 14 +
 drivers/staging/ccree/ssi_fips_local.h  |  4 ++--
 drivers/staging/ccree/ssi_hash.c| 12 ---
 drivers/staging/ccree/ssi_ivgen.c   |  1 -
 drivers/staging/ccree/ssi_ivgen.h   |  1 -
 drivers/staging/ccree/ssi_pm.c  |  5 -
 drivers/staging/ccree/ssi_pm.h  |  3 ---
 drivers/staging/ccree/ssi_request_mgr.c |  9 +++--
 drivers/staging/ccree/ssi_sram_mgr.c|  2 --
 drivers/staging/ccree/ssi_sram_mgr.h|  1 -
 drivers/staging/ccree/ssi_sysfs.c   |  4 
 drivers/staging/ccree/ssi_sysfs.h   |  1 +
 24 files changed, 33 insertions(+), 133 deletions(-)

diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 53105dd..1fc0b05 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -49,7 +49,6 @@
 #define AES_CCM_RFC4309_NONCE_SIZE 3
 #define MAX_NONCE_SIZE CTR_RFC3686_NONCE_SIZE
 
-
 /* Value of each ICV_CMP byte (of 8) in case of success */
 #define ICV_VERIF_OK 0x01
 
@@ -209,7 +208,6 @@ static int ssi_aead_init(struct crypto_aead *tfm)
return -ENOMEM;
 }
 
-
 static void ssi_aead_complete(struct device *dev, void *ssi_req, void __iomem 
*cc_base)
 {
struct aead_request *areq = (struct aead_request *)ssi_req;
@@ -402,6 +400,7 @@ static int validate_keys_sizes(struct ssi_aead_ctx *ctx)
 
return 0; /* All tests of keys sizes passed */
 }
+
 /* This function prepers the user key so it can pass to the hmac processing
  * (copy to intenral buffer or hash in case of key longer than block
  */
@@ -526,7 +525,6 @@ ssi_get_plain_hmac_key(struct crypto_aead *tfm, const u8 
*key, unsigned int keyl
return rc;
 }
 
-
 static int
 ssi_aead_setkey(struct crypto_aead *tfm, const u8 *key, unsigned int keylen)
 {
@@ -594,7 +592,6 @@ ssi_aead_setkey(struct crypto_aead *tfm, const u8 *key, 
unsigned int keylen)
goto badkey;
}
 
-
/* STAT_PHASE_2: Create sequence */
 
switch (ctx->auth_mode) {
@@ -613,7 +610,6 @@ ssi_aead_setkey(struct crypto_aead *tfm, const u8 *key, 
unsigned int keylen)
goto badkey;
}
 
-
/* STAT_PHASE_3: Submit sequence to HW */
 
if (seq_len > 0) { /* For CCM there is no sequence to setup the key */
@@ -1372,6 +1368,7 @@ static int validate_data_size(struct ssi_aead_ctx *ctx,
 static unsigned int format_ccm_a0(u8 *pA0Buff, u32 headerSize)
 {
unsigned int len = 0;
+
if (headerSize == 0)
return 0;
 
@@ -1424,7 +1421,6 @@ static inline int ssi_aead_ccm(
unsigned int cipher_flow_mode;
dma_addr_t mac_result;
 
-
if (req_ctx->gen_ctx.op_type == DRV_CRYPTO_DIRECTION_DECRYPT) {
cipher_flow_mode = AES_to_HASH_and_DOUT;
mac_result = req_ctx->mac_buf_dma_addr;
@@ -1481,7 +1477,6 @@ static inline int ssi_aead_ccm(
set_aes_not_hash_mode(&desc[idx]);
idx++;
 
-
/* process assoc data */
if (req->assoclen > 0) {
ssi_aead_create_assoc_desc(req, DIN_HASH, desc, &idx);
@@ -1556,6 +1551,7 @@ static int config_ccm_adata(struct aead_request *req)
req->cryptlen :
(req->cryptlen - ctx->authsize);
int rc;
+
memset(req_ctx->mac_buf, 0, AES_BLOCK_SIZE);
memset(req_ctx->ccm_config, 0, AES_BLOCK_SIZE * 3);
 
@@ -1808,7 +1804,6 @@ static inline int ssi_aead_gcm(
cipher_flow_mode = AES_to_HASH_and_DOUT;
}
 
-
//in RFC4543 no data to encrypt. just copy data from src to dest.
if (req_ctx->plaintext_authenticate_only) {
ssi_aead_process_cipher_data_desc(req, BYPASS, desc, seq_size);
@@ -1904,15 +1899,16 @@ static int config_gcm_context(struct aead_request *req)
memcpy(req->iv + 12, &counter, 4);
memcpy(req_ctx->gcm_iv_inc1, req->iv, 16);
 
-
if (!req_ctx->plaintext_authenticate_only) {
__be64 temp64;
+
temp64 = cpu_to_be64(req->assoclen * 8);
memcpy(&req_ctx->gcm_len_block.lenA, &temp64, sizeof(temp64));
temp64 = cpu_to_be64(cryptlen 

[PATCH 08/14] staging: ccree: fix pointer location

[Gilad Ben-Yossef]

Fix location of pointer in variables definitions and dereference.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_aead.h|  4 ++--
 drivers/staging/ccree/ssi_buffer_mgr.c  | 12 ++--
 drivers/staging/ccree/ssi_cipher.c  |  8 
 drivers/staging/ccree/ssi_fips_ll.c | 24 
 drivers/staging/ccree/ssi_fips_local.c  |  2 +-
 drivers/staging/ccree/ssi_hash.c|  2 +-
 drivers/staging/ccree/ssi_hash.h|  6 +++---
 drivers/staging/ccree/ssi_request_mgr.c | 10 +-
 drivers/staging/ccree/ssi_sysfs.c   |  4 ++--
 9 files changed, 36 insertions(+), 36 deletions(-)

diff --git a/drivers/staging/ccree/ssi_aead.h b/drivers/staging/ccree/ssi_aead.h
index 07cab84..d69e729 100644
--- a/drivers/staging/ccree/ssi_aead.h
+++ b/drivers/staging/ccree/ssi_aead.h
@@ -98,8 +98,8 @@ struct aead_req_ctx {
struct ssi_mlli assoc;
struct ssi_mlli src;
struct ssi_mlli dst;
-   struct scatterlist* srcSgl;
-   struct scatterlist* dstSgl;
+   struct scatterlist *srcSgl;
+   struct scatterlist *dstSgl;
unsigned int srcOffset;
unsigned int dstOffset;
enum ssi_req_dma_buf_type assoc_buff_type;
diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c 
b/drivers/staging/ccree/ssi_buffer_mgr.c
index e060ea1..1b41c12 100644
--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -66,7 +66,7 @@ struct buffer_array {
int total_data_len[MAX_NUM_OF_BUFFERS_IN_MLLI];
enum dma_buffer_type type[MAX_NUM_OF_BUFFERS_IN_MLLI];
bool is_last[MAX_NUM_OF_BUFFERS_IN_MLLI];
-   u32 * mlli_nents[MAX_NUM_OF_BUFFERS_IN_MLLI];
+   u32 *mlli_nents[MAX_NUM_OF_BUFFERS_IN_MLLI];
 };
 
 /**
@@ -409,7 +409,7 @@ static int ssi_buffer_mgr_map_scatterlist(
 static inline int
 ssi_aead_handle_config_buf(struct device *dev,
struct aead_req_ctx *areq_ctx,
-   u8* config_data,
+   u8 *config_data,
struct buffer_array *sg_data,
unsigned int assoclen)
 {
@@ -444,7 +444,7 @@ ssi_aead_handle_config_buf(struct device *dev,
 
 static inline int ssi_ahash_handle_curr_buf(struct device *dev,
   struct ahash_req_ctx *areq_ctx,
-  u8* curr_buff,
+  u8 *curr_buff,
   u32 curr_buff_cnt,
   struct buffer_array *sg_data)
 {
@@ -1460,7 +1460,7 @@ int ssi_buffer_mgr_map_hash_request_final(
 {
struct ahash_req_ctx *areq_ctx = (struct ahash_req_ctx *)ctx;
struct device *dev = &drvdata->plat_dev->dev;
-   u8* curr_buff = areq_ctx->buff_index ? areq_ctx->buff1 :
+   u8 *curr_buff = areq_ctx->buff_index ? areq_ctx->buff1 :
areq_ctx->buff0;
u32 *curr_buff_cnt = areq_ctx->buff_index ? &areq_ctx->buff1_cnt :
&areq_ctx->buff0_cnt;
@@ -1551,11 +1551,11 @@ int ssi_buffer_mgr_map_hash_request_update(
 {
struct ahash_req_ctx *areq_ctx = (struct ahash_req_ctx *)ctx;
struct device *dev = &drvdata->plat_dev->dev;
-   u8* curr_buff = areq_ctx->buff_index ? areq_ctx->buff1 :
+   u8 *curr_buff = areq_ctx->buff_index ? areq_ctx->buff1 :
areq_ctx->buff0;
u32 *curr_buff_cnt = areq_ctx->buff_index ? &areq_ctx->buff1_cnt :
&areq_ctx->buff0_cnt;
-   u8* next_buff = areq_ctx->buff_index ? areq_ctx->buff0 :
+   u8 *next_buff = areq_ctx->buff_index ? areq_ctx->buff0 :
areq_ctx->buff1;
u32 *next_buff_cnt = areq_ctx->buff_index ? &areq_ctx->buff0_cnt :
&areq_ctx->buff1_cnt;
diff --git a/drivers/staging/ccree/ssi_cipher.c 
b/drivers/staging/ccree/ssi_cipher.c
index 1baa215..b4fc9a6 100644
--- a/drivers/staging/ccree/ssi_cipher.c
+++ b/drivers/staging/ccree/ssi_cipher.c
@@ -268,11 +268,11 @@ static const u8 zero_buff[] = {   0x0, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x0, 0x0,
 static int ssi_fips_verify_3des_keys(const u8 *key, unsigned int keylen)
 {
 #ifdef CCREE_FIPS_SUPPORT
-   tdes_keys_t *tdes_key = (tdes_keys_t*)key;
+   tdes_keys_t *tdes_key = (tdes_keys_t *)key;
 
/* verify key1 != key2 and key3 != key2*/
-   if (unlikely((memcmp((u8*)tdes_key->key1, (u8*)tdes_key->key2, 
sizeof(tdes_key->key1)) == 0) ||
- (memcmp((u8*)tdes_key->key3, (u8*)tdes_key->key2, 
sizeof(tdes_key->key3)) == 0))) {
+   if (unlikely((memcmp((u8 *)tdes_key->key1, (u8 *)tdes_key->key2, 
sizeof(tdes_key->key1)) == 0) ||
+ (memcmp((u8 *)tdes_key->key3, (u8 *)tdes_key->key2, 
sizeof(tdes_key->key3)) == 0))) {
return -ENOEXEC;
}
 #endif /* CCREE_FIPS_SUPPORT */
@@ -342,7 +342,7 @@ static int ssi_blkcipher_setkey(struct crypto_tfm *tfm,
 
if (ssi_is_hw_key(tfm)) {
/* setting HW key slots */

[PATCH 10/14] staging: ccree: remove custom type ssi_fips_error_t

[Gilad Ben-Yossef]

Replace custom type ssi_fips_error_t with underlying enum.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_fips.c   |  4 ++--
 drivers/staging/ccree/ssi_fips.h   |  6 +++---
 drivers/staging/ccree/ssi_fips_ext.c   |  6 +++---
 drivers/staging/ccree/ssi_fips_ll.c| 30 +++---
 drivers/staging/ccree/ssi_fips_local.c | 28 ++--
 drivers/staging/ccree/ssi_fips_local.h |  2 +-
 6 files changed, 38 insertions(+), 38 deletions(-)

diff --git a/drivers/staging/ccree/ssi_fips.c b/drivers/staging/ccree/ssi_fips.c
index 2b8a616..948ea49 100644
--- a/drivers/staging/ccree/ssi_fips.c
+++ b/drivers/staging/ccree/ssi_fips.c
@@ -24,7 +24,7 @@
 
 
 extern int ssi_fips_ext_get_state(ssi_fips_state_t *p_state);
-extern int ssi_fips_ext_get_error(ssi_fips_error_t *p_err);
+extern int ssi_fips_ext_get_error(enum cc_fips_error *p_err);
 
 /*
  * This function returns the REE FIPS state.
@@ -48,7 +48,7 @@ EXPORT_SYMBOL(ssi_fips_get_state);
  * This function returns the REE FIPS error.
  * It should be called by kernel module.
  */
-int ssi_fips_get_error(ssi_fips_error_t *p_err)
+int ssi_fips_get_error(enum cc_fips_error *p_err)
 {
int rc = 0;
 
diff --git a/drivers/staging/ccree/ssi_fips.h b/drivers/staging/ccree/ssi_fips.h
index 2fdb1b9..d1cd489 100644
--- a/drivers/staging/ccree/ssi_fips.h
+++ b/drivers/staging/ccree/ssi_fips.h
@@ -30,7 +30,7 @@ typedef enum ssi_fips_state {
 } ssi_fips_state_t;
 
 
-typedef enum ssi_fips_error {
+enum cc_fips_error {
CC_REE_FIPS_ERROR_OK = 0,
CC_REE_FIPS_ERROR_GENERAL,
CC_REE_FIPS_ERROR_FROM_TEE,
@@ -53,12 +53,12 @@ typedef enum ssi_fips_error {
CC_REE_FIPS_ERROR_HMAC_SHA512_PUT,
CC_REE_FIPS_ERROR_ROM_CHECKSUM,
CC_REE_FIPS_ERROR_RESERVE32B = S32_MAX
-} ssi_fips_error_t;
+};
 
 
 
 int ssi_fips_get_state(ssi_fips_state_t *p_state);
-int ssi_fips_get_error(ssi_fips_error_t *p_err);
+int ssi_fips_get_error(enum cc_fips_error *p_err);
 
 #endif  /*__SSI_FIPS_H__*/
 
diff --git a/drivers/staging/ccree/ssi_fips_ext.c 
b/drivers/staging/ccree/ssi_fips_ext.c
index b897c03..aab2805 100644
--- a/drivers/staging/ccree/ssi_fips_ext.c
+++ b/drivers/staging/ccree/ssi_fips_ext.c
@@ -29,7 +29,7 @@ module_param(tee_error, bool, 0644);
 MODULE_PARM_DESC(tee_error, "Simulate TEE library failure flag: 0 - no error 
(default), 1 - TEE error occured ");
 
 static ssi_fips_state_t fips_state = CC_FIPS_STATE_NOT_SUPPORTED;
-static ssi_fips_error_t fips_error = CC_REE_FIPS_ERROR_OK;
+static enum cc_fips_error fips_error = CC_REE_FIPS_ERROR_OK;
 
 /*
  * This function returns the FIPS REE state.
@@ -55,7 +55,7 @@ int ssi_fips_ext_get_state(ssi_fips_state_t *p_state)
  * the error value is stored.
  * The reference code uses global variable.
  */
-int ssi_fips_ext_get_error(ssi_fips_error_t *p_err)
+int ssi_fips_ext_get_error(enum cc_fips_error *p_err)
 {
int rc = 0;
 
@@ -85,7 +85,7 @@ int ssi_fips_ext_set_state(ssi_fips_state_t state)
  * the error value is stored.
  * The reference code uses global variable.
  */
-int ssi_fips_ext_set_error(ssi_fips_error_t err)
+int ssi_fips_ext_set_error(enum cc_fips_error err)
 {
fips_error = err;
return 0;
diff --git a/drivers/staging/ccree/ssi_fips_ll.c 
b/drivers/staging/ccree/ssi_fips_ll.c
index 4a11f15..cbb0fe2 100644
--- a/drivers/staging/ccree/ssi_fips_ll.c
+++ b/drivers/staging/ccree/ssi_fips_ll.c
@@ -271,7 +271,7 @@ static const FipsGcmData FipsGcmDataTable[] = {
 #define FIPS_GCM_NUM_OF_TESTS(sizeof(FipsGcmDataTable) / 
sizeof(FipsGcmData))
 
 
-static inline ssi_fips_error_t
+static inline enum cc_fips_error
 FIPS_CipherToFipsError(enum drv_cipher_mode mode, bool is_aes)
 {
switch (mode)
@@ -415,10 +415,10 @@ ssi_cipher_fips_run_test(struct ssi_drvdata *drvdata,
 }
 
 
-ssi_fips_error_t
+enum cc_fips_error
 ssi_cipher_fips_power_up_tests(struct ssi_drvdata *drvdata, void 
*cpu_addr_buffer, dma_addr_t dma_coherent_buffer)
 {
-   ssi_fips_error_t error = CC_REE_FIPS_ERROR_OK;
+   enum cc_fips_error error = CC_REE_FIPS_ERROR_OK;
size_t i;
struct fips_cipher_ctx *virt_ctx = (struct fips_cipher_ctx 
*)cpu_addr_buffer;
 
@@ -544,10 +544,10 @@ ssi_cmac_fips_run_test(struct ssi_drvdata *drvdata,
return rc;
 }
 
-ssi_fips_error_t
+enum cc_fips_error
 ssi_cmac_fips_power_up_tests(struct ssi_drvdata *drvdata, void 
*cpu_addr_buffer, dma_addr_t dma_coherent_buffer)
 {
-   ssi_fips_error_t error = CC_REE_FIPS_ERROR_OK;
+   enum cc_fips_error error = CC_REE_FIPS_ERROR_OK;
size_t i;
struct fips_cmac_ctx *virt_ctx = (struct fips_cmac_ctx 
*)cpu_addr_buffer;
 
@@ -604,7 +604,7 @@ ssi_cmac_fips_power_up_tests(struct ssi_drvdata *drvdata, 
void *cpu_addr_buffer,
 }
 
 
-static inline ssi_fips_error_t
+static inline enum cc_fips_error
 FIPS_HashToFipsError(enum drv_hash_mode hash_mode)
 {
switch (hash_mode) {
@@ -690,10 +690,10 @@ ssi_hash_fips_run_test(stru

Re: [PATCH] rpmsg: Solve circular dependencies involving RPMSG_VIRTIO

[Arnd Bergmann]

On Tue, Jun 27, 2017 at 8:43 AM, Bjorn Andersson
 wrote:
> While it's very common to use RPMSG for communicating with firmware
> running on these remoteprocs there is no functional dependency on RPMSG.
> As such RPMSG should be selected by the system integrator and not
> automatically by the remoteproc drivers.
>
> This does solve problems reported with circular Kconfig dependencies for
> Davinci and Keystone remoteproc drivers.
>
> Signed-off-by: Bjorn Andersson 
> ---

Looks good to me,

Acked-by: Arnd Bergmann 

[PATCH 11/14] staging: ccree: remove custom type ssi_fips_state_t

[Gilad Ben-Yossef]

Replace custom type ssi_fips_state_t with underlying enum.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_fips.c   | 4 ++--
 drivers/staging/ccree/ssi_fips.h   | 6 +++---
 drivers/staging/ccree/ssi_fips_ext.c   | 6 +++---
 drivers/staging/ccree/ssi_fips_local.c | 8 
 4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/ccree/ssi_fips.c b/drivers/staging/ccree/ssi_fips.c
index 948ea49..d34d9ef 100644
--- a/drivers/staging/ccree/ssi_fips.c
+++ b/drivers/staging/ccree/ssi_fips.c
@@ -23,14 +23,14 @@
 #include "ssi_fips.h"
 
 
-extern int ssi_fips_ext_get_state(ssi_fips_state_t *p_state);
+extern int ssi_fips_ext_get_state(enum cc_fips_state_t *p_state);
 extern int ssi_fips_ext_get_error(enum cc_fips_error *p_err);
 
 /*
  * This function returns the REE FIPS state.
  * It should be called by kernel module.
  */
-int ssi_fips_get_state(ssi_fips_state_t *p_state)
+int ssi_fips_get_state(enum cc_fips_state_t *p_state)
 {
int rc = 0;
 
diff --git a/drivers/staging/ccree/ssi_fips.h b/drivers/staging/ccree/ssi_fips.h
index d1cd489..ce5fa45 100644
--- a/drivers/staging/ccree/ssi_fips.h
+++ b/drivers/staging/ccree/ssi_fips.h
@@ -22,12 +22,12 @@
  * @brief This file contains FIPS related defintions and APIs.
  */
 
-typedef enum ssi_fips_state {
+enum cc_fips_state {
CC_FIPS_STATE_NOT_SUPPORTED = 0,
CC_FIPS_STATE_SUPPORTED,
CC_FIPS_STATE_ERROR,
CC_FIPS_STATE_RESERVE32B = S32_MAX
-} ssi_fips_state_t;
+};
 
 
 enum cc_fips_error {
@@ -57,7 +57,7 @@ enum cc_fips_error {
 
 
 
-int ssi_fips_get_state(ssi_fips_state_t *p_state);
+int ssi_fips_get_state(enum cc_fips_state *p_state);
 int ssi_fips_get_error(enum cc_fips_error *p_err);
 
 #endif  /*__SSI_FIPS_H__*/
diff --git a/drivers/staging/ccree/ssi_fips_ext.c 
b/drivers/staging/ccree/ssi_fips_ext.c
index aab2805..295aeb6 100644
--- a/drivers/staging/ccree/ssi_fips_ext.c
+++ b/drivers/staging/ccree/ssi_fips_ext.c
@@ -28,7 +28,7 @@ static bool tee_error;
 module_param(tee_error, bool, 0644);
 MODULE_PARM_DESC(tee_error, "Simulate TEE library failure flag: 0 - no error 
(default), 1 - TEE error occured ");
 
-static ssi_fips_state_t fips_state = CC_FIPS_STATE_NOT_SUPPORTED;
+static enum cc_fips_state_t fips_state = CC_FIPS_STATE_NOT_SUPPORTED;
 static enum cc_fips_error fips_error = CC_REE_FIPS_ERROR_OK;
 
 /*
@@ -37,7 +37,7 @@ static enum cc_fips_error fips_error = CC_REE_FIPS_ERROR_OK;
  * the state value is stored.
  * The reference code uses global variable.
  */
-int ssi_fips_ext_get_state(ssi_fips_state_t *p_state)
+int ssi_fips_ext_get_state(enum cc_fips_state_t *p_state)
 {
int rc = 0;
 
@@ -73,7 +73,7 @@ int ssi_fips_ext_get_error(enum cc_fips_error *p_err)
  * the state value is stored.
  * The reference code uses global variable.
  */
-int ssi_fips_ext_set_state(ssi_fips_state_t state)
+int ssi_fips_ext_set_state(enum cc_fips_state_t state)
 {
fips_state = state;
return 0;
diff --git a/drivers/staging/ccree/ssi_fips_local.c 
b/drivers/staging/ccree/ssi_fips_local.c
index dfc871d..9b84876 100644
--- a/drivers/staging/ccree/ssi_fips_local.c
+++ b/drivers/staging/ccree/ssi_fips_local.c
@@ -50,9 +50,9 @@ struct ssi_fips_handle {
 };
 
 
-extern int ssi_fips_get_state(ssi_fips_state_t *p_state);
+extern int ssi_fips_get_state(enum cc_fips_state_t *p_state);
 extern int ssi_fips_get_error(enum cc_fips_error *p_err);
-extern int ssi_fips_ext_set_state(ssi_fips_state_t state);
+extern int ssi_fips_ext_set_state(enum cc_fips_state_t state);
 extern int ssi_fips_ext_set_error(enum cc_fips_error err);
 
 /* FIPS power-up tests */
@@ -234,7 +234,7 @@ enum cc_fips_error cc_fips_run_power_up_tests(struct 
ssi_drvdata *drvdata)
  */
 int ssi_fips_check_fips_error(void)
 {
-   ssi_fips_state_t fips_state;
+   enum cc_fips_state_t fips_state;
 
if (ssi_fips_get_state(&fips_state) != 0) {
FIPS_LOG("ssi_fips_get_state FAILED, returning.. \n");
@@ -251,7 +251,7 @@ int ssi_fips_check_fips_error(void)
 /* The function sets the REE FIPS state.*
  * It should be used while driver is being loaded.
  */
-int ssi_fips_set_state(ssi_fips_state_t state)
+int ssi_fips_set_state(enum cc_fips_state_t state)
 {
return ssi_fips_ext_set_state(state);
 }
-- 
2.1.4

[PATCH][drm-next] drm/i915: fix spelling mistake: "CouarPoint" -> "CougarPoint"

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistake in DRM_DEBUG_KMS message

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/i915/i915_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index ee2325b180e7..aa99619bfc1b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -132,7 +132,7 @@ static enum intel_pch intel_virt_detect_pch(struct 
drm_i915_private *dev_priv)
DRM_DEBUG_KMS("Assuming Ibex Peak PCH\n");
} else if (IS_GEN6(dev_priv) || IS_IVYBRIDGE(dev_priv)) {
ret = PCH_CPT;
-   DRM_DEBUG_KMS("Assuming CouarPoint PCH\n");
+   DRM_DEBUG_KMS("Assuming CougarPoint PCH\n");
} else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
ret = PCH_LPT;
DRM_DEBUG_KMS("Assuming LynxPoint PCH\n");
-- 
2.11.0

[PATCH 2/2] iommu/dma: use __GFP_NOWARN only for high-order allocations

[Tomasz Figa]

Memory allocation routines are expected to report allocation errors to
kernel log. However, current implementation of __iommu_dma_alloc_pages()
adds __GFP_NOWARN for all calls to alloc_pages(), which completely
disables any logging.

Fix it by adding __GFP_NOWARN only to high order allocation attempts,
which are not critical.

Signed-off-by: Tomasz Figa 
---
 drivers/iommu/dma-iommu.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 29965a092a69..8507987eed90 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -433,6 +433,7 @@ static struct page **__iommu_dma_alloc_pages(unsigned int 
count,
 {
struct page **pages;
unsigned int i = 0, array_size = count * sizeof(*pages);
+   const gfp_t high_order_gfp = __GFP_NOWARN | __GFP_NORETRY;
 
order_mask &= (2U << MAX_ORDER) - 1;
if (!order_mask)
@@ -452,8 +453,6 @@ static struct page **__iommu_dma_alloc_pages(unsigned int 
count,
if (!(gfp & (__GFP_DMA | __GFP_DMA32)))
gfp |= __GFP_HIGHMEM;
 
-   gfp |= __GFP_NOWARN;
-
while (count) {
struct page *page = NULL;
unsigned int order_size;
@@ -469,7 +468,7 @@ static struct page **__iommu_dma_alloc_pages(unsigned int 
count,
 
order_size = 1U << order;
page = alloc_pages((order_mask - order_size) ?
-  gfp | __GFP_NORETRY : gfp, order);
+  gfp | high_order_gfp : gfp, order);
if (!page)
continue;
if (!order)
-- 
2.13.1.611.g7e3b11ae1-goog

[PATCH 03/14] staging: ccree: fix else placement

[Gilad Ben-Yossef]

Fix cases where the else clause was not located correctly after the if
brace.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_buffer_mgr.c | 3 +--
 drivers/staging/ccree/ssi_pm.c | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c 
b/drivers/staging/ccree/ssi_buffer_mgr.c
index 5c46145..3c74ae3 100644
--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -852,8 +852,7 @@ static inline int ssi_buffer_mgr_aead_chain_assoc(
sg_index = current_sg->length;
if (sg_index > size_of_assoc) { //the first entry in the scatter list 
contains all the associated data
mapped_nents++;
-   }
-   else{
+   } else {
while (sg_index <= size_of_assoc) {
current_sg = sg_next(current_sg);
//if have reached the end of the sgl, then this is 
unexpected
diff --git a/drivers/staging/ccree/ssi_pm.c b/drivers/staging/ccree/ssi_pm.c
index c8c5875..ae1f7f0 100644
--- a/drivers/staging/ccree/ssi_pm.c
+++ b/drivers/staging/ccree/ssi_pm.c
@@ -110,8 +110,7 @@ int ssi_power_mgr_runtime_put_suspend(struct device *dev)
(struct ssi_drvdata *)dev_get_drvdata(dev))) {
pm_runtime_mark_last_busy(dev);
rc = pm_runtime_put_autosuspend(dev);
-   }
-   else {
+   } else {
/* Something wrong happens*/
BUG();
}
-- 
2.1.4

[PATCH 05/14] staging: ccree: no need for braces for single statements

[Gilad Ben-Yossef]

Fix several cases of needless braces around single statement blocks.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_aead.c| 38 +++---
 drivers/staging/ccree/ssi_buffer_mgr.c  | 70 ++---
 drivers/staging/ccree/ssi_cipher.c  | 41 +++
 drivers/staging/ccree/ssi_driver.c  |  9 +++--
 drivers/staging/ccree/ssi_fips.c|  6 +--
 drivers/staging/ccree/ssi_fips_ext.c|  6 +--
 drivers/staging/ccree/ssi_fips_local.c  | 39 +-
 drivers/staging/ccree/ssi_hash.c| 35 ++---
 drivers/staging/ccree/ssi_ivgen.c   |  4 +-
 drivers/staging/ccree/ssi_request_mgr.c | 20 --
 drivers/staging/ccree/ssi_sysfs.c   |  4 +-
 11 files changed, 110 insertions(+), 162 deletions(-)

diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 5782c9d..fdb257d 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -243,11 +243,10 @@ static void ssi_aead_complete(struct device *dev, void 
*ssi_req, void __iomem *c
 
/* If an IV was generated, copy it back to the user provided 
buffer. */
if (areq_ctx->backup_giv != NULL) {
-   if (ctx->cipher_mode == DRV_CIPHER_CTR) {
+   if (ctx->cipher_mode == DRV_CIPHER_CTR)
memcpy(areq_ctx->backup_giv, areq_ctx->ctr_iv + 
CTR_RFC3686_NONCE_SIZE, CTR_RFC3686_IV_SIZE);
-   } else if (ctx->cipher_mode == DRV_CIPHER_CCM) {
+   else if (ctx->cipher_mode == DRV_CIPHER_CCM)
memcpy(areq_ctx->backup_giv, areq_ctx->ctr_iv + 
CCM_BLOCK_IV_OFFSET, CCM_BLOCK_IV_SIZE);
-   }
}
}
 
@@ -521,9 +520,8 @@ ssi_get_plain_hmac_key(struct crypto_aead *tfm, const u8 
*key, unsigned int keyl
if (unlikely(rc != 0))
SSI_LOG_ERR("send_request() failed (rc=%d)\n", rc);
 
-   if (likely(key_dma_addr != 0)) {
+   if (likely(key_dma_addr != 0))
dma_unmap_single(dev, key_dma_addr, keylen, DMA_TO_DEVICE);
-   }
 
return rc;
 }
@@ -928,11 +926,10 @@ static inline void ssi_aead_setup_cipher_desc(
set_flow_mode(&desc[idx], ctx->flow_mode);
set_din_type(&desc[idx], DMA_DLLI, req_ctx->gen_ctx.iv_dma_addr,
 hw_iv_size, NS_BIT);
-   if (ctx->cipher_mode == DRV_CIPHER_CTR) {
+   if (ctx->cipher_mode == DRV_CIPHER_CTR)
set_setup_mode(&desc[idx], SETUP_LOAD_STATE1);
-   } else {
+   else
set_setup_mode(&desc[idx], SETUP_LOAD_STATE0);
-   }
set_cipher_mode(&desc[idx], ctx->cipher_mode);
idx++;
 
@@ -1375,9 +1372,9 @@ static int validate_data_size(struct ssi_aead_ctx *ctx,
 static unsigned int format_ccm_a0(u8 *pA0Buff, u32 headerSize)
 {
unsigned int len = 0;
-   if (headerSize == 0) {
+   if (headerSize == 0)
return 0;
-   }
+
if (headerSize < ((1UL << 16) - (1UL << 8))) {
len = 2;
 
@@ -1498,9 +1495,8 @@ static inline int ssi_aead_ccm(
}
 
/* process the cipher */
-   if (req_ctx->cryptlen != 0) {
+   if (req_ctx->cryptlen != 0)
ssi_aead_process_cipher_data_desc(req, cipher_flow_mode, desc, 
&idx);
-   }
 
/* Read temporal MAC */
hw_desc_init(&desc[idx]);
@@ -1579,9 +1575,8 @@ static int config_ccm_adata(struct aead_request *req)
*b0 |= 64;  /* Enable bit 6 if Adata exists. */
 
rc = set_msg_len(b0 + 16 - l, cryptlen, l);  /* Write L'. */
-   if (rc != 0) {
+   if (rc != 0)
return rc;
-   }
 /* END of "taken from crypto/ccm.c" */
 
/* l(a) - size of associated data. */
@@ -1861,9 +1856,8 @@ static inline void ssi_aead_dump_gcm(
SSI_LOG_DEBUG("cipher_mode %d, authsize %d, enc_keylen %d, assoclen %d, 
cryptlen %d\n", \
 ctx->cipher_mode, ctx->authsize, 
ctx->enc_keylen, req->assoclen, req_ctx->cryptlen);
 
-   if (ctx->enckey != NULL) {
+   if (ctx->enckey != NULL)
dump_byte_array("mac key", ctx->enckey, 16);
-   }
 
dump_byte_array("req->iv", req->iv, AES_BLOCK_SIZE);
 
@@ -1877,13 +1871,11 @@ static inline void ssi_aead_dump_gcm(
 
dump_byte_array("gcm_len_block", req_ctx->gcm_len_block.lenA, 
AES_BLOCK_SIZE);
 
-   if (req->src != NULL && req->cryptlen) {
+   if (req->src != NULL && req->cryptlen)
dump_byte_array("req->src", sg_virt(req->src), req->cryptlen + 
req->assoclen);
-   }
 
-   if (req->dst != NULL) {
+   if (req->dst != NULL)
dump_byte_array("req->dst", sg_virt(req->dst), req->cryptlen + 
ctx->authsize + req->assoclen);
-   }
 }
 #endif
 
@@ -2083,14 +2075,12 @@ static int ssi_aead_process(struct aead_request *req, 
enum drv_cryp

[PATCH 06/14] staging: ccree: fix unmatched if/else braces

[Gilad Ben-Yossef]

Fix mismatched braces between if and else.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_buffer_mgr.c | 3 ++-
 drivers/staging/ccree/ssi_cipher.c | 7 +++
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c 
b/drivers/staging/ccree/ssi_buffer_mgr.c
index 9e8a134..f9720fc 100644
--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -551,8 +551,9 @@ int ssi_buffer_mgr_map_blkcipher_request(
SSI_LOG_DEBUG("Mapped iv %u B at va=%pK to dma=0x%llX\n",
ivsize, info,
(unsigned long long)req_ctx->gen_ctx.iv_dma_addr);
-   } else
+   } else {
req_ctx->gen_ctx.iv_dma_addr = 0;
+   }
 
/* Map the src SGL */
rc = ssi_buffer_mgr_map_scatterlist(dev, src,
diff --git a/drivers/staging/ccree/ssi_cipher.c 
b/drivers/staging/ccree/ssi_cipher.c
index c233b7c..88ed777 100644
--- a/drivers/staging/ccree/ssi_cipher.c
+++ b/drivers/staging/ccree/ssi_cipher.c
@@ -401,8 +401,9 @@ static int ssi_blkcipher_setkey(struct crypto_tfm *tfm,
/* STAT_PHASE_1: Copy key to ctx */
dma_sync_single_for_cpu(dev, ctx_p->user.key_dma_addr,
max_key_buf_size, DMA_TO_DEVICE);
-#if SSI_CC_HAS_MULTI2
+
if (ctx_p->flow_mode == S_DIN_to_MULTI2) {
+#if SSI_CC_HAS_MULTI2
memcpy(ctx_p->user.key, key, CC_MULTI2_SYSTEM_N_DATA_KEY_SIZE);
ctx_p->key_round_number = key[CC_MULTI2_SYSTEM_N_DATA_KEY_SIZE];
if (ctx_p->key_round_number < CC_MULTI2_MIN_NUM_ROUNDS ||
@@ -410,10 +411,8 @@ static int ssi_blkcipher_setkey(struct crypto_tfm *tfm,
crypto_tfm_set_flags(tfm, CRYPTO_TFM_RES_BAD_KEY_LEN);
SSI_LOG_DEBUG("ssi_blkcipher_setkey: SSI_CC_HAS_MULTI2 
einval");
return -EINVAL;
-   }
-   } else
 #endif /*SSI_CC_HAS_MULTI2*/
-   {
+   } else {
memcpy(ctx_p->user.key, key, keylen);
if (keylen == 24)
memset(ctx_p->user.key + 24, 0, CC_AES_KEY_SIZE_MAX - 
24);
-- 
2.1.4

[PATCH 04/14] staging: ccree: remove redundant blank lines

[Gilad Ben-Yossef]

Remove redundant blank lines in brace blocks

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_aead.c| 2 --
 drivers/staging/ccree/ssi_buffer_mgr.c  | 8 
 drivers/staging/ccree/ssi_cipher.c  | 5 -
 drivers/staging/ccree/ssi_driver.c  | 1 -
 drivers/staging/ccree/ssi_hash.c| 2 --
 drivers/staging/ccree/ssi_pm.c  | 1 -
 drivers/staging/ccree/ssi_request_mgr.c | 1 -
 7 files changed, 20 deletions(-)

diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 00375b6..5782c9d 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -2042,7 +2042,6 @@ static int ssi_aead_process(struct aead_request *req, 
enum drv_crypto_direction
 
/* do we need to generate IV? */
if (areq_ctx->backup_giv != NULL) {
-
/* set the DMA mapped IV address*/
if (ctx->cipher_mode == DRV_CIPHER_CTR) {
ssi_req.ivgen_dma_addr[0] = 
areq_ctx->gen_ctx.iv_dma_addr + CTR_RFC3686_NONCE_SIZE;
@@ -2181,7 +2180,6 @@ static int ssi_aead_decrypt(struct aead_request *req)
req->iv = areq_ctx->backup_iv;
 
return rc;
-
 }
 
 #if SSI_CC_HAS_AES_CCM
diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c 
b/drivers/staging/ccree/ssi_buffer_mgr.c
index 3c74ae3..63f057e 100644
--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -608,7 +608,6 @@ int ssi_buffer_mgr_map_blkcipher_request(
rc = ssi_buffer_mgr_generate_mlli(dev, &sg_data, mlli_params);
if (unlikely(rc != 0))
goto ablkcipher_exit;
-
}
 
SSI_LOG_DEBUG("areq_ctx->dma_buf_type = %s\n",
@@ -877,7 +876,6 @@ static inline int ssi_buffer_mgr_aead_chain_assoc(
if (areq_ctx->ccm_hdr_size != ccm_header_size_null) {
if (unlikely((mapped_nents + 1) >
LLI_MAX_NUM_OF_ASSOC_DATA_ENTRIES)) {
-
SSI_LOG_ERR("CCM case.Too many fragments. "
"Current %d max %d\n",
(areq_ctx->assoc.nents + 1),
@@ -895,7 +893,6 @@ static inline int ssi_buffer_mgr_aead_chain_assoc(
 
if (unlikely((do_chain) ||
(areq_ctx->assoc_buff_type == SSI_DMA_BUF_MLLI))) {
-
SSI_LOG_DEBUG("Chain assoc: buff_type=%s nents=%u\n",
GET_DMA_BUFFER_TYPE(areq_ctx->assoc_buff_type),
areq_ctx->assoc.nents);
@@ -1178,7 +1175,6 @@ static inline int ssi_buffer_mgr_aead_chain_data(
 
//check where the data starts
while (sg_index <= size_to_skip) {
-
offset -= areq_ctx->dstSgl->length;
areq_ctx->dstSgl = sg_next(areq_ctx->dstSgl);
//if have reached the end of the sgl, then this is unexpected
@@ -1450,7 +1446,6 @@ int ssi_buffer_mgr_map_aead_request(
if (unlikely(
(areq_ctx->assoc_buff_type == SSI_DMA_BUF_MLLI) ||
(areq_ctx->data_buff_type == SSI_DMA_BUF_MLLI))) {
-
mlli_params->curr_pool = buff_mgr->mlli_buffs_pool;
rc = ssi_buffer_mgr_generate_mlli(dev, &sg_data, mlli_params);
if (unlikely(rc != 0)) {
@@ -1528,7 +1523,6 @@ int ssi_buffer_mgr_map_hash_request_final(
} else {
areq_ctx->data_dma_buf_type = SSI_DMA_BUF_MLLI;
}
-
}
 
/*build mlli */
@@ -1675,7 +1669,6 @@ int ssi_buffer_mgr_map_hash_request_update(
  mlli_params) != 0)) {
goto fail_unmap_din;
}
-
}
areq_ctx->buff_index = (areq_ctx->buff_index ^ swap_index);
 
@@ -1771,7 +1764,6 @@ int ssi_buffer_mgr_fini(struct ssi_drvdata *drvdata)
dma_pool_destroy(buff_mgr_handle->mlli_buffs_pool);
kfree(drvdata->buff_mgr_handle);
drvdata->buff_mgr_handle = NULL;
-
}
return 0;
 }
diff --git a/drivers/staging/ccree/ssi_cipher.c 
b/drivers/staging/ccree/ssi_cipher.c
index 1dab3e6..722b307 100644
--- a/drivers/staging/ccree/ssi_cipher.c
+++ b/drivers/staging/ccree/ssi_cipher.c
@@ -104,7 +104,6 @@ static int validate_keys_sizes(struct ssi_ablkcipher_ctx 
*ctx_p, u32 size) {
 #endif
default:
break;
-
}
return -EINVAL;
 }
@@ -158,7 +157,6 @@ static int validate_data_size(struct ssi_ablkcipher_ctx 
*ctx_p, unsigned int siz
 #endif /*SSI_CC_HAS_MULTI2*/
default:
break;
-
}
return -EINVAL;
 }
@@ -498,7 +496,6 @@ ssi_blkcipher_create_setup_desc(
set_cipher_mode(&desc[*seq_size], cipher_mode);
set_cipher_config0(&desc[*seq_size], direction);
if (flow_mode == S_DIN_to_AES) {
-
if (ssi_is_hw_key(tfm)) {
set_hw_crypto_key(&

Re: [PATCH 22/23] usercopy: split user-controlled slabs to separate caches

[Michal Hocko]

On Tue 20-06-17 15:22:58, Kees Cook wrote:
> On Tue, Jun 20, 2017 at 1:24 PM, Laura Abbott  wrote:
> > On 06/19/2017 04:36 PM, Kees Cook wrote:
> >> From: David Windsor 
> >>
> >> Some userspace APIs (e.g. ipc, seq_file) provide precise control over
> >> the size of kernel kmallocs, which provides a trivial way to perform
> >> heap overflow attacks where the attacker must control neighboring
> >> allocations of a specific size. Instead, move these APIs into their own
> >> cache so they cannot interfere with standard kmallocs. This is enabled
> >> with CONFIG_HARDENED_USERCOPY_SPLIT_KMALLOC.
> >>
> >> This patch is modified from Brad Spengler/PaX Team's PAX_USERCOPY_SLABS
> >> code in the last public patch of grsecurity/PaX based on my understanding
> >> of the code. Changes or omissions from the original code are mine and
> >> don't reflect the original grsecurity/PaX code.
> >>
> >> Signed-off-by: David Windsor 
> >> [kees: added SLAB_NO_MERGE flag to allow split of future no-merge Kconfig]
> >> Signed-off-by: Kees Cook 
> >
> > I just did a quick test of kspp/usercopy-whitelist/lateston my arm64 
> > machine and got some spew:
> >
> > [   21.818719] Unexpected gfp: 0x400 (0x400). Fixing up to gfp: 
> > 0x14000c0 (GFP_KERNEL). Fix your code!
> > [   21.828427] CPU: 7 PID: 652 Comm: irqbalance Tainted: GW   
> > 4.12.0-rc5-whitelist+ #236
> > [   21.837259] Hardware name: AppliedMicro X-Gene Mustang Board/X-Gene 
> > Mustang Board, BIOS 3.06.12 Aug 12 2016
> > [   21.846955] Call trace:
> > [   21.849396] [] dump_backtrace+0x0/0x210
> > [   21.854770] [] show_stack+0x24/0x30
> > [   21.859798] [] dump_stack+0x90/0xb4
> > [   21.864827] [] new_slab+0x88/0x90
> > [   21.869681] [] ___slab_alloc+0x428/0x6b0
> > [   21.875141] [] __slab_alloc+0x50/0x68
> > [   21.880341] [] __kmalloc_node+0xd0/0x348
> > [   21.885800] [] kvmalloc_node+0xa0/0xb8
> > [   21.891088] [] single_open_size+0x40/0xb0
> > [   21.896636] [] stat_open+0x54/0x60
> > [   21.901576] [] proc_reg_open+0x90/0x168
> > [   21.906950] [] do_dentry_open+0x1c4/0x328
> > [   21.912496] [] vfs_open+0x58/0x88
> > [   21.917351] [] do_last+0x3d4/0x770
> > [   21.922292] [] path_openat+0x8c/0x2e8
> > [   21.927492] [] do_filp_open+0x70/0xe8
> > [   21.932692] [] do_sys_open+0x178/0x208
> > [   21.937977] [] SyS_openat+0x3c/0x50
> > [   21.943005] [] el0_svc_naked+0x24/0x28
> >
> >
> > I don't think 7e7844226f10 ("lockdep: allow to disable reclaim lockup 
> > detection")
> > is correct after new flags are added because we will still need space
> > for another bit even if lockdep is disabled. That might need to
> > be fixed separately.
> 
> Err... that commit has "___GFP_NOLOCKDEP   0x400u", but my
> tree shows it as 0x200u? Hmm, looks like 1bde33e05123
> ("include/linux/gfp.h: fix ___GFP_NOLOCKDEP value") fixed that?

yes

> Oh, or
> I have misread it. It looks like new GFP flags need to be added
> _above_ GFP_NOLOCKDEP and have to bump GFP_NOLOCKDEP's value too? Like
> this:
> 
> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> index ff4f4a698ad0..deb8ac39fba5 100644
> --- a/include/linux/gfp.h
> +++ b/include/linux/gfp.h
> @@ -40,12 +40,12 @@ struct vm_area_struct;
>  #define ___GFP_DIRECT_RECLAIM  0x40u
>  #define ___GFP_WRITE   0x80u
>  #define ___GFP_KSWAPD_RECLAIM  0x100u
> +#define ___GFP_USERCOPY0x200u
>  #ifdef CONFIG_LOCKDEP
> -#define ___GFP_NOLOCKDEP   0x200u
> +#define ___GFP_NOLOCKDEP   0x400u
>  #else
>  #define ___GFP_NOLOCKDEP   0
>  #endif
> -#define ___GFP_USERCOPY0x400u
>  /* If the above are modified, __GFP_BITS_SHIFT may need updating */

yes, this would work for your case. But...

> > I'm really not a fan the GFP approach though since the flags tend
> > to be a little bit fragile to manage. If we're going to have to
> > add something to callsites anyway, maybe we could just have an
> > alternate function (kmalloc_user?) instead of a GFP flag.

I agree. One additional concern I would have is that people tend to
propagate gfp maks down different layers. What would happen if such a
flag gets to a caller which doesn't expect it. Couldn't it reduce the
whole security point of this excercise?

But I am not really sure I understand consequences of this patch. So how
do those attacks look like. Do you have an example of a CVE which would
be prevented by this measure?

> This would mean building out *_user() versions for all the various
> *alloc() functions, though. That gets kind of long/ugly.

Only prepare those which are really needed. It seems only handful of
them in your patch.

> The other reason to use a GFP flag is to be able to interrogate a
> cache later, which will be handy for doing things like %p and kernel
> symbol censorship (this is what grsecurity does with their HIDESYM
> logic). "If this would write to a usercopy-whitelisted object, censor
> it" etc. Though now that I go double-check, it looks like grsec

Re: [PATCH for 4.12] Revert "pinctrl: rockchip: avoid hardirq-unsafe functions in irq_chip"

[Tony Lindgren]

* Brian Norris  [170627 00:07]:
> On Mon, Jun 26, 2017 at 11:24:09PM -0700, Tony Lindgren wrote:
> > Hmm so how come drivers/bluetooth/btusb.c can't use the generic
> > dev_pm_set_dedicated_wake_irq()? Can you please take a look?
> 
> I took a look previously, and last time I did, there were too many bugs
> for it to be useful. You may have fixed the ones I reported w.r.t.
> assumptions about runtime PM.

Yes several issues got fixed over past few years. If you find issues
please let me know, otherwise I can't help.

> I also recall there being some difficulty with supporting
> level-triggered interrupts that way. (This signal has no device-level
> mask, and it triggers for all sorts of BT activity. There may not be a
> relevant "edge".)

Well typically the wakeirq needs to be disabled during runtime like we
do for the generic wakeirqs. It might be connected to the RX line for
example so it's just noise during runtime. If you actually need it during
runtime then it's a separate story but I doubt that's the case here.

Talking of GPIO interrupt triggering, I wonder if something like below
might help? It seems we're missing the setting of triggering, see below.

> > If there are issues remaining let's rather fix them so we can get rid
> > of the custom tinkering of wake-up events in the drivers.
> 
> That's nice, but that doesn't answer my questions. Perhaps that's a side
> project. The point is that we're clearly violating the documented APIs.

Certainly all these issues need to be fixed if we intent to use it. Funny
how I have not run into these with my test cases. Do you have a GPIO
irqchip on I2C for handling the wake-up interrupts?

Regards,

Tony

8< ---
diff --git a/drivers/base/power/wakeirq.c b/drivers/base/power/wakeirq.c
--- a/drivers/base/power/wakeirq.c
+++ b/drivers/base/power/wakeirq.c
@@ -198,7 +198,8 @@ int dev_pm_set_dedicated_wake_irq(struct device *dev, int 
irq)
 * so we use a threaded irq.
 */
err = request_threaded_irq(irq, NULL, handle_threaded_wake_irq,
-  IRQF_ONESHOT, dev_name(dev), wirq);
+  irq_get_trigger_type(irq) | IRQF_ONESHOT,
+  dev_name(dev), wirq);
if (err)
goto err_free;
 

Re: [PATCH] HID: wacom:fix spelling mistake: "exising" -> "existing"

[Benjamin Tissoires]

On Jun 26 2017 or thereabouts, Colin King wrote:
> From: Colin Ian King 
> 
> trivial fix to spelling mistake in hid_warn warning message
> 
> Signed-off-by: Colin Ian King 
> ---

Looks good to me:
Reviewed-by: Benjamin Tissoires 

Cheers,
Benjamin

>  drivers/hid/wacom_wac.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
> index 1992bb0732c2..9f940293ede4 100644
> --- a/drivers/hid/wacom_wac.c
> +++ b/drivers/hid/wacom_wac.c
> @@ -2110,28 +2110,28 @@ static void wacom_wac_pen_event(struct hid_device 
> *hdev, struct hid_field *field
>   return;
>   case WACOM_HID_WD_OFFSETLEFT:
>   if (features->offset_left && value != features->offset_left)
> - hid_warn(hdev, "%s: overriding exising left offset "
> + hid_warn(hdev, "%s: overriding existing left offset "
>"%d -> %d\n", __func__, value,
>features->offset_left);
>   features->offset_left = value;
>   return;
>   case WACOM_HID_WD_OFFSETRIGHT:
>   if (features->offset_right && value != features->offset_right)
> - hid_warn(hdev, "%s: overriding exising right offset "
> + hid_warn(hdev, "%s: overriding existing right offset "
>"%d -> %d\n", __func__, value,
>features->offset_right);
>   features->offset_right = value;
>   return;
>   case WACOM_HID_WD_OFFSETTOP:
>   if (features->offset_top && value != features->offset_top)
> - hid_warn(hdev, "%s: overriding exising top offset "
> + hid_warn(hdev, "%s: overriding existing top offset "
>"%d -> %d\n", __func__, value,
>features->offset_top);
>   features->offset_top = value;
>   return;
>   case WACOM_HID_WD_OFFSETBOTTOM:
>   if (features->offset_bottom && value != features->offset_bottom)
> - hid_warn(hdev, "%s: overriding exising bottom offset "
> + hid_warn(hdev, "%s: overriding existing bottom offset "
>"%d -> %d\n", __func__, value,
>features->offset_bottom);
>   features->offset_bottom = value;
> -- 
> 2.11.0
> 

Re: [PATCH v2 16/51] block: bounce: avoid direct access to bvec table

[Ming Lei]

On Mon, Jun 26, 2017 at 11:12:11PM -0700, Matthew Wilcox wrote:
> On Mon, Jun 26, 2017 at 08:09:59PM +0800, Ming Lei wrote:
> > bio_for_each_segment_all(bvec, bio, i) {
> > -   org_vec = bio_orig->bi_io_vec + i + start;
> > -
> > -   if (bvec->bv_page == org_vec->bv_page)
> > -   continue;
> > +   orig_vec = bio_iter_iovec(bio_orig, orig_iter);
> > +   if (bvec->bv_page == orig_vec.bv_page)
> > +   goto next;
> >  
> > dec_zone_page_state(bvec->bv_page, NR_BOUNCE);
> > mempool_free(bvec->bv_page, pool);
> > + next:
> > +   bio_advance_iter(bio_orig, &orig_iter, orig_vec.bv_len);
> > }
> >  
> 
> I think this might be written more clearly as:
> 
>   bio_for_each_segment_all(bvec, bio, i) {
>   orig_vec = bio_iter_iovec(bio_orig, orig_iter);
>   if (bvec->bv_page != orig_vec.bv_page) {
>   dec_zone_page_state(bvec->bv_page, NR_BOUNCE);
>   mempool_free(bvec->bv_page, pool);
>   }
>   bio_advance_iter(bio_orig, &orig_iter, orig_vec.bv_len);
>   }
> 
> What do you think?

Yeah, looks the above code is more clean, will do it in V3.

thanks,
Ming

Re: [PATCH v2] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

[Daniel Vetter]

On Mon, Jun 26, 2017 at 03:44:07PM -0400, Harry Wentland wrote:
> On 2017-06-20 01:57 PM, Andrey Grodzovsky wrote:
> > Problem : While running IGT kms_atomic_transition test suite i encountered
> > a hang in drmHandleEvent immediately following  an atomic_commit.
> > After dumping the atomic state I relized that in this case there was
> > not even one CRTC attached to the state and only disabled
> > planes. This probably due to a commit which hadn't changed any property
> > which would require attaching crtc state. This means drmHandleEvent
> > will never wake up from read since without CRTC in atomic state
> > the event fd will not be signaled.
> > 
> > Fix: Protect against this issue by failing atomic_commit early in
> > drm_mode_atomic_commit where such probelm can be identified.
> > 
> > v2:
> > Fix typos and extra newlines.
> > 
> > Change-Id: I3ee28ffae35fd1e8bfe553146c44da53da02e6f8
> > Signed-off-by: Andrey Grodzovsky 
> 
> Reviewed-by: Harry Wentland 

Stalling on this hoping for the igt patch. Does it exist already?
-Daniel

> 
> Harry
> 
> > ---
> >  drivers/gpu/drm/drm_atomic.c | 11 ++-
> >  1 file changed, 10 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index a567310..48145bf 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1933,7 +1933,7 @@ static int prepare_crtc_signaling(struct drm_device 
> > *dev,
> >  {
> > struct drm_crtc *crtc;
> > struct drm_crtc_state *crtc_state;
> > -   int i, ret;
> > +   int i, c = 0, ret;
> >  
> > if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY)
> > return 0;
> > @@ -1994,8 +1994,17 @@ static int prepare_crtc_signaling(struct drm_device 
> > *dev,
> >  
> > crtc_state->event->base.fence = fence;
> > }
> > +
> > +   c++;
> > }
> >  
> > +   /*
> > +* Having this flag means user mode pends on event which will never
> > +* reach due to lack of at least one CRTC for signaling
> > +*/
> > +   if (c == 0 && (arg->flags & DRM_MODE_PAGE_FLIP_EVENT))
> > +   return -EINVAL;
> > +
> > return 0;
> >  }
> >  
> > 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: mmotm 2017-06-23-15-03 uploaded

[Rasmus Villemoes]

>>
>> However, the patch in mmotm seems to be missing this crucial hunk that
>> Rasmus had in the patch he sent [1]:
>>
>> -__rmqueue_fallback(struct zone *zone, unsigned int order, int
>> start_migratetype)
>> +__rmqueue_fallback(struct zone *zone, int order, int start_migratetype)
>>
>> which makes this a signed vs signed comparison.
>>
>> What happened to it? Andrew?

This is really odd. Checking, I see that it was also absent from the
'this patch has been added to -mm' mail, but I admit I don't proofread
those to see they match what I sent. Oh well. Let me know if I need to
do anything.

Rasmus

Re: [PATCH 1/2] dt-bindings: spi: Document the STM32 SPI bindings

[Amelie DELAUNAY]

Hi Rob,

On 06/26/2017 08:21 PM, Rob Herring wrote:

On Wed, Jun 21, 2017 at 04:32:05PM +0200, Amelie Delaunay wrote:

This patch adds the documentation of device tree bindings
for the STM32 SPI controller.

Signed-off-by: Amelie Delaunay 
---
  .../devicetree/bindings/spi/spi-stm32.txt  | 60 ++
  1 file changed, 60 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/spi/spi-stm32.txt

diff --git a/Documentation/devicetree/bindings/spi/spi-stm32.txt 
b/Documentation/devicetree/bindings/spi/spi-stm32.txt
new file mode 100644
index 000..3958bf6
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-stm32.txt
@@ -0,0 +1,60 @@
+STMicroelectronics STM32 SPI Controller
+
+The STM32 SPI controller is used to communicate with external devices using
+the Serial Peripheral Interface. It supports full-duplex, half-duplex and
+simplex synchronous serial communication with external devices. It supports
+from 4 to 32-bit data size. Although it can be configured as master or slave,
+only master is supported by the driver.
+
+Required properties:
+- compatible: Must be "st,stm32-spi".
+- reg: Offset and length of the device's register set.
+- interrupts: Must contain the interrupt id.
+- clocks: Must contain an entry for spiclk (which feeds the internal clock
+ generator).
+- #address-cells:  Number of cells required to define a chip select address.
+- #size-cells: Should be zero.
+
+Optional properties:
+- resets: Must contain the phandle to the reset controller.
+- A pinctrl state named "default" may be defined to set pins in mode of
+  operation for SPI transfer.
+- dmas: DMA specifiers for tx and rx dma. DMA fifo mode must be used. See the
+  STM32 DMA bindings, Documentation/devicetree/bindings/dma/stm32-dma.txt.
+- dma-names: DMA request names should include "tx" and "rx" if present.
+- cs-gpios: list of GPIO chip selects. See the SPI bus bindings,
+  Documentation/devicetree/bindings/spi/spi-bus.txt
+
+
+Child nodes represent devices on the SPI bus
+  See ../spi/spi-bus.txt
+
+Optional properties:
+- st,spi-midi-ns: (Master Inter-Data Idleness) minimum time delay in
+ nanoseconds inserted between two consecutive data frames.
+
+
+Example:
+   spi2: spi@40003800 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "st,stm32-spi";
+   reg = <0x40003800 0x400>;
+   interrupts = <36>;
+   clocks = <&rcc SPI2_CK>;
+   resets = <&rcc 1166>;
+   dmas = <&dmamux1 0 39 0x400 0x01>,
+  <&dmamux1 1 40 0x400 0x01>;
+   dma-names = "rx", "tx";
+   pinctrl-0 = <&spi2_pins_b>;
+   pinctrl-names = "default";
+   status = "okay";


Don't show status in examples.


Ok.

+   cs-gpios = <&gpioa 11 0>;
+
+   spidev@0 {
+   compatible = "spidev";


This is not a valid compatible. Pick a real device.

Ok this was just to illustrate the optional property st,spi-midi-ns.


Rob



I will send a new patch to fix these issues.
Thanks,

Amelie

[PATCH] net/mlx5: fix spelling mistake: "alloated" -> "allocated"

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistake in mlx5_ib_dbg message

Signed-off-by: Colin Ian King 
---
 drivers/infiniband/hw/mlx5/main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/infiniband/hw/mlx5/main.c 
b/drivers/infiniband/hw/mlx5/main.c
index 9f7e18612322..db67a61085f7 100644
--- a/drivers/infiniband/hw/mlx5/main.c
+++ b/drivers/infiniband/hw/mlx5/main.c
@@ -1151,7 +1151,7 @@ static int calc_total_bfregs(struct mlx5_ib_dev *dev, 
bool lib_uar_4k,
if (req->num_low_latency_bfregs > req->total_num_bfregs - 1)
return -EINVAL;
 
-   mlx5_ib_dbg(dev, "uar_4k: fw support %s, lib support %s, user requested 
%d bfregs, alloated %d, using %d sys pages\n",
+   mlx5_ib_dbg(dev, "uar_4k: fw support %s, lib support %s, user requested 
%d bfregs, allocated %d, using %d sys pages\n",
MLX5_CAP_GEN(dev->mdev, uar_4k) ? "yes" : "no",
lib_uar_4k ? "yes" : "no", ref_bfregs,
req->total_num_bfregs, *num_sys_pages);
-- 
2.11.0

[PATCH v2 1/2] Staging: rtl8712 : os_intfs.c: use octal permission representation

[Jaya Durga]

Fix checkpatch.pl Warning: Symbolic permissions 'S_IRUGO | S_IWUSR' are not 
preferred.
Consider using octal permissions '0644'.

Signed-off-by: Jaya Durga 
---
 drivers/staging/rtl8712/os_intfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8712/os_intfs.c 
b/drivers/staging/rtl8712/os_intfs.c
index 8836b31..e698f6e 100644
--- a/drivers/staging/rtl8712/os_intfs.c
+++ b/drivers/staging/rtl8712/os_intfs.c
@@ -93,7 +93,7 @@
  */
 static int wifi_test;
 
-module_param_string(ifname, ifname, sizeof(ifname), S_IRUGO | S_IWUSR);
+module_param_string(ifname, ifname, sizeof(ifname), 0644);
 module_param(wifi_test, int, 0644);
 module_param(initmac, charp, 0644);
 module_param(video_mode, int, 0644);
-- 
1.9.1

[PATCH] sparc: time: make of_device_ids const.

[Arvind Yadav]

of_device_ids are not supposed to change at runtime. All functions
working with of_device_ids provided by  work with const
of_device_ids. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
   10821048 3362466 9a2 arch/sparc/kernel/time_32.o

File size after constify:
   textdata bss dec hex filename
   1482 632 3362450 992 arch/sparc/kernel/time_32.o

Signed-off-by: Arvind Yadav 
---
 arch/sparc/kernel/time_32.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/sparc/kernel/time_32.c b/arch/sparc/kernel/time_32.c
index 9f575df..2ce2e7b 100644
--- a/arch/sparc/kernel/time_32.c
+++ b/arch/sparc/kernel/time_32.c
@@ -298,7 +298,7 @@ static int clock_probe(struct platform_device *op)
return 0;
 }
 
-static struct of_device_id clock_match[] = {
+static const struct of_device_id clock_match[] = {
{
.name = "eeprom",
},
-- 
1.9.1

[PATCH v5 1/1] f2fs: dax: implement direct access

[sunqiuyang]

From: Qiuyang Sun 

This patch implements Direct Access (DAX) in F2FS, including:
- a mount option to choose whether to enable DAX or not
- read/write and mmap of regular files in the DAX way
- zero-out of unaligned partial blocks in the DAX way
- garbage collection of DAX files, by mapping both old and new physical
  addresses of a data page into memory and copy data between them directly
- incompatibility of DAX with inline data, atomic or volatile write, etc.

Signed-off-by: Qiuyang Sun 
---
Changlog v4 -> v5:

In DAX write, to avoid stale data, the newly allocated blocks should be
zeroed out before writing to them. We introduce a new flag
F2FS_GET_BLOCK_ZERO for f2fs_map_blocks(), for which a single struct
f2fs_map_blocks can never contain old and new blocks at the same time, so
that zeroing out new blocks would not affect old ones. This flag is used in
the write path of f2fs_iomap_begin() for DAX I/O, replacing 
F2FS_GET_BLOCK_PRE_DIO in earlier versions.

---
 fs/f2fs/data.c   | 115 +
 fs/f2fs/f2fs.h   |   9 +++
 fs/f2fs/file.c   | 192 ++-
 fs/f2fs/gc.c | 104 --
 fs/f2fs/inline.c |   4 ++
 fs/f2fs/inode.c  |   8 ++-
 fs/f2fs/namei.c  |   5 ++
 fs/f2fs/super.c  |  15 +
 8 files changed, 445 insertions(+), 7 deletions(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 7d3af48..b28d97a 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -908,6 +908,15 @@ int f2fs_map_blocks(struct inode *inode, struct 
f2fs_map_blocks *map,
err = -EIO;
goto sync_out;
}
+   /*
+* If newly allocated blocks are to be zeroed out later,
+* a single f2fs_map_blocks must not contain both old
+* and new blocks at the same time.
+*/
+   if (flag == F2FS_GET_BLOCK_ZERO
+   && (map->m_flags & F2FS_MAP_MAPPED)
+   && !(map->m_flags & F2FS_MAP_NEW))
+   goto sync_out;
if (flag == F2FS_GET_BLOCK_PRE_AIO) {
if (blkaddr == NULL_ADDR) {
prealloc++;
@@ -994,6 +1003,12 @@ int f2fs_map_blocks(struct inode *inode, struct 
f2fs_map_blocks *map,
goto next_dnode;
 
 sync_out:
+   if (flag == F2FS_GET_BLOCK_ZERO && map->m_flags & F2FS_MAP_NEW) {
+   clean_bdev_aliases(inode->i_sb->s_bdev,
+   map->m_pblk, map->m_len);
+   sb_issue_zeroout(inode->i_sb, map->m_pblk,
+   map->m_len, GFP_NOFS);
+   }
f2fs_put_dnode(&dn);
 unlock_out:
if (create) {
@@ -2257,3 +2272,103 @@ int f2fs_migrate_page(struct address_space *mapping,
.migratepage= f2fs_migrate_page,
 #endif
 };
+
+#ifdef CONFIG_FS_DAX
+#include 
+#include 
+
+static int f2fs_iomap_begin(struct inode *inode, loff_t offset,
+   loff_t length, unsigned int flags, struct iomap *iomap)
+{
+   struct block_device *bdev;
+   unsigned long first_block = F2FS_BYTES_TO_BLK(offset);
+   unsigned long last_block = F2FS_BYTES_TO_BLK(offset + length - 1);
+   struct f2fs_map_blocks map;
+   int ret;
+
+   if (WARN_ON_ONCE(f2fs_has_inline_data(inode)))
+   return -ERANGE;
+
+   map.m_lblk = first_block;
+   map.m_len = last_block - first_block + 1;
+   map.m_next_pgofs = NULL;
+
+   if (!(flags & IOMAP_WRITE))
+   ret = f2fs_map_blocks(inode, &map, 0, F2FS_GET_BLOCK_FIEMAP);
+   else {
+   /* i_size should be kept here and changed later in f2fs_iomap_end */
+   loff_t original_i_size = i_size_read(inode);
+
+   ret = f2fs_map_blocks(inode, &map, 1, F2FS_GET_BLOCK_ZERO);
+   if (i_size_read(inode) > original_i_size) {
+   f2fs_i_size_write(inode, original_i_size);
+   if (ret) {
+   truncate_pagecache(inode, original_i_size);
+   truncate_blocks(inode, original_i_size, true);
+   }
+   }
+   }
+
+   if (ret)
+   return ret;
+
+   iomap->flags = 0;
+   bdev = inode->i_sb->s_bdev;
+   iomap->bdev = bdev;
+   if (blk_queue_dax(bdev->bd_queue))
+   iomap->dax_dev = dax_get_by_host(bdev->bd_disk->disk_name);
+   else
+   iomap->dax_dev = NULL;
+   iomap->offset = F2FS_BLK_TO_BYTES((u64)first_block);
+
+   if (map.m_len == 0) {
+   iomap->type = IOMAP_HOLE;
+   iomap->blkno = IOMAP_NULL_BLOCK;
+   iomap->length = F2FS_BLKSIZE;
+   } else {
+   if (map.m_flags & F2FS_MAP_UNWRITTEN)
+

Re: [PATCH] HID: wacom:fix spelling mistake: "exising" -> "existing"

[Jiri Kosina]

On Mon, 26 Jun 2017, Colin King wrote:

> From: Colin Ian King 
> 
> trivial fix to spelling mistake in hid_warn warning message
> 
> Signed-off-by: Colin Ian King 

Applied to for-4.13/wacom.

-- 
Jiri Kosina
SUSE Labs

[PATCH 1/3] include: uapi: usb: Introduce USB charger type and state definition

[Baolin Wang]

Introducing USB charger type and state definition can help
to support USB charging which will be added in USB phy core.

Signed-off-by: Baolin Wang 
---
 include/uapi/linux/usb/charger.h |   31 +++
 1 file changed, 31 insertions(+)
 create mode 100644 include/uapi/linux/usb/charger.h

diff --git a/include/uapi/linux/usb/charger.h b/include/uapi/linux/usb/charger.h
new file mode 100644
index 000..5f72af3
--- /dev/null
+++ b/include/uapi/linux/usb/charger.h
@@ -0,0 +1,31 @@
+/*
+ * This file defines the USB charger type and state that are needed for
+ * USB device APIs.
+ */
+
+#ifndef _UAPI__LINUX_USB_CHARGER_H
+#define _UAPI__LINUX_USB_CHARGER_H
+
+/*
+ * USB charger type:
+ * SDP (Standard Downstream Port)
+ * DCP (Dedicated Charging Port)
+ * CDP (Charging Downstream Port)
+ * ACA (Accessory Charger Adapters)
+ */
+enum usb_charger_type {
+   UNKNOWN_TYPE,
+   SDP_TYPE,
+   DCP_TYPE,
+   CDP_TYPE,
+   ACA_TYPE,
+};
+
+/* USB charger state */
+enum usb_charger_state {
+   USB_CHARGER_DEFAULT,
+   USB_CHARGER_PRESENT,
+   USB_CHARGER_ABSENT,
+};
+
+#endif /* _UAPI__LINUX_USB_CHARGER_H */
-- 
1.7.9.5

[PATCH 2/3] usb: phy: Add USB charger support

[Baolin Wang]

This patch introduces the usb charger support based on usb phy that
makes an enhancement to a power driver. The basic conception of the
usb charger is that, when one usb charger is added or removed by
reporting from the extcon device state change, the usb charger will
report to power user to set the current limitation.

Power user can register a notifiee on the usb phy by issuing
usb_register_notifier() to get notified by charger status changes
or charger current changes.

we can notify what current to be drawn to power user according to
different charger type, and now we have 2 methods to get charger type.
One is get charger type from extcon subsystem, which also means the
charger state changes. Another is we can get the charger type from
USB controller detecting or PMIC detecting, and the charger state
changes should be told by issuing usb_phy_set_charger_state().

Signed-off-by: Baolin Wang 
---
 drivers/usb/phy/phy.c   |  265 +++
 include/linux/usb/phy.h |   48 +
 2 files changed, 313 insertions(+)

diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index 032f5af..db72802 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -18,6 +18,18 @@
 
 #include 
 
+/* Default current range by charger type. */
+#define DEFAULT_SDP_CUR_MIN2
+#define DEFAULT_SDP_CUR_MAX500
+#define DEFAULT_SDP_CUR_MIN_SS 150
+#define DEFAULT_SDP_CUR_MAX_SS 900
+#define DEFAULT_DCP_CUR_MIN500
+#define DEFAULT_DCP_CUR_MAX5000
+#define DEFAULT_CDP_CUR_MIN1500
+#define DEFAULT_CDP_CUR_MAX5000
+#define DEFAULT_ACA_CUR_MIN1500
+#define DEFAULT_ACA_CUR_MAX5000
+
 static LIST_HEAD(phy_list);
 static LIST_HEAD(phy_bind_list);
 static DEFINE_SPINLOCK(phy_lock);
@@ -77,6 +89,216 @@ static struct usb_phy *__of_usb_find_phy(struct device_node 
*node)
return ERR_PTR(-EPROBE_DEFER);
 }
 
+static void usb_phy_set_default_current(struct usb_phy *usb_phy)
+{
+   usb_phy->chg_cur.sdp_min = DEFAULT_SDP_CUR_MIN;
+   usb_phy->chg_cur.sdp_max = DEFAULT_SDP_CUR_MAX;
+   usb_phy->chg_cur.dcp_min = DEFAULT_DCP_CUR_MIN;
+   usb_phy->chg_cur.dcp_max = DEFAULT_DCP_CUR_MAX;
+   usb_phy->chg_cur.cdp_min = DEFAULT_CDP_CUR_MIN;
+   usb_phy->chg_cur.cdp_max = DEFAULT_CDP_CUR_MAX;
+   usb_phy->chg_cur.aca_min = DEFAULT_ACA_CUR_MIN;
+   usb_phy->chg_cur.aca_max = DEFAULT_ACA_CUR_MAX;
+}
+
+/**
+ * usb_phy_notify_charger_work - notify the USB charger state
+ * @work - the charger work to notify the USB charger state
+ *
+ * This work can be issued when USB charger state has been changed or
+ * USB charger current has been changed, then we can notify the current
+ * what can be drawn to power user and the charger state to userspace.
+ *
+ * If we get the charger type from extcon subsystem, we can notify the
+ * charger state to power user automatically by usb_phy_get_charger_type()
+ * issuing from extcon subsystem.
+ *
+ * If we get the charger type from ->charger_detect() instead of extcon
+ * subsystem, the usb phy driver should issue usb_phy_set_charger_state()
+ * to set charger state when the charger state has been changed.
+ */
+static void usb_phy_notify_charger_work(struct work_struct *work)
+{
+   struct usb_phy *usb_phy = container_of(work, struct usb_phy, chg_work);
+   char uchger_state[50] = { 0 };
+   char *envp[] = { uchger_state, NULL };
+   unsigned int min, max;
+
+   switch (usb_phy->chg_state) {
+   case USB_CHARGER_PRESENT:
+   usb_phy_get_charger_current(usb_phy, &min, &max);
+
+   atomic_notifier_call_chain(&usb_phy->notifier, max, usb_phy);
+   snprintf(uchger_state, ARRAY_SIZE(uchger_state),
+"USB_CHARGER_STATE=%s", "USB_CHARGER_PRESENT");
+   break;
+   case USB_CHARGER_ABSENT:
+   usb_phy_set_default_current(usb_phy);
+
+   atomic_notifier_call_chain(&usb_phy->notifier, 0, usb_phy);
+   snprintf(uchger_state, ARRAY_SIZE(uchger_state),
+"USB_CHARGER_STATE=%s", "USB_CHARGER_ABSENT");
+   break;
+   default:
+   dev_warn(usb_phy->dev, "Unknown USB charger state: %d\n",
+usb_phy->chg_state);
+   return;
+   }
+
+   kobject_uevent_env(&usb_phy->dev->kobj, KOBJ_CHANGE, envp);
+}
+
+/**
+ * usb_phy_get_charger_type - get charger type from extcon subsystem
+ * @nb -the notifier block to determine charger type
+ * @state - the cable state
+ * @data - private data
+ *
+ * Determin the charger type from extcon subsystem which also means the
+ * charger state has been chaned, then we should notify this event.
+ */
+static int usb_phy_get_charger_type(struct notifier_block *nb,
+   unsigned long state, void *data)
+{
+   struct usb_phy *usb_phy = container_of(nb, struct usb_phy, type_nb);
+
+   if (extcon_get_state(usb_phy->edev, EXTCON_CHG_USB_

[PATCH 3/3] power: wm831x_power: Support USB charger current limit management

[Baolin Wang]

Integrate with the newly added USB charger interface to limit the current
we draw from the USB input based on the input device configuration
identified by the USB stack, allowing us to charge more quickly from high
current inputs without drawing more current than specified from others.

Signed-off-by: Mark Brown 
Signed-off-by: Baolin Wang 
---
 drivers/power/supply/wm831x_power.c |   61 +++
 1 file changed, 61 insertions(+)

diff --git a/drivers/power/supply/wm831x_power.c 
b/drivers/power/supply/wm831x_power.c
index 7082301..3e3480708 100644
--- a/drivers/power/supply/wm831x_power.c
+++ b/drivers/power/supply/wm831x_power.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -31,6 +32,8 @@ struct wm831x_power {
char usb_name[20];
char battery_name[20];
bool have_battery;
+   struct usb_phy *usb_phy;
+   struct notifier_block usb_notify;
 };
 
 static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
@@ -125,6 +128,43 @@ static int wm831x_usb_get_prop(struct power_supply *psy,
POWER_SUPPLY_PROP_VOLTAGE_NOW,
 };
 
+/* In milliamps */
+static const unsigned int wm831x_usb_limits[] = {
+   0,
+   2,
+   100,
+   500,
+   900,
+   1500,
+   1800,
+   550,
+};
+
+static int wm831x_usb_limit_change(struct notifier_block *nb,
+  unsigned long limit, void *data)
+{
+   struct wm831x_power *wm831x_power = container_of(nb,
+struct wm831x_power,
+usb_notify);
+   unsigned int i, best;
+
+   /* Find the highest supported limit */
+   best = 0;
+   for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
+   if (limit >= wm831x_usb_limits[i] &&
+   wm831x_usb_limits[best] < wm831x_usb_limits[i])
+   best = i;
+   }
+
+   dev_dbg(wm831x_power->wm831x->dev,
+   "Limiting USB current to %umA", wm831x_usb_limits[best]);
+
+   wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
+   WM831X_USB_ILIM_MASK, best);
+
+   return 0;
+}
+
 /*
  * Battery properties
  */
@@ -607,6 +647,22 @@ static int wm831x_power_probe(struct platform_device *pdev)
}
}
 
+   power->usb_phy = devm_usb_get_phy_by_phandle(&pdev->dev,
+"usb-phy", 0);
+   if (IS_ERR(power->usb_phy)) {
+   ret = PTR_ERR(power->usb_phy);
+   dev_err(&pdev->dev, "Failed to find USB phy: %d\n", ret);
+   goto err_bat_irq;
+   }
+
+   power->usb_notify.notifier_call = wm831x_usb_limit_change;
+   ret = usb_register_notifier(power->usb_phy,
+   &power->usb_notify);
+   if (ret) {
+   dev_err(&pdev->dev, "Failed to register notifier: %d\n", ret);
+   goto err_bat_irq;
+   }
+
return ret;
 
 err_bat_irq:
@@ -637,6 +693,11 @@ static int wm831x_power_remove(struct platform_device 
*pdev)
struct wm831x *wm831x = wm831x_power->wm831x;
int irq, i;
 
+   if (wm831x_power->usb_phy) {
+   usb_unregister_notifier(wm831x_power->usb_phy,
+   &wm831x_power->usb_notify);
+   }
+
for (i = 0; i < ARRAY_SIZE(wm831x_bat_irqs); i++) {
irq = wm831x_irq(wm831x, 
 platform_get_irq_byname(pdev,
-- 
1.7.9.5

Re: [PATCH] Input: synaptics - switch t460s 20FN to use RMI4 over SMBus

[Benjamin Tissoires]

On Jun 26 2017 or thereabouts, Benjamin Tissoires wrote:
> On Jun 26 2017 or thereabouts, Christopher Bachner wrote:
> > Hello,
> > 
> > I am assuming that if the inertouch message is not showing up in dmesg,
> > then it is working. Is that a correct assumption?
> > 
> > Either way I also attached my dmesg.
> > 
> > I am not sure, though, why the scroll mode still freezes if I move the my
> > fingers quickly on the touchpad while also using the trackpoint. Is that
> > maybe a future fix and this change is just the foundation for it? Overall
> > the usage of the trackpoint is better now for sure.
> 
> Sadly, you are also hit by:
> [6.355378] i801_smbus :00:1f.4: BIOS is accessing SMBus registers
> [6.355380] i801_smbus :00:1f.4: Driver SMBus register access inhibited
> 
> Which disables entirely the RMI4 over SMBus module. And then we can not
> probe for it, meaning you are stuck with the PS/2 crappy mode.
> 
> We are aware of this bug and we'll try to fix that. I think the test you
> provides are valid (the patch works as expected), but a different bug
> prevents rmi-smbus to fully initialize the touchpad :(

Could you try applying Lyude's patch: http://patchwork.ozlabs.org/patch/780865/
(on top of mine, of course).

In the dmesg, you should see a Synaptics TM device appearing after
trying to set up the SMBus companion.

Cheers,
Benjamin

[PATCH 4/4] Staging: rtl8712 : osdep_intf.h: fix macro coding style issue

[Jaya Durga]

Fix checkpatch.pl warning of the form "CHECK" Macro argument 'x'
may be better as '(x)' to avoid precedence issues.

Signed-off-by: Jaya Durga 
---
 drivers/staging/rtl8712/osdep_intf.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8712/osdep_intf.h 
b/drivers/staging/rtl8712/osdep_intf.h
index 1985423..dac6aed 100644
--- a/drivers/staging/rtl8712/osdep_intf.h
+++ b/drivers/staging/rtl8712/osdep_intf.h
@@ -29,7 +29,10 @@
 #include "osdep_service.h"
 #include "drv_types.h"
 
-#define RND4(x)x) >> 2) + x) & 3) == 0) ?  0 : 1)) << 2)
+static inline unsigned int RND4(unsigned int x)
+{
+   return (((x >> 2) + (((x & 3) == 0) ?  0 : 1)) << 2);
+}
 
 struct intf_priv {
u8 *intf_dev;
-- 
1.9.1

[PATCH] checkpatch: add *_ON_STACK to $declaration_macros

[Gilad Ben-Yossef]

Add the crypto API *_ON_STACK to $declaration_macros.

Resolves the following false warning:

WARNING: Missing a blank line after declarations
+   int err;
+   SHASH_DESC_ON_STACK(desc, ctx_p->shash_tfm);

Signed-off-by: Gilad Ben-Yossef 
---
 scripts/checkpatch.pl | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 4b9569f..b42eb62 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -733,6 +733,7 @@ our $FuncArg = 
qr{$Typecast{0,1}($LvalOrFunc|$Constant|$String)};
 our $declaration_macros = qr{(?x:

(?:$Storage\s+)?(?:[A-Z_][A-Z0-9]*_){0,2}(?:DEFINE|DECLARE)(?:_[A-Z0-9]+){1,6}\s*\(|
(?:$Storage\s+)?LIST_HEAD\s*\(|
+   (?:$Storage\s+)?[A-Z_]*_ON_STACK\(|
(?:$Storage\s+)?${Type}\s+uninitialized_var\s*\(
 )};
 
-- 
2.1.4

[PATCH 4/6] drivers: perf: hisi: Add support for HiSilicon SoC HHA PMU driver

[Shaokun Zhang]

L3 cache coherence is maintained by Hydra Home Agent (HHA) in HiSilicon
SoC. This patch adds support for HHA PMU driver, Each HHA has own
control, counter and interrupt registers and is an separate PMU. For
each HHA PMU, it has 16-programable counters and supports 0x50 events,
event code is 8-bits and every counter is free-running. Interrupt is
supported to handle counter (48-bits) overflow.

Signed-off-by: Shaokun Zhang 
Signed-off-by: Anurup M 
---
 drivers/perf/hisilicon/Makefile  |   2 +-
 drivers/perf/hisilicon/hisi_uncore_hha_pmu.c | 451 +++
 2 files changed, 452 insertions(+), 1 deletion(-)
 create mode 100644 drivers/perf/hisilicon/hisi_uncore_hha_pmu.c

diff --git a/drivers/perf/hisilicon/Makefile b/drivers/perf/hisilicon/Makefile
index 4a3d3e6..a72afe8 100644
--- a/drivers/perf/hisilicon/Makefile
+++ b/drivers/perf/hisilicon/Makefile
@@ -1 +1 @@
-obj-$(CONFIG_HISI_PMU) += hisi_uncore_pmu.o hisi_uncore_l3c_pmu.o
+obj-$(CONFIG_HISI_PMU) += hisi_uncore_pmu.o hisi_uncore_l3c_pmu.o 
hisi_uncore_hha_pmu.o
diff --git a/drivers/perf/hisilicon/hisi_uncore_hha_pmu.c 
b/drivers/perf/hisilicon/hisi_uncore_hha_pmu.c
new file mode 100644
index 000..ea8fcde
--- /dev/null
+++ b/drivers/perf/hisilicon/hisi_uncore_hha_pmu.c
@@ -0,0 +1,451 @@
+/*
+ * HiSilicon SoC HHA uncore Hardware event counters support
+ *
+ * Copyright (C) 2017 Hisilicon Limited
+ * Author: Shaokun Zhang 
+ * Anurup M 
+ *
+ * This code is based on the uncore PMUs like arm-cci and arm-ccn.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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 should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "hisi_uncore_pmu.h"
+
+/* HHA register definition */
+#define HHA_INT_MASK   0x0804
+#define HHA_INT_STATUS 0x0808
+#define HHA_INT_CLEAR  0x080C
+#define HHA_PERF_CTRL  0x1E00
+#define HHA_EVENT_CTRL 0x1E04
+#define HHA_EVENT_TYPE00x1E80
+#define HHA_CNT0_LOWER 0x1F00
+
+/* HHA has 16-counters and supports 0x50 events */
+#define HHA_NR_COUNTERS0x10
+#define HHA_NR_EVENTS  0x50
+
+#define HHA_PERF_CTRL_EN   0x1
+#define HHA_EVTYPE_NONE0xff
+
+#define HHA_EVTYPE_REG(idx) (HHA_EVENT_TYPE0 + (idx <= 3 ? 0 : 4 * \
+   (idx / 4)))
+
+/*
+ * Select the counter register offset using the counter index
+ * every counter is 48-bits and [48:63] is reserved.
+ */
+static u32 get_counter_reg_off(int cntr_idx)
+{
+   return (HHA_CNT0_LOWER + (cntr_idx * 8));
+}
+
+static u64 hisi_hha_pmu_read_counter(struct hisi_pmu *hha_pmu,
+struct hw_perf_event *hwc)
+{
+   u32 idx = hwc->idx;
+   u32 reg;
+
+   if (!hisi_uncore_pmu_counter_valid(hha_pmu, idx)) {
+   dev_err(hha_pmu->dev, "Unsupported event index:%d!\n", idx);
+   return 0;
+   }
+
+   reg = get_counter_reg_off(idx);
+
+   /* Read 64 bits and like L3C, top 16 bits are RAZ */
+   return readq(hha_pmu->base + reg);
+}
+
+static void hisi_hha_pmu_write_counter(struct hisi_pmu *hha_pmu,
+  struct hw_perf_event *hwc, u64 val)
+{
+   u32 idx = hwc->idx;
+   u32 reg;
+
+   if (!hisi_uncore_pmu_counter_valid(hha_pmu, idx)) {
+   dev_err(hha_pmu->dev, "Unsupported event index:%d!\n", idx);
+   return;
+   }
+
+   reg = get_counter_reg_off(idx);
+   /* Write 64 bits and like L3C, top 16 bits are WI */
+   writeq(val, hha_pmu->base + reg);
+}
+
+static void hisi_hha_pmu_write_evtype(struct hisi_pmu *hha_pmu, int idx,
+ u32 type)
+{
+   u32 reg, reg_idx, shift, val;
+
+   /*
+* Select the appropriate Event select register(HHA_EVENT_TYPEx).
+* There are 4 event select registers for the 16 hardware counters.
+* Event code is 8-bits and for the first 4 hardware counters,
+* HHA_EVENT_TYPE0 is chosen. For the next 4 hardware counters,
+* HHA_EVENT_TYPE1 is chosen and so on.
+*/
+   reg = HHA_EVTYPE_REG(idx);
+   reg_idx = idx % 4;
+   shift = 8 * reg_idx;
+
+   /* Write event code to HHA_EVENT_TYPEx register */
+   val = readl(hha_pmu->base + reg);
+   val &= ~(HHA_EVTYPE_NONE << shift);
+   val |= (type << shift);
+   writel(val, hha_pmu->base + reg);
+}
+
+static void hisi_hha_pmu_start_counters(struct h

[PATCH 0/6] Add HiSilicon SoC uncore Performance Monitoring Unit driver

[Shaokun Zhang]

This patchset adds support for HiSilicon SoC uncore PMUs driver. It
includes L3C, Hydra Home Agent (HHA) and DDRC.

Shaokun Zhang (6):
  Documentation: perf: hisi: Documentation for HiSilicon SoC PMU driver
  drivers: perf: hisi: Add support for HiSilicon SoC uncore PMU driver
  drivers: perf: hisi: Add support for HiSilicon SoC L3C PMU driver
  drivers: perf: hisi: Add support for HiSilicon SoC HHA PMU driver
  drivers: perf: hisi: Add support for HiSilicon SoC DDRC PMU driver
  arm64: MAINTAINERS: hisi: Add HiSilicon SoC PMU support

 Documentation/perf/hisi-pmu.txt   |  51 +++
 MAINTAINERS   |   7 +
 drivers/perf/Kconfig  |   7 +
 drivers/perf/Makefile |   1 +
 drivers/perf/hisilicon/Makefile   |   1 +
 drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c | 435 
 drivers/perf/hisilicon/hisi_uncore_hha_pmu.c  | 451 +
 drivers/perf/hisilicon/hisi_uncore_l3c_pmu.c  | 554 ++
 drivers/perf/hisilicon/hisi_uncore_pmu.c  | 416 +++
 drivers/perf/hisilicon/hisi_uncore_pmu.h  | 116 ++
 include/linux/cpuhotplug.h|   1 +
 11 files changed, 2040 insertions(+)
 create mode 100644 Documentation/perf/hisi-pmu.txt
 create mode 100644 drivers/perf/hisilicon/Makefile
 create mode 100644 drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c
 create mode 100644 drivers/perf/hisilicon/hisi_uncore_hha_pmu.c
 create mode 100644 drivers/perf/hisilicon/hisi_uncore_l3c_pmu.c
 create mode 100644 drivers/perf/hisilicon/hisi_uncore_pmu.c
 create mode 100644 drivers/perf/hisilicon/hisi_uncore_pmu.h

-- 
1.9.1

[PATCH 6/6] arm64: MAINTAINERS: hisi: Add HiSilicon SoC PMU support

[Shaokun Zhang]

Add support HiSilicon SoC uncore PMU driver.

Signed-off-by: Shaokun Zhang 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index c0348bc..fbd664b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6072,6 +6072,13 @@ S:   Maintained
 F: drivers/net/ethernet/hisilicon/
 F: Documentation/devicetree/bindings/net/hisilicon*.txt
 
+HISILICON PMU DRIVER
+M: Shaokun Zhang 
+W: http://www.hisilicon.com
+S: Supported
+F: drivers/perf/hisilicon/
+F: Documentation/perf/hisi-pmu.txt
+
 HISILICON ROCE DRIVER
 M: Lijun Ou 
 M: Wei Hu(Xavier) 
-- 
1.9.1

[PATCH 2/6] drivers: perf: hisi: Add support for HiSilicon SoC uncore PMU driver

[Shaokun Zhang]

This patch adds support HiSilicon SoC uncore PMU driver framework and
interfaces.

Signed-off-by: Shaokun Zhang 
Signed-off-by: Anurup M 
---
 drivers/perf/Kconfig |   7 +
 drivers/perf/Makefile|   1 +
 drivers/perf/hisilicon/Makefile  |   1 +
 drivers/perf/hisilicon/hisi_uncore_pmu.c | 416 +++
 drivers/perf/hisilicon/hisi_uncore_pmu.h | 116 +
 5 files changed, 541 insertions(+)
 create mode 100644 drivers/perf/hisilicon/Makefile
 create mode 100644 drivers/perf/hisilicon/hisi_uncore_pmu.c
 create mode 100644 drivers/perf/hisilicon/hisi_uncore_pmu.h

diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig
index e5197ff..14b7b9d 100644
--- a/drivers/perf/Kconfig
+++ b/drivers/perf/Kconfig
@@ -17,6 +17,13 @@ config ARM_PMU_ACPI
depends on ARM_PMU && ACPI
def_bool y
 
+config HISI_PMU
+   bool "HiSilicon SoC PMU"
+   depends on ACPI && (ARM64 || COMPILE_TEST)
+   help
+ Support for HiSilicon SoC uncore performance monitoring
+ unit (PMU), such as: L3C, HHA and DDRC.
+
 config QCOM_L2_PMU
bool "Qualcomm Technologies L2-cache PMU"
depends on ARCH_QCOM && ARM64 && ACPI
diff --git a/drivers/perf/Makefile b/drivers/perf/Makefile
index 6420bd4..41d3342 100644
--- a/drivers/perf/Makefile
+++ b/drivers/perf/Makefile
@@ -1,5 +1,6 @@
 obj-$(CONFIG_ARM_PMU) += arm_pmu.o arm_pmu_platform.o
 obj-$(CONFIG_ARM_PMU_ACPI) += arm_pmu_acpi.o
+obj-$(CONFIG_HISI_PMU) += hisilicon/
 obj-$(CONFIG_QCOM_L2_PMU)  += qcom_l2_pmu.o
 obj-$(CONFIG_QCOM_L3_PMU) += qcom_l3_pmu.o
 obj-$(CONFIG_XGENE_PMU) += xgene_pmu.o
diff --git a/drivers/perf/hisilicon/Makefile b/drivers/perf/hisilicon/Makefile
new file mode 100644
index 000..2783bb3
--- /dev/null
+++ b/drivers/perf/hisilicon/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_HISI_PMU) += hisi_uncore_pmu.o
diff --git a/drivers/perf/hisilicon/hisi_uncore_pmu.c 
b/drivers/perf/hisilicon/hisi_uncore_pmu.c
new file mode 100644
index 000..3a21c9e
--- /dev/null
+++ b/drivers/perf/hisilicon/hisi_uncore_pmu.c
@@ -0,0 +1,416 @@
+/*
+ * HiSilicon SoC Hardware event counters support
+ *
+ * Copyright (C) 2017 Hisilicon Limited
+ * Author: Anurup M 
+ * Shaokun Zhang 
+ *
+ * This code is based on the uncore PMUs like arm-cci and arm-ccn.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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 should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "hisi_uncore_pmu.h"
+
+/*
+ * PMU format attributes
+ */
+ssize_t hisi_format_sysfs_show(struct device *dev,
+  struct device_attribute *attr, char *buf)
+{
+   struct dev_ext_attribute *eattr;
+
+   eattr = container_of(attr, struct dev_ext_attribute, attr);
+
+   return sprintf(buf, "%s\n", (char *)eattr->var);
+}
+
+/*
+ * PMU event attributes
+ */
+ssize_t hisi_event_sysfs_show(struct device *dev,
+ struct device_attribute *attr, char *page)
+{
+   struct dev_ext_attribute *eattr;
+
+   eattr = container_of(attr, struct dev_ext_attribute, attr);
+
+   return sprintf(page, "config=0x%lx\n", (unsigned long)eattr->var);
+}
+
+/*
+ * sysfs cpumask attributes
+ */
+ssize_t hisi_cpumask_sysfs_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct pmu *pmu = dev_get_drvdata(dev);
+   struct hisi_pmu *hisi_pmu = to_hisi_pmu(pmu);
+
+   return cpumap_print_to_pagebuf(true, buf, &hisi_pmu->cpus);
+}
+
+/* Read Super CPU cluster and CPU cluster ID from MPIDR_EL1 */
+void hisi_read_scl_and_ccl_id(u32 *scl_id, u32 *ccl_id)
+{
+   u64 mpidr;
+
+   mpidr = read_cpuid_mpidr();
+   if (mpidr & MPIDR_MT_BITMASK) {
+   if (scl_id)
+   *scl_id = MPIDR_AFFINITY_LEVEL(mpidr, 3);
+   if (ccl_id)
+   *ccl_id = MPIDR_AFFINITY_LEVEL(mpidr, 2);
+   } else {
+   if (scl_id)
+   *scl_id = MPIDR_AFFINITY_LEVEL(mpidr, 2);
+   if (ccl_id)
+   *ccl_id = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+   }
+}
+
+static bool hisi_validate_event_group(struct perf_event *event)
+{
+   struct perf_event *sibling, *leader = event->group_leader;
+   struct hisi_pmu *hisi_pmu = to_hisi_pmu(event->pmu);
+   /* Include count for the event */
+   int counters = 1;
+
+   /*
+* We must NOT create group

[PATCH 5/6] drivers: perf: hisi: Add support for HiSilicon SoC DDRC PMU driver

[Shaokun Zhang]

This patch adds support for DDRC PMU driver in HiSilicon SoC chip, Each
DDRC has own control, counter and interrupt registers and is an separate
PMU. For each DDRC PMU, it has 8-fixed-purpose counters which have been
mapped to 8-events by hardware, it assumes that counter index is equal
to event code (0 - 7) in DDRC PMU driver. Interrupt is supported to
handle counter (32-bits) overflow.

Signed-off-by: Shaokun Zhang 
Signed-off-by: Anurup M 
---
 drivers/perf/hisilicon/Makefile   |   2 +-
 drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c | 435 ++
 2 files changed, 436 insertions(+), 1 deletion(-)
 create mode 100644 drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c

diff --git a/drivers/perf/hisilicon/Makefile b/drivers/perf/hisilicon/Makefile
index a72afe8..2621d51 100644
--- a/drivers/perf/hisilicon/Makefile
+++ b/drivers/perf/hisilicon/Makefile
@@ -1 +1 @@
-obj-$(CONFIG_HISI_PMU) += hisi_uncore_pmu.o hisi_uncore_l3c_pmu.o 
hisi_uncore_hha_pmu.o
+obj-$(CONFIG_HISI_PMU) += hisi_uncore_pmu.o hisi_uncore_l3c_pmu.o 
hisi_uncore_hha_pmu.o hisi_uncore_ddrc_pmu.o
diff --git a/drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c 
b/drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c
new file mode 100644
index 000..432fb20
--- /dev/null
+++ b/drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c
@@ -0,0 +1,435 @@
+/*
+ * HiSilicon SoC DDRC uncore Hardware event counters support
+ *
+ * Copyright (C) 2017 Hisilicon Limited
+ * Author: Shaokun Zhang 
+ * Anurup M 
+ *
+ * This code is based on the uncore PMUs like arm-cci and arm-ccn.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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 should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "hisi_uncore_pmu.h"
+
+/* DDRC register definition */
+#define DDRC_PERF_CTRL 0x010
+#define DDRC_FLUX_WR   0x380
+#define DDRC_FLUX_RD   0x384
+#define DDRC_FLUX_WCMD  0x388
+#define DDRC_FLUX_RCMD  0x38c
+#define DDRC_PRE_CMD0x3c0
+#define DDRC_ACT_CMD0x3c4
+#define DDRC_BNK_CHG0x3c8
+#define DDRC_RNK_CHG0x3cc
+#define DDRC_EVENT_CTRL 0x6C0
+#define DDRC_INT_MASK  0x6c8
+#define DDRC_INT_STATUS0x6cc
+#define DDRC_INT_CLEAR 0x6d0
+
+/* DDRC supports 8-events and counter is fixed-purpose */
+#define DDRC_NR_COUNTERS   0x8
+#define DDRC_NR_EVENTS DDRC_NR_COUNTERS
+
+#define DDRC_PERF_CTRL_EN  0x2
+
+/*
+ * For DDRC PMU, there are eight-events and every event has been mapped
+ * to fixed-purpose counters which register offset is not consistent.
+ * Therefore there is no write event type and we assume that event
+ * code (0 to 7) is equal to counter index in PMU driver.
+ */
+#define GET_DDRC_EVENTID(hwc)  (hwc->config_base & 0x7)
+
+static const u32 ddrc_reg_off[] = {
+   DDRC_FLUX_WR, DDRC_FLUX_RD, DDRC_FLUX_WCMD, DDRC_FLUX_RCMD,
+   DDRC_PRE_CMD, DDRC_ACT_CMD, DDRC_BNK_CHG, DDRC_RNK_CHG
+};
+
+/*
+ * Select the counter register offset using the counter index.
+ * In DDRC there are no programmable counter, the count
+ * is readed form the statistics counter register itself.
+ */
+static u32 get_counter_reg_off(int cntr_idx)
+{
+   return ddrc_reg_off[cntr_idx];
+}
+
+static u64 hisi_ddrc_pmu_read_counter(struct hisi_pmu *ddrc_pmu,
+ struct hw_perf_event *hwc)
+{
+   /* Use event code as counter index */
+   u32 idx = GET_DDRC_EVENTID(hwc);
+   u32 reg;
+
+   if (!hisi_uncore_pmu_counter_valid(ddrc_pmu, idx)) {
+   dev_err(ddrc_pmu->dev, "Unsupported event index:%d!\n", idx);
+   return 0;
+   }
+
+   reg = get_counter_reg_off(idx);
+
+   return readl(ddrc_pmu->base + reg);
+}
+
+static void hisi_ddrc_pmu_write_counter(struct hisi_pmu *ddrc_pmu,
+   struct hw_perf_event *hwc, u64 val)
+{
+   u32 idx = GET_DDRC_EVENTID(hwc);
+   u32 reg;
+
+   if (!hisi_uncore_pmu_counter_valid(ddrc_pmu, idx)) {
+   dev_err(ddrc_pmu->dev, "Unsupported event index:%d!\n", idx);
+   return;
+   }
+
+   reg = get_counter_reg_off(idx);
+   writel((u32)val, ddrc_pmu->base + reg);
+}
+
+static void hisi_ddrc_pmu_start_counters(struct hisi_pmu *ddrc_pmu)
+{
+   u32 val;
+
+   /* Set perf_enable in DDRC_PERF_CTRL to start event counting */
+   val = readl(ddrc_pmu->base + DDRC_PERF_CTRL);
+   val |= D

[PATCH 1/6] Documentation: perf: hisi: Documentation for HiSilicon SoC PMU driver

[Shaokun Zhang]

This patch adds documentation for the uncore PMUs on HiSilicon SoC.

Signed-off-by: Shaokun Zhang 
Signed-off-by: Anurup M 
---
 Documentation/perf/hisi-pmu.txt | 51 +
 1 file changed, 51 insertions(+)
 create mode 100644 Documentation/perf/hisi-pmu.txt

diff --git a/Documentation/perf/hisi-pmu.txt b/Documentation/perf/hisi-pmu.txt
new file mode 100644
index 000..5fa0b1a
--- /dev/null
+++ b/Documentation/perf/hisi-pmu.txt
@@ -0,0 +1,51 @@
+HiSilicon SoC uncore Performance Monitoring Unit (PMU)
+==
+The HiSilicon SoC chip comprehends various independent system device PMUs
+such as L3 cache (L3C), Hydra Home Agent (HHA) and DDRC. These PMUs are
+independent and have hardware logic to gather statistics and performance
+information.
+
+HiSilicon SoC encapsulates multiple CPU and IO dies. Each CPU cluster (CC
+L) is made up of 4 cpu cores sharing one L3 cache; Each CPU die is called
+Super CPU cluster (SCCL) and is made up of 6 CCLs. Each SCCL has two HHAs
+(0 - 1) and four DDRCs (0 - 3), respectively.
+
+HiSilicon SoC uncore PMU driver
+---
+Each device PMU has separate registers for event counting, control and
+interrupt, and the PMU driver shall register perf PMU drivers like L3C,
+HHA and DDRC etc. The available events and configuration options shall
+be described in the sysfs, see /sys/devices/hisi_*.
+The "perf list" command shall list the available events from sysfs.
+
+Each L3C, HHA and DDRC in one SCCL are registered as an separate PMU with perf.
+The PMU name will appear in event listing as hisi_module _.
+where "index-id" is the index of module and "sccl-id" is the identifier of
+the SCCL.
+e.g. hisi_l3c0_1/rd_hit_cpipe is READ_HIT_CPIPE event of L3C index #0 and SCCL
+ID #1.
+e.g. hisi_hha0_1/rx_operations is RX_OPERATIONS event of HHA index #0 and SCCL
+ID #1.
+
+The driver also provides a "cpumask" sysfs attribute, which shows the CPU core
+ID used to count the uncore PMU event.
+
+Example usage of perf:
+$# perf list
+hisi_l3c0_3/rd_hit_cpipe/ [kernel PMU event]
+--
+hisi_l3c0_3/wr_hit_cpipe/ [kernel PMU event]
+--
+hisi_l3c0_1/rd_hit_cpipe/ [kernel PMU event]
+--
+hisi_l3c0_1/wr_hit_cpipe/ [kernel PMU event]
+--
+
+$# perf stat -a -e hisi_l3c0_1/rd_hit_cpipe/ sleep 5
+$# perf stat -a -e hisi_l3c0_1/config=0x02/ sleep 5
+
+The current driver does not support sampling. So "perf record" is unsupported.
+Also attach to a task is unsupported as the events are all uncore.
+
+Note: Please contact the maintainer for a complete list of events supported for
+the PMU devices in the SoC and its information if needed.
-- 
1.9.1

[PATCH 3/6] drivers: perf: hisi: Add support for HiSilicon SoC L3C PMU driver

[Shaokun Zhang]

This patch adds support for L3C PMU driver in HiSilicon SoC chip, Each
L3C has own control, counter and interrupt registers and is an separate
PMU. For each L3C PMU, it has 8-programable counters and supports 0x60
events, each event code is 8-bits and every counter is free-running.
Interrupt is supported to handle counter (48-bits) overflow.

Signed-off-by: Shaokun Zhang 
Signed-off-by: Anurup M 
---
 drivers/perf/hisilicon/Makefile  |   2 +-
 drivers/perf/hisilicon/hisi_uncore_l3c_pmu.c | 554 +++
 include/linux/cpuhotplug.h   |   1 +
 3 files changed, 556 insertions(+), 1 deletion(-)
 create mode 100644 drivers/perf/hisilicon/hisi_uncore_l3c_pmu.c

diff --git a/drivers/perf/hisilicon/Makefile b/drivers/perf/hisilicon/Makefile
index 2783bb3..4a3d3e6 100644
--- a/drivers/perf/hisilicon/Makefile
+++ b/drivers/perf/hisilicon/Makefile
@@ -1 +1 @@
-obj-$(CONFIG_HISI_PMU) += hisi_uncore_pmu.o
+obj-$(CONFIG_HISI_PMU) += hisi_uncore_pmu.o hisi_uncore_l3c_pmu.o
diff --git a/drivers/perf/hisilicon/hisi_uncore_l3c_pmu.c 
b/drivers/perf/hisilicon/hisi_uncore_l3c_pmu.c
new file mode 100644
index 000..009b70c
--- /dev/null
+++ b/drivers/perf/hisilicon/hisi_uncore_l3c_pmu.c
@@ -0,0 +1,554 @@
+/*
+ * HiSilicon SoC L3C uncore Hardware event counters support
+ *
+ * Copyright (C) 2017 Hisilicon Limited
+ * Author: Anurup M 
+ * Shaokun Zhang 
+ *
+ * This code is based on the uncore PMUs like arm-cci and arm-ccn.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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 should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "hisi_uncore_pmu.h"
+
+/* L3C register definition */
+#define L3C_PERF_CTRL  0x0408
+#define L3C_INT_MASK   0x0800
+#define L3C_INT_STATUS 0x0808
+#define L3C_INT_CLEAR  0x080c
+#define L3C_EVENT_CTRL 0x1c00
+#define L3C_EVENT_TYPE00x1d00
+#define L3C_CNTR0_LOWER0x1e00
+
+/* L3C has 8-counters and supports 0x60 events */
+#define L3C_NR_COUNTERS0x8
+#define L3C_NR_EVENTS  0x60
+
+#define L3C_PERF_CTRL_EN   0x2
+#define L3C_EVTYPE_NONE0xff
+
+/*
+ * Select the counter register offset using the counter index
+ * every counter is 48-bits and [48:63] is reserved.
+ */
+static u32 get_counter_reg_off(int cntr_idx)
+{
+   return (L3C_CNTR0_LOWER + (cntr_idx * 8));
+}
+
+static u64 hisi_l3c_pmu_read_counter(struct hisi_pmu *l3c_pmu,
+struct hw_perf_event *hwc)
+{
+   u32 idx = hwc->idx;
+   u32 reg;
+
+   if (!hisi_uncore_pmu_counter_valid(l3c_pmu, idx)) {
+   dev_err(l3c_pmu->dev, "Unsupported event index:%d!\n", idx);
+   return 0;
+   }
+
+   reg = get_counter_reg_off(idx);
+
+   /* Read 64-bits and the upper 16 bits are Read-As-Zero */
+   return readq(l3c_pmu->base + reg);
+}
+
+static void hisi_l3c_pmu_write_counter(struct hisi_pmu *l3c_pmu,
+  struct hw_perf_event *hwc, u64 val)
+{
+   u32 idx = hwc->idx;
+   u32 reg;
+
+   if (!hisi_uncore_pmu_counter_valid(l3c_pmu, idx)) {
+   dev_err(l3c_pmu->dev, "Unsupported event index:%d!\n", idx);
+   return;
+   }
+
+   reg = get_counter_reg_off(idx);
+   /* Write 64-bits and the upper 16 bits are Writes-Ignored */
+   writeq(val, l3c_pmu->base + reg);
+}
+
+static void hisi_l3c_pmu_write_evtype(struct hisi_pmu *l3c_pmu, int idx,
+ u32 type)
+{
+   u32 reg, reg_idx, shift, val;
+
+   /*
+* Select the appropriate event select register(L3C_EVENT_TYPE0/1).
+* There are 2 event select registers for the 8 hardware counters.
+* Event code is 8-bits and for the former 4 hardware counters,
+* L3C_EVENT_TYPE0 is chosen. For the latter 4 hardware counters,
+* L3C_EVENT_TYPE1 is chosen.
+*/
+   reg = L3C_EVENT_TYPE0 + (idx / 4) * 4;
+   reg_idx = idx % 4;
+   shift = 8 * reg_idx;
+
+   /* Write event code to L3C_EVENT_TYPEx Register */
+   val = readl(l3c_pmu->base + reg);
+   val &= ~(L3C_EVTYPE_NONE << shift);
+   val |= (type << shift);
+   writel(val, l3c_pmu->base + reg);
+}
+
+static void hisi_l3c_pmu_start_counters(struct hisi_pmu *l3c_pmu)
+{
+   u32 val;
+
+   /*
+* Set perf_enable bit in L3C_PERF_CTRL register to st

Re: omap3isp camera was Re: [PATCH v1 0/6] Add support of OV9655 camera

[Hugues FRUCHET]

Hi Nikolaus,

I would propose to work first on YUV support, so you can test a YUV VGA 
grabbing using your OMPA3 setup, I will add this support then in patch 
serie.

For the co-work, let's continue on IRC (irc.freenode.net), chat #v4l, my 
pseudo is "hfr".

BR,
Hugues.

On 06/26/2017 06:28 PM, H. Nikolaus Schaller wrote:
> Hi Hugues,
> 
>> Am 26.06.2017 um 15:19 schrieb Hugues FRUCHET :
>>
>> Nikolaus,
>> some comments about pixel format/resolution below:
>>
>> On 06/26/2017 10:39 AM, Pavel Machek wrote:
>>> On Mon 2017-06-26 08:05:04, H. Nikolaus Schaller wrote:
 Hi Pavel,

> Am 25.06.2017 um 11:18 schrieb Pavel Machek :
>
> Hi!
>
>> * unfortunately we still get no image :(
>>
>> The latter is likely a setup issue of our camera interface (OMAP3 ISP = 
>> Image Signal Processor) which
>> we were not yet able to solve. Oscilloscoping signals on the interface 
>> indicated that signals and
>> sync are correct. But we do not know since mplayer only shows a green 
>> screen.
>
> What mplayer command line do you use? How did you set up the pipeline
> with media-ctl?
>
> On kernel.org, I have tree called camera-fw5-6 , where camera works
> for me on n900. On gitlab, there's modifed fcam-dev, which can be used
> for testing.

 We did have yet another (non-DT) camera driver and media-ctl working in 
 with 3.12.37,
 but had no success yet to update it to work with modern kernels or 
 drivers. It
 is either that the (newer) drivers missing something or the media-ctl has 
 changed.

 Here is the log of our scripts with Hugues' driver and our latest setup:

 root@letux:~# ./camera-demo sxga
 DISPLAY=:0
 XAUTHORITY=tcp
 Camera: /dev/v4l-subdev8
 Setting mode sxga
 media-ctl -r
 media-ctl -l '"ov965x":0 -> "OMAP3 ISP CCDC":0[1]'
 media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0[1]'
 media-ctl -V '"ov965x":0 [UYVY2X8 1280x1024]'
 media-ctl -V '"OMAP3 ISP CCDC":0 [UYVY2X8 1280x1024]'
 media-ctl -V '"OMAP3 ISP CCDC":1 [UYVY 1280x1024]'
>>>
>>> Ok, so you are using capture, not preview.
>>>
>>> You may want to try this one:
>>>
>>> commit 0eae9d2a8f096f703cbc8f9a0ab155cd3cc14cef
>>> Author: Pavel 
>>> Date:   Mon Feb 13 21:26:51 2017 +0100
>>>
>>>  omap3isp: fix VP2SDR bit so capture (not preview) works
>>>
>>>  This is neccessary for capture (not preview) to work properly on
>>>  N900. Why is unknown.
>>> 
>>> Pavel
>>>
 ### starting mplayer in sxga mode ###
 mplayer tv:// -vf rotate=2 -tv 
 driver=v4l2:device=/dev/video2:outfmt=uyvy:width=1280:height=1024:fps=15 
 -vo x11
>>
>> => "outfmt=uyvy:width=1280:height=1024"
>>
>> Nikolaus,
>> Be careful that only VGA/RGB565 is coded in this basic version of OV9655,
>> perhaps this explain partly your troubles ?
> 
> Ah, I see. The driver should support SXGA and UYVY2X8 (because our 3.12 
> compatible driver did).
> 
> This very old (but working) non-DT driver for 3.12 kernels
> was not based on the ov9650.c code but mt9p031.c:
> 
>   
> http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=drivers/media/i2c/ov9655.c;hb=refs/heads/3.12.37
> 
> We abandoned this independent driver because we felt (like you) that 
> extending the existing
> ov9650 driver is a better solution for mainline.
> 
> 
> At least in theory. Therefore I assumed your submission supports SXGA and 
> UYVY as well,
> since your work is based on ours.
> 
> Nevertheless, VGA resolution doesn't work either.
> 
> root@letux:~# ./camera-demo vga
> DISPLAY=:0
> XAUTHORITY=tcp
> Camera: /dev/v4l-subdev8
> Setting mode vga
> media-ctl -r
> media-ctl -l '"ov965x":0 -> "OMAP3 ISP CCDC":0[1]'
> media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0[1]'
> media-ctl -V '"ov965x":0 [UYVY2X8 640x480]'
> media-ctl -V '"OMAP3 ISP CCDC":0 [UYVY2X8 640x480]'
> media-ctl -V '"OMAP3 ISP CCDC":1 [UYVY 640x480]'
> ### starting mplayer in vga mode ###
> mplayer tv:// -vf rotate=2 -tv 
> driver=v4l2:device=/dev/video2:outfmt=uyvy:width=640:height=480:fps=30 -vo x11
> 
> 
> A little later it reports a NULL pointer dereference in ccdc_link_validate() 
> / ccdc_is_shiftable().
> 
> It appears as if the input format translates into a NULL pointer by
> omap3isp_video_format_info(0x1008).
> 
> This NULL pointer is not catched by ccdc_is_shiftable().
> 
> And it indicates that the camera driver is doing a format that is not
> supported by omap3isp...
> 
> 
> So how should we proceed?
> 
> It looks as if your driver supports your scenario (STM32F746G-DISCO) in 
> VGA/RGB565
> and our drivers (basically) support ours (omap3isp) in VGA/SXGA but UYVY.
> 
> We certainly need a generic driver that supports all platforms and formats. So
> we somehow need to get all this stuff into a single driver.
> 
> Working on two different patch sets doesn't make sen

Re: [PATCH 2/3] Turn bitmap_set and bitmap_clear into memset when possible

[Rasmus Villemoes]

> It's actually slightly less efficient in the caller (although obviously
> memset() is going to execute faster than bitmap_set()).  Partly because
> x86 made some odd choices about the behaviour of an 8-bit move instruction
> (it leaves the upper 24 bits intact, rather than zeroing them, so gcc
> has to use a 32-bit move instruction to put 0xff into the second argument
> to memset()),

Heh, I thought gcc knew and made full use of the semantics of memset,
so that only the low byte matters. I suppose there might be
architectures where passing -1 is slightly cheaper (at least in code
size) than 255... [quick checking] indeed, on x86_64, there's no
change in the generated code, but on 32 bit, gcc ends up doing

6a ff   push   $0x

instead of

68 ff 00 00 00  push   $0xff

Re: [PATCH v2 1/2] DT: pinctrl: Add binding documentation for Spreadtrum pin controller

[Baolin Wang]

On 26 June 2017 at 06:19, Linus Walleij  wrote:
> On Wed, Jun 21, 2017 at 10:10 AM, Baolin Wang  wrote:
>> On 20 June 2017 at 17:31, Linus Walleij  wrote:
>>> On Tue, Jun 13, 2017 at 5:15 AM, Baolin Wang  
>>> wrote:
>>>
 I forgot one most important reason why we can not use the "sleep" state. 
 As I explained
 above, the sleep related configuration will bind with the pin's sleep 
 mode. If we set the
 pin's sleep mode as AP_SLEEP, then we can select "sleep" state when AP 
 system goes into
 deep sleep mode by issuing "pinctrl_force_sleep()" in pinctrl suspend 
 function.

 But if we set the pin's sleep mode as PUBCP_SLEEP and pubcp system doesn't 
 run linux kernel
 (it run another thread OS), then we can not select "sleep" state since the 
 AP system does
 not go into deep sleep mode (AP system run linux kernel OS).
>>>
>>> Allright yes it makes sense, and also there are systems that just go into
>>> "hardware sleep" and just put the pin into some pre-programmed mode.
>>>
>>> I'm a bit back-and-forth. I didn't mean that some code would actually
>>> switch the state to "sleep" when we go to sleep, I meant that when
>>> the system configures "default" mode it should also look up and
>>> program the "sleep" mode, but this approach with a special property
>>> is just another way of achieveing the same thing.
>>>
>>> But then we should add a whole slew of sleep states.
>>>
>>> I was thinking whether we could avoid having a special DT property
>>> by parsing ahead to states we do not currently use and programming
>>> that into the sleep mode registers.
>>
>> Yes, for most scenarios, it can work with the "sleep" state to set
>> sleep-related config. But for our Spreadtrum platform scenario (I do
>> not know if there are other platforms need this feature), we can not
>> select the "sleep" state when pubcp system goes into deep sleep mode
>> but ap system does not go into deep sleep mode. So I think we still
>> need these "sleep-bias-pull-up", "sleep-bias-pull-down",
>> "sleep-input-enable" and "sleep-output-enable" properties.
>
> I don't really mean you should select the "sleep" state.
>
> I meant, as part of setting the "default" state or even the "init"
> state, we would inspect the "sleep" state, use those settings, and
> program them into the registers at this early point.

I understood your points. But we can not program all into the
registers at one early point, sometimes these sleep-related configs
need depend on some conditions in users' drivers, like on condition 1:
driver need to set one pin as input-enable when specified system goes
into deep sleep, on condition 2: driver need set this pin as
output-enable when specified system goes into deep sleep. So I still
think it is better if we introduce some standard sleep related
configs.

>
> Then never touch the registers again, and never really go to the
> sleep state by software, just by hardware.
>
> Yours,
> Linus Walleij



-- 
Baolin.wang
Best Regards

Re: [PATCH 00/20] LightNVM: pblk patches for 4.13

[Javier González]

> On 27 Jun 2017, at 00.29, Jens Axboe  wrote:
> 
> On Mon, Jun 26 2017, Javier González wrote:
>> Hi Matias,
>> 
>> Here you have the pblk patchset for this window.
>> 
>> Apart from small fixes for LightNVM core and pblk, there are three
>> relevant changes:
>> 
>> - Metadata for each line is no longer issued on a separate workqueue,
>>   but instead, all I/Os are scheduled on the write thread. This allows
>>   to have more control over LUN collisions. The result is that we can
>>   use the full bandwidth of the device for user data. In the 4.12 pblk,
>>   we use ~25% of the bandwidth for metadata.
>> 
>> - The rate-limiter and GC have been tuned to keep the GC writer busy.
>>   Also, capacity per line is guaranteed for GC I/O as we reach
>>   capacity.
>> 
>> - We have now a FTL state machine. This allows to fail gracefully to
>>   user space in case of irrecoverable errors. This state machine will
>>   be the base for the pblk's FTL log.
>> 
>> The patches apply into your for-4.13/core. You can also find them in:
> 
> Nope, they do not. Patch #7 fails, because it's not on top of the
> bio_set changes that went in a week or two ago. I hand applied that one,
> didn't find issues with the rest.
> 
> But please remember to ensure that it applies on top of the current
> branch.

Thanks Jens. Won't happen again.

Javier



signature.asc
Description: Message signed with OpenPGP

Re: [tip:x86/mm] x86/mmap, ASLR: Do not treat unlimited-stack tasks as legacy mmap

[Jiri Kosina]

On Fri, 23 Jun 2017, Oleg Nesterov wrote:

> > We added a heuristics to treat applications with RLIMIT_STACK configured
> > to unlimited as legacy. This means:
> 
> To me this also means a minor security problem. The comment above
> PER_CLEAR_ON_SETID says "must be cleared upon setuid or setgid exec",
> but if you do "ulimit -s unlimited" before suid exec then
> ADDR_COMPAT_LAYOUT set by security checks will be ignored.

Could you please be a bit more specific here?

mmap_is_legacy() *first* checks for the ADDR_COMPAT_LAYOUT in the 
personality flags, and only then, if it's unset, RLIMIT_STACK comes to 
play.

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH v3 1/2] dt-bindings: i2c: Add Spreadtrum I2C controller documentation

[Baolin Wang]

On 一,  6月 26, 2017 at 09:05:39上午 -0500, Rob Herring wrote:
> On Mon, Jun 26, 2017 at 5:28 AM, Baolin Wang  
> wrote:
> > This patch adds the binding documentation for Spreadtrum I2C
> > controller device.
> >
> > Signed-off-by: Baolin Wang 
> > ---
> > Changes since v2:
> >  - Change compatible strings to be SoC specific.
> >
> > Changes since v1:
> >  - No updates.
> > ---
> >  Documentation/devicetree/bindings/i2c/i2c-sprd.txt |   31 
> > 
> >  1 file changed, 31 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/i2c/i2c-sprd.txt
> 
> Acked-by: Rob Herring 

Thanks Rob.

Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i

[Corentin Labbe]

On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
> On 31/05/17 08:18, Corentin Labbe wrote:
> > The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> > allwinner.
> > In fact the only common part is the descriptor management and the first
> > register function.
> 
> Hi,
> 
> I know I am a bit late with this, but while adapting the U-Boot driver
> to the new binding I was wondering about the internal PHY detection:
> 
> 
> So here you seem to deduce the usage of the internal PHY by the PHY
> interface specified in the DT (MII = internal, RGMII = external).
> I think I raised this question before, but isn't it perfectly legal for
> a board to use MII with an external PHY even on those SoCs that feature
> an internal PHY?
> On the first glance that does not make too much sense, but apart from
> not being the correct binding to describe all of the SoCs features I see
> two scenarios:
> 1) A board vendor might choose to not use the internal PHY because it
> has bugs, lacks features (configurability) or has other issues. For
> instance I have heard reports that the internal PHY makes the SoC go
> rather hot, possibly limiting the CPU frequency. By using an external
> MII PHY (which are still cheaper than RGMII PHYs) this can be avoided.
> 2) A PHY does not necessarily need to be directly connected to
> magnetics. Indeed quite some boards use (RG)MII to connect to a switch
> IC or some other network circuitry, for instance fibre connectors.
> 
> So I was wondering if we would need an explicit:
>   allwinner,use-internal-phy;
> boolean DT property to signal the usage of the internal PHY?
> Alternatively we could go with the negative version:
>   allwinner,disable-internal-phy;
> 
> Or what about introducing a new "allwinner,internal-mii-phy" compatible
> string for the *PHY* node and use that?
> 
> I just want to avoid that we introduce a binding that causes us
> headaches later. I think we can still fix this with a followup patch
> before the driver and its binding hit a release kernel.
> 
> Cheers,
> Andre.
> 

I just see some patch, where "phy-mode = internal" is valid.
I will try to find a way to use it

Regards

Re: [PATCH v3 0/4] kmod: help make deterministic

[Petr Mladek]

On Tue 2017-06-27 02:27:44, Luis R. Rodriguez wrote:
> On Tue, Jun 27, 2017 at 12:44:42AM +0200, Luis R. Rodriguez wrote:
> > On Mon, Jun 26, 2017 at 11:37:36PM +0200, Jessica Yu wrote:
> > > +++ Kees Cook [20/06/17 17:23 -0700]:
> > > > On Tue, Jun 20, 2017 at 1:56 PM, Luis R. Rodriguez  
> > > > wrote:
> > > > > On Fri, May 26, 2017 at 02:12:24PM -0700, Luis R. Rodriguez wrote:
> > > > > > Luis R. Rodriguez (4):
> > > > > >   module: use list_for_each_entry_rcu() on find_module_all()
> > > > > >   kmod: reduce atomic operations on kmod_concurrent and simplify
> > > > > >   kmod: add test driver to stress test the module loader
> > > > > >   kmod: throttle kmod thread limit
> > > > > 
> > > > > About a month now with no further nitpicks. What tree should these 
> > > > > changes
> > > > > go through if there are no issues? Andrew's, Jessica's ?
> > > > 
> > > > Seems like going through Jessica's would make the most sense?
> > > 
> > > Would be happy to take patches 01 (which I need to anyway), 02,
> > > possibly 04 if decoupled from the test driver (03).
> > 
> > Feel free to decouple it, but note that then the commit log must then be
> > changed. My own take is this fix is not so critical as it is a corner case, 
> > so
> > I have instead preferred to couple in the test case and respective fix
> > together. I'll leave it up to you how to proceed.
> 
> Note: Linus noted swait is actually very special use-case [0] so I'd hate to
> add a new use case not vetted for. This use case on kmod.c really does *not*
> require anything but a simple wait though, so really am inclined to let that
> through unless I hear back...
> 
> [0] https://lkml.kernel.org/r/20170627001534.gk21...@wotan.suse.de

Heh, I was not aware of this special case either. The welcoming
comment of the swait API confused me as well.

In this light, I suggest to switch the patch to using the normal wait API.

Best Regards,
Petr

[PATCH] drm/nouveau/therm: fix spelling mistake on array thresolds

[Colin King]

From: Colin Ian King 

Array thresolds should be named thresholds, rename it. Also make it static
static const char * const

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c
index e93b2410c38b..6449771b9dc6 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c
@@ -83,7 +83,7 @@ nvkm_therm_sensor_event(struct nvkm_therm *therm, enum 
nvkm_therm_thrs thrs,
 {
struct nvkm_subdev *subdev = &therm->subdev;
bool active;
-   const char *thresolds[] = {
+   static const char * const thresholds[] = {
"fanboost", "downclock", "critical", "shutdown"
};
int temperature = therm->func->temp_get(therm);
@@ -94,10 +94,10 @@ nvkm_therm_sensor_event(struct nvkm_therm *therm, enum 
nvkm_therm_thrs thrs,
if (dir == NVKM_THERM_THRS_FALLING)
nvkm_info(subdev,
  "temperature (%i C) went below the '%s' threshold\n",
- temperature, thresolds[thrs]);
+ temperature, thresholds[thrs]);
else
nvkm_info(subdev, "temperature (%i C) hit the '%s' threshold\n",
- temperature, thresolds[thrs]);
+ temperature, thresholds[thrs]);
 
active = (dir == NVKM_THERM_THRS_RISING);
switch (thrs) {
-- 
2.11.0

Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i

[Chen-Yu Tsai]

On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
 wrote:
> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
>> On 31/05/17 08:18, Corentin Labbe wrote:
>> > The dwmac-sun8i is a heavy hacked version of stmmac hardware by
>> > allwinner.
>> > In fact the only common part is the descriptor management and the first
>> > register function.
>>
>> Hi,
>>
>> I know I am a bit late with this, but while adapting the U-Boot driver
>> to the new binding I was wondering about the internal PHY detection:
>>
>>
>> So here you seem to deduce the usage of the internal PHY by the PHY
>> interface specified in the DT (MII = internal, RGMII = external).
>> I think I raised this question before, but isn't it perfectly legal for
>> a board to use MII with an external PHY even on those SoCs that feature
>> an internal PHY?
>> On the first glance that does not make too much sense, but apart from
>> not being the correct binding to describe all of the SoCs features I see
>> two scenarios:
>> 1) A board vendor might choose to not use the internal PHY because it
>> has bugs, lacks features (configurability) or has other issues. For
>> instance I have heard reports that the internal PHY makes the SoC go
>> rather hot, possibly limiting the CPU frequency. By using an external
>> MII PHY (which are still cheaper than RGMII PHYs) this can be avoided.
>> 2) A PHY does not necessarily need to be directly connected to
>> magnetics. Indeed quite some boards use (RG)MII to connect to a switch
>> IC or some other network circuitry, for instance fibre connectors.
>>
>> So I was wondering if we would need an explicit:
>>   allwinner,use-internal-phy;
>> boolean DT property to signal the usage of the internal PHY?
>> Alternatively we could go with the negative version:
>>   allwinner,disable-internal-phy;
>>
>> Or what about introducing a new "allwinner,internal-mii-phy" compatible
>> string for the *PHY* node and use that?
>>
>> I just want to avoid that we introduce a binding that causes us
>> headaches later. I think we can still fix this with a followup patch
>> before the driver and its binding hit a release kernel.
>>
>> Cheers,
>> Andre.
>>
>
> I just see some patch, where "phy-mode = internal" is valid.
> I will try to find a way to use it

Can you provide a link?

I'm not a fan of using phy-mode for this. There's no guarantee what
mode the internal PHY uses. That's what phy-mode is for.

In any case, we should fix this before 4.13 is released.

ChenYu

Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i

[Corentin Labbe]

On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
>  wrote:
> > On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
> >> On 31/05/17 08:18, Corentin Labbe wrote:
> >> > The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> >> > allwinner.
> >> > In fact the only common part is the descriptor management and the first
> >> > register function.
> >>
> >> Hi,
> >>
> >> I know I am a bit late with this, but while adapting the U-Boot driver
> >> to the new binding I was wondering about the internal PHY detection:
> >>
> >>
> >> So here you seem to deduce the usage of the internal PHY by the PHY
> >> interface specified in the DT (MII = internal, RGMII = external).
> >> I think I raised this question before, but isn't it perfectly legal for
> >> a board to use MII with an external PHY even on those SoCs that feature
> >> an internal PHY?
> >> On the first glance that does not make too much sense, but apart from
> >> not being the correct binding to describe all of the SoCs features I see
> >> two scenarios:
> >> 1) A board vendor might choose to not use the internal PHY because it
> >> has bugs, lacks features (configurability) or has other issues. For
> >> instance I have heard reports that the internal PHY makes the SoC go
> >> rather hot, possibly limiting the CPU frequency. By using an external
> >> MII PHY (which are still cheaper than RGMII PHYs) this can be avoided.
> >> 2) A PHY does not necessarily need to be directly connected to
> >> magnetics. Indeed quite some boards use (RG)MII to connect to a switch
> >> IC or some other network circuitry, for instance fibre connectors.
> >>
> >> So I was wondering if we would need an explicit:
> >>   allwinner,use-internal-phy;
> >> boolean DT property to signal the usage of the internal PHY?
> >> Alternatively we could go with the negative version:
> >>   allwinner,disable-internal-phy;
> >>
> >> Or what about introducing a new "allwinner,internal-mii-phy" compatible
> >> string for the *PHY* node and use that?
> >>
> >> I just want to avoid that we introduce a binding that causes us
> >> headaches later. I think we can still fix this with a followup patch
> >> before the driver and its binding hit a release kernel.
> >>
> >> Cheers,
> >> Andre.
> >>
> >
> > I just see some patch, where "phy-mode = internal" is valid.
> > I will try to find a way to use it
> 
> Can you provide a link?

https://lkml.org/lkml/2017/6/23/479

> 
> I'm not a fan of using phy-mode for this. There's no guarantee what
> mode the internal PHY uses. That's what phy-mode is for.

For each soc the internal PHY mode is know and setted in 
emac_variant/internal_phy
So its not a problem.

Patch comming soon

Re: [PATCH v4 1/3] pinctrl: Add sleep related configuration

[Baolin Wang]

On 一,  6月 26, 2017 at 11:13:48上午 -0500, Rob Herring wrote:
> On Wed, Jun 21, 2017 at 07:55:37PM +0800, Baolin Wang wrote:
> > In some scenarios, we should set some pins as input/output/pullup/pulldown
> > when the specified system goes into deep sleep mode, then when the system
> > goes into deep sleep mode, these pins will be set automatically by hardware.
> > 
> > Usually we can set the "sleep" state to set sleep related config, but one 
> > SoC
> > usually has not only one system (especially for mobile SoC), some systems on
> > the SoC which did not run linux kernel, they can not select the "sleep" 
> > state
> > when they go into deep sleep mode.
> 
> The wording here is not very clear. I think what you mean is some pins 
> are not controlled by any specific driver in the OS, but need to be 
> controlled when entering sleep mode.

Yes, that is what I meaning, sorry for confusing.

> 
> > Thus we introduce some sleep related config into pinconf-generic for users 
> > to
> > configure.
> > 
> > Signed-off-by: Baolin Wang 
> > ---
> >  - Add this patch since v4.
> > ---
> >  .../bindings/pinctrl/pinctrl-bindings.txt  |   12 
> >  drivers/pinctrl/pinconf-generic.c  |   10 ++
> >  include/linux/pinctrl/pinconf-generic.h|   14 ++
> >  3 files changed, 36 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt 
> > b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
> > index bf3f7b0..e098059 100644
> > --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
> > +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
> > @@ -236,6 +236,18 @@ low-power-enable   - enable low power mode
> >  low-power-disable  - disable low power mode
> >  output-low - set the pin to output mode with low level
> >  output-high- set the pin to output mode with high level
> > +sleep-bias-pull-up - pull up the pin when the specified system goes into
> > + deep sleep mode
> > +sleep-bias-pull-down   - pull down the pin when the specified system 
> > goes into
> > + deep sleep mode
> > +sleep-input-enable - enable input on pin when the specified system goes
> > + into deep sleep mode (no effect on output)
> > +sleep-intput-disable   - disable input on pin when the specified 
> > system goes
> > + into deep sleep mode (no effect on output)
> > +sleep-output-low   - set the pin to output mode with low level when the
> > + specified system goes into deep sleep mode
> > +sleep-output-high  - set the pin to output mode with high level when the
> > + specified system goes into deep sleep mode
> >  slew-rate  - set the slew rate
> 
> I don't really like having 2 ways to define pin setup and this doesn't 
> scale if I need to define 3 states. Couldn't we create pin state 
> definitions and have a pinctrl-n property within the pin controller 
> node to handle all the unhandled pins?

As LinusW also suggest we can create one "sleep" state and program them
into registers at early point (like: after probing pinctrl driver). So I
think I can introduce one called "early-sleep" state which need select it
after initializing pinctrl driver.

> 
> Rob

Re: [PATCH v11 3/4] i2c: aspeed: added driver for Aspeed I2C

[Brendan Higgins]

On Fri, Jun 23, 2017 at 11:43 AM, Wolfram Sang  wrote:
> On Tue, Jun 20, 2017 at 02:15:15PM -0700, Brendan Higgins wrote:
>> Added initial master support for Aspeed I2C controller. Supports
>> fourteen busses present in AST24XX and AST25XX BMC SoCs by Aspeed.
>>
>> Signed-off-by: Brendan Higgins 
>
> Applied to for-next, thanks for all the hard work!

Thanks for the patience!

>
> One question however which can be solved incrementally if needed:
>
>> + if (command & ASPEED_I2CD_SDA_LINE_STS) {
>> + /* Bus is idle: no recovery needed. */
>> + if (command & ASPEED_I2CD_SCL_LINE_STS)
>> + goto out;
>> + dev_dbg(bus->dev, "SCL hung (state %x), attempting recovery\n",
>> + command);
>> +
>> + reinit_completion(&bus->cmd_complete);
>> + writel(ASPEED_I2CD_M_STOP_CMD, bus->base + ASPEED_I2C_CMD_REG);
>
> If SCL is stuck low, how do you want to send a STOP?
>

Fair point. I should probably drop that in the future and just do a
reset, and even then, doing a
reset is probably just wishful thinking. If a slave is holding down
SCL, we are pretty screwed.

Re: [PATCH v3 0/4] g_NCR5380: PDMA fixes and cleanup

[Michael Schmitz]

Ondrej,

could this be a partial write (target did not transfer the last byte)?

One would suppose the chip posts a phase mismatch in that case ...

Cheers,

Michael


Am 27.06.2017 um 18:28 schrieb Ondrej Zary:
> On Monday 26 June 2017, Ondrej Zary wrote:
>> On Monday 26 June 2017 09:30:33 Finn Thain wrote:
>>> Ondrej, would you please test this new series?
>>>
>>> Changed since v1:
>>> - PDMA transfer residual is calculated earlier.
>>> - End of DMA flag check is now polled (if there is any residual).
>>>
>>> Changed since v2:
>>> - Bail out of transfer loops when Gated IRQ gets asserted.
>>> - Make udelay conditional on board type.
>>> - Drop sg_tablesize patch due to performance regression.
>>>
>>>
>>> Finn Thain (1):
>>>   g_NCR5380: Cleanup comments and whitespace
>>>
>>> Ondrej Zary (3):
>>>   g_NCR5380: Fix PDMA transfer size
>>>   g_NCR5380: End PDMA transfer correctly on target disconnection
>>>   g_NCR5380: Re-work PDMA loops
>>>
>>>  drivers/scsi/g_NCR5380.c | 239
>>> +++ 1 file changed, 116
>>> insertions(+), 123 deletions(-)
> 
> BTW. I've probably found the DTC write corruption.
> Added the following check (13 is host buffer index register) - and it 
> triggers 
> sometimes: the value is 1 instead of 0. As we use only 16-bit writes, I don't 
> see how the value could ever be odd. Looks like a bug in the chip.
> The index register corrupts during the transfer, not after IRQ or timeout. 
> The 
> same check at beginning of pwrite() did not trigger.
> 
> The index register is not writable so we must(?) reset the PDMA engine to 
> recover. However, this quick attempt to fix does not work, maybe we should 
> reload the block count and continue?
> 
> --- a/drivers/scsi/g_NCR5380.c
> +++ b/drivers/scsi/g_NCR5380.c
> @@ -595,7 +603,13 @@ static inline int generic_NCR5380_pwrite(struct 
> NCR5380_hostdata *hostdata,
> goto out_wait;
> }
> }
> -
> +   idx = NCR5380_read(13);
> +   if (idx != 0) {
> +   printk("host idx=%d, start=%d\n", idx, start);
> +   NCR5380_write(hostdata->c400_ctl_status, CSR_RESET);
> +   NCR5380_write(hostdata->c400_ctl_status, CSR_BASE);
> +   goto out_wait;
> +   }
> if (hostdata->io_port && hostdata->io_width == 2)
> outsw(hostdata->io_port + hostdata->c400_host_buf,
> src + start, 64);
> 
> 

Re: [PATCH] x86/boot/KASLR: Skip relocation handling in no kaslr case

[Ingo Molnar]

* Baoquan He  wrote:

> As you suggested, we can add a checking to see if the virt_addr is
> bigger than 1G, and print warning if exceed or hang there with error
> message.

Could you try a patch for that, and see whether it catches this particular bug? 
(before the fix is applied.)

Could be a 2 patch series: first the patch that adds the warning, then the fix.

Thanks,

Ingo

Re: [PATCH v2 8/8] iio: counter: Add support for STM32 LPTimer

[Benjamin Gaignard]

2017-06-26 22:29 GMT+02:00 William Breathitt Gray :
> On Sat, Jun 24, 2017 at 09:35:39PM +0100, Jonathan Cameron wrote:
>>On Wed, 21 Jun 2017 16:30:15 +0200
>>Fabrice Gasnier  wrote:
>>
>>> Add support for STM32 Low-Power Timer, that can be used as counter
>>> or quadrature encoder.
>>>
>>> Signed-off-by: Fabrice Gasnier 
>>Hmm. Sometime I'm going to ask you guys to document how all these different
>>components fit together.  Far too many ways of cooking the same dish with
>>some of these ST parts ;)
>>
>>I've cc'd William.  You already have Benjamin.  Hopefully they also
>>have time to cast their eyes over this patch as it would be very helpful.
>>We are still defining new ABI for these devices so good to have more eyes
>>than for a normal patch.
>>Jonathan
>>> ---
>>> Changes in v2:
>>> - s/Low Power/Low-Power
>>> - update few comments
>>> ---
>>>  .../ABI/testing/sysfs-bus-iio-lptimer-stm32|  57 +++
>>>  drivers/iio/counter/Kconfig|   9 +
>>>  drivers/iio/counter/Makefile   |   1 +
>>>  drivers/iio/counter/stm32-lptimer-cnt.c| 383 
>>> +
>>>  4 files changed, 450 insertions(+)
>>>  create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-lptimer-stm32
>>>  create mode 100644 drivers/iio/counter/stm32-lptimer-cnt.c
>>>
>>> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-lptimer-stm32 
>>> b/Documentation/ABI/testing/sysfs-bus-iio-lptimer-stm32
>>> new file mode 100644
>>> index 000..ad2cc63
>>> --- /dev/null
>>> +++ b/Documentation/ABI/testing/sysfs-bus-iio-lptimer-stm32
>>> @@ -0,0 +1,57 @@
>>> +What:   /sys/bus/iio/devices/iio:deviceX/in_count0_preset
>>> +KernelVersion:  4.13
>>> +Contact:fabrice.gasn...@st.com
>>> +Description:
>>> +Reading returns the current preset value. Writing sets the
>>> +preset value. Encoder counts continuously from 0 to preset
>>> +value, depending on direction (up/down).
>>Some of these are generic now and used by several parts.  Time we started
>>thinking about a more generic file. sysfs-bus-iio-counter
>>> +
>>> +What:   
>>> /sys/bus/iio/devices/iio:deviceX/in_count_quadrature_mode_available
>>> +KernelVersion:  4.13
>>> +Contact:fabrice.gasn...@st.com
>>> +Description:
>>> +Reading returns the list possible quadrature modes.
>>> +
>>> +What:   
>>> /sys/bus/iio/devices/iio:deviceX/in_count0_quadrature_mode
>>> +KernelVersion:  4.13
>>> +Contact:fabrice.gasn...@st.com
>>> +Description:
>>> +Configure the device counter quadrature modes:
>>> +- non-quadrature:
>>> +Encoder IN1 input servers as the count input (up
>>> +direction).
>>> +- quadrature:
>>> +Encoder IN1 and IN2 inputs are mixed to get direction
>>> +and count.
>>Don't suppose we can call them A and B in common with labelling on many 
>>encoders?
>>Also makes this documentation same as for the 104 device.
>>> +
>>> +What:   
>>> /sys/bus/iio/devices/iio:deviceX/in_count_polarity_available
>>> +KernelVersion:  4.13
>>> +Contact:fabrice.gasn...@st.com
>>> +Description:
>>> +Reading returns the list possible active edges.
>>> +
>>> +What:   /sys/bus/iio/devices/iio:deviceX/in_count0_polarity
>>> +KernelVersion:  4.13
>>> +Contact:fabrice.gasn...@st.com
>>> +Description:
>>> +Configure the device encoder/counter active edge:
>>> +- rising-edge
>>> +- falling-edge
>>> +- both-edges
>>For both edges, I believe we last supported this with scale.
>>So can we have both edges for the non quadrature?  If so your scale reported
>>is not taking this into account.
>>> +
>>> +In non-quadrature mode, device counts up on active edge.
>>> +In quadrature mode, encoder counting scenarios are as follows:
>>> +
>>> 
>>> +| Active  | Level on |  IN1 signal| IN2 signal 
>>> |
>>> +| edge| opposite 
>>> |--
>>> +| | signal   |  Rising  | Falling |  Rising  | Falling 
>>> |
>>> +
>>> 
>>> +| Rising  | High ->  |   Down   |-|Up|-
>>> |
>>> +| edge| Low  ->  |Up|-|   Down   |-
>>> |
>>> +
>>> 
>>> +| Falling | High ->  |- |Up   |- |   Down  
>>> |
>>> +| edge| Low  ->  |- |   Down  |- |Up   
>>> |
>>> +
>>> 
>>> +| Both| High ->  |   Down   |

Re: [PATCH 1/5] [media] rockchip/rga: v4l2 m2m support

[Tomasz Figa]

Hi Jacob,

Please see my comments inline.

On Mon, Jun 26, 2017 at 11:51 PM, Jacob Chen  wrote:
> Rockchip RGA is a separate 2D raster graphic acceleration unit. It
> accelerates 2D graphics operations, such as point/line drawing, image
> scaling, rotation, BitBLT, alpha blending and image blur/sharpness.
[snip]
> +static int rga_buf_init(struct vb2_buffer *vb)
> +{
> +   struct rga_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
> +   struct rockchip_rga *rga = ctx->rga;
> +   struct sg_table *sgt;
> +   struct scatterlist *sgl;
> +   unsigned int *pages;
> +   struct rga_buf *buf;
> +   unsigned int address, len, i, p;
> +   unsigned int mapped_size = 0;
> +
> +   /* Create local MMU table for RGA */
> +   sgt = vb2_plane_cookie(vb, 0);
> +
> +   /*
> +* Alloc (2^3 * 4K) = 32K byte for storing pages, those space could
> +* cover 32K * 4K = 128M ram address.

Unless I'm missing something, there is 1024 32-bit values in one 4K
page, which can point to 4 MB of memory. The code allocates 8 of them,
which in total allows at most 32 MB per buffer.

> +*/
> +   pages = (unsigned int *)__get_free_pages(GFP_KERNEL | __GFP_ZERO, 3);

This is rather unfortunate and you should expect failures here on
actively used systems with uptime longer than few hours. Changing this
to dma_alloc_coherent() and enabling CMA _might_ give you a bit better
success rate, but...

Normally, this kind of (scatter-gather capable) hardware would allow
some kind of linking of separate pages, e.g. last entry in the page
would point to the next page, or something like that. Doesn't this RGA
block have something similar?

Best regards,
Tomasz

Re: [PATCH] tracing/kprobes: allow to create probe with a module name starting with a digit

[Masami Hiramatsu]

On Thu, 22 Jun 2017 11:24:42 +0200
Sabrina Dubroca  wrote:

> Always try to parse an address, since kstrtoul() will safely fail when
> given a symbol as input. If that fails (which will be the case for a
> symbol), try to parse a symbol instead.
> 
> This allows creating a probe such as:
> 
> p:probe/vlan_gro_receive 8021q:vlan_gro_receive+0
> 
> Which is necessary for this command to work:
> 
> perf probe -m 8021q -a vlan_gro_receive
> 

Ah, I forgot that case.
Nice catch!

Acked-by: Masami Hiramatsu 

Thanks!

> Signed-off-by: Sabrina Dubroca 
> ---
>  kernel/trace/trace_kprobe.c | 14 +-
>  1 file changed, 5 insertions(+), 9 deletions(-)
> 
> diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
> index c129fca6ec99..b53c8d369163 100644
> --- a/kernel/trace/trace_kprobe.c
> +++ b/kernel/trace/trace_kprobe.c
> @@ -707,20 +707,16 @@ static int create_trace_kprobe(int argc, char **argv)
>   pr_info("Probe point is not specified.\n");
>   return -EINVAL;
>   }
> - if (isdigit(argv[1][0])) {
> - /* an address specified */
> - ret = kstrtoul(&argv[1][0], 0, (unsigned long *)&addr);
> - if (ret) {
> - pr_info("Failed to parse address.\n");
> - return ret;
> - }
> - } else {
> +
> + /* try to parse an address. if that fails, try to read the
> +  * input as a symbol. */
> + if (kstrtoul(argv[1], 0, (unsigned long *)&addr)) {
>   /* a symbol specified */
>   symbol = argv[1];
>   /* TODO: support .init module functions */
>   ret = traceprobe_split_symbol_offset(symbol, &offset);
>   if (ret) {
> - pr_info("Failed to parse symbol.\n");
> + pr_info("Failed to parse either an address or a 
> symbol.\n");
>   return ret;
>   }
>   if (offset && is_return &&
> -- 
> 2.13.1
> 


-- 
Masami Hiramatsu 

Re: [PATCH v11 3/4] i2c: aspeed: added driver for Aspeed I2C

[Brendan Higgins]

On Sun, Jun 25, 2017 at 11:18 PM, Joel Stanley  wrote:
> On Sat, Jun 24, 2017 at 4:13 AM, Wolfram Sang  wrote:
>> On Tue, Jun 20, 2017 at 02:15:15PM -0700, Brendan Higgins wrote:
>>> Added initial master support for Aspeed I2C controller. Supports
>>> fourteen busses present in AST24XX and AST25XX BMC SoCs by Aspeed.
>>>
>>> Signed-off-by: Brendan Higgins 
>>
>> Applied to for-next, thanks for all the hard work!
>
> Congratulations Brendan. It's great to see this driver in the tree.
>
> Cheers,
>
> Joel

Thanks! And thank you to everyone who helped! I am not the only person who
put in a lot of hard work.

selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+

[Naresh Kamboju]

selftest capabilities test failed on linux mainline and linux-next and
PASS on linux-4.4.70+
Tested on HiKey ARM64 Development board.

A bug reported in Linaro bug tracking system,
LKFT: Capabilities test_execve fail Wrong effective state AT_SECURE is not set
https://bugs.linaro.org/show_bug.cgi?id=2947

Please guide me to debug the reason for failure.
Kernel config link,
https://pastebin.com/P1uYmdMG

Linux version 4.12.0-rc7-4-gda8b14e (buildslave@x86-64-08) (gcc
version 6.2.1 20161016 (Linaro GCC 6.2-2016.11) ) #1 SMP PREEMPT Mon
Jun 26 20:04:35 UTC 2017

Linux version 4.12.0-rc7-next-20170627 (buildslave@x86-64-07) (gcc
version 6.2.1 20161016 (Linaro GCC 6.2-2016.11)) #1 SMP PREEMPT Tue
Jun 27 06:33:39 UTC 2017

LAVA job id:
https://lkft.validation.linaro.org/scheduler/job/4397#L1412

Running tests in capabilities

[OK] Capabilities after execve were correct
[OK] Capabilities after execve were correct
[OK] Capabilities after execve were correct
[OK] Capabilities after execve were correct
[FAIL] Wrong effective state (AT_SECURE is not set)
[OK] Capabilities after execve were correct
[FAIL] Wrong ambient state (AT_SECURE is not set)
[FAIL] Wrong ambient state (AT_SECURE is not set)
[RUN] +++ Tests with uid == 0 +++
[NOTE] Using global UIDs for tests
[RUN] Root => ep
[OK] Child succeeded
[OK] Check cap_ambient manipulation rules
[OK] PR_CAP_AMBIENT_RAISE failed on non-inheritable cap
[OK] PR_CAP_AMBIENT_RAISE failed on non-permitted cap
[OK] PR_CAP_AMBIENT_RAISE worked
[OK] Basic manipulation appears to work
[RUN] Root +i => eip
[OK] Child succeeded
[RUN] UID 0 +ia => eipa
[OK] Child succeeded
[RUN] Root +ia, suidroot => eipa
[OK] Child succeeded
[RUN] Root +ia, suidnonroot => ip
[FAIL] Child failed
[RUN] Root +ia, sgidroot => eipa
[OK] Child succeeded
[FAIL] Child failed
[RUN] Root +ia, sgidnonroot => eip
[FAIL] Child failed
[OK] Capabilities after execve were correct
[OK] Capabilities after execve were correct
[OK] Capabilities after execve were correct
[FAIL] Wrong effective state (AT_SECURE is not set)
[FAIL] Child failed
[FAIL] Child failed
selftests: test_execve [FAIL]

capabilities test PASS on Linux-4.4.70+.

Running tests in capabilities

case: step_after_suspend_test
definition: 1_kselftest
result: skip
[OK] Capabilities after execve were correct
[OK] Capabilities after execve were correct
[OK] Capabilities after execve were correct
[OK] Capabilities after execve were correct
[OK] Capabilities after execve were correct
[OK] Capabilities after execve were correct
[OK] Capabilities after execve were correct
[OK] Capabilities after execve were correct
[RUN] +++ Tests with uid == 0 +++
[NOTE] Using global UIDs for tests
[RUN] Root => ep
[OK] Child succeeded
[OK] Check cap_ambient manipulation rules
[OK] PR_CAP_AMBIENT_RAISE failed on non-inheritable cap
[OK] PR_CAP_AMBIENT_RAISE failed on non-permitted cap
[OK] PR_CAP_AMBIENT_RAISE worked
[OK] Basic manipulation appears to work
[RUN] Root +i => eip
[OK] Child succeeded
[RUN] UID 0 +ia => eipa
[OK] Child succeeded
[RUN] Root +ia, suidroot => eipa
[OK] Child succeeded
[RUN] Root +ia, suidnonroot => ip
[OK] Child succeeded
[RUN] Root +ia, sgidroot => eipa
[OK] Child succeeded
[OK] Child succeeded
[RUN] Root +ia, sgidnonroot => eip
[OK] Child succeeded
[OK] Capabilities after execve were correct
[OK] Capabilities after execve were correct
[OK] Capabilities after execve were correct
[OK] Capabilities after execve were correct
[OK] Child succeeded
[OK] Child succeeded
selftests: test_execve [PASS]

Thanks and best regards,
Naresh Kamboju

Re: [PATCH] arm: perf: make of_device_ids const

[Will Deacon]

On Tue, Jun 27, 2017 at 11:42:21AM +0530, Arvind Yadav wrote:
> of_device_ids are not supposed to change at runtime. All functions
> working with of_device_ids provided by  work with const
> of_device_ids. So mark the non-const structs as const.
> 
> Signed-off-by: Arvind Yadav 
> ---
>  arch/arm/kernel/perf_event_v6.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

This is already queued in -next.

Will

[PATCH] ligtnvm: if LUNs are already allocated fix return

[Matias Bjørling]

From: Rakesh Pandit 

While creating new device with NVM_DEV_CREATE if LUNs are already
allocated ioctl would return -ENOMEM which is wrong.  This patch
propagates -EBUSY from nvm_reserve_luns which is correct response.

Fixes: ade69e243 ("lightnvm: merge gennvm with core")
Signed-off-by: Rakesh Pandit 
Signed-off-by: Matias Bjørling 
---
 drivers/lightnvm/core.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c
index b8f82f5..9ff348f 100644
--- a/drivers/lightnvm/core.c
+++ b/drivers/lightnvm/core.c
@@ -235,7 +235,7 @@ static int nvm_create_tgt(struct nvm_dev *dev, struct 
nvm_ioctl_create *create)
struct nvm_target *t;
struct nvm_tgt_dev *tgt_dev;
void *targetdata;
-   int ret;
+   int ret = 0;
 
tt = nvm_find_target_type(create->tgttype, 1);
if (!tt) {
@@ -252,8 +252,9 @@ static int nvm_create_tgt(struct nvm_dev *dev, struct 
nvm_ioctl_create *create)
}
mutex_unlock(&dev->mlock);
 
-   if (nvm_reserve_luns(dev, s->lun_begin, s->lun_end))
-   return -ENOMEM;
+   ret = nvm_reserve_luns(dev, s->lun_begin, s->lun_end);
+   if (ret)
+   goto err;
 
t = kmalloc(sizeof(struct nvm_target), GFP_KERNEL);
if (!t) {
@@ -314,8 +315,8 @@ static int nvm_create_tgt(struct nvm_dev *dev, struct 
nvm_ioctl_create *create)
mutex_lock(&dev->mlock);
list_add_tail(&t->list, &dev->targets);
mutex_unlock(&dev->mlock);
-
-   return 0;
+err:
+   return ret;
 err_sysfs:
if (tt->exit)
tt->exit(targetdata);
-- 
2.9.3

[PATCH] Small patch for 4.13 window

[Matias Bjørling]

Hi Jens,

Thanks for picking up the pblk changes. I have just a small one that
wasn't part of the batch. Would you pick this one up as well for the
4.13 window?

-Matias

Rakesh Pandit (1):
  ligtnvm: if LUNs are already allocated fix return

 drivers/lightnvm/core.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

-- 
2.9.3

Re: [PATCH v4 2/4] [media] platform: Add Synopsys Designware HDMI RX Controller Driver

[Jose Abreu]

Hi Sylwester,


On 25-06-2017 22:13, Sylwester Nawrocki wrote:
> On 06/20/2017 07:26 PM, Jose Abreu wrote:
>> This is an initial submission for the Synopsys Designware HDMI RX
>> Controller Driver. This driver interacts with a phy driver so that
>> a communication between them is created and a video pipeline is
>> configured.
>> Signed-off-by: Jose Abreu 
>> Cc: Carlos Palminha 
>> Cc: Mauro Carvalho Chehab 
>> Cc: Hans Verkuil 
>> Cc: Sylwester Nawrocki 
>>
>> Changes from v3:
>>  - Use v4l2 async API (Sylwester)
>>  - Do not block waiting for phy
>>  - Do not use busy waiting delays (Sylwester)
>>  - Simplify dw_hdmi_power_on (Sylwester)
>>  - Use clock API (Sylwester)
>>  - Use compatible string (Sylwester)
>>  - Minor fixes (Sylwester)
>> Changes from v2:
>>  - Address review comments from Hans regarding CEC
>>  - Use CEC notifier
>>  - Enable SCDC
>> Changes from v1:
>>  - Add support for CEC
>>  - Correct typo errors
>>  - Correctly detect interlaced video modes
>>  - Correct VIC parsing
>> Changes from RFC:
>>  - Add support for HDCP 1.4
>>  - Fixup HDMI_VIC not being parsed (Hans)
>>  - Send source change signal when powering off (Hans)
>>  - Add a "wait stable delay"
>>  - Detect interlaced video modes (Hans)
>>  - Restrain g/s_register from reading/writing to HDCP regs (Hans)
>> ---
>>   drivers/media/platform/dwc/Kconfig  |   15 +
>>   drivers/media/platform/dwc/Makefile |1 +
>>   drivers/media/platform/dwc/dw-hdmi-rx.c | 1862 
>> +++
>>   drivers/media/platform/dwc/dw-hdmi-rx.h |  441 
>>   include/media/dwc/dw-hdmi-rx-pdata.h|   97 ++
>>   5 files changed, 2416 insertions(+)
>>   create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.c
>>   create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.h
>>   create mode 100644 include/media/dwc/dw-hdmi-rx-pdata.h
>>
>> diff --git a/drivers/media/platform/dwc/dw-hdmi-rx.c 
>> b/drivers/media/platform/dwc/dw-hdmi-rx.c
>> new file mode 100644
>> index 000..22ee51d
>> --- /dev/null
>> +++ b/drivers/media/platform/dwc/dw-hdmi-rx.c
>> +static const struct of_device_id dw_hdmi_supported_phys[] = {
>> +{ .compatible = "snps,dw-hdmi-phy-e405", .data = DW_PHY_E405_DRVNAME, },
>> +{ },
>> +};
>> +
>> +static struct device_node *dw_hdmi_get_phy_of_node(struct dw_hdmi_dev 
>> *dw_dev,
>> +const struct of_device_id **found_id)
>> +{
>> +struct device_node *child = NULL;
>> +const struct of_device_id *id;
>> +
>> +for_each_child_of_node(dw_dev->of_node, child) {
>> +id = of_match_node(dw_hdmi_supported_phys, child);
>> +if (id)
>> +break;
>> +}
>> +
>> +if (found_id)
>> +*found_id = id;
>> +
>> +return child;
>> +}
>> +
>> +static int dw_hdmi_phy_init(struct dw_hdmi_dev *dw_dev)
>> +{
>> +struct dw_phy_pdata *phy = &dw_dev->phy_config;
>> +const struct of_device_id *of_id;
>> +struct of_dev_auxdata lookup;
>   struct of_dev_auxdata lookup = { };
>
> You could initialize to 0 here and...
>
>> +struct device_node *child;
>> +const char *drvname;
>> +int ret;
>> +
>> +child = dw_hdmi_get_phy_of_node(dw_dev, &of_id);
>> +if (!child || !of_id || !of_id->data) {
>> +dev_err(dw_dev->dev, "no supported phy found in DT\n");
>> +return -EINVAL;
>> +}
>> +
>> +drvname = of_id->data;
>> +phy->funcs = &dw_hdmi_phy_funcs;
>> +phy->funcs_arg = dw_dev;
>> +
>> +lookup.compatible = (char *)of_id->compatible;
>> +lookup.phys_addr = 0x0;
>> +lookup.name = NULL;
> ...drop these two assignments.

Ok.

>
>> +lookup.platform_data = phy;
>> +
>> +request_module(drvname);
> I'd say this request_module() is not needed when you use the v4l2-async 
> subnotifiers and the modules are properly installed in the file system.
> I might be missing something though.

Hmm, well I didn't actually test without request_module but I
think its needed, otherwise I would have to do:

modprobe phy_module
modprobe controller_module

With request_module I just have to do:

modprobe controller_module

>
>> +ret = of_platform_populate(dw_dev->of_node, NULL, &lookup, dw_dev->dev);
>> +if (ret) {
>> +dev_err(dw_dev->dev, "failed to populate phy driver\n");
>> +return ret;
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +static void dw_hdmi_phy_exit(struct dw_hdmi_dev *dw_dev)
>> +{
>> +of_platform_depopulate(dw_dev->dev);
>> +}
>> +static int dw_hdmi_registered(struct v4l2_subdev *sd)
>> +{
>> +struct dw_hdmi_dev *dw_dev = to_dw_dev(sd);
>> +int ret;
>> +
>> +ret = cec_register_adapter(dw_dev->cec_adap, dw_dev->dev);
>> +if (ret) {
>> +dev_err(dw_dev->dev, "failed to register CEC adapter\n");
>> +cec_delete_adapter(dw_dev->cec_adap);
>> +return ret;
>> +}
>> +
>> +cec_register_cec_notifier(d

Re: [PATCH 13/17] RISC-V: Add include subdirectory

[Will Deacon]

Hi Dan,

On Tue, Jun 27, 2017 at 12:07:20AM +, Daniel Lustig wrote:
> > > https://github.com/riscv/riscv-isa-manual/releases/download/riscv-user
> > > -2.2/riscv-spec-v2.2.pdf
> > 
> > That's the most up to date spec.
> 
> Yes, that's the most up to date public spec.  Internally, the RISC-V memory
> model task group has been working on fixing the memory model spec for the
> past couple of months now.  We're aiming to release it for public review
> well before the end of the year.  Hopefully in the coming weeks even.

Excellent, cheers for the update.

> > > which, on the one hand is reassuring (because ignoring dependency
> > > ordering is plain broken), but on the other it doesn't go quite far
> > > enough in defining exactly what constitutes a "syntactic data
> > > dependency". The cumulativity of your fences also needs defining,
> > > because I think this was up in the air at some point and the document
> > > above doesn't seem to tackle it (it doesn't seem to describe what
> > > constitutes being a memory of the predecessor or successor sets)
> 
> That will all covered in the new spec.
> 
> > > P.S. You should also totally get your architects to write a formal
> > > model ;)
> 
> Also in progress :)

3/3 :)

> Were there any more specific questions I can answer in the meantime?  Or
> any specific concern you'd like to point me to?

Nothing specific, but we won't be able to review the
memory-ordering/atomics/locking parts of this patch series until we have
a spec.

Will

Re: [PATCH 3/6] xfs: map KM_MAYFAIL to __GFP_RETRY_MAYFAIL

[Michal Hocko]

Christoph, Darrick
could you have a look at this patch please? Andrew has put it into mmotm
but I definitely do not want it passes your attention.

On Fri 23-06-17 10:53:42, Michal Hocko wrote:
> From: Michal Hocko 
> 
> KM_MAYFAIL didn't have any suitable GFP_FOO counterpart until recently
> so it relied on the default page allocator behavior for the given set
> of flags. This means that small allocations actually never failed.
> 
> Now that we have __GFP_RETRY_MAYFAIL flag which works independently on the
> allocation request size we can map KM_MAYFAIL to it. The allocator will
> try as hard as it can to fulfill the request but fails eventually if
> the progress cannot be made. It does so without triggering the OOM
> killer which can be seen as an improvement because KM_MAYFAIL users
> should be able to deal with allocation failures.
> 
> Cc: Darrick J. Wong 
> Cc: Christoph Hellwig 
> Signed-off-by: Michal Hocko 
> ---
>  fs/xfs/kmem.h | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/fs/xfs/kmem.h b/fs/xfs/kmem.h
> index d6ea520162b2..4d85992d75b2 100644
> --- a/fs/xfs/kmem.h
> +++ b/fs/xfs/kmem.h
> @@ -54,6 +54,16 @@ kmem_flags_convert(xfs_km_flags_t flags)
>   lflags &= ~__GFP_FS;
>   }
>  
> + /*
> +  * Default page/slab allocator behavior is to retry for ever
> +  * for small allocations. We can override this behavior by using
> +  * __GFP_RETRY_MAYFAIL which will tell the allocator to retry as long
> +  * as it is feasible but rather fail than retry forever for all
> +  * request sizes.
> +  */
> + if (flags & KM_MAYFAIL)
> + lflags |= __GFP_RETRY_MAYFAIL;
> +
>   if (flags & KM_ZERO)
>   lflags |= __GFP_ZERO;
>  
> -- 
> 2.11.0
> 

-- 
Michal Hocko
SUSE Labs

Re: [PATCH v2 3/5] dt-bindings: stm32-dma: Add property to handle STM32 DMAMUX

[Pierre Yves MORDRET]

On 06/26/2017 09:33 PM, Rob Herring wrote:
> On Fri, Jun 23, 2017 at 03:00:51PM +0200, Pierre-Yves MORDRET wrote:
>> This patch adds an optional property needed for STM32 DMA controller
>> addressed via STM32 DMAMUX.
>>
>> Signed-off-by: M'boumba Cedric Madianga 
>> Signed-off-by: Pierre-Yves MORDRET 
>> ---
>>   Version history:
>>  v2:
>>  * Typo fix
>> ---
>> ---
>>   Documentation/devicetree/bindings/dma/stm32-dma.txt | 5 -
>>   1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/dma/stm32-dma.txt 
>> b/Documentation/devicetree/bindings/dma/stm32-dma.txt
>> index 4408af6..340c918 100644
>> --- a/Documentation/devicetree/bindings/dma/stm32-dma.txt
>> +++ b/Documentation/devicetree/bindings/dma/stm32-dma.txt
>> @@ -16,6 +16,9 @@ Optional properties:
>>   - resets: Reference to a reset controller asserting the DMA controller
>>   - st,mem2mem: boolean; if defined, it indicates that the controller 
>> supports
>> memory-to-memory transfer
>> +- st,dmamux: boolean; if defined, it indicates that the controller is 
>> behind a
>> +  DMA multiplexer. In that case, using dma instances doesn't work for DMA
>> +  clients. They have to use dma-router instances.
> 
> Won't this be obvious looking at the bindings for clients?
> 
> In any case, this should be implied by the compatible string.
> 
> Rob
> 

Not sure what you are asking here.

Py

Re: [PATCH v2 1/5] dt-bindings: Document the STM32 DMAMUX bindings

[Pierre Yves MORDRET]

On 06/26/2017 09:28 PM, Rob Herring wrote:
> On Fri, Jun 23, 2017 at 03:00:49PM +0200, Pierre-Yves MORDRET wrote:
>> This patch adds the documentation of device tree bindings for the STM32
>> DMAMUX.
>>
>> Signed-off-by: M'boumba Cedric Madianga 
>> Signed-off-by: Pierre-Yves MORDRET 
>> ---
>>   Version history:
>>  v2:
>>  * Move clock bindings from optional to mandatory one
>>  * Drop channelID bindings as managed dynamically from now on by
>>DMAMUX driver.
>> ---
>> ---
>>   .../devicetree/bindings/dma/stm32-dmamux.txt   | 57 
>> ++
>>   1 file changed, 57 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/dma/stm32-dmamux.txt
>>
>> diff --git a/Documentation/devicetree/bindings/dma/stm32-dmamux.txt 
>> b/Documentation/devicetree/bindings/dma/stm32-dmamux.txt
>> new file mode 100644
>> index 000..1d413c5
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/dma/stm32-dmamux.txt
>> @@ -0,0 +1,57 @@
>> +STM32 DMA MUX (DMA request router)
>> +
>> +Required properties:
>> +- compatible:   "st,stm32-dmamux"
> 
> This should be SoC specific (or at least have f4, h7, etc.).

Ok.
compatible:"st,stm32h7-dmamux"

> 
>> +- reg:  Memory map for accessing module
>> +- #dma-cells:   Should be set to <3>.
>> +For more details about the three cells, please see
>> +stm32-dma.txt documentation binding file
> 
> The example below has 4 cells for the dma ctrlr?
> 

Yes.
DMA Controller has 4 cells and DMAMUX only 3.
But I agree this is not very clear. I should add a comment on each cells 
to highlight the mapping onto DMA Cells

>> +- dma-masters:  Phandle pointing to the DMA controller
>> +
>> +Optional properties:
>> +- dma-channels : Number of DMA channels supported.
>> +- dma-requests : Number of DMA requests supported.
>> +- resets: Reference to a reset controller asserting the DMA controller
>> +- clocks: Input clock of the DMAMUX instance.
>> +
>> +Example:
>> +
>> +/* DMA controller */
>> +dma2: dma-controller@40026400 {
>> +compatible = "st,stm32-dma";
>> +reg = <0x40026400 0x400>;
>> +interrupts = <56>,
>> + <57>,
>> + <58>,
>> + <59>,
>> + <60>,
>> + <68>,
>> + <69>,
>> + <70>;
>> +clocks = <&clk_hclk>;
>> +#dma-cells = <4>;
>> +st,mem2mem;
>> +resets = <&rcc 150>;
>> +st,dmamux;
>> +dma-channels = <8>;
>> +};
>> +
>> +/* DMA mux */
>> +dmamux2: dma-router@40020820 {
>> +compatible = "st,stm32-dmamux";
>> +reg = <0x40020800 0x1c>;
>> +#dma-cells = <3>;
>> +dma-requests = <128>;
>> +dma-masters = <&dma2>;
>> +};
>> +
>> +/* DMA client */
>> +usart1: serial@40011000 {
>> +compatible = "st,stm32-usart", "st,stm32-uart";
>> +reg = <0x40011000 0x400>;
>> +interrupts = <37>;
>> +clocks = <&clk_pclk2>;
>> +dmas = <&dmamux2 41 0x414 0>,
>> +   <&dmamux2 42 0x414 0>;
>> +dma-names = "rx", "tx";
>> +};
>> -- 
>> 1.9.1
>>

Py

Re: [PATCH] x86/boot/KASLR: Skip relocation handling in no kaslr case

[Baoquan He]

On 06/27/17 at 10:34am, Ingo Molnar wrote:
> 
> * Baoquan He  wrote:
> 
> > As you suggested, we can add a checking to see if the virt_addr is
> > bigger than 1G, and print warning if exceed or hang there with error
> > message.
> 
> Could you try a patch for that, and see whether it catches this particular 
> bug? 
> (before the fix is applied.)

Sure, below code change should catch it. Just I am struggling to decide
if I should add a new local variable and assign
 max(output_len, kernel_total_size) to it, and the name of the new local
variable is really hard to choose. Let me run a test on below code.

diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index c945acd8fa33..00241c815524 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -390,6 +390,8 @@ asmlinkage __visible void *extract_kernel(void *rmode, 
memptr heap,
 #ifdef CONFIG_X86_64
if (heap > 0x3fffUL)
error("Destination address too large");
+   if (virt_addr + max(output_len, kernel_total_size) > KERNEL_IMAGE_SIZE)
+   error("Destination virtual address is beyond the kernel mapping 
area");
 #else
if (heap > ((-__PAGE_OFFSET-(128<<20)-1) & 0x7fff))
error("Destination address too large");

[PATCH] fix Uart_C Pinning of odroidc2 in linux-4.12.-rc7

[Otto Meier]

Please find attached a fix for wrong uart_c pinning of odroid-c2

in mainline kernels

Regards

Otto




--- linux-next-20170623/drivers/pinctrl/meson/pinctrl-meson-gxbb.c.orig	2017-06-23 11:30:35.072037057 +0200
+++ linux-next-20170623/drivers/pinctrl/meson/pinctrl-meson-gxbb.c	2017-06-26 12:31:27.161783467 +0200
@@ -202,8 +202,8 @@ static const unsigned int uart_rts_b_pin
 
 static const unsigned int uart_tx_c_pins[]	= { PIN(GPIOY_13, EE_OFF) };
 static const unsigned int uart_rx_c_pins[]	= { PIN(GPIOY_14, EE_OFF) };
-static const unsigned int uart_cts_c_pins[]	= { PIN(GPIOX_11, EE_OFF) };
-static const unsigned int uart_rts_c_pins[]	= { PIN(GPIOX_12, EE_OFF) };
+static const unsigned int uart_cts_c_pins[]	= { PIN(GPIOY_11, EE_OFF) };
+static const unsigned int uart_rts_c_pins[]	= { PIN(GPIOY_12, EE_OFF) };
 
 static const unsigned int i2c_sck_a_pins[]	= { PIN(GPIODV_25, EE_OFF) };
 static const unsigned int i2c_sda_a_pins[]	= { PIN(GPIODV_24, EE_OFF) };
@@ -444,10 +444,10 @@ static struct meson_pmx_group meson_gxbb
 	GROUP(pwm_f_x,		3,	18),
 
 	/* Bank Y */
-	GROUP(uart_cts_c,	1,	19),
-	GROUP(uart_rts_c,	1,	18),
-	GROUP(uart_tx_c,	1,	17),
-	GROUP(uart_rx_c,	1,	16),
+	GROUP(uart_cts_c,	1,	17),
+	GROUP(uart_rts_c,	1,	16),
+	GROUP(uart_tx_c,	1,	19),
+	GROUP(uart_rx_c,	1,	18),
 	GROUP(pwm_a_y,		1,	21),
 	GROUP(pwm_f_y,		1,	20),
 	GROUP(i2s_out_ch23_y,	1,	5),

Reply me back!!

[Mr.Adams Salem]

I have been trying to reach you

Re: [PATCH v2 1/8] dt-bindings: mfd: Add STM32 LPTimer binding

[Fabrice Gasnier]

On 06/26/2017 08:07 PM, Rob Herring wrote:
> On Wed, Jun 21, 2017 at 04:30:08PM +0200, Fabrice Gasnier wrote:
>> Add documentation for STMicroelectronics STM32 Low-Power Timer binding.
>>
>> Signed-off-by: Fabrice Gasnier 
>> ---
>> Changes in v2:
>> - Lee's comments: s/Low Power/Low-Power/, remove 0x in example, improve
>>   properties descriptions
>> ---
>>  .../devicetree/bindings/mfd/stm32-lptimer.txt  | 48 
>> ++
>>  1 file changed, 48 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/mfd/stm32-lptimer.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/stm32-lptimer.txt 
>> b/Documentation/devicetree/bindings/mfd/stm32-lptimer.txt
>> new file mode 100644
>> index 000..af859c8
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/stm32-lptimer.txt
>> @@ -0,0 +1,48 @@
>> +STMicroelectronics STM32 Low-Power Timer
>> +
>> +The STM32 Low-Power Timer (LPTIM) is a 16-bit timer that provides several
>> +functions:
>> +- PWM output (with programmable prescaler, configurable polarity)
>> +- Quadrature encoder, counter
>> +- Trigger source for STM32 ADC/DAC (LPTIM_OUT)
>> +
>> +Required properties:
>> +- compatible:   Must be "st,stm32-lptimer".
>> +- reg:  Offset and length of the device's register set.
>> +- clocks:   Phandle to the clock used by the LP Timer module.
>> +- clock-names:  Must be "mux".
>> +- #address-cells:   Should be '<1>'.
>> +- #size-cells:  Should be '<0>'.
>> +
>> +Optional subnodes:
>> +- pwm:  See ../pwm/pwm-stm32-lp.txt
>> +- counter:  See ../iio/timer/stm32-lptimer-cnt.txt
>> +- trigger:  See ../iio/timer/stm32-lptimer-trigger.txt
>> +
>> +Example:
>> +
>> +lptimer1: lptimer@40002400 {
> 
> timer@...

Hi Rob,

I initially put "lptimer" here to distinguish Low-Power Timer hardware
from other "timers" hardware that can be found also on stm32 devices.
I'd prefer to keep it, is it sensible from your point of view ?
Please advise.

> 
>> +compatible = "st,stm32-lptimer";
>> +reg = <0x40002400 0x400>;
>> +clocks = <&timer_clk>;
>> +clock-names = "mux";
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>> +pwm {
>> +compatible = "st,stm32-pwm-lp";
>> +pinctrl-names = "default";
>> +pinctrl-0 = <&lppwm1_pins>;
>> +};
>> +
>> +trigger@0 {
>> +compatible = "st,stm32-lptimer-trigger";
>> +reg = <0>;
> 
> Is there more than 1? 

reg identifies trigger hardware block.

Best Regards,
Thanks,
Fabrice

> 
>> +};
>> +
>> +counter {
>> +compatible = "st,stm32-lptimer-counter";
>> +pinctrl-names = "default";
>> +pinctrl-0 = <&lptim1_in_pins>;
>> +};
>> +};
>> -- 
>> 1.9.1
>>

Re: [PATCH v11 3/4] i2c: aspeed: added driver for Aspeed I2C

[Wolfram Sang]

> > If SCL is stuck low, how do you want to send a STOP?
> >
> 
> Fair point. I should probably drop that in the future and just do a
> reset, and even then, doing a
> reset is probably just wishful thinking. If a slave is holding down
> SCL, we are pretty screwed.

Yes, you'd need to reset the client device. And that has to be done in
the client driver. I wonder if i2c_transfer and friends should return a
specific error value in that case... need to think about it.



signature.asc
Description: PGP signature

Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i

[Andre Przywara]

Hi,

(CC:ing some people from that Rockchip dmwac series)

On 27/06/17 09:21, Corentin Labbe wrote:
> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
>>  wrote:
>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
 On 31/05/17 08:18, Corentin Labbe wrote:
> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> allwinner.
> In fact the only common part is the descriptor management and the first
> register function.

 Hi,

 I know I am a bit late with this, but while adapting the U-Boot driver
 to the new binding I was wondering about the internal PHY detection:


 So here you seem to deduce the usage of the internal PHY by the PHY
 interface specified in the DT (MII = internal, RGMII = external).
 I think I raised this question before, but isn't it perfectly legal for
 a board to use MII with an external PHY even on those SoCs that feature
 an internal PHY?
 On the first glance that does not make too much sense, but apart from
 not being the correct binding to describe all of the SoCs features I see
 two scenarios:
 1) A board vendor might choose to not use the internal PHY because it
 has bugs, lacks features (configurability) or has other issues. For
 instance I have heard reports that the internal PHY makes the SoC go
 rather hot, possibly limiting the CPU frequency. By using an external
 MII PHY (which are still cheaper than RGMII PHYs) this can be avoided.
 2) A PHY does not necessarily need to be directly connected to
 magnetics. Indeed quite some boards use (RG)MII to connect to a switch
 IC or some other network circuitry, for instance fibre connectors.

 So I was wondering if we would need an explicit:
   allwinner,use-internal-phy;
 boolean DT property to signal the usage of the internal PHY?
 Alternatively we could go with the negative version:
   allwinner,disable-internal-phy;

 Or what about introducing a new "allwinner,internal-mii-phy" compatible
 string for the *PHY* node and use that?

 I just want to avoid that we introduce a binding that causes us
 headaches later. I think we can still fix this with a followup patch
 before the driver and its binding hit a release kernel.

 Cheers,
 Andre.

>>>
>>> I just see some patch, where "phy-mode = internal" is valid.
>>> I will try to find a way to use it
>>
>> Can you provide a link?
> 
> https://lkml.org/lkml/2017/6/23/479
> 
>>
>> I'm not a fan of using phy-mode for this. There's no guarantee what
>> mode the internal PHY uses. That's what phy-mode is for.

I can understand Chen-Yu's concerns, but ...

> For each soc the internal PHY mode is know and setted in 
> emac_variant/internal_phy
> So its not a problem.

that is true as well, at least for now.

So while I agree that having a separate property to indicate the usage
of the internal PHY would be nice, I am bit tempted to use this easier
approach and piggy back on the existing phy-mode property.

Are there any insights from the people involved with the Rockchip
internal PHY?
It is worth to introduce a generic boolean property for an internal PHY?
Or shall we actually move this more into the PHY code, introducing new
compatibles for the internal Allwinner and Rockchip Ethernet PHYs?

Cheers,
Andre.

Re: [PATCH 0/2] Notifications for perf sideband events

[Naveen N. Rao]

On 2017/06/19 08:01PM, Naveen N. Rao wrote:
> Currently, there is no way to ask for signals to be delivered when a
> certain number of sideband events have been logged into the ring buffer.
> This is problematic if we are only interested in, say, context switch
> events. Furthermore, signals are more useful (rather than polling) for
> self-profiling. This series provides for a way to achieve this.
> 
> We ride on top of the existing support for ring buffer wakeup to
> generate signals as desired. Counting sideband events still requires
> some changes in the output path, but in normal cases, it ends up being
> just a comparison.
> 
> for
> context switch events and how it can control notification through
> signals. The key changes include the below perf_event_attr settings as
> well as use of IOC_ENABLE:
>   pe.signal_on_wakeup = 1;
>   pe.count_sb_events = 1;
>   pe.wakeup_events = 2;
> 
> To keep things simple, PERF_EVENT_IOC_REFRESH cannot be used if any of
> the new attributes are set.
> 
> RFC v2:
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1420363.html
> Changes:
>   - Send HUP on perf_event_exit_event() (suggested by Jiri)
>   - Disable use of IOC_REFRESH if signal_on_wakeup/count_sb_events is
> set.

Peter, Arnaldo, Jiri,
Can you please take a look at this patchset?

Thanks,
Naveen

> 
> 
> - Naveen
> 
> ---
> Here is a sample program demonstrating the same:
> 
> #define _GNU_SOURCE
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> static long
> perf_event_open(struct perf_event_attr *hw_event, pid_t pid,
>  int cpu, int group_fd, unsigned long flags)
> {
>   return syscall(__NR_perf_event_open, hw_event, pid, cpu,
> group_fd, flags);
> }
> 
> static void sigio_handler(int n, siginfo_t *info, void *uc)
> {
>   fprintf (stderr, "Caught %s\n", info->si_code == POLL_HUP ? "POLL_HUP" :
>  (info->si_code == POLL_IN ? "POLL_IN" : "other signal"));
> }
> 
> int main(int argc, char **argv)
> {
>   struct perf_event_attr pe;
>   struct sigaction act;
>   int fd;
>   void *buf;
> 
>   memset(&act, 0, sizeof(act));
>   act.sa_sigaction = sigio_handler;
>   act.sa_flags = SA_SIGINFO;
>   sigaction(SIGIO, &act, 0);
> 
>   memset(&pe, 0, sizeof(struct perf_event_attr));
>   pe.size = sizeof(struct perf_event_attr);
>   pe.type = PERF_TYPE_SOFTWARE;
>   pe.config = PERF_COUNT_SW_DUMMY;
>   pe.disabled = 1;
>   pe.sample_period = 1;
>   pe.context_switch = 1;
>   pe.signal_on_wakeup = 1;
>   pe.count_sb_events = 1;
>   pe.wakeup_events = 2;
> 
>   fd = perf_event_open(&pe, 0, -1, -1, 0);
>   if (fd == -1) {
>   fprintf(stderr, "Error opening leader %lx\n", (unsigned 
> long)pe.config);
>   exit(EXIT_FAILURE);
>   }
> 
>   buf = mmap(NULL, sysconf(_SC_PAGESIZE) * 2, PROT_READ|PROT_WRITE, 
> MAP_SHARED, fd, 0);
>   if (buf == MAP_FAILED) {
>   fprintf(stderr, "Can't mmap buffer\n");
>   return -1;
>   }
> 
>   if (fcntl(fd, F_SETFL, fcntl(fd, F_GETFL, 0) | O_ASYNC) == -1)
>   return -2;
> 
>   if (fcntl(fd, F_SETSIG, SIGIO) == -1)
>   return -3;
> 
>   if (fcntl(fd, F_SETOWN, getpid()) == -1)
>   return -4;
> 
>   if (ioctl(fd, PERF_EVENT_IOC_ENABLE, 0) == -1)
>   return -5;
> 
>   fprintf (stderr, "Sleep 1\n");
>   sleep(1);
>   fprintf (stderr, "Sleep 2\n");
>   sleep(1);
>   fprintf (stderr, "Sleep 3\n");
>   sleep(1);
> 
>   /* Disable the event counter */
>   ioctl(fd, PERF_EVENT_IOC_DISABLE, 1);
> 
>   close(fd);
> 
>   return 0;
> }
> 
> 
> A sample output:
> $ time ./cs
> Sleep 1
> Caught POLL_IN
> Sleep 2
> Caught POLL_IN
> Sleep 3
> Caught POLL_IN
> 
> real  0m3.040s
> user  0m0.001s
> sys   0m0.003s
> 
> 
> Naveen N. Rao (2):
>   kernel/events: Add option to notify through signals on wakeup
>   kernel/events: Add option to enable counting sideband events in
> wakeup_events
> 
>  include/uapi/linux/perf_event.h |  4 +++-
>  kernel/events/core.c| 20 
>  kernel/events/ring_buffer.c | 16 
>  3 files changed, 31 insertions(+), 9 deletions(-)
> 
> -- 
> 2.13.1
> 

Re: [PATCH v2 5/8] dt-bindings: iio: Add STM32 LPTimer trigger binding

[Fabrice Gasnier]

On 06/26/2017 10:38 PM, Jonathan Cameron wrote:
> 
> 
> On 26 June 2017 19:14:16 BST, Rob Herring  wrote:
>> On Wed, Jun 21, 2017 at 04:30:12PM +0200, Fabrice Gasnier wrote:
>>> Add documentation for STMicroelectronics STM32 Low-Power Timer
>> Trigger
>>> binding.
>>>
>>> Signed-off-by: Fabrice Gasnier 
>>> ---
>>> Changes in v2:
>>> - s/Low Power/Low-Power
>>> - remove leading 0x in example (parent node)
>>> - improve reg property description
>>> ---
>>>  .../bindings/iio/timer/stm32-lptimer-trigger.txt   | 23
>> ++
>>>  1 file changed, 23 insertions(+)
>>>  create mode 100644
>> Documentation/devicetree/bindings/iio/timer/stm32-lptimer-trigger.txt
>>>
>>> diff --git
>> a/Documentation/devicetree/bindings/iio/timer/stm32-lptimer-trigger.txt
>> b/Documentation/devicetree/bindings/iio/timer/stm32-lptimer-trigger.txt
>>> new file mode 100644
>>> index 000..466d99f
>>> --- /dev/null
>>> +++
>> b/Documentation/devicetree/bindings/iio/timer/stm32-lptimer-trigger.txt
>>> @@ -0,0 +1,23 @@
>>> +STMicroelectronics STM32 Low-Power Timer Trigger
>>> +
>>> +STM32 Low-Power Timer provides trigger source (LPTIM output) that
>> can be used
>>> +by STM32 internal ADC and/or DAC.
>>> +
>>> +Must be a sub-node of an STM32 Low-Power Timer device tree node.
>>> +See ../mfd/stm32-lptimer.txt for details about the parent node.
>>> +
>>> +Required properties:
>>> +- compatible:  Must be "st,stm32-lptimer-trigger".
>>> +- reg: Selects trigger hardware block. Must be 0, 1 or 
>>> 2
>>> +   respectively for lptimer1, lptimer2 or lptimer3
>>> +   trigger output.
>>
>> I guess this answers my question. However, this seems like abuse of the
>>
>> reg prop. This should not be how you select a trigger. The DT should 
>> describe all the h/w blocks and then the adc connection is a separate 
>> property.
> I think this is miss described. Reg is labelling instances of the hardware 
> block which is providing the trigger.

Hi Rob, Jonathan,

yes, reg identifies trigger hardware block.
I'll better describe in v3:
- reg: Identify trigger hardware block.

Best regards,
Fabrice

> 
> The connection to an ADC etc is done from userspace.
> 
> 
>>
>> Rob
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Applied "spi: atmel: fix corrupted data issue on SAM9 family SoCs" to the spi tree

[Cyrille Pitchen]

Hi Russell,

Le 23/06/2017 à 19:18, Russell King - ARM Linux a écrit :
> On Fri, Jun 23, 2017 at 05:15:58PM +0100, Mark Brown wrote:
>> +#ifdef CONFIG_SOC_SAM_V4_V5
>> +/*
>> + * Atmel SoCs based on ARM9 (SAM9x) cores should not use spi_map_buf()
>> + * since this later function tries to map buffers with dma_map_sg()
>> + * even if they have not been allocated inside DMA-safe areas.
>> + * On SoCs based on Cortex A5 (SAMA5Dx), it works anyway because for
>> + * those ARM cores, the data cache follows the PIPT model.
>> + * Also the L2 cache controller of SAMA5D2 uses the PIPT model too.
>> + * In case of PIPT caches, there cannot be cache aliases.
>> + * However on ARM9 cores, the data cache follows the VIVT model, hence
>> + * the cache aliases issue can occur when buffers are allocated from
>> + * DMA-unsafe areas, by vmalloc() for instance, where cache coherency is
>> + * not taken into account or at least not handled completely (cache
>> + * lines of aliases are not invalidated).
> 
> There is a solution to this - code (iow, callers of functions that perform
> IO) are expected to use flush_kernel_vmap_range() and
> invalidate_kernel_vmap_range() as documented in Documentation/cachetlb.txt
> to ensure that their "special" views are properly handled.
> 
> These are no-ops for PIPT caches, but aliasing caches have to implement
> them.
> 

So if I understand, calling those two functions at the right places, we
could use DMA transfer again without the need of copying data into a
bounce buffer? It sounds great, I will study that.

Thanks!

Cyrille

Re: [PATCH] ligtnvm: if LUNs are already allocated fix return

[Frans Klaver]

On Tue, Jun 27, 2017 at 10:39 AM, Matias Bjørling  wrote:
> From: Rakesh Pandit 
>
> While creating new device with NVM_DEV_CREATE if LUNs are already
> allocated ioctl would return -ENOMEM which is wrong.  This patch
> propagates -EBUSY from nvm_reserve_luns which is correct response.
>
> Fixes: ade69e243 ("lightnvm: merge gennvm with core")
> Signed-off-by: Rakesh Pandit 
> Signed-off-by: Matias Bjørling 
> ---
>  drivers/lightnvm/core.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c
> index b8f82f5..9ff348f 100644
> --- a/drivers/lightnvm/core.c
> +++ b/drivers/lightnvm/core.c
> @@ -235,7 +235,7 @@ static int nvm_create_tgt(struct nvm_dev *dev, struct 
> nvm_ioctl_create *create)
> struct nvm_target *t;
> struct nvm_tgt_dev *tgt_dev;
> void *targetdata;
> -   int ret;
> +   int ret = 0;

Is there any way that you can reach a 'return ret' without having ret
set by some other assignment?


> tt = nvm_find_target_type(create->tgttype, 1);
> if (!tt) {
> @@ -252,8 +252,9 @@ static int nvm_create_tgt(struct nvm_dev *dev, struct 
> nvm_ioctl_create *create)
> }
> mutex_unlock(&dev->mlock);
>
> -   if (nvm_reserve_luns(dev, s->lun_begin, s->lun_end))
> -   return -ENOMEM;
> +   ret = nvm_reserve_luns(dev, s->lun_begin, s->lun_end);
> +   if (ret)
> +   goto err;

Why don't you return err straight away here?


> t = kmalloc(sizeof(struct nvm_target), GFP_KERNEL);
> if (!t) {
> @@ -314,8 +315,8 @@ static int nvm_create_tgt(struct nvm_dev *dev, struct 
> nvm_ioctl_create *create)
> mutex_lock(&dev->mlock);
> list_add_tail(&t->list, &dev->targets);
> mutex_unlock(&dev->mlock);
> -
> -   return 0;
> +err:
> +   return ret;

This should not be necessary. In any case, the de-init order should
always be the reverse of the init order, so we don't end up confused.

Frans

[PATCH] sparc: kernel: pmc: make of_device_ids const.

[Arvind Yadav]

of_device_ids are not supposed to change at runtime. All functions
working with of_device_ids provided by  work with const
of_device_ids. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 arch/sparc/kernel/pmc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/sparc/kernel/pmc.c b/arch/sparc/kernel/pmc.c
index f12b23f..3b26cf6 100644
--- a/arch/sparc/kernel/pmc.c
+++ b/arch/sparc/kernel/pmc.c
@@ -71,7 +71,7 @@ static int pmc_probe(struct platform_device *op)
return 0;
 }
 
-static struct of_device_id pmc_match[] = {
+static const struct of_device_id pmc_match[] = {
{
.name = PMC_OBPNAME,
},
-- 
1.9.1

Re: [PATCH] drm: exynos: dsi: release DSI_PORT_OUT node right after of_drm_find_bridge()

[Inki Dae]

Hi Andrzej,

2017년 06월 26일 16:02에 Andrzej Hajda 이(가) 쓴 글:
> Hi Shuah,
> 
> 
> On 24.06.2017 02:56, Shuah Khan wrote:
>> Fix to call of_node_put() right after of_drm_find_bridge() instead of
>> holding on to it until exynos_dsi_remove().
> 
> I think the current implementation is OK, node is get in probe and put
> in remove.
> There could be many bind/unbind during lifetime of the bound driver.
> For example, there is possible sequence:
> 1. probe -
> 2. bind
> 3. unbind
> 4. bind
> 
> With this patch on 2nd bind (point 4) driver will call
> of_drm_find_bridge on dsi->bridge_node which was put earlier (point 2.).
> 

Right. This is a problem.

How about moving of_drm_find_bridge function call to probe and keeping 
drm_bridge_attach call in bind for cleanup?
Seems it doesn't need to call of_drm_find_bridge function every time bind 
callback is called.

Thanks,
Inki Dae

> Regards
> Andrzej
> 
> 
>>
>> Suggested-by: Inki Dae 
>> Signed-off-by: Shuah Khan 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 5 +
>>  1 file changed, 1 insertion(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> index e337cd2..7513b88 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> @@ -1689,6 +1689,7 @@ static int exynos_dsi_bind(struct device *dev, struct 
>> device *master,
>>  
>>  if (dsi->bridge_node) {
>>  bridge = of_drm_find_bridge(dsi->bridge_node);
>> +of_node_put(dsi->bridge_node);
>>  if (bridge)
>>  drm_bridge_attach(encoder, bridge, NULL);
>>  }
>> @@ -1807,10 +1808,6 @@ static int exynos_dsi_probe(struct platform_device 
>> *pdev)
>>  
>>  static int exynos_dsi_remove(struct platform_device *pdev)
>>  {
>> -struct exynos_dsi *dsi = platform_get_drvdata(pdev);
>> -
>> -of_node_put(dsi->bridge_node);
>> -
>>  pm_runtime_disable(&pdev->dev);
>>  
>>  component_del(&pdev->dev, &exynos_dsi_component_ops);
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
>