* Re: [PATCH net 0/5] tcp: more robust ooo handling
From: David Miller @ 2018-07-23 19:03 UTC (permalink / raw)
To: edumazet; +Cc: juha-matti.tilli, ycheng, soheil, netdev, eric.dumazet
In-Reply-To: <20180723162821.11556-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Mon, 23 Jul 2018 09:28:16 -0700
> Juha-Matti Tilli reported that malicious peers could inject tiny
> packets in out_of_order_queue, forcing very expensive calls
> to tcp_collapse_ofo_queue() and tcp_prune_ofo_queue() for
> every incoming packet.
>
> With tcp_rmem[2] default of 6MB, the ooo queue could
> contain ~7000 nodes.
>
> This patch series makes sure we cut cpu cycles enough to
> render the attack not critical.
>
> We might in the future go further, like disconnecting
> or black-holing proven malicious flows.
Sucky...
It took me a while to understand the sums_tiny logic, every
time I read that function I forget that we reset all of the
state and restart the loop after a coalesce inside the loop.
Series applied, and queued up for -stable.
Thanks!
^ permalink raw reply
* [PATCH v3 RFC] Smack: Inform peer that IPv6 traffic has been blocked
From: Casey Schaufler @ 2018-07-23 20:04 UTC (permalink / raw)
To: linux-security-module
In-Reply-To: <20180719094732eucas1p18ac5bd15693cd06f868238c7a4951aa1~CvBwyJxUf3081230812eucas1p1q@eucas1p1.samsung.com>
On 7/19/2018 2:47 AM, Piotr Sawicki wrote:
> In this patch we're sending an ICMPv6 message to a peer to
> immediately inform it that making a connection is not possible.
> In case of TCP connections, without this change, the peer
> will be waiting until a connection timeout is exceeded.
>
> Signed-off-by: Piotr Sawicki <p.sawicki2@partner.samsung.com>
Added to git://github.com/cschaufler/next-smack.git#smack-for-4.19-a
> ---
> Changes in v2:
> - Add missing Signed-off-by field
> Changes in v3:
> - Fix formatting issues caused by improper email client configuration
> ---
> security/smack/smack_lsm.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> index c2282ac..efa81bc 100644
> --- a/security/smack/smack_lsm.c
> +++ b/security/smack/smack_lsm.c
> @@ -28,6 +28,7 @@
> #include <linux/tcp.h>
> #include <linux/udp.h>
> #include <linux/dccp.h>
> +#include <linux/icmpv6.h>
> #include <linux/slab.h>
> #include <linux/mutex.h>
> #include <linux/pipe_fs_i.h>
> @@ -4010,6 +4011,9 @@ static int smack_socket_sock_rcv_skb(struct sock *sk, struct sk_buff *skb)
> #ifdef SMACK_IPV6_PORT_LABELING
> rc = smk_ipv6_port_check(sk, &sadd, SMK_RECEIVING);
> #endif /* SMACK_IPV6_PORT_LABELING */
> + if (rc != 0)
> + icmpv6_send(skb, ICMPV6_DEST_UNREACH,
> + ICMPV6_ADM_PROHIBITED, 0);
> break;
> #endif /* CONFIG_IPV6 */
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v4 RFC] Smack: Check UDP-Lite and DCCP protocols during IPv6 handling
From: Casey Schaufler @ 2018-07-23 20:04 UTC (permalink / raw)
To: linux-security-module
In-Reply-To: <20180719094518eucas1p21032c7af4afc37854db8ea84836d6fe3~Cu-zsE2gF2522125221eucas1p2i@eucas1p2.samsung.com>
On 7/19/2018 2:45 AM, Piotr Sawicki wrote:
> The smack_socket_sock_rcv_skb() function is checking smack labels
> only for UDP and TCP frames carried in IPv6 packets. From now on,
> it is able also to handle UDP-Lite and DCCP protocols.
>
> Signed-off-by: Piotr Sawicki <p.sawicki2@partner.samsung.com>
Added to git://github.com/cschaufler/next-smack.git#smack-for-4.19-a
> ---
> Changes in v2:
> - Add missing Signed-off-by field
> Changes in v3:
> - Fix the email subject
> Changes in v4:
> - Fix formatting issues caused by improper email client configuration
> ---
> security/smack/smack_lsm.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> index 8b6cd5a..c2282ac 100644
> --- a/security/smack/smack_lsm.c
> +++ b/security/smack/smack_lsm.c
> @@ -3896,6 +3896,7 @@ static int smk_skb_to_addr_ipv6(struct sk_buff *skb, struct sockaddr_in6 *sip)
> sip->sin6_port = th->source;
> break;
> case IPPROTO_UDP:
> + case IPPROTO_UDPLITE:
> uh = skb_header_pointer(skb, offset, sizeof(_udph), &_udph);
> if (uh != NULL)
> sip->sin6_port = uh->source;
> @@ -3986,7 +3987,8 @@ static int smack_socket_sock_rcv_skb(struct sock *sk, struct sk_buff *skb)
> #if IS_ENABLED(CONFIG_IPV6)
> case PF_INET6:
> proto = smk_skb_to_addr_ipv6(skb, &sadd);
> - if (proto != IPPROTO_UDP && proto != IPPROTO_TCP)
> + if (proto != IPPROTO_UDP && proto != IPPROTO_UDPLITE &&
> + proto != IPPROTO_TCP && proto != IPPROTO_DCCP)
> break;
> #ifdef SMACK_IPV6_SECMARK_LABELING
> if (skb && skb->secmark != 0)
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v3 RFC] Smack: Fix handling of IPv4 traffic received by PF_INET6 sockets
From: Casey Schaufler @ 2018-07-23 20:04 UTC (permalink / raw)
To: linux-security-module
In-Reply-To: <20180719094259eucas1p19513e434a8440d344934c4fe70281c9d~Cu9y7ZvVv2974129741eucas1p18@eucas1p1.samsung.com>
On 7/19/2018 2:42 AM, Piotr Sawicki wrote:
> A socket which has sk_family set to PF_INET6 is able to receive not
> only IPv6 but also IPv4 traffic (IPv4-mapped IPv6 addresses).
>
> Prior to this patch, the smk_skb_to_addr_ipv6() could have been
> called for socket buffers containing IPv4 packets, in result such
> traffic was allowed.
>
> Signed-off-by: Piotr Sawicki <p.sawicki2@partner.samsung.com>
Added to git://github.com/cschaufler/next-smack.git#smack-for-4.19-a
> ---
> Changes in v2:
> - Properly pass the family variable to other functions
> - Fix coding style
> Changes in v3:
> - Fix formatting issues caused by improper email client configuration
> ---
> security/smack/smack_lsm.c | 14 +++++++++-----
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> index 19de675..8b6cd5a 100644
> --- a/security/smack/smack_lsm.c
> +++ b/security/smack/smack_lsm.c
> @@ -3924,15 +3924,19 @@ static int smack_socket_sock_rcv_skb(struct sock *sk, struct sk_buff *skb)
> struct smack_known *skp = NULL;
> int rc = 0;
> struct smk_audit_info ad;
> + u16 family = sk->sk_family;
> #ifdef CONFIG_AUDIT
> struct lsm_network_audit net;
> #endif
> #if IS_ENABLED(CONFIG_IPV6)
> struct sockaddr_in6 sadd;
> int proto;
> +
> + if (family == PF_INET6 && skb->protocol == htons(ETH_P_IP))
> + family = PF_INET;
> #endif /* CONFIG_IPV6 */
>
> - switch (sk->sk_family) {
> + switch (family) {
> case PF_INET:
> #ifdef CONFIG_SECURITY_SMACK_NETFILTER
> /*
> @@ -3950,7 +3954,7 @@ static int smack_socket_sock_rcv_skb(struct sock *sk, struct sk_buff *skb)
> */
> netlbl_secattr_init(&secattr);
>
> - rc = netlbl_skbuff_getattr(skb, sk->sk_family, &secattr);
> + rc = netlbl_skbuff_getattr(skb, family, &secattr);
> if (rc == 0)
> skp = smack_from_secattr(&secattr, ssp);
> else
> @@ -3963,7 +3967,7 @@ static int smack_socket_sock_rcv_skb(struct sock *sk, struct sk_buff *skb)
> #endif
> #ifdef CONFIG_AUDIT
> smk_ad_init_net(&ad, __func__, LSM_AUDIT_DATA_NET, &net);
> - ad.a.u.net->family = sk->sk_family;
> + ad.a.u.net->family = family;
> ad.a.u.net->netif = skb->skb_iif;
> ipv4_skb_to_auditdata(skb, &ad.a, NULL);
> #endif
> @@ -3977,7 +3981,7 @@ static int smack_socket_sock_rcv_skb(struct sock *sk, struct sk_buff *skb)
> rc = smk_bu_note("IPv4 delivery", skp, ssp->smk_in,
> MAY_WRITE, rc);
> if (rc != 0)
> - netlbl_skbuff_err(skb, sk->sk_family, rc, 0);
> + netlbl_skbuff_err(skb, family, rc, 0);
> break;
> #if IS_ENABLED(CONFIG_IPV6)
> case PF_INET6:
> @@ -3993,7 +3997,7 @@ static int smack_socket_sock_rcv_skb(struct sock *sk, struct sk_buff *skb)
> skp = smack_net_ambient;
> #ifdef CONFIG_AUDIT
> smk_ad_init_net(&ad, __func__, LSM_AUDIT_DATA_NET, &net);
> - ad.a.u.net->family = sk->sk_family;
> + ad.a.u.net->family = family;
> ad.a.u.net->netif = skb->skb_iif;
> ipv6_skb_to_auditdata(skb, &ad.a, NULL);
> #endif /* CONFIG_AUDIT */
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [Bug 200633] [Regression] VGA not being detected with R9 380 using AMDGPU after 4.17 kernel update.
From: bugzilla-daemon @ 2018-07-23 20:04 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-200633-2300@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=200633
syboxez@gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Regression|No |Yes
--
You are receiving this mail because:
You are watching the assignee of the bug.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 00/14] format-patch: add --interdiff and --range-diff options
From: Eric Sunshine @ 2018-07-23 20:03 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: Git List, Johannes Schindelin,
Ævar Arnfjörð Bjarmason, Stefan Beller
In-Reply-To: <CACsJy8BgAMYykkNOJc5NgMj-X6SMyskU3iCzTKnL0CLRTdF2oA@mail.gmail.com>
On Mon, Jul 23, 2018 at 12:32 PM Duy Nguyen <pclouds@gmail.com> wrote:
> On Sun, Jul 22, 2018 at 11:57 AM Eric Sunshine <sunshine@sunshineco.com> wrote:
> > When re-submitting a patch series, it is often helpful (for reviewers)
> > to include an interdiff or range-diff against the previous version.
> > Doing so requires manually running git-diff or git-range-diff and
> > copy/pasting the result into the cover letter of the new version.
> >
> > This series automates the process by introducing git-format-patch
> > options --interdiff and --range-diff which insert such a diff into the
> > cover-letter or into the commentary section of the lone patch of a
> > 1-patch series. In the latter case, the interdiff or range-diff is
> > indented to avoid confusing git-am and human readers.
>
> I gave up after 10/14. But what I've seen is nice (yes I have a couple
> comments here and there but you probably won't need to update
> anything).
Thanks for the review comments.
^ permalink raw reply
* [Bug 200633] New: [Regression] VGA not being detected with R9 380 using AMDGPU after 4.17 kernel update.
From: bugzilla-daemon @ 2018-07-23 20:03 UTC (permalink / raw)
To: dri-devel
https://bugzilla.kernel.org/show_bug.cgi?id=200633
Bug ID: 200633
Summary: [Regression] VGA not being detected with R9 380 using
AMDGPU after 4.17 kernel update.
Product: Drivers
Version: 2.5
Kernel Version: 4.17
Hardware: x86-64
OS: Linux
Tree: Mainline
Status: NEW
Severity: low
Priority: P1
Component: Video(DRI - non Intel)
Assignee: drivers_video-dri@kernel-bugs.osdl.org
Reporter: syboxez@gmail.com
Regression: No
OS: Debian Sid
Kernel: 4.17.8
GPU: AMD R9 380
Mesa version: 18.1.4
After upgrading from 4.16 to 4.17 (this bug was also reproduced on 4.18-RC3),
xrandr reports VGA displays (normally DVI-I-1 in my case) as digital displays
(DVI-D-1), and will display a black screen on the monitor I am attempting to
use. In 4.16, it worked perfectly. Booting the system with the 4.16 kernel
resolves the issue.
I will be happy to collect any useful logs upon request, as I'm not too sure
what to look for.
--
You are receiving this mail because:
You are watching the assignee of the bug.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [EXTERNAL] [master][PATCH] posix-smp-demo: SRCREV bump to 1.1.0.1
From: Jacob Stiffler @ 2018-07-23 20:02 UTC (permalink / raw)
To: Mahesh Radhakrishnan, meta-arago
In-Reply-To: <1532021413-49029-2-git-send-email-m-radhakrishnan2@ti.com>
ACK
Denys,
Can you please apply this to the ti2018.01 branch?
Thank you,
Jake
On 7/19/2018 1:30 PM, Mahesh Radhakrishnan wrote:
> Signed-off-by: Mahesh Radhakrishnan <m-radhakrishnan2@ti.com>
> ---
> meta-arago-extras/recipes-apps/posix-smp-demo/posix-smp-demo.inc | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/meta-arago-extras/recipes-apps/posix-smp-demo/posix-smp-demo.inc b/meta-arago-extras/recipes-apps/posix-smp-demo/posix-smp-demo.inc
> index 3d78727..b89ebd4 100644
> --- a/meta-arago-extras/recipes-apps/posix-smp-demo/posix-smp-demo.inc
> +++ b/meta-arago-extras/recipes-apps/posix-smp-demo/posix-smp-demo.inc
> @@ -7,14 +7,14 @@ POSIX_SMP_GIT_URI = "git://git.ti.com/keystone-demos/posix-smp.git"
> POSIX_SMP_GIT_PROTOCOL = "git"
> POSIX_SMP_GIT_BRANCH = "master"
>
> -# Below commit ID corresponds to "DEV.POSIX-SMP.01.01.00.00"
> -POSIX_SMP_SRCREV = "139fe7ec58939dc2743355e5fede0735f8693ebd"
> +# Below commit ID corresponds to "DEV.POSIX-SMP.01.01.00.01"
> +POSIX_SMP_SRCREV = "99834751f63f8f418e659b251f10e8e13b900881"
>
> BRANCH = "${POSIX_SMP_GIT_BRANCH}"
> SRC_URI = "${POSIX_SMP_GIT_URI};protocol=${POSIX_SMP_GIT_PROTOCOL};branch=${BRANCH}"
>
> SRCREV = "${POSIX_SMP_SRCREV}"
> -PV = "01.01.00.00"
> +PV = "01.01.00.01"
> INC_PR = "r0"
>
> S = "${WORKDIR}/git"
^ permalink raw reply
* [xen-4.9-testing test] 125506: regressions - trouble: blocked/broken/fail/pass
From: osstest service owner @ 2018-07-23 20:02 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 125506 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125506/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops <job status> broken
test-armhf-armhf-xl-vhd <job status> broken
build-arm64-pvops 4 host-install(4) broken REGR. vs. 124328
test-arm64-arm64-xl <job status> broken in 125487
build-arm64-xsm <job status> broken in 125487
build-arm64-libvirt <job status> broken in 125487
build-arm64-libvirt 4 host-install(4) broken in 125487 REGR. vs. 124328
build-arm64-xsm 4 host-install(4) broken in 125487 REGR. vs. 124328
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail REGR. vs. 124248
test-amd64-amd64-libvirt-pair 23 guest-migrate/dst_host/src_host fail in 125253 REGR. vs. 124328
Tests which are failing intermittently (not blocking):
test-arm64-arm64-xl 4 host-install(4) broken in 125487 pass in 125416
test-armhf-armhf-xl-vhd 4 host-install(4) broken pass in 125487
test-arm64-arm64-xl-credit2 7 xen-boot fail in 125171 pass in 125487
test-amd64-amd64-xl-qemut-debianhvm-amd64 7 xen-boot fail in 125253 pass in 125506
test-amd64-i386-rumprun-i386 17 rumprun-demo-xenstorels/xenstorels.repeat fail in 125487 pass in 125506
test-armhf-armhf-xl-rtds 12 guest-start fail in 125487 pass in 125506
test-amd64-amd64-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail pass in 125171
test-amd64-i386-libvirt-xsm 10 debian-install fail pass in 125171
test-amd64-i386-xl-raw 10 debian-di-install fail pass in 125171
test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail pass in 125253
test-armhf-armhf-xl-arndale 6 xen-install fail pass in 125487
test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail pass in 125487
test-amd64-i386-qemut-rhel6hvm-amd 10 redhat-install fail pass in 125487
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-arm64-arm64-xl 1 build-check(1) blocked n/a
test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a
test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail in 125171 blocked in 124328
test-amd64-i386-xl-qemuu-ws16-amd64 18 guest-start/win.repeat fail in 125171 blocked in 124328
test-amd64-i386-libvirt-xsm 13 migrate-support-check fail in 125171 never pass
test-amd64-amd64-xl-qemuu-ws16-amd64 14 guest-localmigrate fail in 125416 like 124248
test-arm64-arm64-xl 13 migrate-support-check fail in 125416 never pass
test-arm64-arm64-xl 14 saverestore-support-check fail in 125416 never pass
test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail in 125416 never pass
test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail in 125416 never pass
test-arm64-arm64-xl-xsm 13 migrate-support-check fail in 125416 never pass
test-arm64-arm64-xl-xsm 14 saverestore-support-check fail in 125416 never pass
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail in 125487 blocked in 124328
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 125487 like 124248
test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail in 125487 like 124328
test-amd64-i386-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail in 125487 like 124328
test-arm64-arm64-xl-credit2 13 migrate-support-check fail in 125487 never pass
test-arm64-arm64-xl-credit2 14 saverestore-support-check fail in 125487 never pass
test-armhf-armhf-xl-arndale 13 migrate-support-check fail in 125487 never pass
test-armhf-armhf-xl-arndale 14 saverestore-support-check fail in 125487 never pass
test-armhf-armhf-xl-vhd 12 migrate-support-check fail in 125487 never pass
test-armhf-armhf-xl-vhd 13 saverestore-support-check fail in 125487 never pass
test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 124248
test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail like 124248
test-amd64-i386-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail like 124248
test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail like 124328
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 124328
test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 124328
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 124328
test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 124328
test-amd64-i386-libvirt 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass
test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass
test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass
test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass
test-armhf-armhf-libvirt 13 migrate-support-check fail never pass
test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass
test-amd64-amd64-xl-qemut-win10-i386 10 windows-install fail never pass
test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install fail never pass
test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
test-armhf-armhf-xl 13 migrate-support-check fail never pass
test-armhf-armhf-xl 14 saverestore-support-check fail never pass
version targeted for testing:
xen f5c692acb81219d817e97ea8499f44f9f2764af5
baseline version:
xen 238007d6fae9447bf5e8e73d67ae9fb844e7ff2a
Last test of basis 124328 2018-06-17 23:39:07 Z 35 days
Failing since 124807 2018-06-28 17:38:04 Z 25 days 14 attempts
Testing same since 125144 2018-07-13 01:29:33 Z 10 days 7 attempts
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
Ian Jackson <Ian.Jackson@eu.citrix.com>
Jan Beulich <jbeulich@suse.com>
Juergen Gross <jgross@suse.com>
Kevin Tian <kevin.tian@intel.com>
Paul Durrant <paul.durrant@citrix.com>
Stewart Hildebrand <stewart.hildebrand@dornerworks.com>
jobs:
build-amd64-xsm pass
build-arm64-xsm pass
build-i386-xsm pass
build-amd64-xtf pass
build-amd64 pass
build-arm64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-arm64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-prev pass
build-i386-prev pass
build-amd64-pvops pass
build-arm64-pvops broken
build-armhf-pvops pass
build-i386-pvops pass
build-amd64-rumprun pass
build-i386-rumprun pass
test-xtf-amd64-amd64-1 pass
test-xtf-amd64-amd64-2 pass
test-xtf-amd64-amd64-3 pass
test-xtf-amd64-amd64-4 pass
test-xtf-amd64-amd64-5 pass
test-amd64-amd64-xl pass
test-arm64-arm64-xl blocked
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-xsm pass
test-arm64-arm64-libvirt-xsm blocked
test-amd64-i386-libvirt-xsm fail
test-amd64-amd64-xl-xsm pass
test-arm64-arm64-xl-xsm blocked
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-i386-qemut-rhel6hvm-amd fail
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 fail
test-amd64-i386-xl-qemut-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-rumprun-amd64 pass
test-amd64-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-qemut-ws16-amd64 fail
test-amd64-i386-xl-qemut-ws16-amd64 fail
test-amd64-amd64-xl-qemuu-ws16-amd64 fail
test-amd64-i386-xl-qemuu-ws16-amd64 fail
test-armhf-armhf-xl-arndale fail
test-amd64-amd64-xl-credit2 pass
test-arm64-arm64-xl-credit2 blocked
test-armhf-armhf-xl-credit2 pass
test-armhf-armhf-xl-cubietruck pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-i386-rumprun-i386 pass
test-amd64-amd64-xl-qemut-win10-i386 fail
test-amd64-i386-xl-qemut-win10-i386 fail
test-amd64-amd64-xl-qemuu-win10-i386 fail
test-amd64-i386-xl-qemuu-win10-i386 fail
test-amd64-amd64-qemuu-nested-intel pass
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt pass
test-amd64-amd64-livepatch pass
test-amd64-i386-livepatch pass
test-amd64-amd64-migrupgrade pass
test-amd64-i386-migrupgrade pass
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair fail
test-amd64-i386-libvirt-pair fail
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-pygrub pass
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw pass
test-amd64-i386-xl-raw fail
test-amd64-amd64-xl-rtds pass
test-armhf-armhf-xl-rtds fail
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-amd64-xl-shadow pass
test-amd64-i386-xl-shadow pass
test-amd64-amd64-libvirt-vhd pass
test-armhf-armhf-xl-vhd broken
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
broken-job build-arm64-pvops broken
broken-job test-armhf-armhf-xl-vhd broken
broken-step build-arm64-pvops host-install(4)
broken-step test-armhf-armhf-xl-vhd host-install(4)
broken-job test-arm64-arm64-xl broken
broken-job build-arm64-xsm broken
broken-job build-arm64-libvirt broken
Not pushing.
(No revision log; it would be 307 lines long.)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH 2/2] media: usb: pwc: Don't use coherent DMA buffers for ISO transfer
From: Alan Stern @ 2018-07-23 18:57 UTC (permalink / raw)
To: Matwey V. Kornilov
Cc: Tomasz Figa, Ezequiel Garcia, Hans de Goede, Hans Verkuil,
Mauro Carvalho Chehab, Laurent Pinchart, Steven Rostedt, mingo,
Mike Isely, Bhumika Goyal, Colin King, Linux Media Mailing List,
Linux Kernel Mailing List, Kieran Bingham, keiichiw
In-Reply-To: <CAJs94EZEqWEscECp7bsJ3DvqoU83_Y2WQ55jPaG4MyoG-hvLFQ@mail.gmail.com>
On Mon, 23 Jul 2018, Matwey V. Kornilov wrote:
> I've tried to strategies:
>
> 1) Use dma_unmap and dma_map inside the handler (I suppose this is
> similar to how USB core does when there is no URB_NO_TRANSFER_DMA_MAP)
Yes.
> 2) Use sync_cpu and sync_device inside the handler (and dma_map only
> once at memory allocation)
>
> It is interesting that dma_unmap/dma_map pair leads to the lower
> overhead (+1us) than sync_cpu/sync_device (+2us) at x86_64 platform.
> At armv7l platform using dma_unmap/dma_map leads to ~50 usec in the
> handler, and sync_cpu/sync_device - ~65 usec.
>
> However, I am not sure is it mandatory to call
> dma_sync_single_for_device for FROM_DEVICE direction?
According to Documentation/DMA-API-HOWTO.txt, the CPU should not write
to a DMA_FROM_DEVICE-mapped area, so dma_sync_single_for_device() is
not needed.
Alan Stern
^ permalink raw reply
* Re: [PATCH 10/14] format-patch: add --range-diff option to embed diff in cover letter
From: Eric Sunshine @ 2018-07-23 19:58 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: Git List, Johannes Schindelin,
Ævar Arnfjörð Bjarmason, Stefan Beller
In-Reply-To: <CACsJy8AOeiKp2JnG0h9mw40TdsNft80vUu573ORtqKMor7B+vw@mail.gmail.com>
On Mon, Jul 23, 2018 at 12:28 PM Duy Nguyen <pclouds@gmail.com> wrote:
> On Sun, Jul 22, 2018 at 11:58 AM Eric Sunshine <sunshine@sunshineco.com> wrote:
> > diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
> > index f8a061794d..e7f404be3d 100644
> > --- a/Documentation/git-format-patch.txt
> > +++ b/Documentation/git-format-patch.txt
> > @@ -24,6 +24,7 @@ SYNOPSIS
> > [--to=<email>] [--cc=<email>]
> > [--[no-]cover-letter] [--quiet] [--notes[=<ref>]]
> > [--interdiff=<previous>]
> > + [--range-diff=<previous>]
>
> I wonder if people will use both --interdiff=<rev> and
> --range-diff=<rev> often enough to justify a shortcut
> "--all-kinds-of-diff=<rev>" so that we don't have to type <previous>
> twice. But I guess we don't have to worry about this right now.
My original thought was that --interdiff and --range-diff would be
mutually exclusive, however, I quickly realized that some people might
like to use both options together since each format has its strengths
and weaknesses. (I've used both types of diffs together when preparing
rerolls of my own series and found that, together, they provided a
better picture of the reroll than either would have alone.)
Based upon experience on this mailing list, I'd guess that most people
would use only one or the other, though that doesn't speak for other
projects. And, as you note, it's something that can be added later if
warranted (plus, this series is already long and I'd like to avoid
making it longer for something like this whose value is only
speculative).
^ permalink raw reply
* [Intel-wired-lan] [jkirsher-next-queue:dev-queue] BUILD SUCCESS f117974c8e78e6abdcdeeaf31d5352d66dad9694
From: kbuild test robot @ 2018-07-23 19:56 UTC (permalink / raw)
To: intel-wired-lan
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git dev-queue
branch HEAD: f117974c8e78e6abdcdeeaf31d5352d66dad9694 ice: Fix missing shift
elapsed time: 119m
configs tested: 122
The following configs have been built successfully.
More configs may be tested in the coming days.
x86_64 allmodconfig
powerpc mpc8560_ads_defconfig
x86_64 randconfig-a0-07240159
x86_64 acpi-redef
x86_64 allyesdebian
x86_64 nfsroot
sh allnoconfig
sh rsk7269_defconfig
sh sh7785lcr_32bit_defconfig
sh titan_defconfig
i386 randconfig-c0-07231120
mips jmr3927_defconfig
sparc64 allnoconfig
mips lasat_defconfig
parisc a500_defconfig
x86_64 randconfig-it0-07231322
i386 randconfig-n0-201829
x86_64 randconfig-x007-201829
x86_64 randconfig-x003-201829
x86_64 randconfig-x000-201829
x86_64 randconfig-x005-201829
x86_64 randconfig-x004-201829
x86_64 randconfig-x008-201829
x86_64 randconfig-x001-201829
x86_64 randconfig-x009-201829
x86_64 randconfig-x002-201829
x86_64 randconfig-x006-201829
ia64 alldefconfig
ia64 allnoconfig
ia64 defconfig
i386 randconfig-i0-201829
i386 randconfig-i1-201829
powerpc allnoconfig
powerpc defconfig
powerpc ppc64_defconfig
s390 default_defconfig
i386 allmodconfig
x86_64 randconfig-x018-201829
x86_64 randconfig-x011-201829
x86_64 randconfig-x015-201829
x86_64 randconfig-x019-201829
x86_64 randconfig-x014-201829
x86_64 randconfig-x010-201829
x86_64 randconfig-x013-201829
x86_64 randconfig-x016-201829
x86_64 randconfig-x017-201829
x86_64 randconfig-x012-201829
i386 randconfig-a0-201829
i386 randconfig-a1-201829
x86_64 randconfig-s0-07231842
x86_64 randconfig-s1-07231842
x86_64 randconfig-s2-07231842
alpha defconfig
parisc allnoconfig
parisc b180_defconfig
parisc c3000_defconfig
parisc defconfig
arm ezx_defconfig
m68k m5249evb_defconfig
microblaze allnoconfig
nds32 defconfig
i386 alldefconfig
i386 allnoconfig
i386 defconfig
m68k m5475evb_defconfig
m68k multi_defconfig
m68k sun3_defconfig
i386 randconfig-s0-201829
i386 randconfig-s1-201829
x86_64 randconfig-s3-07232252
x86_64 randconfig-s4-07232252
x86_64 randconfig-s5-07232252
openrisc or1ksim_defconfig
um i386_defconfig
um x86_64_defconfig
mips capcella_defconfig
mips rb532_defconfig
sh apsh4a3a_defconfig
x86_64 randconfig-i0-201829
powerpc pcm030_defconfig
powerpc tqm8548_defconfig
sh hp6xx_defconfig
microblaze mmu_defconfig
microblaze nommu_defconfig
sparc defconfig
sparc64 defconfig
c6x evmc6678_defconfig
h8300 h8300h-sim_defconfig
nios2 10m50_defconfig
xtensa common_defconfig
xtensa iss_defconfig
x86_64 randconfig-u0-07240101
openrisc allnoconfig
powerpc fsp2_defconfig
s390 zfcpdump_defconfig
i386 randconfig-x012-201829
i386 randconfig-x017-201829
i386 randconfig-x014-201829
i386 randconfig-x016-201829
i386 randconfig-x013-201829
i386 randconfig-x011-201829
i386 randconfig-x018-201829
i386 randconfig-x010-201829
i386 randconfig-x015-201829
i386 randconfig-x019-201829
mips 32r2_defconfig
mips 64r6el_defconfig
mips allnoconfig
mips fuloong2e_defconfig
mips jz4740
mips malta_kvm_defconfig
mips txx9
i386 randconfig-x008-201829
i386 randconfig-x009-201829
i386 randconfig-x005-201829
i386 randconfig-x000-201829
i386 randconfig-x003-201829
i386 randconfig-x001-201829
i386 randconfig-x004-201829
i386 randconfig-x006-201829
i386 randconfig-x007-201829
i386 randconfig-x002-201829
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [PATCH v4] drm/i915: Skip repeated calls to i915_gem_set_wedged()
From: Chris Wilson @ 2018-07-23 19:56 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <20180723145335.24579-1-chris@chris-wilson.co.uk>
If we already wedged, i915_gem_set_wedged() becomes a complicated no-op.
v2: Make sure the double set-wedged is synchronous, a parallel call
should not return before the driver is indeed wedged.
References: https://bugs.freedesktop.org/show_bug.cgi?id=107343
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/i915_gem.c | 32 ++++++++++++++++++++++-----
drivers/gpu/drm/i915/i915_gpu_error.h | 3 ++-
2 files changed, 29 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8b52cb768a67..912be7356984 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3298,12 +3298,27 @@ static void nop_complete_submit_request(struct i915_request *request)
spin_unlock_irqrestore(&request->engine->timeline.lock, flags);
}
+static void wait_for_wedged(struct i915_gpu_error *error)
+{
+ DEFINE_WAIT_BIT(wq_entry, &error->flags, I915_WEDGED);
+
+ __wait_on_bit(&error->reset_queue,
+ &wq_entry, bit_wait, TASK_UNINTERRUPTIBLE);
+}
+
void i915_gem_set_wedged(struct drm_i915_private *i915)
{
+ struct i915_gpu_error *error = &i915->gpu_error;
struct intel_engine_cs *engine;
enum intel_engine_id id;
- GEM_TRACE("start\n");
+ if (test_bit(I915_WEDGED, &error->flags))
+ return;
+
+ if (test_and_set_bit(I915_WEDGE_IN_PROGRESS, &error->flags)) {
+ wait_for_wedged(error);
+ return;
+ }
if (GEM_SHOW_DEBUG()) {
struct drm_printer p = drm_debug_printer(__func__);
@@ -3312,8 +3327,7 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
intel_engine_dump(engine, &p, "%s\n", engine->name);
}
- set_bit(I915_WEDGED, &i915->gpu_error.flags);
- smp_mb__after_atomic();
+ GEM_TRACE("start\n");
/*
* First, stop submission to hw, but do not yet complete requests by
@@ -3372,17 +3386,25 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
i915_gem_reset_finish_engine(engine);
}
+ smp_mb__before_atomic();
+ set_bit(I915_WEDGED, &error->flags);
+ clear_bit(I915_WEDGE_IN_PROGRESS, &error->flags);
+
GEM_TRACE("end\n");
- wake_up_all(&i915->gpu_error.reset_queue);
+ wake_up_all(&error->reset_queue);
}
bool i915_gem_unset_wedged(struct drm_i915_private *i915)
{
+ struct i915_gpu_error *error = &i915->gpu_error;
struct i915_timeline *tl;
lockdep_assert_held(&i915->drm.struct_mutex);
- if (!test_bit(I915_WEDGED, &i915->gpu_error.flags))
+
+ if (test_bit(I915_WEDGE_IN_PROGRESS, &error->flags))
+ wait_for_wedged(error);
+ if (!test_bit(I915_WEDGED, &error->flags))
return true;
GEM_TRACE("start\n");
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h b/drivers/gpu/drm/i915/i915_gpu_error.h
index f893a4e8b783..1a78a8f330f2 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -267,8 +267,9 @@ struct i915_gpu_error {
#define I915_RESET_BACKOFF 0
#define I915_RESET_HANDOFF 1
#define I915_RESET_MODESET 2
+#define I915_RESET_ENGINE 3
#define I915_WEDGED (BITS_PER_LONG - 1)
-#define I915_RESET_ENGINE (I915_WEDGED - I915_NUM_ENGINES)
+#define I915_WEDGE_IN_PROGRESS (I915_WEDGED - 1)
/** Number of times an engine has been reset */
u32 reset_engine_count[I915_NUM_ENGINES];
--
2.18.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* [rocko/master][PATCHv2] tidl-utils: SRCREV bump
From: Djordje Senicic @ 2018-07-23 19:54 UTC (permalink / raw)
To: meta-arago; +Cc: d-senicic1, Djordje Senicic
* Get new version of tidl-utils configuration files with fixed path
* RDEPENDS is not needed for x86 target, as executables are statically linked
Signed-off-by: Djordje Senicic <x0157990@ti.com>
---
| 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--git a/meta-arago-extras/recipes-ti/tidl-utils/tidl-utils.bb b/meta-arago-extras/recipes-ti/tidl-utils/tidl-utils.bb
index 264b030..569de5a 100644
--- a/meta-arago-extras/recipes-ti/tidl-utils/tidl-utils.bb
+++ b/meta-arago-extras/recipes-ti/tidl-utils/tidl-utils.bb
@@ -8,10 +8,10 @@ INC_PR = "r0"
LIC_FILES_CHKSUM = "file://docs/LICENSE.txt;md5=a93aa5af7a3bbbb6fb34c8df59efaa5c"
-RDEPENDS_${PN} += " tidl-api tidl-examples "
+RDEPENDS_${PN}_class-target += " tidl-api tidl-examples "
SRC_URI = "git://git.ti.com/tidl/tidl-utils.git;protocol=git;branch=master"
-SRCREV = "93f66d2c53960b13b7e7f20208ee205f727aaf28"
+SRCREV = "994d90ae583610673d9d39086ca5e84027a9c56e"
PR = "${INC_PR}.0"
--
1.9.1
^ permalink raw reply related
* ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Skip repeated calls to i915_gem_set_wedged() (rev3)
From: Patchwork @ 2018-07-23 19:54 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
In-Reply-To: <20180723145335.24579-1-chris@chris-wilson.co.uk>
== Series Details ==
Series: drm/i915: Skip repeated calls to i915_gem_set_wedged() (rev3)
URL : https://patchwork.freedesktop.org/series/47067/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
fbfeaf105d25 drm/i915: Skip repeated calls to i915_gem_set_wedged()
-:60: WARNING:MEMORY_BARRIER: memory barrier without comment
#60: FILE: drivers/gpu/drm/i915/i915_gem.c:3388:
+ smp_mb__before_atomic();
total: 0 errors, 1 warnings, 0 checks, 73 lines checked
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v10 7/7] Bluetooth: hci_qca: Add support for Qualcomm Bluetooth chip wcn3990
From: Matthias Kaehlcke @ 2018-07-23 19:54 UTC (permalink / raw)
To: Balakrishna Godavarthi
Cc: marcel, johan.hedberg, linux-kernel, devicetree, linux-bluetooth,
thierry.escande, rtatiya, hemantg, linux-arm-msm
In-Reply-To: <20180720133243.6851-8-bgodavar@codeaurora.org>
On Fri, Jul 20, 2018 at 07:02:43PM +0530, Balakrishna Godavarthi wrote:
> Add support to set voltage/current of various regulators
> to power up/down Bluetooth chip wcn3990.
>
> Signed-off-by: Balakrishna Godavarthi <bgodavar@codeaurora.org>
> ---
> changes in v10:
> * added support to read regulator currents from dts.
I commented on this below
> * added support to try to connect with chip if it fails to respond to initial commands
> * updated review comments.
>
> changes in v9:
> * moved flow control to vendor and set_baudarte functions.
> * removed parent regs.
>
> changes in v8:
> * closing qca buffer, if qca_power_setup fails
> * chnaged ibs start timer function call location.
> * updated review comments.
>
> changes in v7:
> * addressed review comments.
>
> changes in v6:
> * Hooked up qca_power to qca_serdev.
> * renamed all the naming inconsistency functions with qca_*
> * leveraged common code of ROME for wcn3990.
> * created wrapper functions for re-usable blocks.
> * updated function of _*regulator_enable and _*regualtor_disable.
> * removed redundant comments and functions.
> * addressed review comments.
>
> Changes in v5:
> * updated regulator vddpa min_uV to 1304000.
> * addressed review comments.
>
> Changes in v4:
> * Segregated the changes of btqca from hci_qca
> * rebased all changes on top of bluetooth-next.
> * addressed review comments.
>
> ---
> drivers/bluetooth/btqca.h | 4 +
> drivers/bluetooth/hci_qca.c | 481 ++++++++++++++++++++++++++++++++----
> 2 files changed, 439 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/bluetooth/btqca.h b/drivers/bluetooth/btqca.h
> index a9c2779f3e07..9e2bbcf5c002 100644
> --- a/drivers/bluetooth/btqca.h
> +++ b/drivers/bluetooth/btqca.h
> @@ -37,6 +37,10 @@
> #define EDL_TAG_ID_HCI (17)
> #define EDL_TAG_ID_DEEP_SLEEP (27)
>
> +#define QCA_WCN3990_POWERON_PULSE 0xFC
> +#define QCA_WCN3990_POWEROFF_PULSE 0xC0
> +#define QCA_WCN3990_FORCE_BOOT_PULSE 0xC0
This is the same value as QCA_WCN3990_POWEROFF_PULSE. From the usage
it seems it's really just a power off pulse, so let's stick to this
name, instead of having two names for the same thing.
> +static int qca_send_vendor_pulse(struct hci_dev *hdev, u8 cmd)
My understanding from earlier discussion is that these pulses are
limited to power on/off. If that is correct this should probably be
called qca_send_power_pulse().
> +{
> + struct hci_uart *hu = hci_get_drvdata(hdev);
> + struct qca_data *qca = hu->priv;
> + struct sk_buff *skb;
> +
> + /* These vendor pulses are single byte command which are sent
> + * at required baudrate to WCN3990. on WCN3990, we have an external
s/on/On/
> + * circuit at Tx pin which decodes the pulse sent at specific baudrate.
> + * For example, as WCN3990 supports RF COEX frequency for both Wi-Fi/BT
> + * and also, we use the same power inputs to turn ON and OFF for
nit: not sure how much value is added by (sometimes) using upper case
for certain things (ON, OFF, COLD, HOST, ...).
> + * Wi-Fi/BT. Powering up the power sources will not enable BT, until
> + * we send a POWER ON pulse at 115200. This algorithm will help to
115200 what? bps I guess.
> +static int qca_wcn3990_init(struct hci_uart *hu, u32 *soc_ver)
> +{
> + struct hci_dev *hdev = hu->hdev;
> + int i, ret = 1;
Initialization not necessary, more details below.
> +
> + /* WCN3990 is a discrete Bluetooth chip connected to APPS processor.
APPS is a Qualcomm specific term, and some QCA docs also call it
APSS. Just say 'SoC' which is universally understood.
> + * sometimes we will face communication synchronization issues,
> + * like reading version command timeouts. In which HCI_SETUP fails,
> + * to overcome these issues, we try to communicate by performing an
> + * COLD power OFF and ON.
> + */
> + for (i = 1; i <= 10 && ret; i++) {
Is it really that bad that more than say 3 iterations might be needed?
Common practice is to start loops with index 0.
The check for ret is not needed. All jumps to 'regs_off' are done
when an error is detected. The loop is left when 'ret == 0' at the
bottom.
> + /* This helper will turn ON chip if it is powered off.
> + * if the chip is already powered ON, function call will
> + * return zero.
> + */
Comments are great when they add value, IMO this one doesn't and just
adds distraction. Most readers will assume that after
qca_power_setup(hu, true) the chip is powered on, regardless of the
previous power state.
> + ret = qca_power_setup(hu, true);
> + if (ret)
> + goto regs_off;
> +
> + /* Forcefully enable wcn3990 to enter in to boot mode. */
nit: Sometimes the comments and logs name the chip wcn3990, others
WCN3990. Personally I don't care which spelling is used, but please be
consistent.
> + host_set_baudrate(hu, 2400);
> + ret = qca_send_vendor_pulse(hdev, QCA_WCN3990_FORCE_BOOT_PULSE);
> + if (ret)
> + goto regs_off;
> +
> + qca_set_speed(hu, QCA_INIT_SPEED);
> + ret = qca_send_vendor_pulse(hdev, QCA_WCN3990_POWERON_PULSE);
> + if (ret)
> + goto regs_off;
> +
> + /* Wait for 100 ms for SoC to boot */
> + msleep(100);
> +
> + /* Now the device is in ready state to communicate with host.
> + * To sync HOST with device we need to reopen port.
> + * Without this, we will have RTS and CTS synchronization
> + * issues.
> + */
> + serdev_device_close(hu->serdev);
> + ret = serdev_device_open(hu->serdev);
> + if (ret) {
> + bt_dev_err(hu->hdev, "failed to open port");
> + break;
> + }
> +
> + hci_uart_set_flow_control(hu, false);
> + ret = qca_read_soc_version(hdev, soc_ver);
> + if (ret < 0 || soc_ver == 0)
> + bt_dev_err(hdev, "Failed to get version:%d", ret);
The check for soc_ver is/should be done in qca_read_soc_version(),
same for the error log.
> + if (!ret)
> + break;
> +
> +regs_off:
> + bt_dev_err(hdev, "retrying to establish communication: %d", i);
Use i + 1 if starting the loop at 0.
> +static const struct qca_vreg_data qca_soc_data = {
> + .soc_type = QCA_WCN3990,
> + .vregs = (struct qca_vreg []) {
> + { "vddio", 1800000, 1800000, 15000 },
> + { "vddxo", 1800000, 1800000, 80000 },
> + { "vddrf", 1304000, 1304000, 300000 },
> + { "vddch0", 3000000, 3312000, 450000 },
> + },
The currents of 300mA and 450mA seem high for Bluetooth, I'm not an
expert in this area though, they might be reasonable peak currents for
certain use cases.
> +static int qca_power_shutdown(struct hci_dev *hdev)
> +{
> + struct hci_uart *hu = hci_get_drvdata(hdev);
> +
> + host_set_baudrate(hu, 2400);
> + qca_send_vendor_pulse(hdev, QCA_WCN3990_POWEROFF_PULSE);
> + return qca_power_setup(hu, false);
> +}
The return value changed from void to int, but nobody ever checks it ...
> +static void qca_regulator_get_current(struct device *dev,
> + struct qca_vreg *vregs)
> +{
> + char prop_name[32]; /* 32 is max size of property name */
> +
> + /* We have different platforms where the load value is controlled
> + * via PMIC controllers. In such cases load required to power ON
> + * Bluetooth chips are defined in the PMIC. We have option to set
> + * operation mode like high or low power modes.
> + * We do have some platforms where driver need to enable the load for
> + * WCN3990. Based on the current property value defined for the
> + * regulators, driver will decide the regulator output load.
> + * If the current property for the regulator is defined in the dts
> + * we will read from dts tree, else from the default load values.
> + */
Let's make sure we all really understand why this is needed. You
mentioned RPMh regulators earlier and said a special value of 1uA
would be needed to enable high power mode. Later when I pointed to the
RPMh regulator code you agreed that this special value wouldn't make
any difference.
Now the defaults are higher:
> + { "vddio", 1800000, 1800000, 15000 },
> + { "vddxo", 1800000, 1800000, 80000 },
> + { "vddrf", 1304000, 1304000, 300000 },
> + { "vddch0", 3000000, 3312000, 450000 },
What would supposedly go wrong if these values were passed to one of
the PMICs you are concerned about? Please be more specific than the
above comment.
> + snprintf(prop_name, 32, "%s-current", vregs->name);
> + BT_DBG("Looking up %s from device tree\n", prop_name);
'\n' not needed with BT_DBG()
> +
> + if (device_property_read_bool(dev, prop_name))
> + device_property_read_u32(dev, prop_name, &vregs->load_uA);
Why device_property_read_bool()?
> + BT_DBG("current %duA selected for regulator %s", vregs->load_uA,
> + vregs->name);
> +}
> +
> +static int qca_init_regulators(struct qca_power *qca,
> + const struct qca_vreg_data *data)
> +{
> + int i, num_vregs;
> + int load_uA;
> +
> + num_vregs = data->num_vregs;
> + qca->vreg_bulk = devm_kzalloc(qca->dev, num_vregs *
> + sizeof(struct regulator_bulk_data),
> + GFP_KERNEL);
> + if (!qca->vreg_bulk)
> + return -ENOMEM;
> +
> + qca->vreg_data = devm_kzalloc(qca->dev, sizeof(struct qca_vreg_data),
> + GFP_KERNEL);
> + if (!qca->vreg_data)
> + return -ENOMEM;
> +
> + qca->vreg_data->num_vregs = data->num_vregs;
> + qca->vreg_data->soc_type = data->soc_type;
> +
> + qca->vreg_data->vregs = devm_kzalloc(qca->dev, num_vregs *
> + sizeof(struct qca_vreg_data),
sizeof(struct qca_vreg)
> + GFP_KERNEL);
> +
> + if (!qca->vreg_data->vregs)
> + return -ENOMEM;
> +
> + for (i = 0; i < num_vregs; i++) {
> + /* copy regulator name, min voltage, max voltage */
> + qca->vreg_data->vregs[i].name = data->vregs[i].name;
> + qca->vreg_data->vregs[i].min_uV = data->vregs[i].min_uV;
> + qca->vreg_data->vregs[i].max_uV = data->vregs[i].max_uV;
> + load_uA = data->vregs[i].load_uA;
> + qca->vreg_data->vregs[i].load_uA = load_uA;
memcpy(&qca->vreg_data->vregs[i], &data->vregs[i]); ?
Or do it outside of the loop for all regulators at once.
> static int qca_serdev_probe(struct serdev_device *serdev)
> {
> struct qca_serdev *qcadev;
> + const struct qca_vreg_data *data;
> int err;
>
> qcadev = devm_kzalloc(&serdev->dev, sizeof(*qcadev), GFP_KERNEL);
> @@ -1069,47 +1418,87 @@ static int qca_serdev_probe(struct serdev_device *serdev)
> return -ENOMEM;
>
> qcadev->serdev_hu.serdev = serdev;
> + data = of_device_get_match_data(&serdev->dev);
> serdev_device_set_drvdata(serdev, qcadev);
> + if (data && data->soc_type == QCA_WCN3990) {
> + qcadev->btsoc_type = QCA_WCN3990;
> + qcadev->bt_power = devm_kzalloc(&serdev->dev,
> + sizeof(struct qca_power),
> + GFP_KERNEL);
> + if (!qcadev->bt_power)
> + return -ENOMEM;
> +
> + qcadev->bt_power->dev = &serdev->dev;
> + err = qca_init_regulators(qcadev->bt_power, data);
> + if (err) {
> + BT_ERR("Failed to init regulators:%d", err);
> + goto out;
> + }
>
> - qcadev->bt_en = devm_gpiod_get(&serdev->dev, "enable",
> - GPIOD_OUT_LOW);
> - if (IS_ERR(qcadev->bt_en)) {
> - dev_err(&serdev->dev, "failed to acquire enable gpio\n");
> - return PTR_ERR(qcadev->bt_en);
> - }
> + qcadev->bt_power->vregs_on = false;
>
> - qcadev->susclk = devm_clk_get(&serdev->dev, NULL);
> - if (IS_ERR(qcadev->susclk)) {
> - dev_err(&serdev->dev, "failed to acquire clk\n");
> - return PTR_ERR(qcadev->susclk);
> - }
> + /* Read max speed supported by wcn3990 from dts
> + * tree. if max-speed property is not enabled in
> + * dts, QCA driver will use default operating speed
> + * from proto structure.
> + */
The comment doesn't add much value.
> + device_property_read_u32(&serdev->dev, "max-speed",
> + &qcadev->oper_speed);
> + if (!qcadev->oper_speed)
> + BT_INFO("UART will pick default operating speed");
Not a change in this version, but BT_INFO seems a bit verbose, we
should avoid spamming the kernel log.
^ permalink raw reply
* Re: [PATCH] [meta-cloud-services][patch]：tgt:1.0.67 -> 1.0.73
From: Bruce Ashfield @ 2018-07-23 19:53 UTC (permalink / raw)
To: Hong Liu; +Cc: meta-virtualization
In-Reply-To: <20180723090011.11902-2-hongl.fnst@cn.fujitsu.com>
merged.
Bruce
On Mon, Jul 23, 2018 at 5:00 AM, Hong Liu <hongl.fnst@cn.fujitsu.com> wrote:
> Upgrade tgt from 1.0.67 to 1.0.73
>
> Signed-off-by: Hong Liu <hongl.fnst@cn.fujitsu.com>
> ---
> meta-openstack/recipes-support/tgt/tgt_git.bb | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta-openstack/recipes-support/tgt/tgt_git.bb b/meta-openstack/recipes-support/tgt/tgt_git.bb
> index 9ca181a..f4e12da 100644
> --- a/meta-openstack/recipes-support/tgt/tgt_git.bb
> +++ b/meta-openstack/recipes-support/tgt/tgt_git.bb
> @@ -4,8 +4,8 @@ LICENSE = "GPLv2"
> LIC_FILES_CHKSUM = "file://scripts/tgtd.spec;beginline=7;endline=7;md5=21c19ea7dad04648b9c2f791b6e29b4c"
> DEPENDS = "sg3-utils"
>
> -SRCREV = "cb7971cfeecaa43c15eed4719dc82516d7e87b6c"
> -PV = "1.0.67+git${SRCPV}"
> +SRCREV = "013223dc886a03719ca02db52162056249d99448"
> +PV = "1.0.73+git${SRCPV}"
>
> SRC_URI = "git://github.com/fujita/tgt.git \
> file://0001-Correct-the-path-of-header-files-check-in-Yocto-buil.patch \
> --
> 2.7.4
>
>
>
> --
> _______________________________________________
> meta-virtualization mailing list
> meta-virtualization@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-virtualization
--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
^ permalink raw reply
* Re: [PATCH] [meta-cloud-services][patch]:python-sphinx:1.4.1->1.7.6
From: Bruce Ashfield @ 2018-07-23 19:53 UTC (permalink / raw)
To: Hong Liu; +Cc: meta-virtualization
In-Reply-To: <20180723090011.11902-1-hongl.fnst@cn.fujitsu.com>
merged
Bruce
On Mon, Jul 23, 2018 at 5:00 AM, Hong Liu <hongl.fnst@cn.fujitsu.com> wrote:
> 1.Upgrade python-sphinx from 1.4.1 to 1.7.6.
>
> 2.Modify LIC_FILES_CHKSUM,because of delete "PYTHON SOFTWARE FOUNDATION LICENSE VERSION 2"
>
> Signed-off-by: Hong Liu <hongl.fnst@cn.fujitsu.com>
> ---
> recipes-devtools/python/python-sphinx_1.4.1.bb | 12 ------------
> recipes-devtools/python/python-sphinx_1.7.6.bb | 12 ++++++++++++
> 2 files changed, 12 insertions(+), 12 deletions(-)
> delete mode 100644 recipes-devtools/python/python-sphinx_1.4.1.bb
> create mode 100644 recipes-devtools/python/python-sphinx_1.7.6.bb
>
> diff --git a/recipes-devtools/python/python-sphinx_1.4.1.bb b/recipes-devtools/python/python-sphinx_1.4.1.bb
> deleted file mode 100644
> index 476ff97..0000000
> --- a/recipes-devtools/python/python-sphinx_1.4.1.bb
> +++ /dev/null
> @@ -1,12 +0,0 @@
> -DESCRIPTION = "Python documentation generator"
> -HOMEPAGE = "http://sphinx-doc.org/"
> -SECTION = "devel/python"
> -LICENSE = "BSD"
> -LIC_FILES_CHKSUM = "file://LICENSE;md5=72f034adc6f7b05b09bc00d1a05bb065"
> -
> -PYPI_PACKAGE = "Sphinx"
> -
> -SRC_URI[md5sum] = "4c4988e0306a04cef8dccc384281e585"
> -SRC_URI[sha256sum] = "c6871a784d24aba9270b6b28541537a57e2fcf4d7c799410eba18236bc76d6bc"
> -
> -inherit setuptools pypi
> diff --git a/recipes-devtools/python/python-sphinx_1.7.6.bb b/recipes-devtools/python/python-sphinx_1.7.6.bb
> new file mode 100644
> index 0000000..0200c9e
> --- /dev/null
> +++ b/recipes-devtools/python/python-sphinx_1.7.6.bb
> @@ -0,0 +1,12 @@
> +DESCRIPTION = "Python documentation generator"
> +HOMEPAGE = "http://sphinx-doc.org/"
> +SECTION = "devel/python"
> +LICENSE = "BSD"
> +LIC_FILES_CHKSUM = "file://LICENSE;md5=89cbefcd0a80481e8b26a9a7d25be749"
> +
> +PYPI_PACKAGE = "Sphinx"
> +
> +SRC_URI[md5sum] = "8fbd77d80c8e0966964751ab31a0204a"
> +SRC_URI[sha256sum] = "217ad9ece2156ed9f8af12b5d2c82a499ddf2c70a33c5f81864a08d8c67b9efc"
> +
> +inherit setuptools pypi
> --
> 2.7.4
>
>
>
> --
> _______________________________________________
> meta-virtualization mailing list
> meta-virtualization@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-virtualization
--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
^ permalink raw reply
* Re: [PATCH 3/5] drm/amdgpu: enable system interrupt for jrbc
From: Boyuan Zhang @ 2018-07-23 19:53 UTC (permalink / raw)
To: Alex Deucher, Boyuan Zhang; +Cc: amd-gfx list
In-Reply-To: <CADnq5_NFgHpv4Z_2scvRC8y6EYPqUtnsvGXF6g2mD4yEKuQGOw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 2018-07-19 02:51 PM, Alex Deucher wrote:
> On Wed, Jul 18, 2018 at 4:39 PM, <boyuan.zhang@amd.com> wrote:
>> From: Boyuan Zhang <boyuan.zhang@amd.com>
>>
>> Enable system interrupt for jrbc during engine starting time.
>>
>> Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
>> ---
>> drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 8 +++++++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
>> index 4fccb21..22c1588 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
>> @@ -595,6 +595,7 @@ static int vcn_v1_0_start(struct amdgpu_device *adev)
>> struct amdgpu_ring *ring = &adev->vcn.ring_dec;
>> uint32_t rb_bufsz, tmp;
>> uint32_t lmi_swap_cntl;
>> + uint32_t reg_temp;
>> int i, j, r;
>>
>> /* disable byte swapping */
>> @@ -700,6 +701,11 @@ static int vcn_v1_0_start(struct amdgpu_device *adev)
>> (UVD_MASTINT_EN__VCPU_EN_MASK|UVD_MASTINT_EN__SYS_EN_MASK),
>> ~(UVD_MASTINT_EN__VCPU_EN_MASK|UVD_MASTINT_EN__SYS_EN_MASK));
>>
>> + /* enable system interrupt for JRBC*/
>> + reg_temp = RREG32(SOC15_REG_OFFSET(UVD, 0, mmUVD_SYS_INT_EN));
>> + reg_temp |= UVD_SYS_INT_EN__UVD_JRBC_EN_MASK;
>> + WREG32(SOC15_REG_OFFSET(UVD, 0, mmUVD_SYS_INT_EN), reg_temp);
>> +
> Shouldn't we move the setting of these interrupts into
> vcn_v1_0_set_interrupt_state()? Same for the mastint. that way they
> will get enabled/disabled as part of the fence driver sequence I
> think. Or do they need to happen in a specific sequence?
>
> Alex
Hmm... at least for this JPEG specific case, interrupt won't be raised
during those times that we don't care about the interrupt. This is not
like other system component where interrupt might still be raised even
if we don't care about it. So my feeling is that whether we disable it
at the beginning and enable it later on, or we just enable it at the
beginning doesn't really matter in the practical sense.
Regards,
Boyuan
>
>> /* clear the bit 4 of VCN_STATUS */
>> WREG32_P(SOC15_REG_OFFSET(UVD, 0, mmUVD_STATUS), 0,
>> ~(2 << UVD_STATUS__VCPU_REPORT__SHIFT));
>> @@ -1754,7 +1760,7 @@ static const struct amdgpu_irq_src_funcs vcn_v1_0_irq_funcs = {
>>
>> static void vcn_v1_0_set_irq_funcs(struct amdgpu_device *adev)
>> {
>> - adev->vcn.irq.num_types = adev->vcn.num_enc_rings + 1;
>> + adev->vcn.irq.num_types = adev->vcn.num_enc_rings + 2;
>> adev->vcn.irq.funcs = &vcn_v1_0_irq_funcs;
>> }
>>
>> --
>> 2.7.4
>>
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* Re: [PATCH 1/4] kubernetes: explicitly build for $TARGET_ARCH
From: Bruce Ashfield @ 2018-07-23 19:51 UTC (permalink / raw)
To: Koen Kooi; +Cc: Raymond Danks, meta-virtualization, Koen Kooi
In-Reply-To: <20180723144850.17279-1-koen.kooi@linaro.org>
I had to add a QA skip for PN-misc, since in my config it was throwing
a GNU_HASH error.
This is now pushed, thanks for the cleanups.
Cheers,
Bruce
On Mon, Jul 23, 2018 at 10:48 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> 'make all' uses 'uname' to select the build target, leading to compile failures like this:
>
> | arm-angstrom-linux-gnueabi-gcc: error: unrecognized command line option '-m64'
>
> After providing the proper arch to the makefile it will try to use a hardcoded compiler:
>
> | # runtime/cgo
> | exec: "arm-linux-gnueabihf-gcc": executable file not found in $PATH
>
> Fix that up by removing all hardcoded 'CC' entries in golang.sh
>
> Signed-off-by: Koen Kooi <koen.kooi@linaro.org>
> ---
> ...ack-lib-golang.sh-use-CC-from-environment.patch | 40 ++++++++++++++++++++++
> recipes-containers/kubernetes/kubernetes_git.bb | 6 ++--
> 2 files changed, 44 insertions(+), 2 deletions(-)
> create mode 100644 recipes-containers/kubernetes/kubernetes/0001-hack-lib-golang.sh-use-CC-from-environment.patch
>
> diff --git a/recipes-containers/kubernetes/kubernetes/0001-hack-lib-golang.sh-use-CC-from-environment.patch b/recipes-containers/kubernetes/kubernetes/0001-hack-lib-golang.sh-use-CC-from-environment.patch
> new file mode 100644
> index 0000000..62d0521
> --- /dev/null
> +++ b/recipes-containers/kubernetes/kubernetes/0001-hack-lib-golang.sh-use-CC-from-environment.patch
> @@ -0,0 +1,40 @@
> +From 9cbb2d523d481053d405ebac830c2074b00d3417 Mon Sep 17 00:00:00 2001
> +From: Koen Kooi <koen.kooi@linaro.org>
> +Date: Mon, 23 Jul 2018 15:28:02 +0200
> +Subject: [PATCH] hack/lib/golang.sh: use CC from environment
> +
> +Toolchain tupples differs, especially when using vendor provides ones.
> +
> +Upstream-status: Inappropriate [embedded specific]
> +Signed-off-by: Koen Kooi <koen.kooi@linaro.org>
> +---
> + hack/lib/golang.sh | 4 ----
> + 1 file changed, 4 deletions(-)
> +
> +diff --git a/hack/lib/golang.sh b/hack/lib/golang.sh
> +index c5d4634..563e2b4b 100755
> +--- a/src/import/hack/lib/golang.sh
> ++++ b/src/import/hack/lib/golang.sh
> +@@ -278,19 +278,15 @@ kube::golang::set_platform_envs() {
> + case "${platform}" in
> + "linux/arm")
> + export CGO_ENABLED=1
> +- export CC=arm-linux-gnueabihf-gcc
> + ;;
> + "linux/arm64")
> + export CGO_ENABLED=1
> +- export CC=aarch64-linux-gnu-gcc
> + ;;
> + "linux/ppc64le")
> + export CGO_ENABLED=1
> +- export CC=powerpc64le-linux-gnu-gcc
> + ;;
> + "linux/s390x")
> + export CGO_ENABLED=1
> +- export CC=s390x-linux-gnu-gcc
> + ;;
> + esac
> + fi
> +--
> +2.9.5
> +
> diff --git a/recipes-containers/kubernetes/kubernetes_git.bb b/recipes-containers/kubernetes/kubernetes_git.bb
> index 10558ef..33cb933 100644
> --- a/recipes-containers/kubernetes/kubernetes_git.bb
> +++ b/recipes-containers/kubernetes/kubernetes_git.bb
> @@ -7,6 +7,7 @@ maintenance, and scaling of applications. \
>
> SRCREV_kubernetes = "210c9cd7e1782e9fe46938fe0368556f2166a528"
> SRC_URI = "git://github.com/kubernetes/kubernetes.git;branch=release-1.11;name=kubernetes \
> + file://0001-hack-lib-golang.sh-use-CC-from-environment.patch \
> "
>
> DEPENDS += "rsync-native \
> @@ -46,6 +47,7 @@ inherit goarch
>
> do_compile() {
> export GOARCH="${TARGET_GOARCH}"
> + export GOOS="${TARGET_GOOS}"
> export GOROOT="${STAGING_LIBDIR_NATIVE}/${TARGET_SYS}/go"
> export GOPATH="${S}/src/import:${S}/src/import/vendor"
>
> @@ -72,7 +74,7 @@ do_compile() {
>
> cd ${S}/src/import
> # to limit what is built, use 'WHAT', i.e. make WHAT=cmd/kubelet
> - make all
> + make cross KUBE_BUILD_PLATFORMS=${GOOS}/${GOARCH}
> }
>
> do_install() {
> @@ -82,7 +84,7 @@ do_install() {
>
> install -d ${D}${sysconfdir}/kubernetes/manifests/
>
> - install -m 755 -D ${S}/src/import/_output/bin/kube* ${D}/${bindir}
> + install -m 755 -D ${S}/src/import/_output/local/bin/${TARGET_GOOS}/${TARGET_GOARCH}/* ${D}/${bindir}
>
> install -m 0644 ${S}/src/import/build/debs/kubelet.service ${D}${systemd_unitdir}/system/
> install -m 0644 ${S}/src/import/build/debs/10-kubeadm.conf ${D}${systemd_unitdir}/system/kubelet.service.d/
> --
> 2.9.5
>
--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
^ permalink raw reply
* ✓ Fi.CI.BAT: success for drm/i915/icl: Add DSS_CTL Registers
From: Patchwork @ 2018-07-23 19:50 UTC (permalink / raw)
To: Anusha Srivatsa; +Cc: intel-gfx
In-Reply-To: <1532373080-8962-1-git-send-email-anusha.srivatsa@intel.com>
== Series Details ==
Series: drm/i915/icl: Add DSS_CTL Registers
URL : https://patchwork.freedesktop.org/series/47082/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4530 -> Patchwork_9750 =
== Summary - SUCCESS ==
No regressions found.
External URL: https://patchwork.freedesktop.org/api/1.0/series/47082/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_9750 that come from known issues:
=== IGT changes ===
==== Issues hit ====
igt@drv_selftest@live_workarounds:
fi-kbl-7560u: PASS -> DMESG-FAIL (fdo#107292)
igt@gem_exec_suspend@basic-s4-devices:
fi-glk-j4005: PASS -> DMESG-WARN (fdo#106097)
igt@kms_chamelium@dp-crc-fast:
fi-kbl-7500u: PASS -> DMESG-FAIL (fdo#103841)
igt@kms_flip@basic-flip-vs-wf_vblank:
fi-glk-j4005: PASS -> FAIL (fdo#100368)
==== Possible fixes ====
igt@debugfs_test@read_all_entries:
fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS
igt@drv_selftest@live_workarounds:
fi-skl-6700hq: DMESG-FAIL (fdo#107292) -> PASS
igt@gem_exec_suspend@basic-s3:
fi-glk-j4005: DMESG-WARN (fdo#106097) -> PASS
igt@kms_chamelium@dp-edid-read:
fi-kbl-7500u: FAIL (fdo#103841) -> PASS
igt@kms_flip@basic-flip-vs-wf_vblank:
fi-glk-dsi: FAIL (fdo#100368) -> PASS
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097
fdo#107292 https://bugs.freedesktop.org/show_bug.cgi?id=107292
== Participating hosts (50 -> 43) ==
Missing (7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-skl-caroline fi-byt-clapper
== Build changes ==
* Linux: CI_DRM_4530 -> Patchwork_9750
CI_DRM_4530: d27cc4a37a5cc1ef14a3aafdcb6682e5f6a85d09 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_4571: 65fccc149b85968cdce4737266b056059c1510f3 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9750: 5f0003a0e20267007302ae46a29a033798e7a419 @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
5f0003a0e202 drm/i915/icl: Add DSS_CTL Registers
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9750/issues.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* IETF RFC 8276 - File System Extended Attributes in NFSv4
From: Marc Eshel @ 2018-07-23 18:45 UTC (permalink / raw)
To: Bruce Fields
Cc: Libtirpc-devel Mailing List, Linux NFS Mailing list,
linux-nfs-owner
In-Reply-To: <OFA232E502.EADD3A82-ON882582D3.00667F9D-882582D3.0066E08D@LocalDomain>
Hi Bruce,
Do you know of any plans to add IETF RFC 8276 - File System Extended
Attributes in NFSv4 to the Linux NFS Client or Server?
Marc.
^ permalink raw reply
* Re: [PATCH 1/9] contrib: add a script to initialize VS Code configuration
From: Junio C Hamano @ 2018-07-23 19:48 UTC (permalink / raw)
To: Johannes Schindelin via GitGitGadget; +Cc: git, Johannes Schindelin
In-Reply-To: <e2e449a00385531d326d6811a871dde59624b818.1532353966.git.gitgitgadget@gmail.com>
"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:
> diff --git a/contrib/vscode/init.sh b/contrib/vscode/init.sh
> new file mode 100755
> index 000000000..3cc93243f
> --- /dev/null
> +++ b/contrib/vscode/init.sh
> @@ -0,0 +1,165 @@
> +#!/bin/sh
This is caued by our usual "git apply --whitespace=warn" as it
contains lines indented by spaces not tabs (perhaps the json
literals?) Can we have contrib/vscode/.gitattributes to tweak the
whitespace breakage checking rules so that this file is excempt?
I'll just shut my eyes while applying this series for today, though
;-)
^ permalink raw reply
* Re: [PATCH bpf] bpf: btf: Ensure the member->offset is in the right order
From: Yonghong Song @ 2018-07-23 18:45 UTC (permalink / raw)
To: Martin KaFai Lau, netdev; +Cc: Alexei Starovoitov, Daniel Borkmann, kernel-team
In-Reply-To: <20180721003837.2772516-1-kafai@fb.com>
On 7/20/18 5:38 PM, Martin KaFai Lau wrote:
> This patch ensures the member->offset of a struct
> is in the correct order (i.e the later member's offset cannot
> go backward).
>
> The current "pahole -J" BTF encoder does not generate something
> like this. However, checking this can ensure future encoder
> will not violate this.
>
> Fixes: 69b693f0aefa ("bpf: btf: Introduce BPF Type Format (BTF)")
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Acked-by: Yonghong Song <yhs@fb.com>
^ permalink raw reply
* Re: [PATCH 06/14] format-patch: allow --interdiff to apply to a lone-patch
From: Eric Sunshine @ 2018-07-23 19:46 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: Git List, Johannes Schindelin,
Ævar Arnfjörð Bjarmason, Stefan Beller
In-Reply-To: <CACsJy8Aw6R8-3kDfhCqunXziajCg9O_1WrEYc4rfKa+-=m1D5g@mail.gmail.com>
On Mon, Jul 23, 2018 at 12:22 PM Duy Nguyen <pclouds@gmail.com> wrote:
> On Sun, Jul 22, 2018 at 11:58 AM Eric Sunshine <sunshine@sunshineco.com> wrote:
> > + if (cmit_fmt_is_mail(ctx.fmt) && opt->idiff_oid1) {
>
> OK putting idiff stuff in rev_info is probably the right choice. But
> we all three fields prefixed with idiff_, maybe you could just add a
> new struct "idiff_options" to contain them and add a pointer to that
> struct in rev_info. Then "opt->idiff" is enough to know if idiff is
> requested instead of relying on idiff_oid1 (seems too random).
I have mixed feelings about this suggestion for the following reasons:
* 'struct rev_info' already contains a number of specialized fields
which apply in only certain use cases but not others, and those fields
often are grouped textually to show relationship rather than being
bundled in a struct.
* These new fields are very specific to this particular operation and
are unlikely to ever have wider use, so adding the extra level of
indirection/abstraction (whatever you'd call it) feels overkill and,
while nice theoretically, adds complexity without much practical
value.
* Bundling these fields in a struct might incorrectly imply to readers
that these items, collectively, can be used in some general-purpose
fashion, which isn't at all the case; they are very specific to this
operation and that struct would never be used elsewhere or for any
other purpose.
The upside of bundling them in a struct, as you mention, is that
"opt->idiff" would be slightly more obvious than "opt->idiff_oid1" as
a "should we print an interdiff?" conditional. On the other hand, this
case is so specific and narrow that I'm not sure it warrants such
generality.
^ 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.