* Re: Reg. rpm changelog
From: Burton, Ross @ 2018-07-23 18:49 UTC (permalink / raw)
To: Vikram Chhibber; +Cc: Yocto-mailing-list
In-Reply-To: <CALBAsRwS7cEcx1mp3GGx4vWeLzjW7i0MNcN-aO0o+Mog3xbdYQ@mail.gmail.com>
On 23 July 2018 at 18:30, Vikram Chhibber <vikram.chhibber@gmail.com> wrote:
> Thanks Mark. Is it possible to somehow use already created changelog while
> building rpm?
You mean that you'll maintain an independent changelog but want it to
be in the RPM?
Ross
^ permalink raw reply
* [linux-3.18 test] 125505: regressions - FAIL
From: osstest service owner @ 2018-07-23 18:49 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 125505 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125505/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 125138
test-amd64-i386-libvirt-xsm 18 guest-start/debian.repeat fail REGR. vs. 125138
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125138
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125138
test-amd64-amd64-xl-xsm 10 debian-install fail REGR. vs. 125138
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 7 xen-boot fail REGR. vs. 125138
Tests which did not succeed, but are not blocking:
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-arm64-arm64-xl 1 build-check(1) blocked n/a
test-arm64-arm64-examine 1 build-check(1) blocked n/a
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-armhf-armhf-libvirt 14 saverestore-support-check fail like 125138
test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail like 125138
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 125138
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 125138
test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 125138
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125138
test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125138
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass
test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass
test-amd64-i386-xl-pvshim 12 guest-start fail never pass
test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-i386-libvirt 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt 13 migrate-support-check fail never pass
test-amd64-i386-libvirt-xsm 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-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass
test-armhf-armhf-libvirt 13 migrate-support-check fail never pass
test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass
build-arm64-pvops 6 kernel-build fail never pass
test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass
test-amd64-amd64-libvirt-vhd 12 migrate-support-check 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
test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 14 saverestore-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-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass
test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass
test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install fail never pass
test-amd64-amd64-xl-qemut-win10-i386 10 windows-install fail never pass
test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
version targeted for testing:
linux 7612025fbc7a5ab54bf71f48b99b0b6a15fc7b06
baseline version:
linux ac35b66883e8330ffde609152e13c225b12de6a4
Last test of basis 125138 2018-07-12 16:49:01 Z 11 days
Testing same since 125505 2018-07-22 12:11:31 Z 1 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Alex Vesker <valex@mellanox.com>
Amit Pundir <amit.pundir@linaro.org>
Andreas Schwab <schwab@linux-m68k.org>
Christian Lamparter <chunkeey@googlemail.com>
Dan Carpenter <dan.carpenter@oracle.com>
David S. Miller <davem@davemloft.net>
Eric Biggers <ebiggers@google.com>
Eric Dumazet <edumazet@google.com>
Florian Westphal <fw@strlen.de>
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Herbert Xu <herbert@gondor.apana.org.au>
Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Jann Horn <jannh@google.com>
Jason Gunthorpe <jgg@mellanox.com>
Jason Wang <jasowang@redhat.com>
Jens Axboe <axboe@kernel.dk>
Johan Hovold <johan@kernel.org>
Jonas Gorski <jonas.gorski@gmail.com>
Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Leon Romanovsky <leonro@mellanox.com>
Linus Torvalds <torvalds@linux-foundation.org>
Neal Cardwell <ncardwell@google.com>
Nico Sneck <snecknico@gmail.com>
Pablo Neira Ayuso <pablo@netfilter.org>
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Saeed Mahameed <saeedm@mellanox.com>
Santosh Shilimkar <santosh.shilimkar@oracle.com>
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Theodore Ts'o <tytso@mit.edu>
Yuchung Cheng <ycheng@google.com>
jobs:
build-amd64-xsm pass
build-arm64-xsm pass
build-i386-xsm 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-pvops pass
build-arm64-pvops fail
build-armhf-pvops pass
build-i386-pvops pass
build-amd64-rumprun pass
build-i386-rumprun 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 fail
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 fail
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm fail
test-amd64-amd64-libvirt-xsm pass
test-arm64-arm64-libvirt-xsm blocked
test-amd64-i386-libvirt-xsm fail
test-amd64-amd64-xl-xsm fail
test-arm64-arm64-xl-xsm blocked
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvhv2-amd fail
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 pass
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 pass
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-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail
test-amd64-amd64-examine pass
test-arm64-arm64-examine blocked
test-armhf-armhf-examine pass
test-amd64-i386-examine 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-amd64-xl-pvhv2-intel fail
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-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-xl-pvshim pass
test-amd64-i386-xl-pvshim fail
test-amd64-amd64-pygrub pass
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw pass
test-amd64-i386-xl-raw pass
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 pass
------------------------------------------------------------
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
Not pushing.
(No revision log; it would be 733 lines long.)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* [Intel-wired-lan] [jkirsher-next-queue:dev-queue] BUILD SUCCESS 4518264e4c304d1e5a8c0dd081fe723430aaaa65
From: kbuild test robot @ 2018-07-23 18:49 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: 4518264e4c304d1e5a8c0dd081fe723430aaaa65 ixgb: use dma_zalloc_coherent instead of allocator/memset
elapsed time: 83m
configs tested: 140
The following configs have been built successfully.
More configs may be tested in the coming days.
alpha defconfig
parisc allnoconfig
parisc b180_defconfig
parisc c3000_defconfig
parisc defconfig
x86_64 allmodconfig
powerpc mpc8560_ads_defconfig
x86_64 randconfig-a0-07232124
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
powerpc mpc5200_defconfig
sh magicpanelr2_defconfig
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
powerpc allnoconfig
powerpc defconfig
powerpc ppc64_defconfig
s390 default_defconfig
i386 randconfig-i0-201829
i386 randconfig-i1-201829
i386 defconfig
arm vf610m4_defconfig
x86_64 randconfig-v0-07232238
c6x evmc6678_defconfig
h8300 h8300h-sim_defconfig
nios2 10m50_defconfig
xtensa common_defconfig
xtensa iss_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
arm pxa3xx_defconfig
ia64 gensparse_defconfig
mips db1xxx_defconfig
sh secureedge5410_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
x86_64 randconfig-i0-201829
sparc defconfig
sparc64 allnoconfig
sparc64 defconfig
powerpc pcm030_defconfig
powerpc tqm8548_defconfig
sh hp6xx_defconfig
microblaze mmu_defconfig
microblaze nommu_defconfig
powerpc ppc6xx_defconfig
powerpc64 allmodconfig
x86_64 randconfig-u0-07240101
s390 performance_defconfig
sh allyesconfig
x86_64 randconfig-ne0-07232115
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
i386 randconfig-sb0-07231305
x86_64 randconfig-ws0-07230849
i386 randconfig-x078-201829
i386 randconfig-x070-201829
i386 randconfig-x075-201829
i386 randconfig-x076-201829
i386 randconfig-x074-201829
i386 randconfig-x079-201829
i386 randconfig-x071-201829
i386 randconfig-x073-201829
i386 randconfig-x072-201829
i386 randconfig-x077-201829
ia64 alldefconfig
ia64 allnoconfig
ia64 defconfig
x86_64 fedora-25
x86_64 kexec
x86_64 rhel
x86_64 rhel-7.2
openrisc or1ksim_defconfig
um i386_defconfig
um x86_64_defconfig
arm shannon_defconfig
mips ip28_defconfig
x86_64 randconfig-r0-07231315
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
i386 alldefconfig
i386 allnoconfig
mips 32r2_defconfig
mips 64r6el_defconfig
mips allnoconfig
mips fuloong2e_defconfig
mips jz4740
mips malta_kvm_defconfig
mips txx9
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [Qemu-devel] [PATCH for-3.0] tests/libqtest: Improve kill_qemu() assert
From: Peter Maydell @ 2018-07-23 18:47 UTC (permalink / raw)
To: qemu-devel
Cc: patches, Richard Henderson, Philippe Mathieu-Daudé,
Alex Bennée, Michael S . Tsirkin
In kill_qemu() we have an assert that checks that the QEMU process
didn't dump core:
assert(!WCOREDUMP(wstatus));
Unfortunately the WCOREDUMP macro here means the resulting message
is not very easy to comprehend on at least some systems:
ahci-test: tests/libqtest.c:113: kill_qemu: Assertion `!(((__extension__ (((union { __typeof(wstatus) __in; int __i; }) { .__in = (wstatus) }).__i))) & 0x80)' failed.
and it doesn't identify what signal the process took.
Instead of using a raw assert, print the information in an
easier to understand way:
/i386/ahci/sanity: tests/libqtest.c:119: kill_qemu() tried to terminate QEMU process but it dumped core with signal 11 (Segmentation fault)
Aborted (core dumped)
(Of course, the really useful information would be why the QEMU
process dumped core in the first place, but we don't have that
by the time the test program has picked up the exit status.)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
changes v1->v2: addressed some of the bikeshedding with:
* print file-and-line in the fprintf message, and then
just abort(), rather than assert(0)
* print the signal name via strsignal() as well
tests/libqtest.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/tests/libqtest.c b/tests/libqtest.c
index 098af6aec44..bfc86a15f4b 100644
--- a/tests/libqtest.c
+++ b/tests/libqtest.c
@@ -110,7 +110,16 @@ static void kill_qemu(QTestState *s)
pid = waitpid(s->qemu_pid, &wstatus, 0);
if (pid == s->qemu_pid && WIFSIGNALED(wstatus)) {
- assert(!WCOREDUMP(wstatus));
+ if (WCOREDUMP(wstatus)) {
+ int sig = WTERMSIG(wstatus);
+ const char *signame = strsignal(sig) ?: "unknown ???";
+
+ fprintf(stderr,
+ "%s:%d: kill_qemu() tried to terminate QEMU "
+ "process but it dumped core with signal %d (%s)\n",
+ __FILE__, __LINE__, sig, signame);
+ abort();
+ }
}
}
}
--
2.17.1
^ permalink raw reply related
* [PATCH v2] rfkill: fix spelling mistake contidion to condition
From: Richard Guy Briggs @ 2018-07-23 18:47 UTC (permalink / raw)
To: netdev; +Cc: Linux-Audit Mailing List, Richard Guy Briggs
This came about while trying to determine if there would be any pattern
match on contid, a new audit container identifier internal variable.
This was the only one.
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
---
net/rfkill/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index a7a4e6f..3aab053 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -508,8 +508,8 @@ void rfkill_remove_epo_lock(void)
/**
* rfkill_is_epo_lock_active - returns true EPO is active
*
- * Returns 0 (false) if there is NOT an active EPO contidion,
- * and 1 (true) if there is an active EPO contition, which
+ * Returns 0 (false) if there is NOT an active EPO condition,
+ * and 1 (true) if there is an active EPO condition, which
* locks all radios in one of the BLOCKED states.
*
* Can be called in atomic context.
--
1.8.3.1
^ permalink raw reply related
* Re: Regression with crc32c selection?
From: Holger Hoffstätte @ 2018-07-23 17:45 UTC (permalink / raw)
To: dsterba, linux-btrfs
In-Reply-To: <20180723165040.GP26141@twin.jikos.cz>
On 07/23/18 18:50, David Sterba wrote:
> On Mon, Jul 23, 2018 at 04:13:26PM +0200, Holger Hoffstätte wrote:
>> While backporting a bunch of fixes to my own 4.16.x tree
>> (4.17 had a few too many bugs for my taste) I also ended up merging:
>
> Curious, bugs in btrfs or the whole 4.17 kernel? And if bugs, real
> breakage or backported fixes?
Overall. I don't remember specifics but skimming lkml at the time
didn't inspire a lot of confidence, and since I already had a large
number of hand-picked & backported patches from 4.17/4.18/4.19 :) for
btrfs, xfs, net, blk-mq & drivers - just the stuff I care about - I skipped
it instead of upgrading & rebasing everything. Might well be that the latest
4.17-stable works reliably, but 4.18 is already around the corner, so..
no really good reason. :)
cheers
Holger
^ permalink raw reply
* Re: [SPDK] Howto build with an external env, i.e. alternate CONFIG_ENV
From: Lance Hartmann ORACLE @ 2018-07-23 18:46 UTC (permalink / raw)
To: spdk
[-- Attachment #1: Type: text/plain, Size: 4633 bytes --]
> On Jul 20, 2018, at 5:17 PM, Walker, Benjamin <benjamin.walker(a)intel.com> wrote:
>
> Hi Lance,
>
> On Fri, 2018-07-20 at 16:34 -0500, Lance Hartmann ORACLE wrote:
>> Another especially notable take-away for me was the realization that the
>> environment library -- I'll refer to the default env for example here,
>> libspdk_env_dpdk.a -- consists only of the objects compiled from
>> SPDK_ROOT_DIR/lib/env_dpdk. With the ability to specify an alternate
>> environment, semantically, I had mistakenly assumed that the env library would
>> contain not only the SPDK implementation of the environment API, but also
>> everything on which it depended; i.e. for the default environment, the DPDK
>> objects. But, that doesn't appear to be so. Instead, when performing final
>> linking of each SPDK executable, not only is the SPDK environment library
>> specified, but so are the necessary DPDK libs on which it depends. Variables
>> pulled in from the SPDK's environment makefile, env.mk, are used to specify
>> those DPDK libs along with additional, special linking flags.
>>
>> We need to update the doc's Porting Guide to reflect these details, and I'd be
>> happy to volunteer to work on that effort.
>
> Please do!
>
>> However, before embarking on that task, I'd like to pose the question: are
>> there reasons why we couldn't or shouldn't produce the environment library to
>> consist of both the SPDK env implementation layer and the objects on which it
>> depends? It would seem that would make final linking of executables a little
>> easier and reduce the complexity/effort of someone wanting to develop and use
>> an alternate environment.
>
> How do you envision this playing with environment libraries that need to link
> against shared libraries, especially ones provided with the system itself? I'm
> not an expert in all of the available linker options, so maybe there is some way
> to embed enough information to properly link/load a shared library directly into
> the static library.
>
This is an area in which I would greatly appreciate additional discussion, weighing the engineering cost/benefits of such flexibility. I, myself, could for example embrace the idea that for the sake of simplifying final linking that we propose the SPDK env implementation is built as a shared library which could be generated with a dependency on the DPDK (or its replaced equivalent) which also be shared lib(s). Alternatively, I could also potentially be persuaded that we take an all static approach, though I hasten to add I can appreciate there may be stakeholders who strongly advocate/need shared libs. I am aware of precedents where a package provided both static and shared versions of their libraries, and sometimes even in separate packages; i.e. a "static" package. So, for greater flexibility, I could also envision a new SPDK configure option enabling the developer to specify static vs. dynamic, and perhaps with the options for the needed linking flags. On the latter, I'm aware per configure that it appears the build of the SPDK can/will honor shell environment variables for CFLAGS, CXXFLAGS, LDFLAGS and DESTDIR, but I don't know how challenging the use of those could be to override (or concatenate) those already figured out in the *mk/Makefile files.
Out of curiosity, I retrieved the available DPDK packages from Ubuntu, and there are quite a few of them, including those with a static and dynamic dpdk library. I haven't dug through all of the SPDK build options, but my initial pass would suggest it's currently built with only static env (and static DPDK) libs, at least for the default configuration.
Taking all of this a step further is the expectation that in the future we will provide two very different ways to build with the SPDK. Today, we're checking out the SPDK repo and relying on the collection of makefiles therein to build the SPDK. But, moving forward, we hope to produce an spdk-devel package(s) so that SPDK app developers could build against it/them. Such a build environment there is outside our purview save for our need to provide the proper contents of those devel package(s).
In summary, I'm seeking, if possible, to simplify the build with respect to the env while keeping in mind the future with -devel package(s). I'm very much hoping to get more input from others in the SPDK community on this topic, and am happy to volunteer on the implementation and documentation thereof once we can form a broader consensus.
thanks much,
--
Lance Hartmann
lance.hartmann(a)oracle.com
[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 7435 bytes --]
^ permalink raw reply
* [PATCH] drm/msm: Replace PTR_RET with PTR_ERR_OR_ZERO
From: Gustavo A. R. Silva @ 2018-07-23 18:46 UTC (permalink / raw)
To: Rob Clark, David Airlie
Cc: linux-arm-msm, dri-devel, freedreno, linux-kernel,
Gustavo A. R. Silva
PTR_RET is deprecated, use PTR_ERR_OR_ZERO instead.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
index 8d907fa..25ddbb8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
@@ -35,7 +35,7 @@ int msm_dss_get_clk(struct device *dev, struct dss_clk *clk_arry, int num_clk)
for (i = 0; i < num_clk; i++) {
clk_arry[i].clk = clk_get(dev, clk_arry[i].clk_name);
- rc = PTR_RET(clk_arry[i].clk);
+ rc = PTR_ERR_OR_ZERO(clk_arry[i].clk);
if (rc) {
DEV_ERR("%pS->%s: '%s' get failed. rc=%d\n",
__builtin_return_address(0), __func__,
--
2.7.4
^ permalink raw reply related
* [rocko/master][PATCH] tidl-utils: SRCREV bump
From: Djordje Senicic @ 2018-07-23 18:46 UTC (permalink / raw)
To: meta-arago; +Cc: d-senicic1, Djordje Senicic
* SRC rev increase to include fixed paths of configuration files
Signed-off-by: Djordje Senicic <x0157990@ti.com>
---
| 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--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..e4fb600 100644
--- a/meta-arago-extras/recipes-ti/tidl-utils/tidl-utils.bb
+++ b/meta-arago-extras/recipes-ti/tidl-utils/tidl-utils.bb
@@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = "file://docs/LICENSE.txt;md5=a93aa5af7a3bbbb6fb34c8df59efaa5c
RDEPENDS_${PN} += " 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
* Re: [PATCH 3/5] coccinelle: exclude sha1dc source files from static analysis
From: SZEDER Gábor @ 2018-07-23 18:43 UTC (permalink / raw)
To: Eric Sunshine
Cc: Junio C Hamano, Git mailing list, René Scharfe,
Derrick Stolee, Nguyễn Thái Ngọc Duy
In-Reply-To: <CAPig+cSOZd+t17j7FSCYAydS34ZtfcRFZyE6E9fz=u7xB-01Mg@mail.gmail.com>
On Mon, Jul 23, 2018 at 8:28 PM Eric Sunshine <sunshine@sunshineco.com> wrote:
>
> On Mon, Jul 23, 2018 at 9:51 AM SZEDER Gábor <szeder.dev@gmail.com> wrote:
> > sha1dc is an external library, that we carry in-tree for convenience
> > or grab as a submodule, so there is no use in applying our semantic
> > patches to its source files.
> >
> > Therefore, exclude sha1dc's source files from Coccinelle's static
> > analysis.
> >
> > Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
> > ---
> > diff --git a/Makefile b/Makefile
> > @@ -2666,10 +2666,16 @@ check: command-list.h
> > +ifdef DC_SHA1_SUBMODULE
> > +COCCI_SOURCES = $(filter-out sha1collisiondetection/%,$(C_SOURCES))
> > +else
> > +COCCI_SOURCES = $(filter-out sha1dc/%,$(C_SOURCES))
> > +endif
>
> Can't you just filter out both of these unconditionally without
> worrying about DC_SHA1_SUBMODULE?
I'm not sure what you mean by that. Like this perhaps?
COCCI_SOURCES = $(filter-out sha1collisiondetection/%,$(filter-out
sha1dc/%,$(C_SOURCES)))
While it's only a single line, I don't think it's any easier on the
eyes.
^ permalink raw reply
* Re: [PATCH v4 00/11] hugetlb: Factorize hugetlb architecture primitives
From: Alex Ghiti @ 2018-07-23 17:41 UTC (permalink / raw)
To: Michael Ellerman
Cc: linux, catalin.marinas, will.deacon, tony.luck, fenghua.yu, ralf,
paul.burton, jhogan, jejb, deller, benh, paulus, ysato, dalias,
davem, tglx, mingo, hpa, x86, arnd, linux-arm-kernel,
linux-kernel, linux-ia64, linux-mips, linux-parisc, linuxppc-dev,
linux-sh, sparclinux, linux-arch, Naoya Horiguchi, Mike Kravetz,
Michal Hocko
In-Reply-To: <87d0vehx16.fsf@concordia.ellerman.id.au>
Ok will do and report when done.
Thanks for your feedback,
Alex
On 07/23/2018 02:00 PM, Michael Ellerman wrote:
> Alex Ghiti <alex@ghiti.fr> writes:
>
>> Does anyone have any suggestion about those patches ?
> Cross compiling it for some non-x86 arches would be a good start :)
>
> There are cross compilers available here:
>
> https://mirrors.edge.kernel.org/pub/tools/crosstool/
>
>
> cheers
>
>> On 07/09/2018 02:16 PM, Michal Hocko wrote:
>>> [CC hugetlb guys - http://lkml.kernel.org/r/20180705110716.3919-1-alex@ghiti.fr]
>>>
>>> On Thu 05-07-18 11:07:05, Alexandre Ghiti wrote:
>>>> In order to reduce copy/paste of functions across architectures and then
>>>> make riscv hugetlb port (and future ports) simpler and smaller, this
>>>> patchset intends to factorize the numerous hugetlb primitives that are
>>>> defined across all the architectures.
>>>>
>>>> Except for prepare_hugepage_range, this patchset moves the versions that
>>>> are just pass-through to standard pte primitives into
>>>> asm-generic/hugetlb.h by using the same #ifdef semantic that can be
>>>> found in asm-generic/pgtable.h, i.e. __HAVE_ARCH_***.
>>>>
>>>> s390 architecture has not been tackled in this serie since it does not
>>>> use asm-generic/hugetlb.h at all.
>>>> powerpc could be factorized a bit more (cf huge_ptep_set_wrprotect).
>>>>
>>>> This patchset has been compiled on x86 only.
>>>>
>>>> Changelog:
>>>>
>>>> v4:
>>>> Fix powerpc build error due to misplacing of #include
>>>> <asm-generic/hugetlb.h> outside of #ifdef CONFIG_HUGETLB_PAGE, as
>>>> pointed by Christophe Leroy.
>>>>
>>>> v1, v2, v3:
>>>> Same version, just problems with email provider and misuse of
>>>> --batch-size option of git send-email
>>>>
>>>> Alexandre Ghiti (11):
>>>> hugetlb: Harmonize hugetlb.h arch specific defines with pgtable.h
>>>> hugetlb: Introduce generic version of hugetlb_free_pgd_range
>>>> hugetlb: Introduce generic version of set_huge_pte_at
>>>> hugetlb: Introduce generic version of huge_ptep_get_and_clear
>>>> hugetlb: Introduce generic version of huge_ptep_clear_flush
>>>> hugetlb: Introduce generic version of huge_pte_none
>>>> hugetlb: Introduce generic version of huge_pte_wrprotect
>>>> hugetlb: Introduce generic version of prepare_hugepage_range
>>>> hugetlb: Introduce generic version of huge_ptep_set_wrprotect
>>>> hugetlb: Introduce generic version of huge_ptep_set_access_flags
>>>> hugetlb: Introduce generic version of huge_ptep_get
>>>>
>>>> arch/arm/include/asm/hugetlb-3level.h | 32 +---------
>>>> arch/arm/include/asm/hugetlb.h | 33 +----------
>>>> arch/arm64/include/asm/hugetlb.h | 39 +++---------
>>>> arch/ia64/include/asm/hugetlb.h | 47 ++-------------
>>>> arch/mips/include/asm/hugetlb.h | 40 +++----------
>>>> arch/parisc/include/asm/hugetlb.h | 33 +++--------
>>>> arch/powerpc/include/asm/book3s/32/pgtable.h | 2 +
>>>> arch/powerpc/include/asm/book3s/64/pgtable.h | 1 +
>>>> arch/powerpc/include/asm/hugetlb.h | 43 ++------------
>>>> arch/powerpc/include/asm/nohash/32/pgtable.h | 2 +
>>>> arch/powerpc/include/asm/nohash/64/pgtable.h | 1 +
>>>> arch/sh/include/asm/hugetlb.h | 54 ++---------------
>>>> arch/sparc/include/asm/hugetlb.h | 40 +++----------
>>>> arch/x86/include/asm/hugetlb.h | 72 +----------------------
>>>> include/asm-generic/hugetlb.h | 88 +++++++++++++++++++++++++++-
>>>> 15 files changed, 143 insertions(+), 384 deletions(-)
>>>>
>>>> --
>>>> 2.16.2
^ permalink raw reply
* [PATCH] net/9p/trans_fd.c: fix race by holding the lock
From: Tomas Bortoli @ 2018-07-23 18:42 UTC (permalink / raw)
To: ericvh, rminnich, lucho
Cc: asmadeus, davem, v9fs-developer, netdev, linux-kernel, syzkaller,
Tomas Bortoli
It may be possible to run p9_fd_cancel() with a deleted req->req_list
and incur in a double del. To fix hold the client->lock while changing
the status, so the other threads will be synchronized.
Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com>
Reported-by: syzbot+735d926e9d1317c3310c@syzkaller.appspotmail.com
---
net/9p/trans_fd.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c
index 588bf88c3305..f9f96d50d96d 100644
--- a/net/9p/trans_fd.c
+++ b/net/9p/trans_fd.c
@@ -197,15 +197,14 @@ static void p9_mux_poll_stop(struct p9_conn *m)
static void p9_conn_cancel(struct p9_conn *m, int err)
{
struct p9_req_t *req, *rtmp;
- unsigned long flags;
LIST_HEAD(cancel_list);
p9_debug(P9_DEBUG_ERROR, "mux %p err %d\n", m, err);
- spin_lock_irqsave(&m->client->lock, flags);
+ spin_lock(&m->client->lock);
if (m->err) {
- spin_unlock_irqrestore(&m->client->lock, flags);
+ spin_unlock(&m->client->lock);
return;
}
@@ -217,7 +216,6 @@ static void p9_conn_cancel(struct p9_conn *m, int err)
list_for_each_entry_safe(req, rtmp, &m->unsent_req_list, req_list) {
list_move(&req->req_list, &cancel_list);
}
- spin_unlock_irqrestore(&m->client->lock, flags);
list_for_each_entry_safe(req, rtmp, &cancel_list, req_list) {
p9_debug(P9_DEBUG_ERROR, "call back req %p\n", req);
@@ -226,6 +224,7 @@ static void p9_conn_cancel(struct p9_conn *m, int err)
req->t_err = err;
p9_client_cb(m->client, req, REQ_STATUS_ERROR);
}
+ spin_unlock(&m->client->lock);
}
static __poll_t
@@ -373,8 +372,9 @@ static void p9_read_work(struct work_struct *work)
if (m->req->status != REQ_STATUS_ERROR)
status = REQ_STATUS_RCVD;
list_del(&m->req->req_list);
- spin_unlock(&m->client->lock);
+ /* update req->status while holding client->lock */
p9_client_cb(m->client, m->req, status);
+ spin_unlock(&m->client->lock);
m->rc.sdata = NULL;
m->rc.offset = 0;
m->rc.capacity = 0;
--
2.11.0
^ permalink raw reply related
* Re: bitbake is corrupting my files during unpacking
From: Andre McCurdy @ 2018-07-23 18:42 UTC (permalink / raw)
To: MOHAMMAD RASIM; +Cc: Yocto discussion list
In-Reply-To: <2d030ea4-b2df-58fe-9947-e1c4e40ea17b@gmail.com>
On Sat, Jul 21, 2018 at 12:55 AM, MOHAMMAD RASIM
<mohammad.rasim96@gmail.com> wrote:
> well apparently this is caused by the unzip binary that is compiled by the
> openembedded unzip recipe.
> If I unzip the same zip file with the unzip binary that is shipped with my
> system(manjaro) then the files are not corrupted but when I use the unzip
> binary compiled by the openembedded recipe I get error and file corruptions.
> These are some of the errors I get when unzipping with the openembedded
> unzip:
> ...
> symlink error: File name too long
>
> This error happens to multiple files where the file is symlinked to the
> content of the file and not to a path !
> Where should I report this bug ? openembedded ? unzip upstream ?
If you google the "symlink error" you should find multiple hits, which
all indicate a known bug in upstream unzip 6.0.
So, it should be reported upstream. However, given that the last unzip
release is now over 9 years old and there doesn't appear to be a
public upstream development branch, the chances of getting a timely
response don't look too good.
We should probably add the fix to the unzip recipe in oe-core:
https://bugzilla.redhat.com/show_bug.cgi?id=972427
^ permalink raw reply
* [U-Boot] [PATCH 3/4] gpio: xilinx: Not read output values via regs
From: Stefan Herbrechtsmeier @ 2018-07-23 18:42 UTC (permalink / raw)
To: u-boot
In-Reply-To: <c0bbc06f6f2033844a73a78bc994c14fa965048c.1532346215.git.michal.simek@xilinx.com>
Hi Michal,
Am 23.07.2018 um 13:43 schrieb Michal Simek:
> Reading registers for finding out output value is not working because
> input value is read instead in case of tristate.
>
> Reported-by: Stefan Herbrechtsmeier <stefan@herbrechtsmeier.net>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> ---
>
> drivers/gpio/xilinx_gpio.c | 38 +++++++++++++++++++++++++++++++++-----
> 1 file changed, 33 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpio/xilinx_gpio.c b/drivers/gpio/xilinx_gpio.c
> index 4da9ae114d87..9d3e9379d0e5 100644
> --- a/drivers/gpio/xilinx_gpio.c
> +++ b/drivers/gpio/xilinx_gpio.c
> @@ -358,6 +358,11 @@ struct xilinx_gpio_platdata {
> int bank_max[XILINX_GPIO_MAX_BANK];
> int bank_input[XILINX_GPIO_MAX_BANK];
> int bank_output[XILINX_GPIO_MAX_BANK];
> + u32 dout_default[XILINX_GPIO_MAX_BANK];
> +};
> +
> +struct xilinx_gpio_privdata {
> + u32 output_val[XILINX_GPIO_MAX_BANK];
> };
>
> static int xilinx_gpio_get_bank_pin(unsigned offset, u32 *bank_num,
> @@ -387,6 +392,7 @@ static int xilinx_gpio_set_value(struct udevice *dev, unsigned offset,
> int value)
> {
> struct xilinx_gpio_platdata *platdata = dev_get_platdata(dev);
> + struct xilinx_gpio_privdata *priv = dev_get_priv(dev);
> int val, ret;
> u32 bank, pin;
>
> @@ -394,19 +400,21 @@ static int xilinx_gpio_set_value(struct udevice *dev, unsigned offset,
> if (ret)
> return ret;
>
> - debug("%s: regs: %lx, value: %x, gpio: %x, bank %x, pin %x\n",
> - __func__, (ulong)platdata->regs, value, offset, bank, pin);
> + val = priv->output_val[bank];
> +
> + debug("%s: regs: %lx, value: %x, gpio: %x, bank %x, pin %x, out %x\n",
> + __func__, (ulong)platdata->regs, value, offset, bank, pin, val);
>
> if (value) {
> - val = readl(&platdata->regs->gpiodata + bank * 2);
> val = val | (1 << pin);
> writel(val, &platdata->regs->gpiodata + bank * 2);
> } else {
> - val = readl(&platdata->regs->gpiodata + bank * 2);
> val = val & ~(1 << pin);
> writel(val, &platdata->regs->gpiodata + bank * 2);
> }
You could replace the two writel function calls by one.
>
> + priv->output_val[bank] = val;
> +
> return val;
> };
>
> @@ -441,6 +449,7 @@ static int xilinx_gpio_get_function(struct udevice *dev, unsigned offset)
> static int xilinx_gpio_get_value(struct udevice *dev, unsigned offset)
> {
> struct xilinx_gpio_platdata *platdata = dev_get_platdata(dev);
> + struct xilinx_gpio_privdata *priv = dev_get_priv(dev);
> int val, ret;
> u32 bank, pin;
>
> @@ -451,7 +460,14 @@ static int xilinx_gpio_get_value(struct udevice *dev, unsigned offset)
> debug("%s: regs: %lx, gpio: %x, bank %x, pin %x\n", __func__,
> (ulong)platdata->regs, offset, bank, pin);
>
> - val = readl(&platdata->regs->gpiodata + bank * 2);
> + if (xilinx_gpio_get_function(dev, offset) == GPIOF_INPUT) {
> + debug("%s: Read input value from reg\n", __func__);
> + val = readl(&platdata->regs->gpiodata + bank * 2);
> + } else {
> + debug("%s: Read saved output value\n", __func__);
> + val = priv->output_val[bank];
> + }
Why you don't always read the data register? This doesn't work for three
state outputs.
> +
> val = !!(val & (1 << pin));
>
> return val;
> @@ -558,11 +574,17 @@ static int xilinx_gpio_probe(struct udevice *dev)
> {
> struct xilinx_gpio_platdata *platdata = dev_get_platdata(dev);
> struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
> + struct xilinx_gpio_privdata *priv = dev_get_priv(dev);
>
> uc_priv->bank_name = dev->name;
>
> uc_priv->gpio_count = platdata->bank_max[0] + platdata->bank_max[1];
>
> + priv->output_val[0] = platdata->dout_default[0];
> +
> + if (platdata->bank_max[1])
> + priv->output_val[1] = platdata->dout_default[1];
> +
> return 0;
> }
>
> @@ -579,6 +601,9 @@ static int xilinx_gpio_ofdata_to_platdata(struct udevice *dev)
> "xlnx,all-inputs", 0);
> platdata->bank_output[0] = dev_read_u32_default(dev,
> "xlnx,all-outputs", 0);
> + platdata->dout_default[0] = dev_read_u32_default(dev,
> + "xlnx,dout-default",
> + 0);
>
> is_dual = dev_read_u32_default(dev, "xlnx,is-dual", 0);
> if (is_dual) {
> @@ -588,6 +613,8 @@ static int xilinx_gpio_ofdata_to_platdata(struct udevice *dev)
> "xlnx,all-inputs-2", 0);
> platdata->bank_output[1] = dev_read_u32_default(dev,
> "xlnx,all-outputs-2", 0);
> + platdata->dout_default[1] = dev_read_u32_default(dev,
> + "xlnx,dout-default-2", 0);
> }
>
> return 0;
> @@ -606,5 +633,6 @@ U_BOOT_DRIVER(xilinx_gpio) = {
> .ofdata_to_platdata = xilinx_gpio_ofdata_to_platdata,
> .probe = xilinx_gpio_probe,
> .platdata_auto_alloc_size = sizeof(struct xilinx_gpio_platdata),
> + .priv_auto_alloc_size = sizeof(struct xilinx_gpio_privdata),
> };
> #endif
Best regards
 Stefan
^ permalink raw reply
* [U-Boot] [RFC PATCH] gpio: zynq: Setup bank_name to dev->name
From: Simon Glass @ 2018-07-23 18:41 UTC (permalink / raw)
To: u-boot
In-Reply-To: <f6624e7e-2b89-ff90-c648-c43316aca718@xilinx.com>
Hi Michal,
On 23 July 2018 at 03:08, Michal Simek <michal.simek@xilinx.com> wrote:
>
> On 20.7.2018 21:31, Stefan Herbrechtsmeier wrote:
> > Hi Michal,
> >
> > Am 12.07.2018 um 16:04 schrieb Michal Simek:
> >> There should be proper bank name setup to distiguish between different
> >> gpio drivers. Use dev->name for it.
> >>
> >> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> >> ---
> >>
> >> drivers/gpio/zynq_gpio.c | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/gpio/zynq_gpio.c b/drivers/gpio/zynq_gpio.c
> >> index 26f69b1a713f..f793ee5754a8 100644
> >> --- a/drivers/gpio/zynq_gpio.c
> >> +++ b/drivers/gpio/zynq_gpio.c
> >> @@ -337,6 +337,8 @@ static int zynq_gpio_probe(struct udevice *dev)
> >> struct zynq_gpio_privdata *priv = dev_get_priv(dev);
> >> struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
> >> + uc_priv->bank_name = dev->name;
> >> +
> >> if (priv->p_data)
> >> uc_priv->gpio_count = priv->p_data->ngpio;
> >>
> > Does this not lead to ugly names because the gpio number is append to
> > the bank_name? Have you check the "gpio status -a" output?
>
> Yes I was checking it. Names are composed together but also just numbers
> works as before.
>
> gpio at ff0a00000: input: 0 [ ]
> gpio at ff0a00001: input: 0 [ ]
> gpio at ff0a00002: input: 0 [ ]
> gpio at ff0a00003: input: 0 [ ]
> gpio at ff0a00004: input: 0 [ ]
> gpio at ff0a00005: input: 0 [ ]
> gpio at ff0a00006: input: 0 [ ]
> gpio at ff0a00007: input: 0 [ ]
> gpio at ff0a00008: input: 0 [ ]
> gpio at ff0a00009: input: 0 [ ]
>
> If you know better way how to setup a bank name please let me know but I
> need to distinguish ps gpio from pl one and for pl we need to know the
> address.
>
> >
> > Other drivers use the gpio-bank-name from the device tree.
>
> I can't see this property inside Linux kernel. If this has been reviewed
> by dt guys please let me know.
Linux doesn't have this concept and has no command line. I am
skeptical they would be interested in adding the property.
If we can get this in by renaming it (e.g. to u-boot,gpio-bank-name)
then that would be OK. Otherwise I think we just have to rely on
having our own binding file.
Regards,
Simon
^ permalink raw reply
* Re: [Qemu-devel] [PATCH V10 10/20] qmp event: Add COLO_EXIT event to notify users while exited COLO
From: Eric Blake @ 2018-07-23 18:41 UTC (permalink / raw)
To: Zhang Chen, qemu-devel, Paolo Bonzini, Juan Quintela,
Dr . David Alan Gilbert, Jason Wang, Markus Armbruster
Cc: zhanghailiang, Li Zhijian
In-Reply-To: <20180722193350.6028-11-zhangckid@gmail.com>
On 07/22/2018 02:33 PM, Zhang Chen wrote:
> From: zhanghailiang <zhang.zhanghailiang@huawei.com>
>
> If some errors happen during VM's COLO FT stage, it's important to
> notify the users of this event. Together with 'x-colo-lost-heartbeat',
> Users can intervene in COLO's failover work immediately.
> If users don't want to get involved in COLO's failover verdict,
> it is still necessary to notify users that we exited COLO mode.
>
> Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
> Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com>
> Signed-off-by: Zhang Chen <zhangckid@gmail.com>
> Reviewed-by: Eric Blake <eblake@redhat.com>
> Reviewed-by: Markus Armbruster <armbru@redhat.com>
> ---
> migration/colo.c | 31 +++++++++++++++++++++++++++++++
> qapi/migration.json | 38 ++++++++++++++++++++++++++++++++++++++
> 2 files changed, 69 insertions(+)
At this point in the release cycle, this series feels like enough of a
new feature (rather than a bug fix) that it is probably not appropriate
for 3.0, which means...
> +++ b/qapi/migration.json
> @@ -900,6 +900,44 @@
> { 'enum': 'FailoverStatus',
> 'data': [ 'none', 'require', 'active', 'completed', 'relaunch' ] }
>
> +##
> +# @COLO_EXIT:
> +#
> +# Emitted when VM finishes COLO mode due to some errors happening or
> +# at the request of users.
> +#
> +# @mode: report COLO mode when COLO exited.
> +#
> +# @reason: describes the reason for the COLO exit.
> +#
> +# Since: 3.0
...this and other references should be updated to 3.1.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
^ permalink raw reply
* Re: [PATCH] tpm: add support for nonblocking operation
From: Jarkko Sakkinen @ 2018-07-23 17:38 UTC (permalink / raw)
To: Tadeusz Struk; +Cc: flihp, linux-integrity
In-Reply-To: <7c197161-9cb2-1e67-bb7f-b360d557bad9@intel.com>
On Mon, Jul 16, 2018 at 01:10:42PM -0700, Tadeusz Struk wrote:
> On 07/16/2018 10:34 AM, Jarkko Sakkinen wrote:
> > On Thu, Jul 05, 2018 at 04:15:06PM -0700, flihp wrote:
> >> Thanks for reviewing the patch Jarkko. While you're doing that I took
> >> some time to hack up code to demonstrate the utility of supporting this
> >> feature. The code can be found here:
> >>
> >> https://github.com/flihp/glib-tss2-async-example
> >>
> >> In short, the example application `glib-tss2-event` uses a glib main
> >> event loop to create an RSA 2048 primary key in the TPM2 NULL hierarchy
> >> while using a glib timer event to time the operation. A GSource object
> >> is used to generate an event when the FD underlying the tss2 function
> >> call has data ready. While the application waits for an event indicating
> >> that the CreatePrimary operation is complete, it counts timer events
> >> that occur every 100ms. Once the CreatePrimary operation completes the
> >> number of timer events that occurred is used to make a rough calculation
> >> of the elapsed time. This value is then printed to the console.
> >>
> >> This takes ~300 lines of C code and requires no management or
> >> synchronization of threads. The glib GMainContext is "just a poll()
> >> loop" according to the glib documentation here:
> >>
> >> https://developer.gnome.org/programming-guidelines/stable/main-contexts.html.en
> >>
> >> and so supporting 'poll' is the easiest way to integrate with glib /
> >> gtk+. This is true of any other event system that relies on 'poll'
> >> instead of worker threads.
> >>
> >> I've tested this against the userspace resource management daemon (which
> >> supports 'poll') as well as the kernel interface using Tadeusz's patch
> >> currently under review here. If / when this gets merged feel free to add
> >> a "tested-by" line for myself:
> >> Tested-by: Philip Tricca <philip.b.tricca@intel.com>
> >
> > I see the value now. I'll test this at early August when I'm back from
> > my leave.
> >
> > Noticed now that the whole patch should be reposted because CC is missing
> > linux-kernel and linux-security-module (maybe with a link to your test
> > application in the cover letter).
>
> I'll rebase and resend it after you will be back from vacation.
> Thanks,
> --
> Tadeusz
Please add also the requested CC's. Thank you.
/Jarkko
^ permalink raw reply
* Re: [PATCH] firmware: vpd: Fix section enabled flag on vpd_section_destroy
From: Dmitry Torokhov @ 2018-07-23 18:39 UTC (permalink / raw)
To: Guenter Roeck
Cc: Anton Vasilyev, Greg Kroah-Hartman, Samuel Holland, Pan Bian,
linux-kernel, ldv-project
In-Reply-To: <20180723182710.GB2964@roeck-us.net>
On Mon, Jul 23, 2018 at 11:27:10AM -0700, Guenter Roeck wrote:
> On Mon, Jul 23, 2018 at 10:23:05AM -0700, Dmitry Torokhov wrote:
> > On Mon, Jul 23, 2018 at 10:13:36AM -0700, Guenter Roeck wrote:
> > > On Mon, Jul 23, 2018 at 07:48:57PM +0300, Anton Vasilyev wrote:
> > > > static struct ro_vpd and rw_vpd are initialized by vpd_sections_init()
> > > > in vpd_probe() based on header's ro and rw sizes.
> > > > In vpd_remove() vpd_section_destroy() performs deinitialization based
> > > > on enabled flag, which is set to true by vpd_sections_init().
> > > > This leads to call of vpd_section_destroy() on already destroyed section
> > > > for probe-release-probe-release sequence if first probe performs
> > > > ro_vpd initialization and second probe does not initialize it.
> > > >
> > >
> > > I am not sure if the situation described can be seen in the first place.
> > > The second probe would only not perform ro_vpd initialization if it fails
> > > prior to that, ie if it fails to allocate memory or if there is a
> > > consistency problem. In that case the remove function would not be called.
> > >
> > > However, there is a problem in the code: A partially failed probe will
> > > leave the system in inconsistent state. Example: ro section initializes,
> > > rw section fails to initialize. The probe will fail, but the ro section
> > > will not be destroyed, its sysfs attributes still exist, and its memory
> > > is still mapped. It would make more sense to fix _that_ problem.
> > > Essentially, vpd_sections_init() should clean up after itself after it
> > > fails to initialize a section.
> > >
> > > Note that I am not convinced that the "enabled" flag is needed in the first
> > > place. It is only relevant if vpd_section_destroy() is called, which only
> > > happens from the remove function. The remove function is only called if the
> > > probe function succeeded. In that case it is always set for both sections.
> >
> > The problem will happen if coreboot memory changes between 2 probes so
> > that header.ro_size is not 0 on the first pass and is 0 on the second
> > pass. Not quite likely to ever happen in real life, but resetting a flag
> > is pretty cheap to not do it.
> >
>
> If that can happen between probes, meaning it is not guaranteed to be
> constant during the lifetime of the system, doesn't that mean it can
> happen anytime ?
I think we can assume that the data is stable while coreboot device is
registered, but I can imagine one can theoretically have a debug
coreboot data provider that can supply different coreboot parameters
across load/unload. I.e. we have coreboot_table-acpi.c and
coreboot_table-of.c, we might create coreboot_table-test.c to feed
arbitrary data to the subsystem.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2] pack-objects: fix performance issues on packing large deltas
From: Duy Nguyen @ 2018-07-23 18:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Elijah Newren, Jeff King
In-Reply-To: <xmqq8t617rqv.fsf@gitster-ct.c.googlers.com>
On Mon, Jul 23, 2018 at 8:04 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
> > Access to e->delta_size_ (and by extension
> > pack->delta_size[e - pack->objects]) is unprotected as before, the
> > thread scheduler in pack-objects must make sure "e" is never updated
> > by two different threads.
>
> OK. Do we need to worry about "e" (e.g. "e->delta_size_valid")
> being accessed while/before it is set by another thread?
I left some details out because I think it's getting to a gray area.
We already do this
if (!DELTA(trg_entry)) {
max_size = trg_size/2 - the_hash_algo->rawsz;
ref_depth = 1;
} else {
max_size = DELTA_SIZE(trg_entry);
...
SET_DELTA(trg_entry, src_entry);
SET_DELTA_SIZE(trg_entry, delta_size);
if the bottom half is running on one thread and stopped in the middle
while the top half is running in another thread, we have a problem.
But perhaps max_size is not that big a deal because incorrect max_size
may produce a bad pack but can't corrupt it.
I will have to study the thread dispatch code more to have a better
answer, unfortunately.
--
Duy
^ permalink raw reply
* Re: [PATCH] drivers/memory/Kconfig: Add CONFIG_OF dependency
From: Arnd Bergmann @ 2018-07-23 18:39 UTC (permalink / raw)
To: Boris Brezillon
Cc: Randy Dunlap, Anders Roxell, Miquel Raynal,
Linux Kernel Mailing List, Rob Herring, DTML
In-Reply-To: <20180723181424.3c07f5b8@bbrezillon>
On Mon, Jul 23, 2018 at 6:14 PM, Boris Brezillon
<boris.brezillon@bootlin.com> wrote:
> On Mon, 23 Jul 2018 18:04:52 +0200
> Arnd Bergmann <arnd@arndb.de> wrote:
>
>> On Mon, Jul 23, 2018 at 5:40 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Mon, Jul 23, 2018 at 11:41 AM, Boris Brezillon
>> > <boris.brezillon@bootlin.com> wrote:
>> >> On Mon, 23 Jul 2018 11:34:43 +0200
>> >> Arnd Bergmann <arnd@arndb.de> wrote:
>> >>
>> >>> On Sun, Jul 22, 2018 at 8:29 AM, Boris Brezillon
>> >>> <boris.brezillon@bootlin.com> wrote:
>> >>> > +Arnd, Rob and the DT ML.
> Yep, somehow io.h was indirectly included by gpio.h. I fixed that in my
> patch when replacing gpio.h by gpio/consumer.h by including linux/io.h.
Ok, looks good. With the patch from you plus the one from Anders,
I don't see any more randconfig failures in this driver.
Arnd
^ permalink raw reply
* [RFC RESEND PATCH] drm/rockchip: update cursors asynchronously through atomic.
From: Gustavo Padovan @ 2018-07-23 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180723143634.GJ20359@art_vandelay>
Hi Enric,
On 07/23/2018 11:36 AM, Sean Paul wrote:
> On Wed, Jun 27, 2018 at 11:14:47PM +0200, Enric Balletbo i Serra wrote:
>> Add support to async updates of cursors by using the new atomic
>> interface for that.
>>
>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
>
> LGTM. Given rockchip hasn't weighed in on the patch, and that you've tested it
> on real hardware, let's land it.
>
> Reviewed-by: Sean Paul <seanpaul@chromium.org>
Your patch don't apply cleanly anymore. Can you rebase it and add the
r-b to the patch while at it? Thanks!
Gustavo
>
>
>> ---
>> I am sending this as RFC because I still don't have a deep knowledge of
>> the hw and I am not sure if the vop_plane_update function can be reused
>> in both cases, atomic_updates and atomic_async_updates. I think that
>> someone with more knowledge should take a look. The patch was tested on
>> a Samsung Chromebook Plus in two ways.
>>
>> 1. Running all igt kms_cursor_legacy and kms_atomic at plane_cursor_legacy
>> tests and see that there is no regression after the patch.
>>
>> 2. Running weston using the atomic API.
>>
>> Best regards,
>> Enric
>>
>> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 80 ++++++++++++++++-----
>> 1 file changed, 64 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> index 53d4afe15278..1eb6bda924af 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> @@ -688,8 +688,7 @@ static void vop_plane_atomic_disable(struct drm_plane *plane,
>> spin_unlock(&vop->reg_lock);
>> }
>>
>> -static void vop_plane_atomic_update(struct drm_plane *plane,
>> - struct drm_plane_state *old_state)
>> +static void vop_plane_update(struct drm_plane *plane)
>> {
>> struct drm_plane_state *state = plane->state;
>> struct drm_crtc *crtc = state->crtc;
>> @@ -710,20 +709,6 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
>> bool rb_swap;
>> int format;
>>
>> - /*
>> - * can't update plane when vop is disabled.
>> - */
>> - if (WARN_ON(!crtc))
>> - return;
>> -
>> - if (WARN_ON(!vop->is_enabled))
>> - return;
>> -
>> - if (!state->visible) {
>> - vop_plane_atomic_disable(plane, old_state);
>> - return;
>> - }
>> -
>> obj = rockchip_fb_get_gem_obj(fb, 0);
>> rk_obj = to_rockchip_obj(obj);
>>
>> @@ -794,10 +779,73 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
>> spin_unlock(&vop->reg_lock);
>> }
>>
>> +static void vop_plane_atomic_update(struct drm_plane *plane,
>> + struct drm_plane_state *old_state)
>> +{
>> + struct drm_plane_state *state = plane->state;
>> + struct vop *vop = to_vop(state->crtc);
>> +
>> + /*
>> + * can't update plane when vop is disabled.
>> + */
>> + if (WARN_ON(!state->crtc))
>> + return;
>> +
>> + if (WARN_ON(!vop->is_enabled))
>> + return;
>> +
>> + if (!state->visible) {
>> + vop_plane_atomic_disable(plane, old_state);
>> + return;
>> + }
>> +
>> + vop_plane_update(plane);
>> +}
>> +
>> +static int vop_plane_atomic_async_check(struct drm_plane *plane,
>> + struct drm_plane_state *state)
>> +{
>> + struct drm_crtc_state *crtc_state;
>> +
>> + crtc_state = drm_atomic_get_existing_crtc_state(state->state,
>> + state->crtc);
>> + if (WARN_ON(!crtc_state))
>> + return -EINVAL;
>> +
>> + if (!crtc_state->active)
>> + return -EINVAL;
>> +
>> + if (plane->state->crtc != state->crtc ||
>> + plane->state->src_w != state->src_w ||
>> + plane->state->src_h != state->src_h ||
>> + plane->state->crtc_w != state->crtc_w ||
>> + plane->state->crtc_h != state->crtc_h ||
>> + !plane->state->fb ||
>> + plane->state->fb != state->fb)
>> + return -EINVAL;
>> +
>> + return 0;
>> +}
>> +
>> +static void vop_plane_atomic_async_update(struct drm_plane *plane,
>> + struct drm_plane_state *new_state)
>> +{
>> + plane->state->src_x = new_state->src_x;
>> + plane->state->src_y = new_state->src_y;
>> + plane->state->crtc_x = new_state->crtc_x;
>> + plane->state->crtc_y = new_state->crtc_y;
>> + plane->state->fb = new_state->fb;
>> + *plane->state = *new_state;
>> +
>> + vop_plane_update(plane);
>> +}
>> +
>> static const struct drm_plane_helper_funcs plane_helper_funcs = {
>> .atomic_check = vop_plane_atomic_check,
>> .atomic_update = vop_plane_atomic_update,
>> .atomic_disable = vop_plane_atomic_disable,
>> + .atomic_async_check = vop_plane_atomic_async_check,
>> + .atomic_async_update = vop_plane_atomic_async_update,
>> };
>>
>> static const struct drm_plane_funcs vop_plane_funcs = {
>> --
>> 2.18.0
>>
>
--
Gustavo Padovan
Collabora Ltd
^ permalink raw reply
* Re: [RFC RESEND PATCH] drm/rockchip: update cursors asynchronously through atomic.
From: Gustavo Padovan @ 2018-07-23 18:39 UTC (permalink / raw)
To: Sean Paul, Enric Balletbo i Serra
Cc: Sandy Huang, Heiko Stübner, David Airlie, linux-arm-kernel,
linux-kernel, dri-devel, linux-rockchip, Tomasz Figa, Sean Paul,
kernel, Stéphane Marchesin
In-Reply-To: <20180723143634.GJ20359@art_vandelay>
Hi Enric,
On 07/23/2018 11:36 AM, Sean Paul wrote:
> On Wed, Jun 27, 2018 at 11:14:47PM +0200, Enric Balletbo i Serra wrote:
>> Add support to async updates of cursors by using the new atomic
>> interface for that.
>>
>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
>
> LGTM. Given rockchip hasn't weighed in on the patch, and that you've tested it
> on real hardware, let's land it.
>
> Reviewed-by: Sean Paul <seanpaul@chromium.org>
Your patch don't apply cleanly anymore. Can you rebase it and add the
r-b to the patch while at it? Thanks!
Gustavo
>
>
>> ---
>> I am sending this as RFC because I still don't have a deep knowledge of
>> the hw and I am not sure if the vop_plane_update function can be reused
>> in both cases, atomic_updates and atomic_async_updates. I think that
>> someone with more knowledge should take a look. The patch was tested on
>> a Samsung Chromebook Plus in two ways.
>>
>> 1. Running all igt kms_cursor_legacy and kms_atomic@plane_cursor_legacy
>> tests and see that there is no regression after the patch.
>>
>> 2. Running weston using the atomic API.
>>
>> Best regards,
>> Enric
>>
>> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 80 ++++++++++++++++-----
>> 1 file changed, 64 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> index 53d4afe15278..1eb6bda924af 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> @@ -688,8 +688,7 @@ static void vop_plane_atomic_disable(struct drm_plane *plane,
>> spin_unlock(&vop->reg_lock);
>> }
>>
>> -static void vop_plane_atomic_update(struct drm_plane *plane,
>> - struct drm_plane_state *old_state)
>> +static void vop_plane_update(struct drm_plane *plane)
>> {
>> struct drm_plane_state *state = plane->state;
>> struct drm_crtc *crtc = state->crtc;
>> @@ -710,20 +709,6 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
>> bool rb_swap;
>> int format;
>>
>> - /*
>> - * can't update plane when vop is disabled.
>> - */
>> - if (WARN_ON(!crtc))
>> - return;
>> -
>> - if (WARN_ON(!vop->is_enabled))
>> - return;
>> -
>> - if (!state->visible) {
>> - vop_plane_atomic_disable(plane, old_state);
>> - return;
>> - }
>> -
>> obj = rockchip_fb_get_gem_obj(fb, 0);
>> rk_obj = to_rockchip_obj(obj);
>>
>> @@ -794,10 +779,73 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
>> spin_unlock(&vop->reg_lock);
>> }
>>
>> +static void vop_plane_atomic_update(struct drm_plane *plane,
>> + struct drm_plane_state *old_state)
>> +{
>> + struct drm_plane_state *state = plane->state;
>> + struct vop *vop = to_vop(state->crtc);
>> +
>> + /*
>> + * can't update plane when vop is disabled.
>> + */
>> + if (WARN_ON(!state->crtc))
>> + return;
>> +
>> + if (WARN_ON(!vop->is_enabled))
>> + return;
>> +
>> + if (!state->visible) {
>> + vop_plane_atomic_disable(plane, old_state);
>> + return;
>> + }
>> +
>> + vop_plane_update(plane);
>> +}
>> +
>> +static int vop_plane_atomic_async_check(struct drm_plane *plane,
>> + struct drm_plane_state *state)
>> +{
>> + struct drm_crtc_state *crtc_state;
>> +
>> + crtc_state = drm_atomic_get_existing_crtc_state(state->state,
>> + state->crtc);
>> + if (WARN_ON(!crtc_state))
>> + return -EINVAL;
>> +
>> + if (!crtc_state->active)
>> + return -EINVAL;
>> +
>> + if (plane->state->crtc != state->crtc ||
>> + plane->state->src_w != state->src_w ||
>> + plane->state->src_h != state->src_h ||
>> + plane->state->crtc_w != state->crtc_w ||
>> + plane->state->crtc_h != state->crtc_h ||
>> + !plane->state->fb ||
>> + plane->state->fb != state->fb)
>> + return -EINVAL;
>> +
>> + return 0;
>> +}
>> +
>> +static void vop_plane_atomic_async_update(struct drm_plane *plane,
>> + struct drm_plane_state *new_state)
>> +{
>> + plane->state->src_x = new_state->src_x;
>> + plane->state->src_y = new_state->src_y;
>> + plane->state->crtc_x = new_state->crtc_x;
>> + plane->state->crtc_y = new_state->crtc_y;
>> + plane->state->fb = new_state->fb;
>> + *plane->state = *new_state;
>> +
>> + vop_plane_update(plane);
>> +}
>> +
>> static const struct drm_plane_helper_funcs plane_helper_funcs = {
>> .atomic_check = vop_plane_atomic_check,
>> .atomic_update = vop_plane_atomic_update,
>> .atomic_disable = vop_plane_atomic_disable,
>> + .atomic_async_check = vop_plane_atomic_async_check,
>> + .atomic_async_update = vop_plane_atomic_async_update,
>> };
>>
>> static const struct drm_plane_funcs vop_plane_funcs = {
>> --
>> 2.18.0
>>
>
--
Gustavo Padovan
Collabora Ltd
^ permalink raw reply
* [meta-processor-sdk][PATCH] tidl-utils: Add tidl-utils to devkit
From: Djordje Senicic @ 2018-07-23 18:38 UTC (permalink / raw)
To: meta-arago; +Cc: d-senicic1, Djordje Senicic
* Include tidl-utils package along with tidl-viewer into devkit
Signed-off-by: Djordje Senicic <x0157990@ti.com>
---
.../packagegroups/nativesdk-packagegroup-arago-sdk-host.bbappend | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/recipes-core/packagegroups/nativesdk-packagegroup-arago-sdk-host.bbappend b/recipes-core/packagegroups/nativesdk-packagegroup-arago-sdk-host.bbappend
index 514d125..b0fafee 100644
--- a/recipes-core/packagegroups/nativesdk-packagegroup-arago-sdk-host.bbappend
+++ b/recipes-core/packagegroups/nativesdk-packagegroup-arago-sdk-host.bbappend
@@ -1,3 +1,3 @@
-PR_append = ".tisdk0"
+PR_append = ".tisdk1"
-EXTRA_TI_TOOLS_append = " nativesdk-tidl-viewer"
+EXTRA_TI_TOOLS_append = " nativesdk-tidl-viewer nativesdk-tidl-utils "
--
1.9.1
^ permalink raw reply related
* [PATCH v2 1/3] Revert "ARM: dts: imx7d: Invert legacy PCI irq mapping"
From: Andrey Smirnov @ 2018-07-23 18:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <42ff53eeea3067b19e3e16bed8392706502c8f23.camel@nxp.com>
On Mon, Jul 23, 2018 at 5:41 AM Leonard Crestez <leonard.crestez@nxp.com> wrote:
>
> On Fri, 2018-07-20 at 08:33 -0700, Andrey Smirnov wrote:
> > On Fri, Jul 20, 2018 at 5:48 AM Leonard Crestez <leonard.crestez@nxp.com> wrote:
> > >
> > > This reverts commit 1c86c9dd82f859b474474a7fee0d5195da2c9c1d.
> > >
> > > That commit followed the reference manual but unfortunately the imx7d
> > > manual is incorrect.
> >
> > I'd also add similar comment to DT file to prevent people from trying
> > to "fix" this in the future.
>
> I'll try to see if I can follow up internally with docs team to get
> this updated in the next revision of the reference manual.
>
Not sure if we are on the same page here, but what I meant is adding
the same explanation that is in your commit message to Device Tree
file as well so that if anyone looks at DT code and goes "Huh?" in the
future, they wouldn't have to research commit history to see the
reason why things the way they are.
> > Also, this change is going to break QEMU's mapping found here:
>
> I had no idea that existed, I guess somebody needs to fix that as well.
>
I take it it's a no to my "any chance you can fix that as well?" ;-).
I'll see if I can find time to do that this week.
> Do you have an imx7d board using pci or did you just test in emulation?
>
I used real i.MX7D Sabre board with i210 network card, when I was
porting i.MX7 PCIe patches. However, as per note I made in the
original submission:
https://lkml.org/lkml/2017/10/9/913
this IRQ swap patch came up as a result of "connecting" emulated ICH4
in QEMU which was using legacy interrupts.
Thanks,
Andrey Smirnov
^ permalink raw reply
* Re: [PATCH v2 1/3] Revert "ARM: dts: imx7d: Invert legacy PCI irq mapping"
From: Andrey Smirnov @ 2018-07-23 18:38 UTC (permalink / raw)
To: Leonard Crestez
Cc: Richard Zhu, linux-kernel, Dong Aisheng, Jingoo Han, linux-imx,
lorenzo.pieralisi, linux-pm, Fabio Estevam, Joao.Pinto, Shawn Guo,
linux-arm-kernel, Bjorn Helgaas, Lucas Stach, Sascha Hauer,
linux-pci
In-Reply-To: <42ff53eeea3067b19e3e16bed8392706502c8f23.camel@nxp.com>
On Mon, Jul 23, 2018 at 5:41 AM Leonard Crestez <leonard.crestez@nxp.com> wrote:
>
> On Fri, 2018-07-20 at 08:33 -0700, Andrey Smirnov wrote:
> > On Fri, Jul 20, 2018 at 5:48 AM Leonard Crestez <leonard.crestez@nxp.com> wrote:
> > >
> > > This reverts commit 1c86c9dd82f859b474474a7fee0d5195da2c9c1d.
> > >
> > > That commit followed the reference manual but unfortunately the imx7d
> > > manual is incorrect.
> >
> > I'd also add similar comment to DT file to prevent people from trying
> > to "fix" this in the future.
>
> I'll try to see if I can follow up internally with docs team to get
> this updated in the next revision of the reference manual.
>
Not sure if we are on the same page here, but what I meant is adding
the same explanation that is in your commit message to Device Tree
file as well so that if anyone looks at DT code and goes "Huh?" in the
future, they wouldn't have to research commit history to see the
reason why things the way they are.
> > Also, this change is going to break QEMU's mapping found here:
>
> I had no idea that existed, I guess somebody needs to fix that as well.
>
I take it it's a no to my "any chance you can fix that as well?" ;-).
I'll see if I can find time to do that this week.
> Do you have an imx7d board using pci or did you just test in emulation?
>
I used real i.MX7D Sabre board with i210 network card, when I was
porting i.MX7 PCIe patches. However, as per note I made in the
original submission:
https://lkml.org/lkml/2017/10/9/913
this IRQ swap patch came up as a result of "connecting" emulated ICH4
in QEMU which was using legacy interrupts.
Thanks,
Andrey Smirnov
^ 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.