* [Xen-devel] [linux-4.4 test] 147279: regressions - FAIL
From: osstest service owner @ 2020-02-20 11:00 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 147279 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147279/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 139698
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 139698
Tests which are failing intermittently (not blocking):
test-amd64-amd64-qemuu-nested-amd 14 xen-boot/l1 fail in 147111 pass in 147279
test-armhf-armhf-xl-credit1 7 xen-boot fail in 147111 pass in 147279
test-amd64-i386-xl-xsm 23 leak-check/check fail in 147111 pass in 147279
test-armhf-armhf-libvirt 19 leak-check/check fail in 147111 pass in 147279
test-amd64-amd64-xl-rtds 16 guest-localmigrate fail pass in 147111
test-amd64-i386-libvirt-xsm 18 guest-start/debian.repeat fail pass in 147186
test-armhf-armhf-libvirt-raw 11 guest-start fail pass in 147186
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail in 147111 REGR. vs. 139698
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 147111 never pass
test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 147111 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-i386-xl-pvshim 12 guest-start fail never pass
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass
test-amd64-amd64-xl-pvhv2-amd 12 guest-start 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-i386-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-i386-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-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass
test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop 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-rtds 13 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 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-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-multivcpu 13 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass
test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemut-win7-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-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-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass
version targeted for testing:
linux 76e5c6fd6d163f1aa63969cc982e79be1fee87a7
baseline version:
linux dc16a7e5f36d65b25a1b66ade14356773ed52875
Last test of basis 139698 2019-08-04 07:48:30 Z 200 days
Failing since 139773 2019-08-06 16:40:26 Z 197 days 110 attempts
Testing same since 147111 2020-02-16 03:37:56 Z 4 days 3 attempts
------------------------------------------------------------
1097 people touched revisions under test,
not listing them all
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-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-xl-qemut-debianhvm-i386-xsm pass
test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass
test-amd64-amd64-libvirt-xsm pass
test-amd64-i386-libvirt-xsm fail
test-amd64-amd64-xl-xsm pass
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 fail
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-credit1 pass
test-armhf-armhf-xl-credit1 pass
test-amd64-amd64-xl-credit2 pass
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-armhf-armhf-examine pass
test-amd64-i386-examine pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-amd64-qemuu-nested-intel fail
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 fail
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds fail
test-armhf-armhf-xl-rtds pass
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 55417 lines long.)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [Intel-gfx] [PATCH] drm/i915: remove the other slab_dependencies
From: Chris Wilson @ 2020-02-20 11:00 UTC (permalink / raw)
To: Matthew Auld, intel-gfx
In-Reply-To: <20200220105707.344522-1-matthew.auld@intel.com>
Quoting Matthew Auld (2020-02-20 10:57:07)
> The real one can be found in i915_scheduler.c.
>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
You're not a fan of redundancy, I see :)
Oops,
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH] PM / hibernate: fix typo "reserverd_size" -> "reserved_size"
From: Rafael J. Wysocki @ 2020-02-20 11:01 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Rafael J . Wysocki, Pavel Machek, Linux PM,
Linux Kernel Mailing List
In-Reply-To: <20200214140621.19796-1-alexandre.belloni@bootlin.com>
On Fri, Feb 14, 2020 at 3:06 PM Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
>
> Fix a mistake in a variable name in a comment.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> ---
> kernel/power/snapshot.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
> index ddade80ad276..d82b7b88d616 100644
> --- a/kernel/power/snapshot.c
> +++ b/kernel/power/snapshot.c
> @@ -1681,7 +1681,7 @@ static unsigned long minimum_image_size(unsigned long saveable)
> * hibernation for allocations made while saving the image and for device
> * drivers, in case they need to allocate memory from their hibernation
> * callbacks (these two numbers are given by PAGES_FOR_IO (which is a rough
> - * estimate) and reserverd_size divided by PAGE_SIZE (which is tunable through
> + * estimate) and reserved_size divided by PAGE_SIZE (which is tunable through
> * /sys/power/reserved_size, respectively). To make this happen, we compute the
> * total number of available page frames and allocate at least
> *
> --
Applied as 5.6 material, thanks!
^ permalink raw reply
* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
From: Marc Zyngier @ 2020-02-20 11:01 UTC (permalink / raw)
To: Stefan Agner
Cc: linux-arm-kernel, kvmarm, kvm, Vladimir Murzin, Russell King,
Arnd Bergmann, Suzuki K Poulose, Quentin Perret, Christoffer Dall,
James Morse, Paolo Bonzini, Will Deacon, Julien Thierry
In-Reply-To: <69845f739bbd91e73cd82e7c4683ab5a@agner.ch>
On 2020-02-19 13:53, Stefan Agner wrote:
> On 2020-02-10 15:13, Marc Zyngier wrote:
>> KVM/arm was merged just over 7 years ago, and has lived a very quiet
>> life so far. It mostly works if you're prepared to deal with its
>> limitations, it has been a good prototype for the arm64 version,
>> but it suffers a few problems:
>>
>> - It is incomplete (no debug support, no PMU)
>> - It hasn't followed any of the architectural evolutions
>> - It has zero users (I don't count myself here)
>> - It is more and more getting in the way of new arm64 developments
>>
>> So here it is: unless someone screams and shows that they rely on
>> KVM/arm to be maintained upsteam, I'll remove 32bit host support
>> form the tree. One of the reasons that makes me confident nobody is
>> using it is that I never receive *any* bug report. Yes, it is perfect.
>
> Not entirely true:
> https://lore.kernel.org/m/e2f7196ca6c70c55463a45b490f6731a@agner.ch
And I thank you for that. This bug was actually hitting both arm and
arm64, and triggered by a bogus DT (that KVM should have handled in a
nicer way). What I was trying to say is that nobody reports bugs that
are specific to 32bit KVM/arm.
> But, after that was fixed, it actually was perfect :-D
> https://blog.printk.io/2016/09/kvm-with-kvmtool-on-armv7/
Hey, neat! not sure how useful, but neat nonetheless... ;-)
> That said, I never used it in a real-world application, so from my side
> removing it is fine.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
From: Marc Zyngier @ 2020-02-20 11:01 UTC (permalink / raw)
To: Stefan Agner
Cc: Russell King, kvm, Arnd Bergmann, Paolo Bonzini, Will Deacon,
kvmarm, linux-arm-kernel
In-Reply-To: <69845f739bbd91e73cd82e7c4683ab5a@agner.ch>
On 2020-02-19 13:53, Stefan Agner wrote:
> On 2020-02-10 15:13, Marc Zyngier wrote:
>> KVM/arm was merged just over 7 years ago, and has lived a very quiet
>> life so far. It mostly works if you're prepared to deal with its
>> limitations, it has been a good prototype for the arm64 version,
>> but it suffers a few problems:
>>
>> - It is incomplete (no debug support, no PMU)
>> - It hasn't followed any of the architectural evolutions
>> - It has zero users (I don't count myself here)
>> - It is more and more getting in the way of new arm64 developments
>>
>> So here it is: unless someone screams and shows that they rely on
>> KVM/arm to be maintained upsteam, I'll remove 32bit host support
>> form the tree. One of the reasons that makes me confident nobody is
>> using it is that I never receive *any* bug report. Yes, it is perfect.
>
> Not entirely true:
> https://lore.kernel.org/m/e2f7196ca6c70c55463a45b490f6731a@agner.ch
And I thank you for that. This bug was actually hitting both arm and
arm64, and triggered by a bogus DT (that KVM should have handled in a
nicer way). What I was trying to say is that nobody reports bugs that
are specific to 32bit KVM/arm.
> But, after that was fixed, it actually was perfect :-D
> https://blog.printk.io/2016/09/kvm-with-kvmtool-on-armv7/
Hey, neat! not sure how useful, but neat nonetheless... ;-)
> That said, I never used it in a real-world application, so from my side
> removing it is fine.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply
* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
From: Marc Zyngier @ 2020-02-20 11:01 UTC (permalink / raw)
To: Stefan Agner
Cc: Vladimir Murzin, Russell King, kvm, Arnd Bergmann,
Suzuki K Poulose, Quentin Perret, Christoffer Dall, James Morse,
Julien Thierry, Paolo Bonzini, Will Deacon, kvmarm,
linux-arm-kernel
In-Reply-To: <69845f739bbd91e73cd82e7c4683ab5a@agner.ch>
On 2020-02-19 13:53, Stefan Agner wrote:
> On 2020-02-10 15:13, Marc Zyngier wrote:
>> KVM/arm was merged just over 7 years ago, and has lived a very quiet
>> life so far. It mostly works if you're prepared to deal with its
>> limitations, it has been a good prototype for the arm64 version,
>> but it suffers a few problems:
>>
>> - It is incomplete (no debug support, no PMU)
>> - It hasn't followed any of the architectural evolutions
>> - It has zero users (I don't count myself here)
>> - It is more and more getting in the way of new arm64 developments
>>
>> So here it is: unless someone screams and shows that they rely on
>> KVM/arm to be maintained upsteam, I'll remove 32bit host support
>> form the tree. One of the reasons that makes me confident nobody is
>> using it is that I never receive *any* bug report. Yes, it is perfect.
>
> Not entirely true:
> https://lore.kernel.org/m/e2f7196ca6c70c55463a45b490f6731a@agner.ch
And I thank you for that. This bug was actually hitting both arm and
arm64, and triggered by a bogus DT (that KVM should have handled in a
nicer way). What I was trying to say is that nobody reports bugs that
are specific to 32bit KVM/arm.
> But, after that was fixed, it actually was perfect :-D
> https://blog.printk.io/2016/09/kvm-with-kvmtool-on-armv7/
Hey, neat! not sure how useful, but neat nonetheless... ;-)
> That said, I never used it in a real-world application, so from my side
> removing it is fine.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 13/17] s390x: protvirt: Move diag 308 data over SIDAD
From: Cornelia Huck @ 2020-02-20 11:00 UTC (permalink / raw)
To: Janosch Frank; +Cc: qemu-s390x, mihajlov, qemu-devel, david
In-Reply-To: <20200214151636.8764-14-frankja@linux.ibm.com>
On Fri, 14 Feb 2020 10:16:32 -0500
Janosch Frank <frankja@linux.ibm.com> wrote:
> For protected guests the IPIB is written/read to/from the satellite
> block, so we need to make those accesses virtual to make them go
> through KVM mem ops.
Confused. What does 'make those accesses virtual' mean?
>
> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
> ---
> target/s390x/diag.c | 32 +++++++++++++++++++++++++-------
> 1 file changed, 25 insertions(+), 7 deletions(-)
>
> diff --git a/target/s390x/diag.c b/target/s390x/diag.c
> index 6aaeef6029..59ae122e82 100644
> --- a/target/s390x/diag.c
> +++ b/target/s390x/diag.c
> @@ -88,6 +88,7 @@ static int diag308_parm_check(CPUS390XState *env, uint64_t r1, uint64_t addr,
> void handle_diag_308(CPUS390XState *env, uint64_t r1, uint64_t r3, uintptr_t ra)
> {
> CPUState *cs = env_cpu(env);
> + S390CPU *cpu = S390_CPU(cs);
> uint64_t addr = env->regs[r1];
> uint64_t subcode = env->regs[r3];
> IplParameterBlock *iplb;
> @@ -118,14 +119,24 @@ void handle_diag_308(CPUS390XState *env, uint64_t r1, uint64_t r3, uintptr_t ra)
> if (diag308_parm_check(env, r1, addr, ra, false)) {
> return;
> }
> +
Whitespace.
> iplb = g_new0(IplParameterBlock, 1);
> - cpu_physical_memory_read(addr, iplb, sizeof(iplb->len));
> + if (!env->pv) {
> + cpu_physical_memory_read(addr, iplb, sizeof(iplb->len));
> + } else {
> + s390_cpu_pv_mem_read(cpu, 0, iplb, sizeof(iplb->len));
> + }
> +
> if (!iplb_valid_len(iplb)) {
> env->regs[r1 + 1] = DIAG_308_RC_INVALID;
> goto out;
> }
>
> - cpu_physical_memory_read(addr, iplb, be32_to_cpu(iplb->len));
> + if (!env->pv) {
> + cpu_physical_memory_read(addr, iplb, be32_to_cpu(iplb->len));
> + } else {
> + s390_cpu_pv_mem_read(cpu, 0, iplb, be32_to_cpu(iplb->len));
> + }
>
> if (!iplb_valid_ccw(iplb) && !iplb_valid_fcp(iplb) &&
> !(iplb_valid_pv(iplb) && s390_ipl_pv_check_components(iplb) >= 0)) {
> @@ -137,23 +148,30 @@ void handle_diag_308(CPUS390XState *env, uint64_t r1, uint64_t r3, uintptr_t ra)
> env->regs[r1 + 1] = DIAG_308_RC_OK;
> out:
> g_free(iplb);
> - return;
> + break;
> case DIAG308_STORE:
> case DIAG308_PV_STORE:
> if (diag308_parm_check(env, r1, addr, ra, true)) {
> return;
> }
> +
Whitespace.
> if (subcode == DIAG308_PV_STORE) {
> iplb = s390_ipl_get_iplb_secure();
> } else {
> iplb = s390_ipl_get_iplb();
> }
> - if (iplb) {
> - cpu_physical_memory_write(addr, iplb, be32_to_cpu(iplb->len));
> - env->regs[r1 + 1] = DIAG_308_RC_OK;
> - } else {
> + if (!iplb) {
> env->regs[r1 + 1] = DIAG_308_RC_NO_CONF;
> + return;
> }
> +
> + if (!env->pv) {
> + cpu_physical_memory_write(addr, iplb, be32_to_cpu(iplb->len));
> + } else {
> + s390_cpu_pv_mem_write(cpu, 0, iplb, be32_to_cpu(iplb->len));
> + }
> +
> + env->regs[r1 + 1] = DIAG_308_RC_OK;
> break;
> case DIAG308_PV_START:
> iplb = s390_ipl_get_iplb_secure();
^ permalink raw reply
* [linux-next:master 2654/3478] drivers/clk//tegra/clk-tegra124.c:865:31: error: 'TEGRA124_CLK_OSC' undeclared here (not in a function); did you mean 'TEGRA124_CLK_CEC'?
From: kbuild test robot @ 2020-02-20 11:02 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 19114 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
head: f4aba10148cd290bbbf4d0efae0e9789a13c2778
commit: 78b5672e023c6a42ab4a59fb962fb31adb609e6b [2654/3478] clk: tegra: Add Tegra OSC to clock lookup
config: arm64-allyesconfig (attached as .config)
compiler: aarch64-linux-gcc (GCC) 7.5.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 78b5672e023c6a42ab4a59fb962fb31adb609e6b
# save the attached .config to linux build tree
GCC_VERSION=7.5.0 make.cross ARCH=arm64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
Note: the linux-next/master HEAD f4aba10148cd290bbbf4d0efae0e9789a13c2778 builds fine.
It may have been fixed somewhere.
All errors (new ones prefixed by >>):
>> drivers/clk//tegra/clk-tegra124.c:865:31: error: 'TEGRA124_CLK_OSC' undeclared here (not in a function); did you mean 'TEGRA124_CLK_CEC'?
[tegra_clk_osc] = { .dt_id = TEGRA124_CLK_OSC, .present = true },
^~~~~~~~~~~~~~~~
TEGRA124_CLK_CEC
drivers/clk//tegra/clk-tegra124.c:866:36: error: 'TEGRA124_CLK_OSC_DIV2' undeclared here (not in a function); did you mean 'TEGRA124_CLK_OSC'?
[tegra_clk_osc_div2] = { .dt_id = TEGRA124_CLK_OSC_DIV2, .present = true },
^~~~~~~~~~~~~~~~~~~~~
TEGRA124_CLK_OSC
drivers/clk//tegra/clk-tegra124.c:867:36: error: 'TEGRA124_CLK_OSC_DIV4' undeclared here (not in a function); did you mean 'TEGRA124_CLK_OSC_DIV2'?
[tegra_clk_osc_div4] = { .dt_id = TEGRA124_CLK_OSC_DIV4, .present = true },
^~~~~~~~~~~~~~~~~~~~~
TEGRA124_CLK_OSC_DIV2
--
>> drivers/clk//tegra/clk-tegra210.c:2376:31: error: 'TEGRA210_CLK_OSC' undeclared here (not in a function); did you mean 'TEGRA210_CLK_EMC'?
[tegra_clk_osc] = { .dt_id = TEGRA210_CLK_OSC, .present = true },
^~~~~~~~~~~~~~~~
TEGRA210_CLK_EMC
drivers/clk//tegra/clk-tegra210.c:2377:36: error: 'TEGRA210_CLK_OSC_DIV2' undeclared here (not in a function); did you mean 'TEGRA210_CLK_OSC'?
[tegra_clk_osc_div2] = { .dt_id = TEGRA210_CLK_OSC_DIV2, .present = true },
^~~~~~~~~~~~~~~~~~~~~
TEGRA210_CLK_OSC
drivers/clk//tegra/clk-tegra210.c:2378:36: error: 'TEGRA210_CLK_OSC_DIV4' undeclared here (not in a function); did you mean 'TEGRA210_CLK_OSC_DIV2'?
[tegra_clk_osc_div4] = { .dt_id = TEGRA210_CLK_OSC_DIV4, .present = true },
^~~~~~~~~~~~~~~~~~~~~
TEGRA210_CLK_OSC_DIV2
vim +865 drivers/clk//tegra/clk-tegra124.c
746
747 static struct tegra_clk tegra124_clks[tegra_clk_max] __initdata = {
748 [tegra_clk_ispb] = { .dt_id = TEGRA124_CLK_ISPB, .present = true },
749 [tegra_clk_rtc] = { .dt_id = TEGRA124_CLK_RTC, .present = true },
750 [tegra_clk_timer] = { .dt_id = TEGRA124_CLK_TIMER, .present = true },
751 [tegra_clk_uarta] = { .dt_id = TEGRA124_CLK_UARTA, .present = true },
752 [tegra_clk_sdmmc2_8] = { .dt_id = TEGRA124_CLK_SDMMC2, .present = true },
753 [tegra_clk_i2s1] = { .dt_id = TEGRA124_CLK_I2S1, .present = true },
754 [tegra_clk_i2c1] = { .dt_id = TEGRA124_CLK_I2C1, .present = true },
755 [tegra_clk_sdmmc1_8] = { .dt_id = TEGRA124_CLK_SDMMC1, .present = true },
756 [tegra_clk_sdmmc4_8] = { .dt_id = TEGRA124_CLK_SDMMC4, .present = true },
757 [tegra_clk_pwm] = { .dt_id = TEGRA124_CLK_PWM, .present = true },
758 [tegra_clk_i2s2] = { .dt_id = TEGRA124_CLK_I2S2, .present = true },
759 [tegra_clk_usbd] = { .dt_id = TEGRA124_CLK_USBD, .present = true },
760 [tegra_clk_isp_8] = { .dt_id = TEGRA124_CLK_ISP, .present = true },
761 [tegra_clk_disp2] = { .dt_id = TEGRA124_CLK_DISP2, .present = true },
762 [tegra_clk_disp1] = { .dt_id = TEGRA124_CLK_DISP1, .present = true },
763 [tegra_clk_host1x_8] = { .dt_id = TEGRA124_CLK_HOST1X, .present = true },
764 [tegra_clk_vcp] = { .dt_id = TEGRA124_CLK_VCP, .present = true },
765 [tegra_clk_i2s0] = { .dt_id = TEGRA124_CLK_I2S0, .present = true },
766 [tegra_clk_apbdma] = { .dt_id = TEGRA124_CLK_APBDMA, .present = true },
767 [tegra_clk_kbc] = { .dt_id = TEGRA124_CLK_KBC, .present = true },
768 [tegra_clk_kfuse] = { .dt_id = TEGRA124_CLK_KFUSE, .present = true },
769 [tegra_clk_sbc1] = { .dt_id = TEGRA124_CLK_SBC1, .present = true },
770 [tegra_clk_nor] = { .dt_id = TEGRA124_CLK_NOR, .present = true },
771 [tegra_clk_sbc2] = { .dt_id = TEGRA124_CLK_SBC2, .present = true },
772 [tegra_clk_sbc3] = { .dt_id = TEGRA124_CLK_SBC3, .present = true },
773 [tegra_clk_i2c5] = { .dt_id = TEGRA124_CLK_I2C5, .present = true },
774 [tegra_clk_mipi] = { .dt_id = TEGRA124_CLK_MIPI, .present = true },
775 [tegra_clk_hdmi] = { .dt_id = TEGRA124_CLK_HDMI, .present = true },
776 [tegra_clk_csi] = { .dt_id = TEGRA124_CLK_CSI, .present = true },
777 [tegra_clk_i2c2] = { .dt_id = TEGRA124_CLK_I2C2, .present = true },
778 [tegra_clk_uartc] = { .dt_id = TEGRA124_CLK_UARTC, .present = true },
779 [tegra_clk_mipi_cal] = { .dt_id = TEGRA124_CLK_MIPI_CAL, .present = true },
780 [tegra_clk_usb2] = { .dt_id = TEGRA124_CLK_USB2, .present = true },
781 [tegra_clk_usb3] = { .dt_id = TEGRA124_CLK_USB3, .present = true },
782 [tegra_clk_vde_8] = { .dt_id = TEGRA124_CLK_VDE, .present = true },
783 [tegra_clk_bsea] = { .dt_id = TEGRA124_CLK_BSEA, .present = true },
784 [tegra_clk_bsev] = { .dt_id = TEGRA124_CLK_BSEV, .present = true },
785 [tegra_clk_uartd] = { .dt_id = TEGRA124_CLK_UARTD, .present = true },
786 [tegra_clk_i2c3] = { .dt_id = TEGRA124_CLK_I2C3, .present = true },
787 [tegra_clk_sbc4] = { .dt_id = TEGRA124_CLK_SBC4, .present = true },
788 [tegra_clk_sdmmc3_8] = { .dt_id = TEGRA124_CLK_SDMMC3, .present = true },
789 [tegra_clk_pcie] = { .dt_id = TEGRA124_CLK_PCIE, .present = true },
790 [tegra_clk_owr] = { .dt_id = TEGRA124_CLK_OWR, .present = true },
791 [tegra_clk_afi] = { .dt_id = TEGRA124_CLK_AFI, .present = true },
792 [tegra_clk_csite] = { .dt_id = TEGRA124_CLK_CSITE, .present = true },
793 [tegra_clk_la] = { .dt_id = TEGRA124_CLK_LA, .present = true },
794 [tegra_clk_trace] = { .dt_id = TEGRA124_CLK_TRACE, .present = true },
795 [tegra_clk_soc_therm] = { .dt_id = TEGRA124_CLK_SOC_THERM, .present = true },
796 [tegra_clk_dtv] = { .dt_id = TEGRA124_CLK_DTV, .present = true },
797 [tegra_clk_i2cslow] = { .dt_id = TEGRA124_CLK_I2CSLOW, .present = true },
798 [tegra_clk_tsec] = { .dt_id = TEGRA124_CLK_TSEC, .present = true },
799 [tegra_clk_xusb_host] = { .dt_id = TEGRA124_CLK_XUSB_HOST, .present = true },
800 [tegra_clk_msenc] = { .dt_id = TEGRA124_CLK_MSENC, .present = true },
801 [tegra_clk_csus] = { .dt_id = TEGRA124_CLK_CSUS, .present = true },
802 [tegra_clk_mselect] = { .dt_id = TEGRA124_CLK_MSELECT, .present = true },
803 [tegra_clk_tsensor] = { .dt_id = TEGRA124_CLK_TSENSOR, .present = true },
804 [tegra_clk_i2s3] = { .dt_id = TEGRA124_CLK_I2S3, .present = true },
805 [tegra_clk_i2s4] = { .dt_id = TEGRA124_CLK_I2S4, .present = true },
806 [tegra_clk_i2c4] = { .dt_id = TEGRA124_CLK_I2C4, .present = true },
807 [tegra_clk_sbc5] = { .dt_id = TEGRA124_CLK_SBC5, .present = true },
808 [tegra_clk_sbc6] = { .dt_id = TEGRA124_CLK_SBC6, .present = true },
809 [tegra_clk_d_audio] = { .dt_id = TEGRA124_CLK_D_AUDIO, .present = true },
810 [tegra_clk_apbif] = { .dt_id = TEGRA124_CLK_APBIF, .present = true },
811 [tegra_clk_dam0] = { .dt_id = TEGRA124_CLK_DAM0, .present = true },
812 [tegra_clk_dam1] = { .dt_id = TEGRA124_CLK_DAM1, .present = true },
813 [tegra_clk_dam2] = { .dt_id = TEGRA124_CLK_DAM2, .present = true },
814 [tegra_clk_hda2codec_2x] = { .dt_id = TEGRA124_CLK_HDA2CODEC_2X, .present = true },
815 [tegra_clk_audio0_2x] = { .dt_id = TEGRA124_CLK_AUDIO0_2X, .present = true },
816 [tegra_clk_audio1_2x] = { .dt_id = TEGRA124_CLK_AUDIO1_2X, .present = true },
817 [tegra_clk_audio2_2x] = { .dt_id = TEGRA124_CLK_AUDIO2_2X, .present = true },
818 [tegra_clk_audio3_2x] = { .dt_id = TEGRA124_CLK_AUDIO3_2X, .present = true },
819 [tegra_clk_audio4_2x] = { .dt_id = TEGRA124_CLK_AUDIO4_2X, .present = true },
820 [tegra_clk_spdif_2x] = { .dt_id = TEGRA124_CLK_SPDIF_2X, .present = true },
821 [tegra_clk_actmon] = { .dt_id = TEGRA124_CLK_ACTMON, .present = true },
822 [tegra_clk_extern1] = { .dt_id = TEGRA124_CLK_EXTERN1, .present = true },
823 [tegra_clk_extern2] = { .dt_id = TEGRA124_CLK_EXTERN2, .present = true },
824 [tegra_clk_extern3] = { .dt_id = TEGRA124_CLK_EXTERN3, .present = true },
825 [tegra_clk_sata_oob] = { .dt_id = TEGRA124_CLK_SATA_OOB, .present = true },
826 [tegra_clk_sata] = { .dt_id = TEGRA124_CLK_SATA, .present = true },
827 [tegra_clk_hda] = { .dt_id = TEGRA124_CLK_HDA, .present = true },
828 [tegra_clk_se] = { .dt_id = TEGRA124_CLK_SE, .present = true },
829 [tegra_clk_hda2hdmi] = { .dt_id = TEGRA124_CLK_HDA2HDMI, .present = true },
830 [tegra_clk_sata_cold] = { .dt_id = TEGRA124_CLK_SATA_COLD, .present = true },
831 [tegra_clk_cilab] = { .dt_id = TEGRA124_CLK_CILAB, .present = true },
832 [tegra_clk_cilcd] = { .dt_id = TEGRA124_CLK_CILCD, .present = true },
833 [tegra_clk_cile] = { .dt_id = TEGRA124_CLK_CILE, .present = true },
834 [tegra_clk_dsialp] = { .dt_id = TEGRA124_CLK_DSIALP, .present = true },
835 [tegra_clk_dsiblp] = { .dt_id = TEGRA124_CLK_DSIBLP, .present = true },
836 [tegra_clk_entropy] = { .dt_id = TEGRA124_CLK_ENTROPY, .present = true },
837 [tegra_clk_dds] = { .dt_id = TEGRA124_CLK_DDS, .present = true },
838 [tegra_clk_dp2] = { .dt_id = TEGRA124_CLK_DP2, .present = true },
839 [tegra_clk_amx] = { .dt_id = TEGRA124_CLK_AMX, .present = true },
840 [tegra_clk_adx] = { .dt_id = TEGRA124_CLK_ADX, .present = true },
841 [tegra_clk_xusb_ss] = { .dt_id = TEGRA124_CLK_XUSB_SS, .present = true },
842 [tegra_clk_i2c6] = { .dt_id = TEGRA124_CLK_I2C6, .present = true },
843 [tegra_clk_vim2_clk] = { .dt_id = TEGRA124_CLK_VIM2_CLK, .present = true },
844 [tegra_clk_hdmi_audio] = { .dt_id = TEGRA124_CLK_HDMI_AUDIO, .present = true },
845 [tegra_clk_clk72Mhz] = { .dt_id = TEGRA124_CLK_CLK72MHZ, .present = true },
846 [tegra_clk_vic03] = { .dt_id = TEGRA124_CLK_VIC03, .present = true },
847 [tegra_clk_adx1] = { .dt_id = TEGRA124_CLK_ADX1, .present = true },
848 [tegra_clk_dpaux] = { .dt_id = TEGRA124_CLK_DPAUX, .present = true },
849 [tegra_clk_sor0] = { .dt_id = TEGRA124_CLK_SOR0, .present = true },
850 [tegra_clk_sor0_out] = { .dt_id = TEGRA124_CLK_SOR0_OUT, .present = true },
851 [tegra_clk_gpu] = { .dt_id = TEGRA124_CLK_GPU, .present = true },
852 [tegra_clk_amx1] = { .dt_id = TEGRA124_CLK_AMX1, .present = true },
853 [tegra_clk_uartb] = { .dt_id = TEGRA124_CLK_UARTB, .present = true },
854 [tegra_clk_vfir] = { .dt_id = TEGRA124_CLK_VFIR, .present = true },
855 [tegra_clk_spdif_in] = { .dt_id = TEGRA124_CLK_SPDIF_IN, .present = true },
856 [tegra_clk_spdif_out] = { .dt_id = TEGRA124_CLK_SPDIF_OUT, .present = true },
857 [tegra_clk_vi_9] = { .dt_id = TEGRA124_CLK_VI, .present = true },
858 [tegra_clk_vi_sensor_8] = { .dt_id = TEGRA124_CLK_VI_SENSOR, .present = true },
859 [tegra_clk_fuse] = { .dt_id = TEGRA124_CLK_FUSE, .present = true },
860 [tegra_clk_fuse_burn] = { .dt_id = TEGRA124_CLK_FUSE_BURN, .present = true },
861 [tegra_clk_clk_32k] = { .dt_id = TEGRA124_CLK_CLK_32K, .present = true },
862 [tegra_clk_clk_m] = { .dt_id = TEGRA124_CLK_CLK_M, .present = true },
863 [tegra_clk_clk_m_div2] = { .dt_id = TEGRA124_CLK_CLK_M_DIV2, .present = true },
864 [tegra_clk_clk_m_div4] = { .dt_id = TEGRA124_CLK_CLK_M_DIV4, .present = true },
> 865 [tegra_clk_osc] = { .dt_id = TEGRA124_CLK_OSC, .present = true },
866 [tegra_clk_osc_div2] = { .dt_id = TEGRA124_CLK_OSC_DIV2, .present = true },
867 [tegra_clk_osc_div4] = { .dt_id = TEGRA124_CLK_OSC_DIV4, .present = true },
868 [tegra_clk_pll_ref] = { .dt_id = TEGRA124_CLK_PLL_REF, .present = true },
869 [tegra_clk_pll_c] = { .dt_id = TEGRA124_CLK_PLL_C, .present = true },
870 [tegra_clk_pll_c_out1] = { .dt_id = TEGRA124_CLK_PLL_C_OUT1, .present = true },
871 [tegra_clk_pll_c2] = { .dt_id = TEGRA124_CLK_PLL_C2, .present = true },
872 [tegra_clk_pll_c3] = { .dt_id = TEGRA124_CLK_PLL_C3, .present = true },
873 [tegra_clk_pll_m] = { .dt_id = TEGRA124_CLK_PLL_M, .present = true },
874 [tegra_clk_pll_m_out1] = { .dt_id = TEGRA124_CLK_PLL_M_OUT1, .present = true },
875 [tegra_clk_pll_p] = { .dt_id = TEGRA124_CLK_PLL_P, .present = true },
876 [tegra_clk_pll_p_out1] = { .dt_id = TEGRA124_CLK_PLL_P_OUT1, .present = true },
877 [tegra_clk_pll_p_out2] = { .dt_id = TEGRA124_CLK_PLL_P_OUT2, .present = true },
878 [tegra_clk_pll_p_out3] = { .dt_id = TEGRA124_CLK_PLL_P_OUT3, .present = true },
879 [tegra_clk_pll_p_out4] = { .dt_id = TEGRA124_CLK_PLL_P_OUT4, .present = true },
880 [tegra_clk_pll_a] = { .dt_id = TEGRA124_CLK_PLL_A, .present = true },
881 [tegra_clk_pll_a_out0] = { .dt_id = TEGRA124_CLK_PLL_A_OUT0, .present = true },
882 [tegra_clk_pll_d] = { .dt_id = TEGRA124_CLK_PLL_D, .present = true },
883 [tegra_clk_pll_d_out0] = { .dt_id = TEGRA124_CLK_PLL_D_OUT0, .present = true },
884 [tegra_clk_pll_d2] = { .dt_id = TEGRA124_CLK_PLL_D2, .present = true },
885 [tegra_clk_pll_d2_out0] = { .dt_id = TEGRA124_CLK_PLL_D2_OUT0, .present = true },
886 [tegra_clk_pll_u] = { .dt_id = TEGRA124_CLK_PLL_U, .present = true },
887 [tegra_clk_pll_u_480m] = { .dt_id = TEGRA124_CLK_PLL_U_480M, .present = true },
888 [tegra_clk_pll_u_60m] = { .dt_id = TEGRA124_CLK_PLL_U_60M, .present = true },
889 [tegra_clk_pll_u_48m] = { .dt_id = TEGRA124_CLK_PLL_U_48M, .present = true },
890 [tegra_clk_pll_u_12m] = { .dt_id = TEGRA124_CLK_PLL_U_12M, .present = true },
891 [tegra_clk_pll_x] = { .dt_id = TEGRA124_CLK_PLL_X, .present = true },
892 [tegra_clk_pll_x_out0] = { .dt_id = TEGRA124_CLK_PLL_X_OUT0, .present = true },
893 [tegra_clk_pll_re_vco] = { .dt_id = TEGRA124_CLK_PLL_RE_VCO, .present = true },
894 [tegra_clk_pll_re_out] = { .dt_id = TEGRA124_CLK_PLL_RE_OUT, .present = true },
895 [tegra_clk_spdif_in_sync] = { .dt_id = TEGRA124_CLK_SPDIF_IN_SYNC, .present = true },
896 [tegra_clk_i2s0_sync] = { .dt_id = TEGRA124_CLK_I2S0_SYNC, .present = true },
897 [tegra_clk_i2s1_sync] = { .dt_id = TEGRA124_CLK_I2S1_SYNC, .present = true },
898 [tegra_clk_i2s2_sync] = { .dt_id = TEGRA124_CLK_I2S2_SYNC, .present = true },
899 [tegra_clk_i2s3_sync] = { .dt_id = TEGRA124_CLK_I2S3_SYNC, .present = true },
900 [tegra_clk_i2s4_sync] = { .dt_id = TEGRA124_CLK_I2S4_SYNC, .present = true },
901 [tegra_clk_vimclk_sync] = { .dt_id = TEGRA124_CLK_VIMCLK_SYNC, .present = true },
902 [tegra_clk_audio0] = { .dt_id = TEGRA124_CLK_AUDIO0, .present = true },
903 [tegra_clk_audio1] = { .dt_id = TEGRA124_CLK_AUDIO1, .present = true },
904 [tegra_clk_audio2] = { .dt_id = TEGRA124_CLK_AUDIO2, .present = true },
905 [tegra_clk_audio3] = { .dt_id = TEGRA124_CLK_AUDIO3, .present = true },
906 [tegra_clk_audio4] = { .dt_id = TEGRA124_CLK_AUDIO4, .present = true },
907 [tegra_clk_spdif] = { .dt_id = TEGRA124_CLK_SPDIF, .present = true },
908 [tegra_clk_clk_out_1] = { .dt_id = TEGRA124_CLK_CLK_OUT_1, .present = true },
909 [tegra_clk_clk_out_2] = { .dt_id = TEGRA124_CLK_CLK_OUT_2, .present = true },
910 [tegra_clk_clk_out_3] = { .dt_id = TEGRA124_CLK_CLK_OUT_3, .present = true },
911 [tegra_clk_blink] = { .dt_id = TEGRA124_CLK_BLINK, .present = true },
912 [tegra_clk_xusb_host_src] = { .dt_id = TEGRA124_CLK_XUSB_HOST_SRC, .present = true },
913 [tegra_clk_xusb_falcon_src] = { .dt_id = TEGRA124_CLK_XUSB_FALCON_SRC, .present = true },
914 [tegra_clk_xusb_fs_src] = { .dt_id = TEGRA124_CLK_XUSB_FS_SRC, .present = true },
915 [tegra_clk_xusb_ss_src] = { .dt_id = TEGRA124_CLK_XUSB_SS_SRC, .present = true },
916 [tegra_clk_xusb_ss_div2] = { .dt_id = TEGRA124_CLK_XUSB_SS_DIV2, .present = true },
917 [tegra_clk_xusb_dev_src] = { .dt_id = TEGRA124_CLK_XUSB_DEV_SRC, .present = true },
918 [tegra_clk_xusb_dev] = { .dt_id = TEGRA124_CLK_XUSB_DEV, .present = true },
919 [tegra_clk_xusb_hs_src] = { .dt_id = TEGRA124_CLK_XUSB_HS_SRC, .present = true },
920 [tegra_clk_sclk] = { .dt_id = TEGRA124_CLK_SCLK, .present = true },
921 [tegra_clk_hclk] = { .dt_id = TEGRA124_CLK_HCLK, .present = true },
922 [tegra_clk_pclk] = { .dt_id = TEGRA124_CLK_PCLK, .present = true },
923 [tegra_clk_cclk_g] = { .dt_id = TEGRA124_CLK_CCLK_G, .present = true },
924 [tegra_clk_cclk_lp] = { .dt_id = TEGRA124_CLK_CCLK_LP, .present = true },
925 [tegra_clk_dfll_ref] = { .dt_id = TEGRA124_CLK_DFLL_REF, .present = true },
926 [tegra_clk_dfll_soc] = { .dt_id = TEGRA124_CLK_DFLL_SOC, .present = true },
927 [tegra_clk_vi_sensor2] = { .dt_id = TEGRA124_CLK_VI_SENSOR2, .present = true },
928 [tegra_clk_pll_p_out5] = { .dt_id = TEGRA124_CLK_PLL_P_OUT5, .present = true },
929 [tegra_clk_pll_c4] = { .dt_id = TEGRA124_CLK_PLL_C4, .present = true },
930 [tegra_clk_pll_dp] = { .dt_id = TEGRA124_CLK_PLL_DP, .present = true },
931 [tegra_clk_audio0_mux] = { .dt_id = TEGRA124_CLK_AUDIO0_MUX, .present = true },
932 [tegra_clk_audio1_mux] = { .dt_id = TEGRA124_CLK_AUDIO1_MUX, .present = true },
933 [tegra_clk_audio2_mux] = { .dt_id = TEGRA124_CLK_AUDIO2_MUX, .present = true },
934 [tegra_clk_audio3_mux] = { .dt_id = TEGRA124_CLK_AUDIO3_MUX, .present = true },
935 [tegra_clk_audio4_mux] = { .dt_id = TEGRA124_CLK_AUDIO4_MUX, .present = true },
936 [tegra_clk_spdif_mux] = { .dt_id = TEGRA124_CLK_SPDIF_MUX, .present = true },
937 [tegra_clk_clk_out_1_mux] = { .dt_id = TEGRA124_CLK_CLK_OUT_1_MUX, .present = true },
938 [tegra_clk_clk_out_2_mux] = { .dt_id = TEGRA124_CLK_CLK_OUT_2_MUX, .present = true },
939 [tegra_clk_clk_out_3_mux] = { .dt_id = TEGRA124_CLK_CLK_OUT_3_MUX, .present = true },
940 [tegra_clk_cec] = { .dt_id = TEGRA124_CLK_CEC, .present = true },
941 };
942
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 70466 bytes --]
^ permalink raw reply
* Re: [PATCH v3 16/17] s390x: protvirt: Handle SIGP store status correctly
From: Cornelia Huck @ 2020-02-20 11:02 UTC (permalink / raw)
To: Janosch Frank; +Cc: qemu-s390x, mihajlov, qemu-devel, david
In-Reply-To: <20200214151636.8764-17-frankja@linux.ibm.com>
On Fri, 14 Feb 2020 10:16:35 -0500
Janosch Frank <frankja@linux.ibm.com> wrote:
> Status storing is not done by QEMU anymore, but is handled by SIE.
>
> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
> Reviewed-by: Thomas Huth <thuth@redhat.com>
> ---
> target/s390x/helper.c | 4 ++++
> target/s390x/sigp.c | 1 +
> 2 files changed, 5 insertions(+)
>
> diff --git a/target/s390x/helper.c b/target/s390x/helper.c
> index a3a49164e4..3800c4b395 100644
> --- a/target/s390x/helper.c
> +++ b/target/s390x/helper.c
> @@ -246,6 +246,10 @@ int s390_store_status(S390CPU *cpu, hwaddr addr, bool store_arch)
> hwaddr len = sizeof(*sa);
> int i;
>
> + if (cpu->env.pv) {
> + return 0;
> + }
> +
> sa = cpu_physical_memory_map(addr, &len, 1);
> if (!sa) {
> return -EFAULT;
> diff --git a/target/s390x/sigp.c b/target/s390x/sigp.c
> index c604f17710..da0cfb97de 100644
> --- a/target/s390x/sigp.c
> +++ b/target/s390x/sigp.c
> @@ -497,6 +497,7 @@ void do_stop_interrupt(CPUS390XState *env)
> if (s390_cpu_set_state(S390_CPU_STATE_STOPPED, cpu) == 0) {
> qemu_system_shutdown_request(SHUTDOWN_CAUSE_GUEST_SHUTDOWN);
> }
> + /* Storing will occur on next SIE entry for fmt 4 */
What's fmt 4?
> if (cpu->env.sigp_order == SIGP_STOP_STORE_STATUS) {
> s390_store_status(cpu, S390_STORE_STATUS_DEF_ADDR, true);
> }
^ permalink raw reply
* Re: [dpdk-dev] [PATCH 2/4] ci: fix Travis config warnings
From: Thomas Monjalon @ 2020-02-20 11:03 UTC (permalink / raw)
To: David Marchand; +Cc: aconole, dev, Michael Santana
In-Reply-To: <20200219194131.29417-3-david.marchand@redhat.com>
19/02/2020 20:41, David Marchand:
> Reading https://config.travis-ci.com/ and using
> https://config.travis-ci.com/explore to check changes, we can cleanup
> some warnings reported by the config validation options in Travis.
For documentation purpose, would be good to describe issues in the commit log.
^ permalink raw reply
* Re: [PATCH 01/19] vfs: syscall: Add fsinfo() to query filesystem information [ver #16]
From: David Howells @ 2020-02-20 11:03 UTC (permalink / raw)
To: Jann Horn
Cc: dhowells, Al Viro, raven, Miklos Szeredi, Christian Brauner,
Linux API, linux-fsdevel, kernel list
In-Reply-To: <CAG48ez0o3iHjQJNvh8V2Ao77g0CqfqGsv6caMCOFDy7w-VdtkQ@mail.gmail.com>
Jann Horn <jannh@google.com> wrote:
> > +int fsinfo_string(const char *s, struct fsinfo_context *ctx)
> ...
> Please add a check here to ensure that "ret" actually fits into the
> buffer (and use WARN_ON() if you think the check should never fire).
> Otherwise I think this is too fragile.
How about:
int fsinfo_string(const char *s, struct fsinfo_context *ctx)
{
unsigned int len;
char *p = ctx->buffer;
int ret = 0;
if (s) {
len = strlen(s);
if (len > ctx->buf_size - 1)
len = ctx->buf_size;
if (!ctx->want_size_only) {
memcpy(p, s, len);
p[len] = 0;
}
ret = len;
}
return ret;
}
I've also added a check to eliminate the copy if userspace didn't actually
supply a buffer.
> > + ret = vfs_statfs(path, &buf);
> > + if (ret < 0 && ret != -ENOSYS)
> > + return ret;
> ...
> > + memcpy(&p->f_fsid, &buf.f_fsid, sizeof(p->f_fsid));
>
> What's going on here? If vfs_statfs() returns -ENOSYS, we just use the
> (AFAICS uninitialized) buf.f_fsid anyway in the memcpy() below and
> return it to userspace?
Good point. I've made the access to the buffer contingent on ret==0. If I
don't set it, it will just be left pre-cleared.
> > + return sizeof(*attr);
>
> I think you meant sizeof(*info).
Yes. I've renamed the buffer point to "p" in all cases so that it's more
obvious.
> > + return ctx->usage;
>
> It is kind of weird that you have to return the ctx->usage everywhere
> even though the caller already has ctx...
At this point, it's only used and returned by fsinfo_attributes() and really
is only for the use of the attribute getter function.
I could, I suppose, return the amount of data in ctx->usage and then preset it
for VSTRUCT-type objects. Unfortunately, I can't make the getter return void
since it might have to return an error.
> > + ctx->buffer = kvmalloc(ctx->buf_size, GFP_KERNEL);
>
> ctx->buffer is _almost_ always pre-zeroed (see vfs_do_fsinfo() below),
> except if we have FSINFO_TYPE_OPAQUE or FSINFO_TYPE_LIST with a size
> bigger than what the attribute's ->size field said? Is that
> intentional?
Fixed.
> > +struct fsinfo_attribute {
> > + unsigned int attr_id; /* The ID of the attribute */
> > + enum fsinfo_value_type type:8; /* The type of the attribute's value(s) */
> > + unsigned int flags:8;
> > + unsigned int size:16; /* - Value size (FSINFO_STRUCT) */
> > + unsigned int element_size:16; /* - Element size (FSINFO_LIST) */
> > + int (*get)(struct path *path, struct fsinfo_context *params);
> > +};
>
> Why the bitfields? It doesn't look like that's going to help you much,
> you'll just end up with 6 bytes of holes on x86-64:
Expanding them to non-bitfields will require an extra 10 bytes, making the
struct 8 bytes bigger with 4 bytes of padding. I can do that if you'd rather.
David
^ permalink raw reply
* Re: [PATCH v6 2/4] tty: rename tty_kopen() and add new function tty_kopen_shared()
From: Uwe Kleine-König @ 2020-02-20 11:04 UTC (permalink / raw)
To: Johan Hovold
Cc: kernel, linux-serial, Greg Kroah-Hartman, linux-kernel,
Dan Murphy, Pavel Machek, Jiri Slaby, linux-leds,
Jacek Anaszewski
In-Reply-To: <20200219171759.GE32540@localhost>
On Wed, Feb 19, 2020 at 06:17:59PM +0100, Johan Hovold wrote:
> On Wed, Feb 19, 2020 at 05:37:58PM +0100, Uwe Kleine-König wrote:
> > On Wed, Feb 19, 2020 at 02:21:13PM +0100, Johan Hovold wrote:
> > > On Thu, Feb 13, 2020 at 10:15:58AM +0100, Uwe Kleine-König wrote:
> > > > From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > > >
> > > > Introduce a new function tty_kopen_shared() that yields a struct
> > > > tty_struct. The semantic difference to tty_kopen() is that the tty is
> > > > expected to be used already. So rename tty_kopen() to
> > > > tty_kopen_exclusive() for clearness, adapt the single user and put the
> > > > common code in a new static helper function.
> > > >
> > > > tty_kopen_shared is to be used to implement an LED trigger for tty
> > > > devices in one of the next patches.
> > > >
> > > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > > > ---
> > >
> > > > -/**
> > > > - * tty_kopen - open a tty device for kernel
> > > > - * @device: dev_t of device to open
> > > > - *
> > > > - * Opens tty exclusively for kernel. Performs the driver lookup,
> > > > - * makes sure it's not already opened and performs the first-time
> > > > - * tty initialization.
> > > > - *
> > > > - * Returns the locked initialized &tty_struct
> > > > - *
> > > > - * Claims the global tty_mutex to serialize:
> > > > - * - concurrent first-time tty initialization
> > > > - * - concurrent tty driver removal w/ lookup
> > > > - * - concurrent tty removal from driver table
> > > > - */
> > > > -struct tty_struct *tty_kopen(dev_t device)
> > > > +static struct tty_struct *tty_kopen(dev_t device, int shared)
> > > > {
> > > > struct tty_struct *tty;
> > > > struct tty_driver *driver;
> > > > @@ -1905,7 +1890,7 @@ struct tty_struct *tty_kopen(dev_t device)
> > > >
> > > > /* check whether we're reopening an existing tty */
> > > > tty = tty_driver_lookup_tty(driver, NULL, index);
> > > > - if (IS_ERR(tty))
> > > > + if (IS_ERR(tty) || shared)
> > >
> > > So here you skip initialisation and return NULL if the tty isn't already
> > > in use (e.g. is open) when shared is set.
> >
> > Which is good, right? If I remember my tests correctly this even works
> > if the tty isn't opened but just "exists".
>
> No, this means that your trigger will never be installed unless the port
> is already open, yet the sysfs interface still returns success (see
> patch 4/4 dev_store()).
Ah I think I see. tty_driver_lookup_tty() might return NULL which for
the trigger driver indicates that tty_kopen_shared should be retried,
right?
> Note that the struct tty doesn't exist until the port is opened; it's
> allocated in tty_init_dev() that you skip above when "shared" is set.
That needs fixing. I will try to resolve the dialog with Andy before
addressing that in the next iteration.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
^ permalink raw reply
* [dpdk-dev] [PATCH] crypto/nitrox: fix coverity defects
From: Nagadheeraj Rottela @ 2020-02-20 11:04 UTC (permalink / raw)
To: akhil.goyal; +Cc: dev, jsrikanth, Nagadheeraj Rottela
Address the defects reported by coverity: Unintended sign extension
and Out-of-bounds access.
Coverity issue: 349899, 349905, 349911, 349921, 349923, 349926
Fixes: 32e4930d5a3b ("crypto/nitrox: add hardware queue management")
Fixes: 9fdef0cc2385 ("crypto/nitrox: create symmetric cryptodev")
Signed-off-by: Nagadheeraj Rottela <rnagadheeraj@marvell.com>
---
drivers/crypto/nitrox/nitrox_csr.h | 18 +++++++++---------
drivers/crypto/nitrox/nitrox_sym.c | 3 ++-
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/crypto/nitrox/nitrox_csr.h b/drivers/crypto/nitrox/nitrox_csr.h
index 8cd92e38b..b4c969b26 100644
--- a/drivers/crypto/nitrox/nitrox_csr.h
+++ b/drivers/crypto/nitrox/nitrox_csr.h
@@ -12,15 +12,15 @@
#define NITROX_CSR_ADDR(bar_addr, offset) (bar_addr + (offset))
/* NPS packet registers */
-#define NPS_PKT_IN_INSTR_CTLX(_i) (0x10060 + ((_i) * 0x40000))
-#define NPS_PKT_IN_INSTR_BADDRX(_i) (0x10068 + ((_i) * 0x40000))
-#define NPS_PKT_IN_INSTR_RSIZEX(_i) (0x10070 + ((_i) * 0x40000))
-#define NPS_PKT_IN_DONE_CNTSX(_i) (0x10080 + ((_i) * 0x40000))
-#define NPS_PKT_IN_INSTR_BAOFF_DBELLX(_i) (0x10078 + ((_i) * 0x40000))
-#define NPS_PKT_IN_INT_LEVELSX(_i) (0x10088 + ((_i) * 0x40000))
-#define NPS_PKT_SLC_CTLX(_i) (0x10000 + ((_i) * 0x40000))
-#define NPS_PKT_SLC_CNTSX(_i) (0x10008 + ((_i) * 0x40000))
-#define NPS_PKT_SLC_INT_LEVELSX(_i) (0x10010 + ((_i) * 0x40000))
+#define NPS_PKT_IN_INSTR_CTLX(_i) (0x10060UL + ((_i) * 0x40000UL))
+#define NPS_PKT_IN_INSTR_BADDRX(_i) (0x10068UL + ((_i) * 0x40000UL))
+#define NPS_PKT_IN_INSTR_RSIZEX(_i) (0x10070UL + ((_i) * 0x40000UL))
+#define NPS_PKT_IN_DONE_CNTSX(_i) (0x10080UL + ((_i) * 0x40000UL))
+#define NPS_PKT_IN_INSTR_BAOFF_DBELLX(_i) (0x10078UL + ((_i) * 0x40000UL))
+#define NPS_PKT_IN_INT_LEVELSX(_i) (0x10088UL + ((_i) * 0x40000UL))
+#define NPS_PKT_SLC_CTLX(_i) (0x10000UL + ((_i) * 0x40000UL))
+#define NPS_PKT_SLC_CNTSX(_i) (0x10008UL + ((_i) * 0x40000UL))
+#define NPS_PKT_SLC_INT_LEVELSX(_i) (0x10010UL + ((_i) * 0x40000UL))
/* AQM Virtual Function Registers */
#define AQMQ_QSZX(_i) (0x20008 + ((_i)*0x40000))
diff --git a/drivers/crypto/nitrox/nitrox_sym.c b/drivers/crypto/nitrox/nitrox_sym.c
index 56410c44d..d1b32fec9 100644
--- a/drivers/crypto/nitrox/nitrox_sym.c
+++ b/drivers/crypto/nitrox/nitrox_sym.c
@@ -683,7 +683,8 @@ nitrox_sym_pmd_create(struct nitrox_device *ndev)
struct rte_cryptodev *cdev;
rte_pci_device_name(&ndev->pdev->addr, name, sizeof(name));
- snprintf(name + strlen(name), RTE_CRYPTODEV_NAME_MAX_LEN, "_n5sym");
+ snprintf(name + strlen(name), RTE_CRYPTODEV_NAME_MAX_LEN - strlen(name),
+ "_n5sym");
ndev->rte_sym_dev.driver = &nitrox_rte_sym_drv;
ndev->rte_sym_dev.numa_node = ndev->pdev->device.numa_node;
ndev->rte_sym_dev.devargs = NULL;
--
2.13.6
^ permalink raw reply related
* Re: [PATCH nf-next v4 0/9] nftables: Set implementation for arbitrary concatenation of ranges
From: Stefano Brivio @ 2020-02-20 11:04 UTC (permalink / raw)
To: Phil Sutter
Cc: Pablo Neira Ayuso, netfilter-devel, Florian Westphal,
Kadlecsik József, Eric Garver
In-Reply-To: <20200220105240.GG20005@orbyte.nwl.cc>
Hi Phil,
On Thu, 20 Feb 2020 11:52:41 +0100
Phil Sutter <phil@nwl.cc> wrote:
> Hi Stefano,
>
> When playing with adding multiple elements, I suddenly noticed a
> disturbance in the force (general protection fault). Here's a
> reproducer:
>
> | $NFT -f - <<EOF
> | table t {
> | set s {
> | type ipv4_addr . inet_service
> | flags interval
> | }
> | }
> | EOF
> |
> | $NFT add element t s '{ 10.0.0.1 . 22-25, 10.0.0.1 . 10-20 }'
> | $NFT flush set t s
> | $NFT add element t s '{ 10.0.0.1 . 10-20, 10.0.0.1 . 22-25 }'
>
> It is pretty reliable, though sometimes needs a second call. Looks like some
> things going on in parallel which shouldn't. Here's a typical last breath:
>
> [ 71.319848] general protection fault, probably for non-canonical address 0x6f6b6e696c2e756e: 0000 [#1] PREEMPT SMP PTI
> [ 71.321540] CPU: 3 PID: 1201 Comm: kworker/3:2 Not tainted 5.6.0-rc1-00377-g2bb07f4e1d861 #192
> [ 71.322746] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190711_202441-buildvm-armv7-10.arm.fedoraproject.org-2.fc31 04/01/2014
> [ 71.324430] Workqueue: events nf_tables_trans_destroy_work [nf_tables]
> [ 71.325387] RIP: 0010:nft_set_elem_destroy+0xa5/0x110 [nf_tables]
Ouch, thanks for reporting, I'll check in a few hours.
--
Stefano
^ permalink raw reply
* Re: [PATCH v4 3/3] clocksource: Add Low Power STM32 timers driver
From: Daniel Lezcano @ 2020-02-20 11:05 UTC (permalink / raw)
To: Benjamin GAIGNARD, lee.jones@linaro.org, robh+dt@kernel.org,
mark.rutland@arm.com, mcoquelin.stm32@gmail.com, Alexandre TORGUE,
tglx@linutronix.de, Fabrice GASNIER
Cc: devicetree@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Benjamin Gaignard,
Pascal PAILLET-LME
In-Reply-To: <9cc4af9e-27d0-96c3-b3f1-20c88f89b70a@st.com>
On 20/02/2020 11:45, Benjamin GAIGNARD wrote:
[ ... ]
>>> +{
>>> + struct stm32_lp_private *priv = to_priv(clkevt);
>>> +
>>> + /* disable LPTIMER to be able to write into IER register*/
>>> + regmap_write(priv->reg, STM32_LPTIM_CR, 0);
>>> + /* enable ARR interrupt */
>>> + regmap_write(priv->reg, STM32_LPTIM_IER, STM32_LPTIM_ARRMIE);
>>> + /* enable LPTIMER to be able to write into ARR register */
>>> + regmap_write(priv->reg, STM32_LPTIM_CR, STM32_LPTIM_ENABLE);
>>> + /* set next event counter */
>>> + regmap_write(priv->reg, STM32_LPTIM_ARR, evt);
>>> +
>>> + /* start counter */
>>> + if (is_periodic)
>>> + regmap_write(priv->reg, STM32_LPTIM_CR,
>>> + STM32_LPTIM_CNTSTRT | STM32_LPTIM_ENABLE);
>>> + else
>>> + regmap_write(priv->reg, STM32_LPTIM_CR,
>>> + STM32_LPTIM_SNGSTRT | STM32_LPTIM_ENABLE);
>> The regmap config in stm32-lptimer is not defined with the fast_io flag
>> (on purpose or not?) that means we can potentially deadlock here as the
>> lock is a mutex.
>>
>> Isn't it detected with the lock validation scheme?
> It wasn't a problem with other parts of the mfd and I don't notice
> issues so I guess it is ok.
Given your comment below, the case can't happen I agree but there is
still a heavy operation with the locking.
>>> + return 0;
>>> +}
>>> +static int stm32_clkevent_lp_remove(struct platform_device *pdev)
>>> +{
>>> + return -EBUSY; /* cannot unregister clockevent */
>>> +}
>> Won't be the mfd into an inconsistent state here? The other subsystems
>> will be removed but this one will prevent to unload the module leading
>> to a situation where the mfd is partially removed but still there
>> without a possible recovery, no?
> We can't enable the timer part of the mfd at the same time than the
> other features.
Hmm, interesting case. The DT binding does not give this information,
especially in the example. You should fix the DT by giving two examples IMO.
Rob, how do you describe this situation (exclusive properties)?
> It has be exclusive and that exclude the problem you describe above.
Ok, the regmap_write is not a free operation and in this case you can
get rid of all the regmap-ish in this driver.
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: [dpdk-dev] [PATCH 3/4] ci: use an explicit list of Travis jobs
From: Thomas Monjalon @ 2020-02-20 11:05 UTC (permalink / raw)
To: David Marchand; +Cc: aconole, dev, Michael Santana
In-Reply-To: <20200219194131.29417-4-david.marchand@redhat.com>
19/02/2020 20:41, David Marchand:
> Maintaining the .travis.yml requires some knowledge of how Travis
> computes the jobs list (combination of os: arch: compiler: etc...).
> Let's switch to an explicit list to find all jobs at a glance.
>
> To enhance readability, jobs have been sorted per arch/compiler with
> comments to isolate blocks.
>
> Setting required_packages for aarch64 native jobs is unnecessary,
> the global addons: values are the same.
>
> This commit does not change the jobs list (21 jobs in total).
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
Thank you for thinking to poor humans like me with no Travis-fu skill.
^ permalink raw reply
* Re: [PATCH v2] mm: kmemleak: Use address-of operator on section symbols
From: Catalin Marinas @ 2020-02-20 11:05 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Andrew Morton, linux-mm, linux-kernel, clang-built-linux,
Nick Desaulniers
In-Reply-To: <20200220051551.44000-1-natechancellor@gmail.com>
On Wed, Feb 19, 2020 at 10:15:51PM -0700, Nathan Chancellor wrote:
> Clang warns:
>
> These are not true arrays, they are linker defined symbols, which are
> just addresses. Using the address of operator silences the warning and
> does not change the resulting assembly with either clang/ld.lld or
> gcc/ld (tested with diff + objdump -Dr).
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/895
> Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* Re: [PATCH v4 3/3] clocksource: Add Low Power STM32 timers driver
From: Daniel Lezcano @ 2020-02-20 11:05 UTC (permalink / raw)
To: Benjamin GAIGNARD, lee.jones@linaro.org, robh+dt@kernel.org,
mark.rutland@arm.com, mcoquelin.stm32@gmail.com, Alexandre TORGUE,
tglx@linutronix.de, Fabrice GASNIER
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Pascal PAILLET-LME, Benjamin Gaignard,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <9cc4af9e-27d0-96c3-b3f1-20c88f89b70a@st.com>
On 20/02/2020 11:45, Benjamin GAIGNARD wrote:
[ ... ]
>>> +{
>>> + struct stm32_lp_private *priv = to_priv(clkevt);
>>> +
>>> + /* disable LPTIMER to be able to write into IER register*/
>>> + regmap_write(priv->reg, STM32_LPTIM_CR, 0);
>>> + /* enable ARR interrupt */
>>> + regmap_write(priv->reg, STM32_LPTIM_IER, STM32_LPTIM_ARRMIE);
>>> + /* enable LPTIMER to be able to write into ARR register */
>>> + regmap_write(priv->reg, STM32_LPTIM_CR, STM32_LPTIM_ENABLE);
>>> + /* set next event counter */
>>> + regmap_write(priv->reg, STM32_LPTIM_ARR, evt);
>>> +
>>> + /* start counter */
>>> + if (is_periodic)
>>> + regmap_write(priv->reg, STM32_LPTIM_CR,
>>> + STM32_LPTIM_CNTSTRT | STM32_LPTIM_ENABLE);
>>> + else
>>> + regmap_write(priv->reg, STM32_LPTIM_CR,
>>> + STM32_LPTIM_SNGSTRT | STM32_LPTIM_ENABLE);
>> The regmap config in stm32-lptimer is not defined with the fast_io flag
>> (on purpose or not?) that means we can potentially deadlock here as the
>> lock is a mutex.
>>
>> Isn't it detected with the lock validation scheme?
> It wasn't a problem with other parts of the mfd and I don't notice
> issues so I guess it is ok.
Given your comment below, the case can't happen I agree but there is
still a heavy operation with the locking.
>>> + return 0;
>>> +}
>>> +static int stm32_clkevent_lp_remove(struct platform_device *pdev)
>>> +{
>>> + return -EBUSY; /* cannot unregister clockevent */
>>> +}
>> Won't be the mfd into an inconsistent state here? The other subsystems
>> will be removed but this one will prevent to unload the module leading
>> to a situation where the mfd is partially removed but still there
>> without a possible recovery, no?
> We can't enable the timer part of the mfd at the same time than the
> other features.
Hmm, interesting case. The DT binding does not give this information,
especially in the example. You should fix the DT by giving two examples IMO.
Rob, how do you describe this situation (exclusive properties)?
> It has be exclusive and that exclude the problem you describe above.
Ok, the regmap_write is not a free operation and in this case you can
get rid of all the regmap-ish in this driver.
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] xfs: add agf freeblocks verify in xfs_agf_verify
From: Zheng Bin @ 2020-02-20 11:13 UTC (permalink / raw)
To: sandeen, bfoster, dchinner, darrick.wong, linux-xfs; +Cc: renxudong1, yi.zhang
We recently used fuzz(hydra) to test XFS and automatically generate
tmp.img(XFS v5 format, but some metadata is wrong)
xfs_repair information(just one AG):
agf_freeblks 0, counted 3224 in ag 0
agf_longest 536874136, counted 3224 in ag 0
sb_fdblocks 613, counted 3228
Test as follows:
mount tmp.img tmpdir
cp file1M tmpdir
sync
In 4.19-stable, sync will stuck, the reason is:
xfs_mountfs
xfs_check_summary_counts
if ((!xfs_sb_version_haslazysbcount(&mp->m_sb) ||
XFS_LAST_UNMOUNT_WAS_CLEAN(mp)) &&
!xfs_fs_has_sickness(mp, XFS_SICK_FS_COUNTERS))
return 0; -->just return, incore sb_fdblocks still be 613
xfs_initialize_perag_data
cp file1M tmpdir -->ok(write file to pagecache)
sync -->stuck(write pagecache to disk)
xfs_map_blocks
xfs_iomap_write_allocate
while (count_fsb != 0) {
nimaps = 0;
while (nimaps == 0) { --> endless loop
nimaps = 1;
xfs_bmapi_write(..., &nimaps) --> nimaps becomes 0 again
xfs_bmapi_write
xfs_bmap_alloc
xfs_bmap_btalloc
xfs_alloc_vextent
xfs_alloc_fix_freelist
xfs_alloc_space_available -->fail(agf_freeblks is 0)
In linux-next, sync not stuck, cause commit c2b3164320b5 ("xfs:
use the latest extent at writeback delalloc conversion time") remove
the above while, dmesg is as follows:
[ 55.250114] XFS (loop0): page discard on page ffffea0008bc7380, inode 0x1b0c, offset 0.
Users do not know why this page is discard, the better soultion is:
1. Like xfs_repair, make sure sb_fdblocks is equal to counted
(xfs_initialize_perag_data did this, who is not called at this mount)
2. Add agf verify, if fail, will tell users to repair
This patch use the second soultion.
Signed-off-by: Zheng Bin <zhengbin13@huawei.com>
Signed-off-by: Ren Xudong <renxudong1@huawei.com>
---
v1->v2: modify comment, add more agf verify
fs/xfs/libxfs/xfs_alloc.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/fs/xfs/libxfs/xfs_alloc.c b/fs/xfs/libxfs/xfs_alloc.c
index d8053bc..5faed42 100644
--- a/fs/xfs/libxfs/xfs_alloc.c
+++ b/fs/xfs/libxfs/xfs_alloc.c
@@ -2839,6 +2839,7 @@ xfs_agf_verify(
{
struct xfs_mount *mp = bp->b_mount;
struct xfs_agf *agf = XFS_BUF_TO_AGF(bp);
+ int i;
if (xfs_sb_version_hascrc(&mp->m_sb)) {
if (!uuid_equal(&agf->agf_uuid, &mp->m_sb.sb_meta_uuid))
@@ -2858,6 +2859,22 @@ xfs_agf_verify(
be32_to_cpu(agf->agf_flcount) <= xfs_agfl_size(mp)))
return __this_address;
+ if (be32_to_cpu(agf->agf_length) > mp->m_sb.sb_dblocks ||
+ be32_to_cpu(agf->agf_btreeblks) > be32_to_cpu(agf->agf_length) ||
+ be32_to_cpu(agf->agf_rmap_blocks) > be32_to_cpu(agf->agf_length) ||
+ be32_to_cpu(agf->agf_refcount_blocks) > be32_to_cpu(agf->agf_length) ||
+ be32_to_cpu(agf->agf_spare2) != 0)
+ return __this_address;
+
+ for (i = 0; i < ARRAY_SIZE(agf->agf_spare64); i++)
+ if (be64_to_cpu(agf->agf_spare64[i]) != 0)
+ return __this_address;
+
+ if (be32_to_cpu(agf->agf_freeblks) < be32_to_cpu(agf->agf_longest) ||
+ be32_to_cpu(agf->agf_freeblks) > be32_to_cpu(agf->agf_length) ||
+ be32_to_cpu(agf->agf_freeblks) > mp->m_sb.sb_fdblocks)
+ return __this_address;
+
if (be32_to_cpu(agf->agf_levels[XFS_BTNUM_BNO]) < 1 ||
be32_to_cpu(agf->agf_levels[XFS_BTNUM_CNT]) < 1 ||
be32_to_cpu(agf->agf_levels[XFS_BTNUM_BNO]) > XFS_BTREE_MAXLEVELS ||
--
2.7.4
^ permalink raw reply related
* Re: [cip-dev] : isar-cip-core and cip-kernel-config
From: Chris Paterson @ 2020-02-20 11:06 UTC (permalink / raw)
To: Gylstorff Quirin, cip-dev@lists.cip-project.org,
Kiszka, Jan (CT RDA IOT SES-DE)
In-Reply-To: <ca39ce48-8602-0e79-99af-2f44200e2b12@siemens.com>
Hello Quirin,
> From: Gylstorff Quirin <quirin.gylstorff@siemens.com>
> Sent: 18 February 2020 16:20
>
> Hi all,
>
> I am currently trying to have all targets in isar-cip-core running with
> the matching configuration from cip-kernel-config. For some targets
> there are missing config entries to boot Debian 10 e.g. [1].
>
> Should I add these configuration directly to the matching defconfig in
> cip-kernel-config or add new defconfig/snippets for isar-cip-core?
Good question.
I think cip-kernel-config was created to help the CIP maintainers know what configurations etc. to support/maintain.
How will it affect the maintainers if we start adding config options that are only required for testing, rather then for SLTS support? (Or do we technically also need SLTS support for the 'test' config options?)
>
> Currently I am adding them directly to the defconfigs as it is IHMO
> more manageable as it avoid snippets/configs all over the place.
Would another option be to have complete configurations for testing, rather than just the extra snippets?
It would mean we need to maintain two copies of mostly the same thing, but it'll make scripting easier and be clear what is for the Kernel maintainers and what is for testing.
Would it be possible to use the same 'testing' configurations/snippets for both deby and isar versions of cip-core?
Kind regards, Chris
>
> [1]:
> https://gitlab.com/Quirin.Gy/cip-kernel-config/-
> /commit/92979dba2e3c03a422b5b9e8f9c592db9ff43f30
>
> --
> Quirin Gylstorff
>
> Siemens AG
> Corporate Technology
> Research in Digitalization and Automation
> Smart Embedded Systems
> CT RDA IOT SES-DE
> Otto-Hahn-Ring 6
> 81739 Muenchen, Germany
> Mobile: +49 173 3746683
> mailto:quirin.gylstorff@siemens.com
> www.siemens.com/ingenuityforlife
>
> Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim
> Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and
> Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich,
> Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin
> and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB
> 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322
>
> Important notice: This e-mail and any attachment thereof contain
> corporate proprietary information. If you have received it by mistake,
> please notify us immediately by reply e-mail and delete this e-mail and
> its attachments from your system. Thank you.
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev
^ permalink raw reply
* [RFC PATCH 0/3] efi: put an API version number in the PE/COFF header
From: Ard Biesheuvel @ 2020-02-20 11:06 UTC (permalink / raw)
To: linux-efi
Cc: Ard Biesheuvel, lersek, leif, pjones, mjg59, agraf,
ilias.apalodimas, xypron.glpk, daniel.kiper, nivedita,
James.Bottomley
After having added new ways to load the initrd and the mixed mode kernel,
we will need to tell the loader about this, so it can use the new, generic
method if supported, and fall back to the existing method(s) otherwise.
This is an RFC - if there are better ways to record this in the image
somehow, please shout.
Cc: lersek@redhat.com
Cc: leif@nuviainc.com
Cc: pjones@redhat.com
Cc: mjg59@google.com
Cc: agraf@csgraf.de
Cc: ilias.apalodimas@linaro.org
Cc: xypron.glpk@gmx.de
Cc: daniel.kiper@oracle.com
Cc: nivedita@alum.mit.edu
Cc: James.Bottomley@hansenpartnership.com
Ard Biesheuvel (3):
efi/x86: Use symbolic constants in PE header instead of bare numbers
efi/libstub: Introduce symbolic constants for the stub major/minor
version
efi: Bump the Linux EFI stub major version number to #1
arch/arm/boot/compressed/efi-header.S | 4 +-
arch/arm64/kernel/efi-header.S | 4 +-
arch/x86/boot/header.S | 64 ++++++++++----------
include/linux/pe.h | 21 +++++++
4 files changed, 58 insertions(+), 35 deletions(-)
--
2.17.1
^ permalink raw reply
* [RFC PATCH 1/3] efi/x86: Use symbolic constants in PE header instead of bare numbers
From: Ard Biesheuvel @ 2020-02-20 11:06 UTC (permalink / raw)
To: linux-efi
Cc: Ard Biesheuvel, lersek, leif, pjones, mjg59, agraf,
ilias.apalodimas, xypron.glpk, daniel.kiper, nivedita,
James.Bottomley
In-Reply-To: <20200220110649.1303-1-ardb@kernel.org>
Replace bare numbers in the PE/COFF header structure with symbolic
constants so they become self documenting.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
| 60 ++++++++++----------
1 file changed, 31 insertions(+), 29 deletions(-)
--git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 44aeb63ca6ae..9110b58aa2ec 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -15,7 +15,7 @@
* hex while segment addresses are written as segment:offset.
*
*/
-
+#include <linux/pe.h>
#include <asm/segment.h>
#include <asm/boot.h>
#include <asm/page_types.h>
@@ -43,8 +43,7 @@ SYSSEG = 0x1000 /* historical load address >> 4 */
bootsect_start:
#ifdef CONFIG_EFI_STUB
# "MZ", MS-DOS header
- .byte 0x4d
- .byte 0x5a
+ .word MZ_MAGIC
#endif
# Normalize the start address
@@ -97,39 +96,30 @@ bugger_off_msg:
#ifdef CONFIG_EFI_STUB
pe_header:
- .ascii "PE"
- .word 0
+ .long PE_MAGIC
coff_header:
#ifdef CONFIG_X86_32
- .word 0x14c # i386
+ .set image_file_add_flags, IMAGE_FILE_32BIT_MACHINE
+ .set pe_opt_magic, PE_OPT_MAGIC_PE32
+ .word IMAGE_FILE_MACHINE_I386
#else
- .word 0x8664 # x86-64
+ .set image_file_add_flags, 0
+ .set pe_opt_magic, PE_OPT_MAGIC_PE32PLUS
+ .word IMAGE_FILE_MACHINE_AMD64
#endif
.word section_count # nr_sections
.long 0 # TimeDateStamp
.long 0 # PointerToSymbolTable
.long 1 # NumberOfSymbols
.word section_table - optional_header # SizeOfOptionalHeader
-#ifdef CONFIG_X86_32
- .word 0x306 # Characteristics.
- # IMAGE_FILE_32BIT_MACHINE |
- # IMAGE_FILE_DEBUG_STRIPPED |
- # IMAGE_FILE_EXECUTABLE_IMAGE |
- # IMAGE_FILE_LINE_NUMS_STRIPPED
-#else
- .word 0x206 # Characteristics
- # IMAGE_FILE_DEBUG_STRIPPED |
- # IMAGE_FILE_EXECUTABLE_IMAGE |
- # IMAGE_FILE_LINE_NUMS_STRIPPED
-#endif
+ .word IMAGE_FILE_EXECUTABLE_IMAGE | \
+ image_file_add_flags | \
+ IMAGE_FILE_DEBUG_STRIPPED | \
+ IMAGE_FILE_LINE_NUMS_STRIPPED # Characteristics
optional_header:
-#ifdef CONFIG_X86_32
- .word 0x10b # PE32 format
-#else
- .word 0x20b # PE32+ format
-#endif
+ .word pe_opt_magic
.byte 0x02 # MajorLinkerVersion
.byte 0x14 # MinorLinkerVersion
@@ -170,7 +160,7 @@ extra_header_fields:
.long 0x200 # SizeOfHeaders
.long 0 # CheckSum
- .word 0xa # Subsystem (EFI application)
+ .word IMAGE_SUBSYSTEM_EFI_APPLICATION # Subsystem (EFI application)
.word 0 # DllCharacteristics
#ifdef CONFIG_X86_32
.long 0 # SizeOfStackReserve
@@ -210,7 +200,10 @@ section_table:
.long 0 # PointerToLineNumbers
.word 0 # NumberOfRelocations
.word 0 # NumberOfLineNumbers
- .long 0x60500020 # Characteristics (section flags)
+ .long IMAGE_SCN_CNT_CODE | \
+ IMAGE_SCN_MEM_READ | \
+ IMAGE_SCN_MEM_EXECUTE | \
+ IMAGE_SCN_ALIGN_16BYTES # Characteristics
#
# The EFI application loader requires a relocation section
@@ -228,7 +221,10 @@ section_table:
.long 0 # PointerToLineNumbers
.word 0 # NumberOfRelocations
.word 0 # NumberOfLineNumbers
- .long 0x42100040 # Characteristics (section flags)
+ .long IMAGE_SCN_CNT_INITIALIZED_DATA | \
+ IMAGE_SCN_MEM_READ | \
+ IMAGE_SCN_MEM_DISCARDABLE | \
+ IMAGE_SCN_ALIGN_1BYTES # Characteristics
#ifdef CONFIG_EFI_MIXED
#
@@ -244,7 +240,10 @@ section_table:
.long 0 # PointerToLineNumbers
.word 0 # NumberOfRelocations
.word 0 # NumberOfLineNumbers
- .long 0x42100040 # Characteristics (section flags)
+ .long IMAGE_SCN_CNT_INITIALIZED_DATA | \
+ IMAGE_SCN_MEM_READ | \
+ IMAGE_SCN_MEM_DISCARDABLE | \
+ IMAGE_SCN_ALIGN_1BYTES # Characteristics
#endif
#
@@ -263,7 +262,10 @@ section_table:
.long 0 # PointerToLineNumbers
.word 0 # NumberOfRelocations
.word 0 # NumberOfLineNumbers
- .long 0x60500020 # Characteristics (section flags)
+ .long IMAGE_SCN_CNT_CODE | \
+ IMAGE_SCN_MEM_READ | \
+ IMAGE_SCN_MEM_EXECUTE | \
+ IMAGE_SCN_ALIGN_16BYTES # Characteristics
.set section_count, (. - section_table) / 40
#endif /* CONFIG_EFI_STUB */
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] bdi: fix use-after-free for bdi device
From: Yufen Yu @ 2020-02-20 11:07 UTC (permalink / raw)
To: Jan Kara; +Cc: Tejun Heo, axboe, linux-block, bvanassche
In-Reply-To: <20200219125505.GP16121@quack2.suse.cz>
Hi,
On 2020/2/19 20:55, Jan Kara wrote:
> Hi!
>
> On Sat 15-02-20 21:54:08, Yufen Yu wrote:
>
> I've now noticed there's commit 68f23b8906 "memcg: fix a crash in wb_workfn
> when a device disappears" from end of January which tries to address the
> issue you're looking into. Now AFAIU the code is till somewhat racy after
> that commit so I wanted to mention this mostly so that you fixup also the
> new bdi_dev_name() while you're fixing blkg_dev_name().
>
> Also I was wondering about one thing: If we really care about bdi->dev only
> for the name, won't we be much better off with just copying the name to
> bdi->name on registration? Sure it would consume a bit of memory for the
> name copy but I don't think we really care and things would be IMO *much*
> simpler that way... Yufen, Tejun, what do you think?
>
I think copying the name to bdi->name is also need protected by lock.
Otherwise, the reader of bdi->name may read incorrect value when
re-registion have not copy the name completely. Right? So, I also think
using RCU to protect object lifetimes may be a better way.
Thanks,
Yufen
^ permalink raw reply
* [RFC PATCH 2/3] efi/libstub: Introduce symbolic constants for the stub major/minor version
From: Ard Biesheuvel @ 2020-02-20 11:06 UTC (permalink / raw)
To: linux-efi
Cc: Ard Biesheuvel, lersek, leif, pjones, mjg59, agraf,
ilias.apalodimas, xypron.glpk, daniel.kiper, nivedita,
James.Bottomley
In-Reply-To: <20200220110649.1303-1-ardb@kernel.org>
Now that we have added new ways to load the initrd or the mixed mode
kernel, we will also need a way to tell the loader about this. Add
symbolic constants for the PE/COFF major/minor version numbers (which
fortunately have always been 0x0 for all architectures), so that we
can bump them later to document the capabilities of the stub.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
| 4 ++--
| 4 ++--
| 4 ++--
include/linux/pe.h | 3 +++
4 files changed, 9 insertions(+), 6 deletions(-)
--git a/arch/arm/boot/compressed/efi-header.S b/arch/arm/boot/compressed/efi-header.S
index e38fbda02b93..62286da318e7 100644
--- a/arch/arm/boot/compressed/efi-header.S
+++ b/arch/arm/boot/compressed/efi-header.S
@@ -70,8 +70,8 @@ extra_header_fields:
.long SZ_512 @ FileAlignment
.short 0 @ MajorOsVersion
.short 0 @ MinorOsVersion
- .short 0 @ MajorImageVersion
- .short 0 @ MinorImageVersion
+ .short LINUX_EFISTUB_MAJOR_VERSION @ MajorImageVersion
+ .short LINUX_EFISTUB_MINOR_VERSION @ MinorImageVersion
.short 0 @ MajorSubsystemVersion
.short 0 @ MinorSubsystemVersion
.long 0 @ Win32VersionValue
--git a/arch/arm64/kernel/efi-header.S b/arch/arm64/kernel/efi-header.S
index 40c704c5d3a5..914999ccaf8a 100644
--- a/arch/arm64/kernel/efi-header.S
+++ b/arch/arm64/kernel/efi-header.S
@@ -36,8 +36,8 @@ extra_header_fields:
.long PECOFF_FILE_ALIGNMENT // FileAlignment
.short 0 // MajorOperatingSystemVersion
.short 0 // MinorOperatingSystemVersion
- .short 0 // MajorImageVersion
- .short 0 // MinorImageVersion
+ .short LINUX_EFISTUB_MAJOR_VERSION // MajorImageVersion
+ .short LINUX_EFISTUB_MINOR_VERSION // MinorImageVersion
.short 0 // MajorSubsystemVersion
.short 0 // MinorSubsystemVersion
.long 0 // Win32VersionValue
--git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 9110b58aa2ec..a87d788ea54e 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -147,8 +147,8 @@ extra_header_fields:
.long 0x20 # FileAlignment
.word 0 # MajorOperatingSystemVersion
.word 0 # MinorOperatingSystemVersion
- .word 0 # MajorImageVersion
- .word 0 # MinorImageVersion
+ .word LINUX_EFISTUB_MAJOR_VERSION # MajorImageVersion
+ .word LINUX_EFISTUB_MINOR_VERSION # MinorImageVersion
.word 0 # MajorSubsystemVersion
.word 0 # MinorSubsystemVersion
.long 0 # Win32VersionValue
diff --git a/include/linux/pe.h b/include/linux/pe.h
index c86bd3a2f70f..e0869f3eadd6 100644
--- a/include/linux/pe.h
+++ b/include/linux/pe.h
@@ -10,6 +10,9 @@
#include <linux/types.h>
+#define LINUX_EFISTUB_MAJOR_VERSION 0x0
+#define LINUX_EFISTUB_MINOR_VERSION 0x0
+
#define MZ_MAGIC 0x5a4d /* "MZ" */
#define PE_MAGIC 0x00004550 /* "PE\0\0" */
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 4/4] crypto: hisilicon/sec2 - Add pbuffer mode for SEC driver
From: John Garry @ 2020-02-20 11:07 UTC (permalink / raw)
To: Xu Zaibo, herbert, davem
Cc: qianweili, tanghui20, forest.zhouchang, linuxarm, zhangwei375,
shenyang39, yekai13, linux-crypto
In-Reply-To: <69fe2d60-428e-9747-b7c0-d69cf25efc0e@huawei.com>
On 20/02/2020 10:10, Xu Zaibo wrote:
> Hi,
>
>
> On 2020/2/20 17:50, John Garry wrote:
>> On 20/02/2020 09:04, Zaibo Xu wrote:
>>> From: liulongfang <liulongfang@huawei.com>
>>>
>>> In the scenario of SMMU translation, the SEC performance of short
>>> messages
>>> (<512Bytes) cannot meet our expectations. To avoid this, we reserve the
>>> plat buffer (PBUF) memory for small packets when creating TFM.
>>>
>>
>> I haven't gone through the code here, but why not use this method also
>> for non-translated? What are the pros and cons?
> Because non-translated has no performance or throughput problems.
>
OK, so no problem, but I was asking could it be improved, and, if so,
what would be the drawbacks?
As for the change to check if the IOMMU is translating, it seems exact
same as that for the hi1616 driver...
> cheers,
> Zaibo
>
> .
>>
>> The commit message is very light on details.
>>
>> Thanks
>> john
>>
>> .
>>
>
>
> .
^ 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.