* [Bug 91202] Output to DVI-I (or DVI-D) is blank on Tonga (R9 285 and 380X) with multiple monitors
From: bugzilla-daemon @ 2016-11-14 23:03 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-91202-502@http.bugs.freedesktop.org/>
[-- Attachment #1.1: Type: text/plain, Size: 424 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=91202
--- Comment #25 from Guido Winkelmann <guido-xorgbugs@unknownsite.de> ---
I tried upgrading to the newest commit in amd-staging-4.7 today
(680da8633ae17cdea8fddd1ede87253325c8ca25), and now it is broken now, but in a
different way, see: https://bugs.freedesktop.org/show_bug.cgi?id=98730
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 1486 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [MINUTES] Linux Plumbers Audio Mini Conference - Santa Fe 2016
From: Takashi Sakamoto @ 2016-11-14 23:03 UTC (permalink / raw)
To: Mark Brown, Patrick Lai
Cc: alsa-devel@alsa-project.org, mengdong.lin, Mauro Carvalho Chehab,
Koul, Vinod, Pierre-Louis Bossart, Lai, Patrick, Liam Girdwood,
Takashi Iwai, Lars-Peter Clausen, Ughreja, Rakesh A, Eric Laurent,
Charles Keepax, Dylan Reid
In-Reply-To: <20161114140830.rqibtdy4xjat7uis@sirena.org.uk>
Mark,
On 2016年11月14日 23:08, Mark Brown wrote:
> On Sun, Nov 13, 2016 at 08:55:59AM -0800, Patrick Lai wrote:
>
>> Can people upload their slides? Is there a central place to upload the
>> slides? I am in process of preparing workshop presentation to Qualcomm team
>> members.
>
> There's no central place for uploading slides - guess sending them in
> e-mail in followup to the minutes is as good as anything?
Let us upload our resources and add the minutes to plumbers' wiki page
you created?
http://wiki.linuxplumbersconf.org/2016:audio
Regards
Takashi Sakamoto
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply
* [Bug 98730] On kernel startup, all monitors will go blank and stay blank with newest amd-staging-4.7
From: bugzilla-daemon @ 2016-11-14 23:03 UTC (permalink / raw)
To: dri-devel
[-- Attachment #1.1: Type: text/plain, Size: 1415 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=98730
Bug ID: 98730
Summary: On kernel startup, all monitors will go blank and stay
blank with newest amd-staging-4.7
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: critical
Priority: medium
Component: DRM/AMDgpu
Assignee: dri-devel@lists.freedesktop.org
Reporter: guido-xorgbugs@unknownsite.de
When booting with the newest kernel from the amd-staging-4.7 branch from
https://cgit.freedesktop.org/~agd5f/linux/, all connected monitors will go
blank and stay blank indefinitely. The power indicator on the monitors will
start to blink as if there was no signal.
This is with commit 680da8633ae17cdea8fddd1ede87253325c8ca25. With an older
commit, d330e1e9c232895dbd0c183a647d41d54ecc0884, this branch still works.
DAL is enabled in the config in both cases.
The graphics card is a Sapphire Nitro Radeon R9 380X.
There are three monitors connected in total, one to the DVI-I port, one to the
DVI-D port and one to the DisplayPort.
I am using this particular branch as a workaround for the bug described in
https://bugs.freedesktop.org/show_bug.cgi?id=91202
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 2978 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* mvneta bug with mvneta_set_rx_mode()
From: Andrew Lunn @ 2016-11-14 23:03 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: netdev
Hi Thomas
I think i have found a bug in the mvneta driver, when coupled with
DSA. I'm using an Armada 370 RD board, but i expect you can reproduce
this in any board using mvneta and a switch.
I set the MAC address on a switch interface:
root@370-rd:~# ip link set address f2:42:42:42:42:42 dev lan2
root@370-rd:~# ip addr add 10.42.42.42/24 dev lan2
root@370-rd:~# ip link set lan2 up
root@370-rd:~# ip link set eth1 up
root@370-rd:~# ping 10.42.42.41
This does not work:
PING 10.42.42.41 (10.42.42.1) 56(84) bytes of data.
>From 10.42.42.42 icmp_seq=1 Destination Host Unreachable
>From 10.42.42.42 icmp_seq=2 Destination Host Unreachable
>From 10.42.42.42 icmp_seq=3 Destination Host Unreachable
^C
--- 10.42.42.1 ping statistics ---
10 packets transmitted, 0 received, +3 errors, 100% packet loss, time 9338ms
pipe 8
However, if i run tcpdump on the mvneta interface, so putting it into
promiscuous mode:
root@370-rd:~# tcpdump -i eth1 &
[1] 3757
root@370-rd:~# ping 10.42.42.1
PING 10.42.42.1 (10.42.42.1) 56(84) bytes of data.
64 bytes from 10.42.42.1: icmp_seq=1 ttl=64 time=1.43 ms
16:48:28.185095 MEDSA 0.2:0: ARP, Request who-has 10.42.42.1 tell 10.42.42.42, length 28
16:48:28.185767 MEDSA 0.2:0: ARP, Reply 10.42.42.1 is-at d8:eb:97:bf:44:f3 (oui Unknown), length 46
16:48:28.185961 MEDSA 0.2:0: IP 10.42.42.42 > 10.42.42.1: ICMP echo request, id 3760, seq 1, length 64
16:48:28.186429 MEDSA 0.2:0: IP 10.42.42.1 > 10.42.42.42: ICMP echo reply, id 3760, seq 1, length 64
16:48:29.186857 MEDSA 0.2:0: IP 10.42.42.42 > 10.42.42.1: ICMP echo request, id 3760, seq 2, length 64
16:48:29.187620 MEDSA 0.2:0: IP 10.42.42.1 > 10.42.42.42: ICMP echo reply, id 3760, seq 2, length 64
64 bytes from 10.42.42.1: icmp_seq=2 ttl=64 time=0.834 ms
16:48:30.189156 MEDSA 0.2:0: IP 10.42.42.42 > 10.42.42.1: ICMP echo request, id 3760, seq 3, length 64
16:48:30.189867 MEDSA 0.2:0: IP 10.42.42.1 > 10.42.42.42: ICMP echo reply, id 3760, seq 3, length 64
64 bytes from 10.42.42.1: icmp_seq=3 ttl=64 time=0.782 ms
^C
--- 10.42.42.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 0.782/1.015/1.431/0.296 ms
What should happen is that when the MAC address is set on lan2, it
calls dsa_slave_set_mac_address(). It sees that the requested address
is different to the masters MAC address, so it calls dev_uc_add() to
add the MAC address to the master device, i.e. the mvneta. That causes
the MAC address to be added to the interfaces dev->uc list. Since the
driver has dev->priv_flags & IFF_UNICAST_FLT true, it is indicating it
supports unicast filtering. So __dev_set_rx_mode() calls the drivers
set_rx_mode() to setup the filtering.
I don't see anywhere in mvneta where it walks the dev->uc list adding
these MAC addresses to its filter. Either it needs to do this, or it
should not have IFF_UNICAST_FLT, so that the core code will put the
interface into promisc mode when multiple unicast addresses are added.
Do you have time to look into this?
Thanks
Andrew
^ permalink raw reply
* [Buildroot] [git commit branch/next] package/libnet: enable on musl configurations
From: Thomas Petazzoni @ 2016-11-14 23:01 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=966e0e8e10d33407775c5e8b6beb98d0a8810072
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/next
Thanks to a patch taken from upstream
(https://github.com/sam-github/libnet/commit/ffd7fab744a9ad2893169a8fb6244074604d5d0d),
we can enable the libnet package on musl toolchain.
Adjusted the file paths manually so the patch applies to the packaged
libnet sources.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
[Thomas: allow the package to be selected with the musl C library.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
package/libnet/0001-support-musl-libc.patch | 50 +++++++++++++++++++++++++++++
package/libnet/Config.in | 5 ---
2 files changed, 50 insertions(+), 5 deletions(-)
diff --git a/package/libnet/0001-support-musl-libc.patch b/package/libnet/0001-support-musl-libc.patch
new file mode 100644
index 0000000..0704157
--- /dev/null
+++ b/package/libnet/0001-support-musl-libc.patch
@@ -0,0 +1,50 @@
+From ffd7fab744a9ad2893169a8fb6244074604d5d0d Mon Sep 17 00:00:00 2001
+From: rofl0r <retnyg@gmx.net>
+Date: Tue, 12 Aug 2014 21:51:39 +0200
+Subject: [PATCH] Support musl libc, remove support for glibc < 2.1
+
+The workarounds for glibc < 2.1 (was released february 1999) break the
+build with musl libc.
+
+It is very unlikely that 2.0 or earlier is still in use, and if so,
+1) that's a big security hole
+2) code wouldnt compile anyway since noone tested build in the last decade
+3) user of it wouldn't expect anyway to get bleeding edge sw built on it,
+ so he would just use the latest version that works for him.
+
+Closes #52
+---
+ libnet/src/libnet_link_linux.c | 11 -----------
+ 1 file changed, 11 deletions(-)
+
+diff --git a/libnet/src/libnet_link_linux.c b/libnet/src/libnet_link_linux.c
+index 054458d..3c6df3c 100644
+--- a/src/libnet_link_linux.c
++++ b/src/libnet_link_linux.c
+@@ -30,26 +30,15 @@
+ #include <sys/time.h>
+
+ #include <net/if.h>
+-#if (__GLIBC__)
+ #include <netinet/if_ether.h>
+ #include <net/if_arp.h>
+-#else
+-#include <linux/if_arp.h>
+-#include <linux/if_ether.h>
+-#endif
+
+ #if (HAVE_PACKET_SOCKET)
+ #ifndef SOL_PACKET
+ #define SOL_PACKET 263
+ #endif /* SOL_PACKET */
+-#if __GLIBC__ >= 2 && __GLIBC_MINOR >= 1
+ #include <netpacket/packet.h>
+ #include <net/ethernet.h> /* the L2 protocols */
+-#else
+-#include <asm/types.h>
+-#include <linux/if_packet.h>
+-#include <linux/if_ether.h> /* The L2 protocols */
+-#endif
+ #endif /* HAVE_PACKET_SOCKET */
+
+ #include "../include/libnet.h"
diff --git a/package/libnet/Config.in b/package/libnet/Config.in
index 0c5c230..7186972 100644
--- a/package/libnet/Config.in
+++ b/package/libnet/Config.in
@@ -1,12 +1,7 @@
config BR2_PACKAGE_LIBNET
bool "libnet"
- # Build with musl fails due to header issues
- depends on !BR2_TOOLCHAIN_USES_MUSL
help
libnet provides a portable framework for low-level network
packet construction.
http://sourceforge.net/projects/libnet-dev
-
-comment "libnet needs a glibc or uClibc toolchain"
- depends on BR2_TOOLCHAIN_USES_MUSL
^ permalink raw reply related
* Re: [RFC PATCH 1/2] net: use cmpxchg instead of spinlock in ptr rings
From: Michael S. Tsirkin @ 2016-11-14 23:01 UTC (permalink / raw)
To: John Fastabend; +Cc: jasowang, netdev, linux-kernel
In-Reply-To: <20161111044408.1547.92737.stgit@john-Precision-Tower-5810>
On Thu, Nov 10, 2016 at 08:44:08PM -0800, John Fastabend wrote:
>
> ---
> include/linux/ptr_ring_ll.h | 136 +++++++++++++++++++++++++++++++++++++++++++
> include/linux/skb_array.h | 25 ++++++++
> 2 files changed, 161 insertions(+)
> create mode 100644 include/linux/ptr_ring_ll.h
>
> diff --git a/include/linux/ptr_ring_ll.h b/include/linux/ptr_ring_ll.h
> new file mode 100644
> index 0000000..bcb11f3
> --- /dev/null
> +++ b/include/linux/ptr_ring_ll.h
> @@ -0,0 +1,136 @@
> +/*
> + * Definitions for the 'struct ptr_ring_ll' datastructure.
> + *
> + * Author:
> + * John Fastabend <john.r.fastabend@intel.com>
> + *
> + * Copyright (C) 2016 Intel Corp.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + *
> + * This is a limited-size FIFO maintaining pointers in FIFO order, with
> + * one CPU producing entries and another consuming entries from a FIFO.
> + * extended from ptr_ring_ll to use cmpxchg over spin lock.
So when is each one (ptr-ring/ptr-ring-ll) a win? _ll suffix seems to
imply this gives a better latency, OTOH for a ping/pong I suspect
ptr-ring would be better as it avoids index cache line bounces.
> + */
> +
> +#ifndef _LINUX_PTR_RING_LL_H
> +#define _LINUX_PTR_RING_LL_H 1
> +
> +#ifdef __KERNEL__
> +#include <linux/spinlock.h>
> +#include <linux/cache.h>
> +#include <linux/types.h>
> +#include <linux/compiler.h>
> +#include <linux/cache.h>
> +#include <linux/slab.h>
> +#include <asm/errno.h>
> +#endif
> +
> +struct ptr_ring_ll {
> + u32 prod_size;
> + u32 prod_mask;
> + u32 prod_head;
> + u32 prod_tail;
> + u32 cons_size;
> + u32 cons_mask;
> + u32 cons_head;
> + u32 cons_tail;
> +
> + void **queue;
> +};
> +
> +/* Note: callers invoking this in a loop must use a compiler barrier,
> + * for example cpu_relax(). Callers must hold producer_lock.
> + */
> +static inline int __ptr_ring_ll_produce(struct ptr_ring_ll *r, void *ptr)
> +{
> + u32 ret, head, tail, next, slots, mask;
> +
> + do {
> + head = READ_ONCE(r->prod_head);
> + mask = READ_ONCE(r->prod_mask);
> + tail = READ_ONCE(r->cons_tail);
> +
> + slots = mask + tail - head;
> + if (slots < 1)
> + return -ENOMEM;
> +
> + next = head + 1;
> + ret = cmpxchg(&r->prod_head, head, next);
> + } while (ret != head);
So why is this preferable to a lock?
I suspect it's nothing else than the qspinlock fairness
and polling code complexity. It's all not very useful if you
1. are just doing a couple of instructions under the lock
and
2. use a finite FIFO which is unfair anyway
How about this hack (lifted from virt_spin_lock):
static inline void quick_spin_lock(struct qspinlock *lock)
{
do {
while (atomic_read(&lock->val) != 0)
cpu_relax();
} while (atomic_cmpxchg(&lock->val, 0, _Q_LOCKED_VAL) != 0);
}
Or maybe we should even drop the atomic_read in the middle -
worth profiling and comparing:
static inline void quick_spin_lock(struct qspinlock *lock)
{
while (atomic_cmpxchg(&lock->val, 0, _Q_LOCKED_VAL) != 0)
cpu_relax();
}
Then, use quick_spin_lock instead of spin_lock everywhere in
ptr_ring - will that make it more efficient?
> +
> + r->queue[head & mask] = ptr;
> + smp_wmb();
> +
> + while (r->prod_tail != head)
> + cpu_relax();
> +
> + r->prod_tail = next;
> + return 0;
> +}
> +
> +static inline void *__ptr_ring_ll_consume(struct ptr_ring_ll *r)
> +{
> + u32 ret, head, tail, next, slots, mask;
> + void *ptr;
> +
> + do {
> + head = READ_ONCE(r->cons_head);
> + mask = READ_ONCE(r->cons_mask);
> + tail = READ_ONCE(r->prod_tail);
> +
> + slots = tail - head;
> + if (slots < 1)
> + return ERR_PTR(-ENOMEM);
> +
> + next = head + 1;
> + ret = cmpxchg(&r->cons_head, head, next);
> + } while (ret != head);
> +
> + ptr = r->queue[head & mask];
> + smp_rmb();
> +
> + while (r->cons_tail != head)
> + cpu_relax();
> +
> + r->cons_tail = next;
> + return ptr;
> +}
> +
> +static inline void **__ptr_ring_ll_init_queue_alloc(int size, gfp_t gfp)
> +{
> + return kzalloc(ALIGN(size * sizeof(void *), SMP_CACHE_BYTES), gfp);
> +}
> +
> +static inline int ptr_ring_ll_init(struct ptr_ring_ll *r, int size, gfp_t gfp)
> +{
> + r->queue = __ptr_ring_init_queue_alloc(size, gfp);
> + if (!r->queue)
> + return -ENOMEM;
> +
> + r->prod_size = r->cons_size = size;
> + r->prod_mask = r->cons_mask = size - 1;
> + r->prod_tail = r->prod_head = 0;
> + r->cons_tail = r->prod_tail = 0;
> +
> + return 0;
> +}
> +
> +static inline void ptr_ring_ll_cleanup(struct ptr_ring_ll *r, void (*destroy)(void *))
> +{
> + if (destroy) {
> + void *ptr;
> +
> + ptr = __ptr_ring_ll_consume(r);
> + while (!IS_ERR_OR_NULL(ptr)) {
> + destroy(ptr);
> + ptr = __ptr_ring_ll_consume(r);
> + }
> + }
> + kfree(r->queue);
> +}
> +
> +#endif /* _LINUX_PTR_RING_LL_H */
> diff --git a/include/linux/skb_array.h b/include/linux/skb_array.h
> index f4dfade..9b43dfd 100644
> --- a/include/linux/skb_array.h
> +++ b/include/linux/skb_array.h
> @@ -22,6 +22,7 @@
>
> #ifdef __KERNEL__
> #include <linux/ptr_ring.h>
> +#include <linux/ptr_ring_ll.h>
> #include <linux/skbuff.h>
> #include <linux/if_vlan.h>
> #endif
> @@ -30,6 +31,10 @@ struct skb_array {
> struct ptr_ring ring;
> };
>
> +struct skb_array_ll {
> + struct ptr_ring_ll ring;
> +};
> +
> /* Might be slightly faster than skb_array_full below, but callers invoking
> * this in a loop must use a compiler barrier, for example cpu_relax().
> */
> @@ -43,6 +48,11 @@ static inline bool skb_array_full(struct skb_array *a)
> return ptr_ring_full(&a->ring);
> }
>
> +static inline int skb_array_ll_produce(struct skb_array_ll *a, struct sk_buff *skb)
> +{
> + return __ptr_ring_ll_produce(&a->ring, skb);
> +}
> +
> static inline int skb_array_produce(struct skb_array *a, struct sk_buff *skb)
> {
> return ptr_ring_produce(&a->ring, skb);
> @@ -92,6 +102,11 @@ static inline bool skb_array_empty_any(struct skb_array *a)
> return ptr_ring_empty_any(&a->ring);
> }
>
> +static inline struct sk_buff *skb_array_ll_consume(struct skb_array_ll *a)
> +{
> + return __ptr_ring_ll_consume(&a->ring);
> +}
> +
> static inline struct sk_buff *skb_array_consume(struct skb_array *a)
> {
> return ptr_ring_consume(&a->ring);
> @@ -146,6 +161,11 @@ static inline int skb_array_peek_len_any(struct skb_array *a)
> return PTR_RING_PEEK_CALL_ANY(&a->ring, __skb_array_len_with_tag);
> }
>
> +static inline int skb_array_ll_init(struct skb_array_ll *a, int size, gfp_t gfp)
> +{
> + return ptr_ring_ll_init(&a->ring, size, gfp);
> +}
> +
> static inline int skb_array_init(struct skb_array *a, int size, gfp_t gfp)
> {
> return ptr_ring_init(&a->ring, size, gfp);
> @@ -170,6 +190,11 @@ static inline int skb_array_resize_multiple(struct skb_array **rings,
> __skb_array_destroy_skb);
> }
>
> +static inline void skb_array_ll_cleanup(struct skb_array_ll *a)
> +{
> + ptr_ring_ll_cleanup(&a->ring, __skb_array_destroy_skb);
> +}
> +
> static inline void skb_array_cleanup(struct skb_array *a)
> {
> ptr_ring_cleanup(&a->ring, __skb_array_destroy_skb);
^ permalink raw reply
* Re: [PATCH 1/2] libselinux, libsemanage: fall back to gcc in exception.sh
From: Nicolas Iooss @ 2016-11-14 23:00 UTC (permalink / raw)
To: William Roberts; +Cc: selinux@tycho.nsa.gov
In-Reply-To: <CAFftDdrFwOHGGSwzCK1UZAJZF8-h2dw9aLmLBQtR8EQ=6fcsqA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3786 bytes --]
The SWIG wrapper already includes the header files using #include (look at
the beginning of libselinux/src/selinuxswig_python.i [1] for example). The
script exception.h reads the header files (through gcc -aux-info) to
generate some SWIG code for almost every interface returning an integer
(this code converts a negative return value to the raising of a
Python OSError exception).
In SWIG documentation [2] I have not found a way to automatically apply a
%exception block to all functions matched by the pattern "it returns an
integer". As you seem to believe I missed something, could you please
explain how you would proceed here?
Nicolas
[1]
https://github.com/SELinuxProject/selinux/blob/master/libselinux/src/selinuxswig_python.i#L11
[2] http://www.swig.org/Doc3.0/SWIGDocumentation.html
On Mon, Nov 14, 2016 at 11:15 PM, William Roberts <bill.c.roberts@gmail.com>
wrote:
> For a more long term solution, why not just give swig a header file
> (you can ifdef on SWIG for anything to omit), or write the interface
> file by hand. I ended up using a hybrid approach for one my projects
> (the build system is a mess):
>
> https://bitbucket.org/miniat/0x1-miniat/src/f84cb76ab0fbe645ee9c48d30221b2
> 9283745778/vm/src/miniat_python.i?at=master&fileviewer=file-view-default
>
>
> On Mon, Nov 14, 2016 at 1:57 PM, Nicolas Iooss <nicolas.iooss@m4x.org>
> wrote:
> > clang does not support -aux-info option. When exception.sh is run with
> > CC=clang, use gcc to build selinuxswig_python_exception.i and
> > semanageswig_python_exception.i.
> >
> > This does not solve the issue of building libselinux and libsemanage
> > Python wrappers on a system without gcc. However parsing the result of
> > "gcc -aux-info" is easier than parsing the header files so stay with
> > this command at least for now.
> >
> > Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
> > ---
> > libselinux/src/exception.sh | 6 +++++-
> > libsemanage/src/exception.sh | 6 +++++-
> > 2 files changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/libselinux/src/exception.sh b/libselinux/src/exception.sh
> > index a58bf3f45778..a3ff83235ced 100755
> > --- a/libselinux/src/exception.sh
> > +++ b/libselinux/src/exception.sh
> > @@ -15,6 +15,10 @@ echo "
> > ;;
> > esac
> > }
> > -${CC:-gcc} -x c -c -I../include - -aux-info temp.aux <
> ../include/selinux/selinux.h
> > +if ! ${CC:-gcc} -x c -c -I../include - -aux-info temp.aux <
> ../include/selinux/selinux.h
> > +then
> > + # clang does not support -aux-info so fall back to gcc
> > + gcc -x c -c -I../include - -aux-info temp.aux <
> ../include/selinux/selinux.h
> > +fi
> > for i in `awk '/<stdin>.*extern int/ { print $6 }' temp.aux`; do except
> $i ; done
> > rm -f -- temp.aux -.o
> > diff --git a/libsemanage/src/exception.sh b/libsemanage/src/exception.sh
> > index d18959cbe85d..a4095f4f8ba6 100644
> > --- a/libsemanage/src/exception.sh
> > +++ b/libsemanage/src/exception.sh
> > @@ -9,6 +9,10 @@ echo "
> > }
> > "
> > }
> > -${CC:-gcc} -x c -c -I../include - -aux-info temp.aux <
> ../include/semanage/semanage.h
> > +if ! ${CC:-gcc} -x c -c -I../include - -aux-info temp.aux <
> ../include/semanage/semanage.h
> > +then
> > + # clang does not support -aux-info so fall back to gcc
> > + gcc -x c -c -I../include - -aux-info temp.aux <
> ../include/semanage/semanage.h
> > +fi
> > for i in `awk '/extern int/ { print $6 }' temp.aux`; do except $i ; done
> > rm -f -- temp.aux -.o
> > --
> > 2.10.2
> >
> > _______________________________________________
> > Selinux mailing list
> > Selinux@tycho.nsa.gov
> > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> > To get help, send an email containing "help" to
> Selinux-request@tycho.nsa.gov.
>
>
>
> --
> Respectfully,
>
> William C Roberts
>
[-- Attachment #2: Type: text/html, Size: 5440 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] usb: dwc2: add amcc,dwc-otg support
From: John Youn @ 2016-11-14 23:00 UTC (permalink / raw)
To: Christian Lamparter, John Youn
Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-usb@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
Mark Rutland, Rob Herring, Greg Kroah-Hartman, Felipe Balbi
In-Reply-To: <3741942.Du5DzKuQeQ@debian64>
On 11/11/2016 3:12 PM, Christian Lamparter wrote:
> On Friday, November 11, 2016 2:20:42 PM CET John Youn wrote:
>> On 11/11/2016 2:05 PM, Christian Lamparter wrote:
>>> On Friday, November 11, 2016 1:22:16 PM CET John Youn wrote:
>>>> On 11/11/2016 12:59 PM, Christian Lamparter wrote:
>>>>> This patch adds support for the "amcc,usb-otg" device
>>>>> which is found in the PowerPC Canyonlands' dts.
>>>>>
>>>>> The device definition was added by:
>>>>> commit c89b3458d8cc ("powerpc/44x: Add USB DWC DTS entry to Canyonlands board")'
>>>>> but without any driver support as the dwc2 driver wasn't
>>>>> available at that time.
>>>>>
>>>>> Note: The system can't use the generic "snps,dwc2" compatible
>>>>> because of the special ahbcfg configuration. The default
>>>>> GAHBCFG_HBSTLEN_INCR4 of snps,dwc2 can cause a system hang
>>>>> when the USB and SATA is used concurrently.
>>>>
>>>> I don't want to add any more of these param structures to the driver
>>>> unless really necessary. We're trying to remove usage of them in favor
>>>> of using auto-detected defaults and device properties to override
>>>> them.
>>> Ok, thanks. I think that would work. I've attached an updated patch.
>>> Can it be applied/queued now? Or do you want me to resent it later?
>>>
>>>> The AHB Burst is actually one of the ones we were going to do next
>>>> because our platform also doesn't work well with INCR4. In fact I'm
>>>> thinking of making the default INCR.
>>> Is that actually possible to change the default still? This would
>>> require to re-evaluate all existing archs/platforms that use
>>> "snps,dwc2" for INCR16 compatibility.
>>
>> INCR, not INCR16, but you're right, so we may not change it even
>> though though INCR is usually the right choice over INCR4.
> What about making a device-tree property?
Yes, that's what I meant. I'll send a change for this shortly.
>
> Recommended properties:
> - g-ahb-bursts : specifies the ahb bursts length, should be one of
> "single", "INCRx", "INCR4", "INCR8", or "INCR16". If not specified
> the safer but inefficient "INCR4" is used. The optimal setting is
> "INCRx".
>
> Would this work? If so, I can make a patch over the weekend.
>> Anyways, with the binding, can't you just set the compatible string to
>> snps,dwc2?
>
> Ah, let me explain. I had a discussion with Mark Rutland and Rob Herring
> a while back about device-tree bindings.
>
> They made it very clear to me, that they don't want any generic "catch all
> compatible" strings:
>
> "Bindings should be for hardware (either specific device models, or for
> classes), and not for Linux drivers. The latter is subject to arbitrary
> changes while the former is not, as old hardware continues to exist and
> does not change while drivers get completely reworked." [0]
>
> Furthermore, this is an existing binding in kernel's canyonlands.dts [1]
> and this binding can't be easily changed. Rob Herring explained this in
> the context of the "basic-mmio-gpio" patch [2] when I was editing the dts
> to make them work with the changes I made:
>
> "You can't remove the old drivers as they are needed to work with
> old dtbs, so there is no gain.
>
> You would need to match on existing compatibles such as
> moxa,moxart-gpio and provide a match data struct that has all the info
> you are adding here (e.g. data register offset). Then additionally you
> could add "basic-mmio-gpio" (I would drop "basic" part) and the
> additional data associated with it. But it has to be new properties,
> not changing properties. Changing the reg values doesn't work."
>
> So, for this to work with the existing canyonlands.dts, I need to have
> the "amcc,dwc-otg" compatible string.
Ok, if that's the case. But still a bit confused as to what driver was
working with it before since the binding was not defined for dwc2.
>
> Of course, it would be great to hear from Rob Herring and/or Mark Rutland
> about this case.
>
> Regards,
> Christian
>
> [0] <https://patchwork.kernel.org/patch/8976221/>
> [1] <http://lxr.free-electrons.com/source/arch/powerpc/boot/dts/canyonlands.dts#L181>
> [2] <http://www.spinics.net/lists/devicetree/msg124538.html>
>
>
>>>
>>> From what I can tell based would be:
>>> bcm11351, bcm21664, bcm23550, exynos3250, stm32f429, rk3xxx,
>>> stratix10, meson-gxbb, rt3050 and some Altera FPGAs.
>>>
>>>> If that's all you need then a devicetree binding should be enough
>>>> right?
>>> Yes. The device is working fine so far.
>>>
>>> Regards,
>>> Christian
>>>
>>> ---
>>> From 70dd4be016b89655a56bc8260f04683b50f07644 Mon Sep 17 00:00:00 2001
>>> From: Christian Lamparter <chunkeey@gmail.com>
>>> Date: Sun, 6 Nov 2016 00:39:24 +0100
>>> Subject: [PATCH] usb: dwc2: add amcc,dwc-otg support
>>>
>>> This patch adds support for the "amcc,usb-otg" device
>>> which is found in the PowerPC Canyonlands' dts.
>>>
>>> The device definition was added by:
>>> commit c89b3458d8cc ("powerpc/44x: Add USB DWC DTS entry to Canyonlands board")'
>>> but without any driver support as the dwc2 driver wasn't
>>> available at that time.
>>>
>>> Note: The system can't use the generic "snps,dwc2" compatible
>>> because of the special ahbcfg configuration. The default
>>> GAHBCFG_HBSTLEN_INCR4 of snps,dwc2 can cause a system hang
>>> when the USB and SATA is used concurrently.
>>>
>>> Cc: Felipe Balbi <felipe.balbi@linux.intel.com>
>>> Cc: John Youn <johnyoun@synopsys.com>
>>> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
>>> ---
>>> v1->v2:
>>> - moved definitons to params.c
>>> - removed dma_enable / host_dma parameter
>>> - added dma_desc_fs_enable parameter
>>> v2->v3:
>>> - removed parameters
>>>
>>> Please queue this patch until GAHBCFG_HBSTLEN_INCR16 is the default
>>> for ahbcfg.
>>> ---
>>> Documentation/devicetree/bindings/usb/dwc2.txt | 1 +
>>> drivers/usb/dwc2/params.c | 1 +
>>> 2 files changed, 2 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt
>>> index 10a2a4b..6ccfe85 100644
>>> --- a/Documentation/devicetree/bindings/usb/dwc2.txt
>>> +++ b/Documentation/devicetree/bindings/usb/dwc2.txt
>>> @@ -12,6 +12,7 @@ Required properties:
>>> - "lantiq,xrx200-usb": The DWC2 USB controller instance in Lantiq XRX SoCs;
>>> - "amlogic,meson8b-usb": The DWC2 USB controller instance in Amlogic Meson8b SoCs;
>>> - "amlogic,meson-gxbb-usb": The DWC2 USB controller instance in Amlogic S905 SoCs;
>>> + - "amcc,dwc-otg": The DWC2 USB controller instance in AMCC Canyonlands 460EX SoCs;
>>> - snps,dwc2: A generic DWC2 USB controller with default parameters.
>>> - reg : Should contain 1 register range (address and length)
>>> - interrupts : Should contain 1 interrupt
>>> diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
>>> index 64d5c66..9506ab0 100644
>>> --- a/drivers/usb/dwc2/params.c
>>> +++ b/drivers/usb/dwc2/params.c
>>> @@ -239,6 +239,7 @@ const struct of_device_id dwc2_of_match_table[] = {
>>> { .compatible = "samsung,s3c6400-hsotg", .data = NULL},
>>> { .compatible = "amlogic,meson8b-usb", .data = ¶ms_amlogic },
>>> { .compatible = "amlogic,meson-gxbb-usb", .data = ¶ms_amlogic },
>>> + { .compatible = "amcc,dwc-otg", .data = NULL },
>>> {},
>>> };
>>> MODULE_DEVICE_TABLE(of, dwc2_of_match_table);
>>>
For dwc2 part:
Acked-by: John Youn <johnyoun@synopsys.com>
Regards,
John
^ permalink raw reply
* [PATCH v2 iproute2 1/1] tc: print raw qdisc handle.
From: Roman Mashak @ 2016-11-14 22:59 UTC (permalink / raw)
To: stephen; +Cc: netdev, jhs, Roman Mashak
This is v2 patch with fixed code indentation.
Signed-off-by: Roman Mashak <mrv@mojatatu.com>
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
---
tc/tc_qdisc.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/tc/tc_qdisc.c b/tc/tc_qdisc.c
index 93c9a4c..6f60002 100644
--- a/tc/tc_qdisc.c
+++ b/tc/tc_qdisc.c
@@ -231,7 +231,15 @@ int print_qdisc(const struct sockaddr_nl *who,
if (n->nlmsg_type == RTM_DELQDISC)
fprintf(fp, "deleted ");
- fprintf(fp, "qdisc %s %x: ", rta_getattr_str(tb[TCA_KIND]), t->tcm_handle>>16);
+ if (!show_raw) {
+ fprintf(fp, "qdisc %s %x: ", rta_getattr_str(tb[TCA_KIND]),
+ t->tcm_handle >> 16);
+ } else {
+ fprintf(fp, "qdisc %s %x:[%08x] ",
+ rta_getattr_str(tb[TCA_KIND]),
+ t->tcm_handle >> 16, t->tcm_handle);
+ }
+
if (filter_ifindex == 0)
fprintf(fp, "dev %s ", ll_index_to_name(t->tcm_ifindex));
if (t->tcm_parent == TC_H_ROOT)
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] netfilter: Update ip_route_me_harder to consider L3 domain
From: Pablo Neira Ayuso @ 2016-11-14 22:59 UTC (permalink / raw)
To: David Ahern; +Cc: kaber, kadlec, netfilter-devel
In-Reply-To: <1478715880-18952-1-git-send-email-dsa@cumulusnetworks.com>
On Wed, Nov 09, 2016 at 10:24:40AM -0800, David Ahern wrote:
> ip_route_me_harder is not considering the L3 domain and sending lookups
> to the wrong table. For example consider the following output rule:
>
> iptables -I OUTPUT -p tcp --dport 12345 -j REJECT --reject-with tcp-reset
>
> using perf to analyze lookups via the fib_table_lookup tracepoint shows:
>
> vrf-test 1187 [001] 46887.295927: fib:fib_table_lookup: table 255 oif 0 iif 0 src 0.0.0.0 dst 10.100.1.254 tos 0 scope 0 flags 0
> ffffffff8143922c perf_trace_fib_table_lookup ([kernel.kallsyms])
> ffffffff81493aac fib_table_lookup ([kernel.kallsyms])
> ffffffff8148dda3 __inet_dev_addr_type ([kernel.kallsyms])
> ffffffff8148ddf6 inet_addr_type ([kernel.kallsyms])
> ffffffff8149e344 ip_route_me_harder ([kernel.kallsyms])
>
> and
>
> vrf-test 1187 [001] 46887.295933: fib:fib_table_lookup: table 255 oif 0 iif 1 src 10.100.1.254 dst 10.100.1.2 tos 0 scope 0 flags
> ffffffff8143922c perf_trace_fib_table_lookup ([kernel.kallsyms])
> ffffffff81493aac fib_table_lookup ([kernel.kallsyms])
> ffffffff814998ff fib4_rule_action ([kernel.kallsyms])
> ffffffff81437f35 fib_rules_lookup ([kernel.kallsyms])
> ffffffff81499758 __fib_lookup ([kernel.kallsyms])
> ffffffff8144f010 fib_lookup.constprop.34 ([kernel.kallsyms])
> ffffffff8144f759 __ip_route_output_key_hash ([kernel.kallsyms])
> ffffffff8144fc6a ip_route_output_flow ([kernel.kallsyms])
> ffffffff8149e39b ip_route_me_harder ([kernel.kallsyms])
>
> In both cases the lookups are directed to table 255 rather than the
> table associated with the device via the L3 domain. Update both
> lookups to pull the L3 domain from the dst currently attached to the
> skb.
Does ip6_route_me_harder need an update too?
^ permalink raw reply
* Re: [PATCH] loop: return proper error from loop_queue_rq()
From: Jens Axboe @ 2016-11-14 22:58 UTC (permalink / raw)
To: Omar Sandoval, linux-block; +Cc: kernel-team, Ming Lei
In-Reply-To: <fad6bce50526f8554f47d83d61ae334073075a6d.1479164136.git.osandov@fb.com>
On 11/14/2016 03:56 PM, Omar Sandoval wrote:
> From: Omar Sandoval <osandov@fb.com>
>
> ->queue_rq() should return one of the BLK_MQ_RQ_QUEUE_* constants, not
> an errno.
Thanks Omar, applied.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH] drm/i915: cleanup use of INSTR_CLIENT_MASK
From: Chris Wilson @ 2016-11-14 22:57 UTC (permalink / raw)
To: Matthew Auld; +Cc: intel-gfx
In-Reply-To: <1479163174-29686-1-git-send-email-matthew.auld@intel.com>
On Mon, Nov 14, 2016 at 10:39:34PM +0000, Matthew Auld wrote:
> Doing cmd_header >> 29 to extract our 3-bit client value where we know
> cmd_header is a u32 shouldn't then also require the use of a mask. So
> remove the redundant operation and get rid of INSTR_CLIENT_MASK now that
> there are no longer any users.
>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH] iscsi: fix spelling mistakes in dev_warn messages
From: Bart Van Assche @ 2016-11-14 22:24 UTC (permalink / raw)
To: Colin King, Intel SCU Linux support, Artur Paszkiewicz,
James E . J . Bottomley, Martin K . Petersen, linux-scsi
Cc: linux-kernel
In-Reply-To: <20161112164950.5605-1-colin.king@canonical.com>
On 11/12/2016 08:49 AM, Colin King wrote:
> Trivial fix to spelling mistake "suspeneded" to "suspended" in
> dev_warn messages
Reviewed-by: Bart Van Assche <bart.vanassche@sandisk.com>
^ permalink raw reply
* [PATCH] loop: return proper error from loop_queue_rq()
From: Omar Sandoval @ 2016-11-14 22:56 UTC (permalink / raw)
To: linux-block; +Cc: kernel-team, Ming Lei
From: Omar Sandoval <osandov@fb.com>
->queue_rq() should return one of the BLK_MQ_RQ_QUEUE_* constants, not
an errno.
f4aa4c7bbac6 ("block: loop: convert to per-device workqueue")
Signed-off-by: Omar Sandoval <osandov@fb.com>
---
drivers/block/loop.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index fa1b7a9..4af8187 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1646,7 +1646,7 @@ static int loop_queue_rq(struct blk_mq_hw_ctx *hctx,
blk_mq_start_request(bd->rq);
if (lo->lo_state != Lo_bound)
- return -EIO;
+ return BLK_MQ_RQ_QUEUE_ERROR;
switch (req_op(cmd->rq)) {
case REQ_OP_FLUSH:
--
2.10.2
^ permalink raw reply related
* Re: [PATCH 2/2] usb: dwc2: fixes host_dma logic
From: John Youn @ 2016-11-14 22:53 UTC (permalink / raw)
To: Christian Lamparter, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-usb@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
Cc: John Youn, Mark Rutland, Rob Herring, Greg Kroah-Hartman,
Felipe Balbi
In-Reply-To: <4043f817106c8dffdc9a3f411d965465168b263d.1478897792.git.chunkeey@gmail.com>
On 11/11/2016 12:59 PM, Christian Lamparter wrote:
> This patch moves the the host_dma initialization
> before dwc2_set_param_dma_desc_enable and
> dwc2_set_param_dma_desc_fs_enable. The reason being
> that both function need it.
>
> Fixes: 1205489cee75bf39 ("usb: dwc2: Get host DMA device properties")
This should probably be omitted since it's only in Felipe's
testing/next.
Otherwise looks good.
Acked-by: John Youn <johnyoun@synopsys.com>
Regards,
John
>
> Cc: John Youn <johnyoun@synopsys.com>
> Cc: Felipe Balbi <felipe.balbi@linux.intel.com>
> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
> ---
> drivers/usb/dwc2/params.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
> index 5d822c5..222a83c 100644
> --- a/drivers/usb/dwc2/params.c
> +++ b/drivers/usb/dwc2/params.c
> @@ -1157,9 +1157,6 @@ static void dwc2_set_parameters(struct dwc2_hsotg *hsotg,
> bool dma_capable = !(hw->arch == GHWCFG2_SLAVE_ONLY_ARCH);
>
> dwc2_set_param_otg_cap(hsotg, params->otg_cap);
> - dwc2_set_param_dma_desc_enable(hsotg, params->dma_desc_enable);
> - dwc2_set_param_dma_desc_fs_enable(hsotg, params->dma_desc_fs_enable);
> -
> if ((hsotg->dr_mode == USB_DR_MODE_HOST) ||
> (hsotg->dr_mode == USB_DR_MODE_OTG)) {
> bool disable;
> @@ -1174,6 +1171,8 @@ static void dwc2_set_parameters(struct dwc2_hsotg *hsotg,
> !disable, false,
> dma_capable);
> }
> + dwc2_set_param_dma_desc_enable(hsotg, params->dma_desc_enable);
> + dwc2_set_param_dma_desc_fs_enable(hsotg, params->dma_desc_fs_enable);
>
> dwc2_set_param_host_support_fs_ls_low_power(hsotg,
> params->host_support_fs_ls_low_power);
>
^ permalink raw reply
* Re: [PATCH v2] cpufreq: conservative: Decrease frequency faster when the update deferred
From: Stratos Karafotis @ 2016-11-14 22:53 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Rafael J. Wysocki, Viresh Kumar, linux-pm@vger.kernel.org, LKML
In-Reply-To: <CAJZ5v0jBVvM0AGhiqmSz3KLZt4nAVFCdsMUKENNkqzOo9NgCRQ@mail.gmail.com>
On 15/11/2016 12:09 πμ, Rafael J. Wysocki wrote:
> On Mon, Nov 14, 2016 at 10:59 PM, Rafael J. Wysocki <rafael@kernel.org> wrote:
>> On Mon, Nov 14, 2016 at 10:46 PM, Stratos Karafotis
>> <stratosk@semaphore.gr> wrote:
>>>
>>>
>>> On 14/11/2016 10:44 μμ, Rafael J. Wysocki wrote:
>>>> On Sat, Nov 12, 2016 at 10:04 PM, Stratos Karafotis
>>>> <stratosk@semaphore.gr> wrote:
>>>>> Conservative governor changes the CPU frequency in steps.
>>>>> That means that if a CPU runs at max frequency, it will need several
>>>>> sampling periods to return to min frequency when the workload
>>>>> is finished.
>>>>>
>>>>> If the update function that calculates the load and target frequency
>>>>> is deferred, the governor might need even more time to decrease the
>>>>> frequency.
>>>>>
>>>>> This may have impact to power consumption and after all conservative
>>>>> should decrease the frequency if there is no workload at every sampling
>>>>> rate.
>>>>>
>>>>> To resolve the above issue calculate the number of sampling periods
>>>>> that the update is deferred. Considering that for each sampling period
>>>>> conservative should drop the frequency by a freq_step because the
>>>>> CPU was idle apply the proper subtraction to requested frequency.
>>>>>
>>>>> Below, the kernel trace with and without this patch. First an
>>>>> intensive workload is applied on a specific CPU. Then the workload
>>>>> is removed and the CPU goes to idle.
>>>>>
>>>>> WITHOUT
>>>>>
>>>>> <idle>-0 [007] dN.. 620.329153: cpu_idle: state=4294967295 cpu_id=7
>>>>> kworker/7:2-556 [007] .... 620.350857: cpu_frequency: state=1700000 cpu_id=7
>>>>> kworker/7:2-556 [007] .... 620.370856: cpu_frequency: state=1900000 cpu_id=7
>>>>> kworker/7:2-556 [007] .... 620.390854: cpu_frequency: state=2100000 cpu_id=7
>>>>> kworker/7:2-556 [007] .... 620.411853: cpu_frequency: state=2200000 cpu_id=7
>>>>> kworker/7:2-556 [007] .... 620.432854: cpu_frequency: state=2400000 cpu_id=7
>>>>> kworker/7:2-556 [007] .... 620.453854: cpu_frequency: state=2600000 cpu_id=7
>>>>> kworker/7:2-556 [007] .... 620.494856: cpu_frequency: state=2900000 cpu_id=7
>>>>> kworker/7:2-556 [007] .... 620.515856: cpu_frequency: state=3100000 cpu_id=7
>>>>> kworker/7:2-556 [007] .... 620.536858: cpu_frequency: state=3300000 cpu_id=7
>>>>> kworker/7:2-556 [007] .... 620.557857: cpu_frequency: state=3401000 cpu_id=7
>>>>> <idle>-0 [007] d... 669.591363: cpu_idle: state=4 cpu_id=7
>>>>> <idle>-0 [007] d... 669.591939: cpu_idle: state=4294967295 cpu_id=7
>>>>> <idle>-0 [007] d... 669.591980: cpu_idle: state=4 cpu_id=7
>>>>> <idle>-0 [007] dN.. 669.591989: cpu_idle: state=4294967295 cpu_id=7
>>>>> ...
>>>>> <idle>-0 [007] d... 670.201224: cpu_idle: state=4 cpu_id=7
>>>>> <idle>-0 [007] d... 670.221975: cpu_idle: state=4294967295 cpu_id=7
>>>>> kworker/7:2-556 [007] .... 670.222016: cpu_frequency: state=3300000 cpu_id=7
>>>>> <idle>-0 [007] d... 670.222026: cpu_idle: state=4 cpu_id=7
>>>>> <idle>-0 [007] d... 670.234964: cpu_idle: state=4294967295 cpu_id=7
>>>>> ...
>>>>> <idle>-0 [007] d... 670.801251: cpu_idle: state=4 cpu_id=7
>>>>> <idle>-0 [007] d... 671.236046: cpu_idle: state=4294967295 cpu_id=7
>>>>> kworker/7:2-556 [007] .... 671.236073: cpu_frequency: state=3100000 cpu_id=7
>>>>> <idle>-0 [007] d... 671.236112: cpu_idle: state=4 cpu_id=7
>>>>> <idle>-0 [007] d... 671.393437: cpu_idle: state=4294967295 cpu_id=7
>>>>> ...
>>>>> <idle>-0 [007] d... 671.401277: cpu_idle: state=4 cpu_id=7
>>>>> <idle>-0 [007] d... 671.404083: cpu_idle: state=4294967295 cpu_id=7
>>>>> kworker/7:2-556 [007] .... 671.404111: cpu_frequency: state=2900000 cpu_id=7
>>>>> <idle>-0 [007] d... 671.404125: cpu_idle: state=4 cpu_id=7
>>>>> <idle>-0 [007] d... 671.404974: cpu_idle: state=4294967295 cpu_id=7
>>>>> ...
>>>>> <idle>-0 [007] d... 671.501180: cpu_idle: state=4 cpu_id=7
>>>>> <idle>-0 [007] d... 671.995414: cpu_idle: state=4294967295 cpu_id=7
>>>>> kworker/7:2-556 [007] .... 671.995459: cpu_frequency: state=2800000 cpu_id=7
>>>>> <idle>-0 [007] d... 671.995469: cpu_idle: state=4 cpu_id=7
>>>>> <idle>-0 [007] d... 671.996287: cpu_idle: state=4294967295 cpu_id=7
>>>>> ...
>>>>> <idle>-0 [007] d... 672.001305: cpu_idle: state=4 cpu_id=7
>>>>> <idle>-0 [007] d... 672.078374: cpu_idle: state=4294967295 cpu_id=7
>>>>> kworker/7:2-556 [007] .... 672.078410: cpu_frequency: state=2600000 cpu_id=7
>>>>> <idle>-0 [007] d... 672.078419: cpu_idle: state=4 cpu_id=7
>>>>> <idle>-0 [007] d... 672.158020: cpu_idle: state=4294967295 cpu_id=7
>>>>> kworker/7:2-556 [007] .... 672.158040: cpu_frequency: state=2400000 cpu_id=7
>>>>> <idle>-0 [007] d... 672.158044: cpu_idle: state=4 cpu_id=7
>>>>> <idle>-0 [007] d... 672.160038: cpu_idle: state=4294967295 cpu_id=7
>>>>> ...
>>>>> <idle>-0 [007] d... 672.234557: cpu_idle: state=4 cpu_id=7
>>>>> <idle>-0 [007] d... 672.237121: cpu_idle: state=4294967295 cpu_id=7
>>>>> kworker/7:2-556 [007] .... 672.237174: cpu_frequency: state=2100000 cpu_id=7
>>>>> <idle>-0 [007] d... 672.237186: cpu_idle: state=4 cpu_id=7
>>>>> <idle>-0 [007] d... 672.237778: cpu_idle: state=4294967295 cpu_id=7
>>>>> ...
>>>>> <idle>-0 [007] d... 672.267902: cpu_idle: state=4 cpu_id=7
>>>>> <idle>-0 [007] d... 672.269860: cpu_idle: state=4294967295 cpu_id=7
>>>>> kworker/7:2-556 [007] .... 672.269906: cpu_frequency: state=1900000 cpu_id=7
>>>>> <idle>-0 [007] d... 672.269914: cpu_idle: state=4 cpu_id=7
>>>>> <idle>-0 [007] d... 672.271902: cpu_idle: state=4294967295 cpu_id=7
>>>>> ...
>>>>> <idle>-0 [007] d... 672.751342: cpu_idle: state=4 cpu_id=7
>>>>> <idle>-0 [007] d... 672.823056: cpu_idle: state=4294967295 cpu_id=7
>>>>> kworker/7:2-556 [007] .... 672.823095: cpu_frequency: state=1600000 cpu_id=7
>>>>>
>>>>> WITH
>>>>>
>>>>> <idle>-0 [007] dN.. 4380.928009: cpu_idle: state=4294967295 cpu_id=7
>>>>> kworker/7:2-399 [007] .... 4380.949767: cpu_frequency: state=2000000 cpu_id=7
>>>>> kworker/7:2-399 [007] .... 4380.969765: cpu_frequency: state=2200000 cpu_id=7
>>>>> kworker/7:2-399 [007] .... 4381.009766: cpu_frequency: state=2500000 cpu_id=7
>>>>> kworker/7:2-399 [007] .... 4381.029767: cpu_frequency: state=2600000 cpu_id=7
>>>>> kworker/7:2-399 [007] .... 4381.049769: cpu_frequency: state=2800000 cpu_id=7
>>>>> kworker/7:2-399 [007] .... 4381.069769: cpu_frequency: state=3000000 cpu_id=7
>>>>> kworker/7:2-399 [007] .... 4381.089771: cpu_frequency: state=3100000 cpu_id=7
>>>>> kworker/7:2-399 [007] .... 4381.109772: cpu_frequency: state=3400000 cpu_id=7
>>>>> kworker/7:2-399 [007] .... 4381.129773: cpu_frequency: state=3401000 cpu_id=7
>>>>> <idle>-0 [007] d... 4428.226159: cpu_idle: state=1 cpu_id=7
>>>>> <idle>-0 [007] d... 4428.226176: cpu_idle: state=4294967295 cpu_id=7
>>>>> <idle>-0 [007] d... 4428.226181: cpu_idle: state=4 cpu_id=7
>>>>> <idle>-0 [007] d... 4428.227177: cpu_idle: state=4294967295 cpu_id=7
>>>>> ...
>>>>> <idle>-0 [007] d... 4428.551640: cpu_idle: state=4 cpu_id=7
>>>>> <idle>-0 [007] d... 4428.649239: cpu_idle: state=4294967295 cpu_id=7
>>>>> kworker/7:2-399 [007] .... 4428.649268: cpu_frequency: state=2800000 cpu_id=7
>>>>> <idle>-0 [007] d... 4428.649278: cpu_idle: state=4 cpu_id=7
>>>>> <idle>-0 [007] d... 4428.689856: cpu_idle: state=4294967295 cpu_id=7
>>>>> ...
>>>>> <idle>-0 [007] d... 4428.799542: cpu_idle: state=4 cpu_id=7
>>>>> <idle>-0 [007] d... 4428.801683: cpu_idle: state=4294967295 cpu_id=7
>>>>> kworker/7:2-399 [007] .... 4428.801748: cpu_frequency: state=1700000 cpu_id=7
>>>>> <idle>-0 [007] d... 4428.801761: cpu_idle: state=4 cpu_id=7
>>>>> <idle>-0 [007] d... 4428.806545: cpu_idle: state=4294967295 cpu_id=7
>>>>> ...
>>>>> <idle>-0 [007] d... 4429.051880: cpu_idle: state=4 cpu_id=7
>>>>> <idle>-0 [007] d... 4429.086240: cpu_idle: state=4294967295 cpu_id=7
>>>>> kworker/7:2-399 [007] .... 4429.086293: cpu_frequency: state=1600000 cpu_id=7
>>>>>
>>>>> Without the patch the CPU dropped to min frequency after 3.2s
>>>>> With the patch applied the CPU dropped to min frequency after 0.86s
>>>>>
>>>>> Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
>>>>> ---
>>>>> v1 -> v2
>>>>> - Use correct terminology in change log
>>>>> - Change the member variable name from 'deferred_periods' to 'idle_periods'
>>>>> - Fix format issue
>>>>>
>>>>> drivers/cpufreq/cpufreq_conservative.c | 14 +++++++++++++-
>>>>> drivers/cpufreq/cpufreq_governor.c | 18 +++++++++++++-----
>>>>> drivers/cpufreq/cpufreq_governor.h | 1 +
>>>>> 3 files changed, 27 insertions(+), 6 deletions(-)
>>>>>
>>>>> diff --git a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/cpufreq_conservative.c
>>>>> index fa5ece3..d787772 100644
>>>>> --- a/drivers/cpufreq/cpufreq_conservative.c
>>>>> +++ b/drivers/cpufreq/cpufreq_conservative.c
>>>>> @@ -73,7 +73,19 @@ static unsigned int cs_dbs_update(struct cpufreq_policy *policy)
>>>>> */
>>>>> if (cs_tuners->freq_step == 0)
>>>>> goto out;
>>>>> -
>>>>> + /*
>>>>> + * Decrease requested_freq for each idle period that we didn't
>>>>> + * update the frequency
>>>>> + */
>>>>> + if (policy_dbs->idle_periods < UINT_MAX) {
>>>>> + unsigned int freq_target = policy_dbs->idle_periods *
>>>>> + get_freq_target(cs_tuners, policy);
>>>>> + if (requested_freq > freq_target)
>>>>> + requested_freq -= freq_target;
>>>>> + else
>>>>> + requested_freq = policy->min;
>>>>> + policy_dbs->idle_periods = UINT_MAX;
>>>>> + }
>>>>> /*
>>>>> * If requested_freq is out of range, it is likely that the limits
>>>>> * changed in the meantime, so fall back to current frequency in that
>>>>> diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
>>>>> index 3729474..1bc7137 100644
>>>>> --- a/drivers/cpufreq/cpufreq_governor.c
>>>>> +++ b/drivers/cpufreq/cpufreq_governor.c
>>>>> @@ -117,7 +117,7 @@ unsigned int dbs_update(struct cpufreq_policy *policy)
>>>>> struct policy_dbs_info *policy_dbs = policy->governor_data;
>>>>> struct dbs_data *dbs_data = policy_dbs->dbs_data;
>>>>> unsigned int ignore_nice = dbs_data->ignore_nice_load;
>>>>> - unsigned int max_load = 0;
>>>>> + unsigned int max_load = 0, idle_periods = UINT_MAX;
>>>>> unsigned int sampling_rate, io_busy, j;
>>>>>
>>>>> /*
>>>>> @@ -163,8 +163,12 @@ unsigned int dbs_update(struct cpufreq_policy *policy)
>>>>> * calls, so the previous load value can be used then.
>>>>> */
>>>>> load = j_cdbs->prev_load;
>>>>> - } else if (unlikely(time_elapsed > 2 * sampling_rate &&
>>>>> - j_cdbs->prev_load)) {
>>>>> + } else if (unlikely(time_elapsed > 2 * sampling_rate)) {
>>>>> + unsigned int periods = time_elapsed / sampling_rate;
>>>>> +
>>>>> + if (periods < idle_periods)
>>>>> + idle_periods = periods;
>>>>> +
>>>>> /*
>>>>> * If the CPU had gone completely idle and a task has
>>>>> * just woken up on this CPU now, it would be unfair to
>>>>> @@ -189,8 +193,10 @@ unsigned int dbs_update(struct cpufreq_policy *policy)
>>>>> * 'time_elapsed' (as compared to the sampling rate)
>>>>> * indicates this scenario.
>>>>> */
>>>>> - load = j_cdbs->prev_load;
>>>>> - j_cdbs->prev_load = 0;
>>>>> + if (j_cdbs->prev_load) {
>>>>> + load = j_cdbs->prev_load;
>>>>> + j_cdbs->prev_load = 0;
>>>>> + }
>>>>> } else {
>>>>> if (time_elapsed >= idle_time) {
>>>>> load = 100 * (time_elapsed - idle_time) / time_elapsed;
>>>>> @@ -218,6 +224,8 @@ unsigned int dbs_update(struct cpufreq_policy *policy)
>>>>> if (load > max_load)
>>>>> max_load = load;
>>>>> }
>>>>> + policy_dbs->idle_periods = idle_periods;
>>>>> +
>>>>> return max_load;
>>>>> }
>>>>> EXPORT_SYMBOL_GPL(dbs_update);
>>>>
>>>> I have a murky suspicion that the changes in dbs_update() are going to
>>>> break something. I need to recall what it was, though.
>>>
>>> The only change in dbs_update() is the calculation of 'idle_periods'.
>>> If I don't miss something I left current functionality untouched.
>>
>> Well, not quite. The else branch may now trigger when
>> j_cdbs->prev_load is zero too which it didn't do before, AFAICS.
>
> What I mean is that the "if else" never triggers when
> j_cdbs->prev_load is zero before the change, but that changes, so the
> "else" branch will not cover the "j_cdbs->prev_load equal to zero"
> case any more. I'm not sure how much that matters ATM, though.
Yes, I understood your point. You are absolutely right. The patch
introduces a bug there:
If time_elapsed > 2 * sampling_rate, it calculates the idle_periods.
Finally checks prev_load. If the prev_load equals to zero
there is no load calculation at all.
Because, as you mentioned, the "else" branch will not cover this case.
So, we would have a load value only for the first deferred update and
zero load if the update is deferred again.
> Sent too quickly, sorry.
I'm sorry for this mistake. My apologies.
I will fix the patch and resend it.
Thanks,
Stratos
^ permalink raw reply
* Re: [PATCH 2/2] usb: dwc2: fixes host_dma logic
From: John Youn @ 2016-11-14 22:53 UTC (permalink / raw)
To: Christian Lamparter,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
Cc: John Youn, Mark Rutland, Rob Herring, Greg Kroah-Hartman,
Felipe Balbi
In-Reply-To: <4043f817106c8dffdc9a3f411d965465168b263d.1478897792.git.chunkeey-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 11/11/2016 12:59 PM, Christian Lamparter wrote:
> This patch moves the the host_dma initialization
> before dwc2_set_param_dma_desc_enable and
> dwc2_set_param_dma_desc_fs_enable. The reason being
> that both function need it.
>
> Fixes: 1205489cee75bf39 ("usb: dwc2: Get host DMA device properties")
This should probably be omitted since it's only in Felipe's
testing/next.
Otherwise looks good.
Acked-by: John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
Regards,
John
>
> Cc: John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
> Cc: Felipe Balbi <felipe.balbi-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> Signed-off-by: Christian Lamparter <chunkeey-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> drivers/usb/dwc2/params.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
> index 5d822c5..222a83c 100644
> --- a/drivers/usb/dwc2/params.c
> +++ b/drivers/usb/dwc2/params.c
> @@ -1157,9 +1157,6 @@ static void dwc2_set_parameters(struct dwc2_hsotg *hsotg,
> bool dma_capable = !(hw->arch == GHWCFG2_SLAVE_ONLY_ARCH);
>
> dwc2_set_param_otg_cap(hsotg, params->otg_cap);
> - dwc2_set_param_dma_desc_enable(hsotg, params->dma_desc_enable);
> - dwc2_set_param_dma_desc_fs_enable(hsotg, params->dma_desc_fs_enable);
> -
> if ((hsotg->dr_mode == USB_DR_MODE_HOST) ||
> (hsotg->dr_mode == USB_DR_MODE_OTG)) {
> bool disable;
> @@ -1174,6 +1171,8 @@ static void dwc2_set_parameters(struct dwc2_hsotg *hsotg,
> !disable, false,
> dma_capable);
> }
> + dwc2_set_param_dma_desc_enable(hsotg, params->dma_desc_enable);
> + dwc2_set_param_dma_desc_fs_enable(hsotg, params->dma_desc_fs_enable);
>
> dwc2_set_param_host_support_fs_ls_low_power(hsotg,
> params->host_support_fs_ls_low_power);
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] libsepol: fix checkpolicy dontaudit compiler bug
From: Nick Kralevich @ 2016-11-14 22:53 UTC (permalink / raw)
To: Stephen Smalley; +Cc: SELinux
In-Reply-To: <1479145685-4899-1-git-send-email-sds@tycho.nsa.gov>
On Mon, Nov 14, 2016 at 9:48 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> The combining logic for dontaudit rules was wrong, causing
> a dontaudit A B:C *; rule to be clobbered by a dontaudit A B:C p;
> rule.
>
> Reported-by: Nick Kralevich <nnk@google.com>
This looks like it fixes my problem. Thanks!
Tested-by: Nick Kralevich <nnk@google.com>
> Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
> ---
> libsepol/src/expand.c | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/libsepol/src/expand.c b/libsepol/src/expand.c
> index 004a029..d7adbf8 100644
> --- a/libsepol/src/expand.c
> +++ b/libsepol/src/expand.c
> @@ -1604,7 +1604,8 @@ static int expand_range_trans(expand_state_t * state,
> static avtab_ptr_t find_avtab_node(sepol_handle_t * handle,
> avtab_t * avtab, avtab_key_t * key,
> cond_av_list_t ** cond,
> - av_extended_perms_t *xperms)
> + av_extended_perms_t *xperms,
> + char *alloced)
> {
> avtab_ptr_t node;
> avtab_datum_t avdatum;
> @@ -1658,6 +1659,11 @@ static avtab_ptr_t find_avtab_node(sepol_handle_t * handle,
> nl->next = *cond;
> *cond = nl;
> }
> + if (alloced)
> + *alloced = 1;
> + } else {
> + if (alloced)
> + *alloced = 0;
> }
>
> return node;
> @@ -1750,7 +1756,7 @@ static int expand_terule_helper(sepol_handle_t * handle,
> return EXPAND_RULE_CONFLICT;
> }
>
> - node = find_avtab_node(handle, avtab, &avkey, cond, NULL);
> + node = find_avtab_node(handle, avtab, &avkey, cond, NULL, NULL);
> if (!node)
> return -1;
> if (enabled) {
> @@ -1790,6 +1796,7 @@ static int expand_avrule_helper(sepol_handle_t * handle,
> class_perm_node_t *cur;
> uint32_t spec = 0;
> unsigned int i;
> + char alloced;
>
> if (specified & AVRULE_ALLOWED) {
> spec = AVTAB_ALLOWED;
> @@ -1824,7 +1831,8 @@ static int expand_avrule_helper(sepol_handle_t * handle,
> avkey.target_class = cur->tclass;
> avkey.specified = spec;
>
> - node = find_avtab_node(handle, avtab, &avkey, cond, extended_perms);
> + node = find_avtab_node(handle, avtab, &avkey, cond,
> + extended_perms, &alloced);
> if (!node)
> return EXPAND_RULE_ERROR;
> if (enabled) {
> @@ -1850,7 +1858,7 @@ static int expand_avrule_helper(sepol_handle_t * handle,
> */
> avdatump->data &= cur->data;
> } else if (specified & AVRULE_DONTAUDIT) {
> - if (avdatump->data)
> + if (!alloced)
> avdatump->data &= ~cur->data;
> else
> avdatump->data = ~cur->data;
> --
> 2.7.4
>
--
Nick Kralevich | Android Security | nnk@google.com | 650.214.4037
^ permalink raw reply
* [PATCH] python3-mako: upgrade to 1.0.6
From: Edwin Plauchu @ 2016-11-14 22:52 UTC (permalink / raw)
To: openembedded-core; +Cc: Edwin Plauchu
From: Edwin Plauchu <edwin.plauchu.camacho@intel.com>
Signed-off-by: Edwin Plauchu <edwin.plauchu.camacho@intel.com>
---
meta/recipes-devtools/python/python-mako.inc | 4 ++--
.../python/{python3-mako_1.0.4.bb => python3-mako_1.0.6.bb} | 0
2 files changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-devtools/python/{python3-mako_1.0.4.bb => python3-mako_1.0.6.bb} (100%)
diff --git a/meta/recipes-devtools/python/python-mako.inc b/meta/recipes-devtools/python/python-mako.inc
index 85ec217..10364db 100644
--- a/meta/recipes-devtools/python/python-mako.inc
+++ b/meta/recipes-devtools/python/python-mako.inc
@@ -5,8 +5,8 @@ LIC_FILES_CHKSUM = "file://LICENSE;md5=1bb21fa2d2f7a534c884b990430a6863"
SRC_URI = "https://files.pythonhosted.org/packages/source/M/Mako/Mako-${PV}.tar.gz"
-SRC_URI[md5sum] = "c5fc31a323dd4990683d2f2da02d4e20"
-SRC_URI[sha256sum] = "fed99dbe4d0ddb27a33ee4910d8708aca9ef1fe854e668387a9ab9a90cbf9059"
+SRC_URI[md5sum] = "a28e22a339080316b2acc352b9ee631c"
+SRC_URI[sha256sum] = "48559ebd872a8e77f92005884b3d88ffae552812cdf17db6768e5c3be5ebbe0d"
UPSTREAM_CHECK_URI = "https://pypi.python.org/pypi/mako/"
UPSTREAM_CHECK_REGEX = "/Mako/(?P<pver>(\d+[\.\-_]*)+)"
diff --git a/meta/recipes-devtools/python/python3-mako_1.0.4.bb b/meta/recipes-devtools/python/python3-mako_1.0.6.bb
similarity index 100%
rename from meta/recipes-devtools/python/python3-mako_1.0.4.bb
rename to meta/recipes-devtools/python/python3-mako_1.0.6.bb
--
2.9.3
^ permalink raw reply related
* Re: [RESEND PATCH 1/2] PCI: rockchip: cleanup bit definition for PCIE_RC_CONFIG_LCS
From: Bjorn Helgaas @ 2016-11-14 22:50 UTC (permalink / raw)
To: Shawn Lin
Cc: Bjorn Helgaas, Rob Herring, linux-pci, linux-rockchip, Wenrui Li,
Brian Norris, Jeffy Chen, devicetree
In-Reply-To: <1479096666-112668-1-git-send-email-shawn.lin@rock-chips.com>
On Mon, Nov 14, 2016 at 12:11:05PM +0800, Shawn Lin wrote:
> PCIE_RC_CONFIG_LCS contains control and status bits specific
> to the PCIe link. The layout for this register looks the same
> as the existed PCI_EXP_LNKCTL and PCI_EXP_LNKSTA. So let's
> reuse them.
>
> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
I applied both to pci/host-rockchip, thanks!
> ---
>
> drivers/pci/host/pcie-rockchip.c | 14 ++++----------
> 1 file changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
> index 7f238af..1dba698 100644
> --- a/drivers/pci/host/pcie-rockchip.c
> +++ b/drivers/pci/host/pcie-rockchip.c
> @@ -141,12 +141,6 @@
> #define PCIE_RC_CONFIG_DCR_CSPL_LIMIT 0xff
> #define PCIE_RC_CONFIG_DCR_CPLS_SHIFT 26
> #define PCIE_RC_CONFIG_LCS (PCIE_RC_CONFIG_BASE + 0xd0)
> -#define PCIE_RC_CONFIG_LCS_RETRAIN_LINK BIT(5)
> -#define PCIE_RC_CONFIG_LCS_CCC BIT(6)
> -#define PCIE_RC_CONFIG_LCS_LBMIE BIT(10)
> -#define PCIE_RC_CONFIG_LCS_LABIE BIT(11)
> -#define PCIE_RC_CONFIG_LCS_LBMS BIT(30)
> -#define PCIE_RC_CONFIG_LCS_LAMS BIT(31)
> #define PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2 (PCIE_RC_CONFIG_BASE + 0x90c)
> #define PCIE_RC_CONFIG_THP_CAP (PCIE_RC_CONFIG_BASE + 0x274)
> #define PCIE_RC_CONFIG_THP_CAP_NEXT_MASK GENMASK(31, 20)
> @@ -229,7 +223,7 @@ static void rockchip_pcie_enable_bw_int(struct rockchip_pcie *rockchip)
> u32 status;
>
> status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
> - status |= (PCIE_RC_CONFIG_LCS_LBMIE | PCIE_RC_CONFIG_LCS_LABIE);
> + status |= (PCI_EXP_LNKCTL_LBMIE | PCI_EXP_LNKCTL_LABIE);
> rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
> }
>
> @@ -238,7 +232,7 @@ static void rockchip_pcie_clr_bw_int(struct rockchip_pcie *rockchip)
> u32 status;
>
> status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
> - status |= (PCIE_RC_CONFIG_LCS_LBMS | PCIE_RC_CONFIG_LCS_LAMS);
> + status |= (PCI_EXP_LNKSTA_LBMS | PCI_EXP_LNKSTA_LABS) << 16;
> rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
> }
>
> @@ -540,7 +534,7 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
>
> /* Set RC's clock architecture as common clock */
> status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
> - status |= PCIE_RC_CONFIG_LCS_CCC;
> + status |= PCI_EXP_LNKCTL_CCC;
> rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
>
> /* Enable Gen1 training */
> @@ -575,7 +569,7 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
> * gen1 finished.
> */
> status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
> - status |= PCIE_RC_CONFIG_LCS_RETRAIN_LINK;
> + status |= PCI_EXP_LNKCTL_RL;
> rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
>
> timeout = jiffies + msecs_to_jiffies(500);
> --
> 1.9.1
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RESEND PATCH 1/2] PCI: rockchip: cleanup bit definition for PCIE_RC_CONFIG_LCS
From: Bjorn Helgaas @ 2016-11-14 22:50 UTC (permalink / raw)
To: Shawn Lin
Cc: Bjorn Helgaas, Rob Herring, linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Wenrui Li,
Brian Norris, Jeffy Chen, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479096666-112668-1-git-send-email-shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
On Mon, Nov 14, 2016 at 12:11:05PM +0800, Shawn Lin wrote:
> PCIE_RC_CONFIG_LCS contains control and status bits specific
> to the PCIe link. The layout for this register looks the same
> as the existed PCI_EXP_LNKCTL and PCI_EXP_LNKSTA. So let's
> reuse them.
>
> Signed-off-by: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
I applied both to pci/host-rockchip, thanks!
> ---
>
> drivers/pci/host/pcie-rockchip.c | 14 ++++----------
> 1 file changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
> index 7f238af..1dba698 100644
> --- a/drivers/pci/host/pcie-rockchip.c
> +++ b/drivers/pci/host/pcie-rockchip.c
> @@ -141,12 +141,6 @@
> #define PCIE_RC_CONFIG_DCR_CSPL_LIMIT 0xff
> #define PCIE_RC_CONFIG_DCR_CPLS_SHIFT 26
> #define PCIE_RC_CONFIG_LCS (PCIE_RC_CONFIG_BASE + 0xd0)
> -#define PCIE_RC_CONFIG_LCS_RETRAIN_LINK BIT(5)
> -#define PCIE_RC_CONFIG_LCS_CCC BIT(6)
> -#define PCIE_RC_CONFIG_LCS_LBMIE BIT(10)
> -#define PCIE_RC_CONFIG_LCS_LABIE BIT(11)
> -#define PCIE_RC_CONFIG_LCS_LBMS BIT(30)
> -#define PCIE_RC_CONFIG_LCS_LAMS BIT(31)
> #define PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2 (PCIE_RC_CONFIG_BASE + 0x90c)
> #define PCIE_RC_CONFIG_THP_CAP (PCIE_RC_CONFIG_BASE + 0x274)
> #define PCIE_RC_CONFIG_THP_CAP_NEXT_MASK GENMASK(31, 20)
> @@ -229,7 +223,7 @@ static void rockchip_pcie_enable_bw_int(struct rockchip_pcie *rockchip)
> u32 status;
>
> status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
> - status |= (PCIE_RC_CONFIG_LCS_LBMIE | PCIE_RC_CONFIG_LCS_LABIE);
> + status |= (PCI_EXP_LNKCTL_LBMIE | PCI_EXP_LNKCTL_LABIE);
> rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
> }
>
> @@ -238,7 +232,7 @@ static void rockchip_pcie_clr_bw_int(struct rockchip_pcie *rockchip)
> u32 status;
>
> status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
> - status |= (PCIE_RC_CONFIG_LCS_LBMS | PCIE_RC_CONFIG_LCS_LAMS);
> + status |= (PCI_EXP_LNKSTA_LBMS | PCI_EXP_LNKSTA_LABS) << 16;
> rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
> }
>
> @@ -540,7 +534,7 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
>
> /* Set RC's clock architecture as common clock */
> status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
> - status |= PCIE_RC_CONFIG_LCS_CCC;
> + status |= PCI_EXP_LNKCTL_CCC;
> rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
>
> /* Enable Gen1 training */
> @@ -575,7 +569,7 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
> * gen1 finished.
> */
> status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
> - status |= PCIE_RC_CONFIG_LCS_RETRAIN_LINK;
> + status |= PCI_EXP_LNKCTL_RL;
> rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
>
> timeout = jiffies + msecs_to_jiffies(500);
> --
> 1.9.1
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v1 1/3] kvm: svm: Add support for additional SVM NPF error codes
From: Brijesh Singh @ 2016-11-14 22:15 UTC (permalink / raw)
To: kvm
Cc: Thomas.Lendacky, brijesh.singh, rkrcmar, joro, x86, linux-kernel,
mingo, hpa, pbonzini, tglx, bp
In-Reply-To: <147916172660.16347.15695649975899246333.stgit@brijesh-build-machine>
From: Tom Lendacky <thomas.lendacky@amd.com>
AMD hardware adds two additional bits to aid in nested page fault handling.
Bit 32 - NPF occurred while translating the guest's final physical address
Bit 33 - NPF occurred while translating the guest page tables
The guest page tables fault indicator can be used as an aid for nested
virtualization. Using V0 for the host, V1 for the first level guest and
V2 for the second level guest, when both V1 and V2 are using nested paging
there are currently a number of unnecessary instruction emulations. When
V2 is launched shadow paging is used in V1 for the nested tables of V2. As
a result, KVM marks these pages as RO in the host nested page tables. When
V2 exits and we resume V1, these pages are still marked RO.
Every nested walk for a guest page table is treated as a user-level write
access and this causes a lot of NPFs because the V1 page tables are marked
RO in the V0 nested tables. While executing V1, when these NPFs occur KVM
sees a write to a read-only page, emulates the V1 instruction and unprotects
the page (marking it RW). This patch looks for cases where we get a NPF due
to a guest page table walk where the page was marked RO. It immediately
unprotects the page and resumes the guest, leading to far fewer instruction
emulations when nested virtualization is used.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
arch/x86/include/asm/kvm_host.h | 11 ++++++++++-
arch/x86/kvm/mmu.c | 20 ++++++++++++++++++--
arch/x86/kvm/svm.c | 2 +-
3 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index bdde807..da07e17 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -191,6 +191,8 @@ enum {
#define PFERR_RSVD_BIT 3
#define PFERR_FETCH_BIT 4
#define PFERR_PK_BIT 5
+#define PFERR_GUEST_FINAL_BIT 32
+#define PFERR_GUEST_PAGE_BIT 33
#define PFERR_PRESENT_MASK (1U << PFERR_PRESENT_BIT)
#define PFERR_WRITE_MASK (1U << PFERR_WRITE_BIT)
@@ -198,6 +200,13 @@ enum {
#define PFERR_RSVD_MASK (1U << PFERR_RSVD_BIT)
#define PFERR_FETCH_MASK (1U << PFERR_FETCH_BIT)
#define PFERR_PK_MASK (1U << PFERR_PK_BIT)
+#define PFERR_GUEST_FINAL_MASK (1ULL << PFERR_GUEST_FINAL_BIT)
+#define PFERR_GUEST_PAGE_MASK (1ULL << PFERR_GUEST_PAGE_BIT)
+
+#define PFERR_NESTED_GUEST_PAGE (PFERR_GUEST_PAGE_MASK | \
+ PFERR_USER_MASK | \
+ PFERR_WRITE_MASK | \
+ PFERR_PRESENT_MASK)
/* apic attention bits */
#define KVM_APIC_CHECK_VAPIC 0
@@ -1203,7 +1212,7 @@ void kvm_vcpu_deactivate_apicv(struct kvm_vcpu *vcpu);
int kvm_emulate_hypercall(struct kvm_vcpu *vcpu);
-int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t gva, u32 error_code,
+int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t gva, u64 error_code,
void *insn, int insn_len);
void kvm_mmu_invlpg(struct kvm_vcpu *vcpu, gva_t gva);
void kvm_mmu_new_cr3(struct kvm_vcpu *vcpu);
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index d9c7e98..f633d29 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -4508,7 +4508,7 @@ static void make_mmu_pages_available(struct kvm_vcpu *vcpu)
kvm_mmu_commit_zap_page(vcpu->kvm, &invalid_list);
}
-int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t cr2, u32 error_code,
+int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t cr2, u64 error_code,
void *insn, int insn_len)
{
int r, emulation_type = EMULTYPE_RETRY;
@@ -4527,12 +4527,28 @@ int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t cr2, u32 error_code,
return r;
}
- r = vcpu->arch.mmu.page_fault(vcpu, cr2, error_code, false);
+ r = vcpu->arch.mmu.page_fault(vcpu, cr2, lower_32_bits(error_code),
+ false);
if (r < 0)
return r;
if (!r)
return 1;
+ /*
+ * Before emulating the instruction, check if the error code
+ * was due to a RO violation while translating the guest page.
+ * This can occur when using nested virtualization with nested
+ * paging in both guests. If true, we simply unprotect the page
+ * and resume the guest.
+ *
+ * Note: AMD only (since it supports the PFERR_GUEST_PAGE_MASK used
+ * in PFERR_NEXT_GUEST_PAGE)
+ */
+ if (error_code == PFERR_NESTED_GUEST_PAGE) {
+ kvm_mmu_unprotect_page(vcpu->kvm, gpa_to_gfn(cr2));
+ return 1;
+ }
+
if (mmio_info_in_cache(vcpu, cr2, direct))
emulation_type = 0;
emulate:
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 8ca1eca..4e462bb 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -2074,7 +2074,7 @@ static void svm_set_dr7(struct kvm_vcpu *vcpu, unsigned long value)
static int pf_interception(struct vcpu_svm *svm)
{
u64 fault_address = svm->vmcb->control.exit_info_2;
- u32 error_code;
+ u64 error_code;
int r = 1;
switch (svm->apf_reason) {
^ permalink raw reply related
* Re: [PATCH] rmc: Fix compiling issue with musl
From: Khem Raj @ 2016-11-14 22:50 UTC (permalink / raw)
To: Jianxun Zhang, openembedded-core
In-Reply-To: <1479161454-236511-1-git-send-email-jianxun.zhang@linux.intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 1768 bytes --]
On 11/14/16 2:10 PM, Jianxun Zhang wrote:
> | src/rmcl/rmcl.c: In function 'query_policy_from_db':
> | src/rmcl/rmcl.c:254:25: error: unknown type name 'ssize_t'
> | ssize_t cmd_name_len = strlen((char *)&rmc_db[policy_idx]) + 1;
> | ^~~~~~~~
>
> The musl C lib provides ssize_t but we need to enable it
> with a macro.
>
> Signed-off-by: Jianxun Zhang <jianxun.zhang@linux.intel.com>
> ---
> Before maintainer(s) push "merge" button, please read this short summary.
> I feel there could be a better syntax to do it. And We could need to get
> an ack from Hernandez, Alejandro who reported this issue and seems still
> have (other) compiling errors even with this patch.
>
> I submit this patch based on my thoughts and test out of tiny config.
>
> Tests:
> () Specify TCLIBC = "musl" in local.conf in my build dir.
> () Build quark
> () I can see this issue happens without the fix
> () With this patch and do clean builds for quark and corei7-64,
> Compiling passes. Boot test passed on RMC targets quark and Broxton-m.
>
> Thanks
>
>
> common/recipes-bsp/rmc/rmc.bb | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/common/recipes-bsp/rmc/rmc.bb b/common/recipes-bsp/rmc/rmc.bb
> index aeaf12e..61a1bdb 100644
> --- a/common/recipes-bsp/rmc/rmc.bb
> +++ b/common/recipes-bsp/rmc/rmc.bb
> @@ -24,6 +24,8 @@ COMPATIBLE_HOST = "(x86_64.*|i.86.*)-linux*"
>
> EXTRA_OEMAKE='RMC_CFLAGS="-Wl,--hash-style=both"'
>
> +EXTRA_OEMAKE_append_libc-musl = '" -D__NEED_ssize_t"'
this is not right way to handle it. you should be doing something like
#include <sys/types.h> in your source file
> +
> # from gnu-efi, we should align arch-mapping with it.
> def rmc_efi_arch(d):
> import re
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 211 bytes --]
^ permalink raw reply
* Re: Debugging Ethernet issues
From: Mason @ 2016-11-14 22:48 UTC (permalink / raw)
To: Florian Fainelli
Cc: Sebastian Frias, Andrew Lunn, netdev, Mans Rullgard,
Sergei Shtylyov, Tom Lendacky, Zach Brown, Shaohui Xie, Tim Beale,
Brian Hill, Vince Bridgers, Balakumaran Kannan, David S. Miller,
Kirill Kapranov
In-Reply-To: <1fd492b4-3c32-7939-791c-56cf6d8c0078@gmail.com>
On 14/11/2016 22:00, Florian Fainelli wrote:
> No I missed that, way too many emails, really.
Sorry, I was trying to be thorough, but I went overboard.
I'll start a new thread tomorrow, with a smaller CC list
(only those who have participated so far) and I'll try to
remain concise.
Regards.
^ permalink raw reply
* [Buildroot] [PATCH 1/1] package/nodejs: bump version to 6.9.1
From: Thomas Petazzoni @ 2016-11-14 22:49 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1479142730-21743-1-git-send-email-cloudyparts@icloud.com>
Hello,
On Mon, 14 Nov 2016 11:58:50 -0500, Patrick Devlin wrote:
> https://nodejs.org/en/blog/release/v6.9.1/
>
> The patches from 6.7.0 have been copied to 6.9.1.
>
> Signed-off-by: Patrick Devlin <cloudyparts@icloud.com>
> ---
> .../{6.7.0 => 6.9.1}/0001-gyp-force-link-command-to-use-CXX.patch | 0
> .../0002-inspector-don-t-build-when-ssl-support-is-disabled.patch | 0
> package/nodejs/Config.in | 2 +-
> package/nodejs/nodejs.hash | 4 ++--
> 4 files changed, 3 insertions(+), 3 deletions(-)
> rename package/nodejs/{6.7.0 => 6.9.1}/0001-gyp-force-link-command-to-use-CXX.patch (100%)
> rename package/nodejs/{6.7.0 => 6.9.1}/0002-inspector-don-t-build-when-ssl-support-is-disabled.patch (100%)
Applied to next, thanks.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.