* [Intel-gfx] ✗ Fi.CI.SPARSE: warning for Refactor Gen11+ SAGV support
From: Patchwork @ 2020-02-20 16:38 UTC (permalink / raw)
To: Stanislav Lisovskiy; +Cc: intel-gfx
In-Reply-To: <20200220120741.6917-1-stanislav.lisovskiy@intel.com>
== Series Details ==
Series: Refactor Gen11+ SAGV support
URL : https://patchwork.freedesktop.org/series/73703/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915: Start passing latency as parameter
Okay!
Commit: drm/i915: Introduce skl_plane_wm_level accessor.
Okay!
Commit: drm/i915: Init obj state in intel_atomic_get_old/new_global_obj_state
Okay!
Commit: drm/i915: Refactor intel_can_enable_sagv
+drivers/gpu/drm/i915/intel_pm.c:3851:6: warning: symbol 'intel_compute_sagv_mask' was not declared. Should it be static?
+drivers/gpu/drm/i915/intel_pm.c:3905:6: warning: symbol 'intel_calculate_sagv_result' was not declared. Should it be static?
Commit: drm/i915: Added required new PCode commands
Okay!
Commit: drm/i915: Restrict qgv points which don't have enough bandwidth.
Okay!
Commit: drm/i915: Enable SAGV support for Gen12
Okay!
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [sdbusplus] To generate a common header for public information of interfaces
From: Patrick Williams @ 2020-02-20 16:38 UTC (permalink / raw)
To: Lei YU; +Cc: OpenBMC Maillist
In-Reply-To: <CAARXrtkwsy3t=bz7wHa=oEG-KwE7dBJ0Upkft-RN9XNgiFdSHA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2668 bytes --]
On Wed, Feb 19, 2020 at 10:59:40AM +0800, Lei YU wrote:
> On Wed, Feb 19, 2020 at 4:39 AM Patrick Williams <patrick@stwcx.xyz> wrote:
> >
> > On Thu, Feb 13, 2020 at 10:38:37PM +0800, Lei YU wrote:
> > I would say any case where this was done should have been fixed. There
> > were already functions in sdbusplus to convert<Enum>ToString and
> > convertForMessage(<Enum>). There are lots of cases where these are
> > being used today[1]. You recently made the interface public as well, so
> > we should begin converting these over.
> >
> > I've also got commits pending, for merge soon, that make the enums be
> > supported as native types, so code should rarely even need to call the
> > "convert" functions anymore. Another refactoring once that is merged.
>
> The idea of my proposal here is not to use "convertXXX" functions,
> instead, it is to provide the constexpr strings that could be used by
> client code.
> E.g. the client code does not need to call any function, but directly use:
>
> * xyz::...::server::MyServer::interface, instead of a user-defined string
> for the interface.
> * xyz::...::MyServer::MyEnum::Enum1, instead of a user-defined string for
> the enum.
I don't see any reason any code should ever directly utilize the enum
strings. We generate code already to safely convert them to and from
real C++ enum types. Why would you want to use string comparison
instead?
Can you elaborate on why we should be enabling this usage pattern?
> Yup, the implementation is actually part of the "client" header, we
> could rename the "common" to "client".
> But preferably, we could combine all the client header into a single
> header, which makes it easier for the client code to use.
> If a client needs to set an enum property to a service, it then does
> not have to include the server header nor the specific client header,
> but include a single header.
> Anyway, this part is done in phosphor-dbus-interface.
>
> So we could say that sdbusplus generates part of the "client" header
> instead of "common" header.
Agree, but we don't even need this code now if people were just
including the server header files (and there are many examples of
clients doing exactly this). If we're not going to create client
headers now, this seems like wasted effort just for some slight syntax
improvement.
We could simply symlink <xyz/openbmc_project/foo/server.hpp> to
<xyz/openbmc_project/foo/client.hpp> and add a `namespace
xyz::openbmc_project::foo::client = xyz::openbmc_project:server;` and
get the same syntactic enhancement without nearly as much work.
--
Patrick Williams
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 04/13] wayland: convert to meson build
From: Alexander Kanavin @ 2020-02-20 16:38 UTC (permalink / raw)
To: Joshua Watt; +Cc: OE-core
In-Reply-To: <CAJdd5GYG+T026v5DUq1j37KBwBwSEq8Y9j56cXaYXwB1m6MFxg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 8060 bytes --]
Thanks for looking into it :)
Alex
On Thu, 20 Feb 2020 at 17:21, Joshua Watt <jpewhacker@gmail.com> wrote:
> On Wed, Feb 19, 2020 at 1:49 PM Alexander Kanavin
> <alex.kanavin@gmail.com> wrote:
> >
> > Replace an autotools-specific .pc adjustment patch with a meson-specific
> one.
>
> This can (and did) break meta-mingw in the autobuilder, but I pushed
> the fix to master-next of meta-mingw
> (
> https://git.yoctoproject.org/cgit/cgit.cgi/meta-mingw/commit/?h=master-next&id=32ccf9d5089694e4a58951ca1a38452f889a27ef
> ),
> so that can be pulled in to try again
>
> >
> > Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
> > ---
> > ...hardcode-the-path-to-wayland-scanner.patch | 26 +++++++++++++++
> > ...-the-native-wayland-scanner-directly.patch | 27 ++++++++++++++++
> > .../wayland/wayland/fixpathinpcfiles.patch | 32 -------------------
> > .../wayland/wayland_1.18.0.bb | 11 ++++---
> > 4 files changed, 59 insertions(+), 37 deletions(-)
> > create mode 100644
> meta/recipes-graphics/wayland/wayland/0002-Do-not-hardcode-the-path-to-wayland-scanner.patch
> > create mode 100644
> meta/recipes-graphics/wayland/wayland/0002-meson.build-find-the-native-wayland-scanner-directly.patch
> > delete mode 100644
> meta/recipes-graphics/wayland/wayland/fixpathinpcfiles.patch
> >
> > diff --git
> a/meta/recipes-graphics/wayland/wayland/0002-Do-not-hardcode-the-path-to-wayland-scanner.patch
> b/meta/recipes-graphics/wayland/wayland/0002-Do-not-hardcode-the-path-to-wayland-scanner.patch
> > new file mode 100644
> > index 0000000000..2199548bdf
> > --- /dev/null
> > +++
> b/meta/recipes-graphics/wayland/wayland/0002-Do-not-hardcode-the-path-to-wayland-scanner.patch
> > @@ -0,0 +1,26 @@
> > +From cbb28635a1079d68e62dbaa1e21791a20dbbbaf4 Mon Sep 17 00:00:00 2001
> > +From: Alexander Kanavin <alex.kanavin@gmail.com>
> > +Date: Mon, 17 Feb 2020 21:46:18 +0100
> > +Subject: [PATCH] Do not hardcode the path to wayland-scanner
> > +
> > +This results in host contamination during builds.
> > +
> > +Upstream-Status: Inappropriate [oe-core specific]
> > +Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
> > +---
> > + src/meson.build | 2 +-
> > + 1 file changed, 1 insertion(+), 1 deletion(-)
> > +
> > +diff --git a/src/meson.build b/src/meson.build
> > +index 294aee0..7e410fa 100644
> > +--- a/src/meson.build
> > ++++ b/src/meson.build
> > +@@ -49,7 +49,7 @@ pkgconfig.generate(
> > + 'datarootdir=' + join_paths('${prefix}',
> get_option('datadir')),
> > + 'pkgdatadir=' + join_paths('${datarootdir}',
> meson.project_name()),
> > + 'bindir=' + join_paths('${prefix}',
> get_option('bindir')),
> > +- 'wayland_scanner=${bindir}/wayland-scanner'
> > ++ 'wayland_scanner=wayland-scanner'
> > + ],
> > + filebase: 'wayland-scanner'
> > + )
> > diff --git
> a/meta/recipes-graphics/wayland/wayland/0002-meson.build-find-the-native-wayland-scanner-directly.patch
> b/meta/recipes-graphics/wayland/wayland/0002-meson.build-find-the-native-wayland-scanner-directly.patch
> > new file mode 100644
> > index 0000000000..f98037a850
> > --- /dev/null
> > +++
> b/meta/recipes-graphics/wayland/wayland/0002-meson.build-find-the-native-wayland-scanner-directly.patch
> > @@ -0,0 +1,27 @@
> > +From 2582d2653ba80917d7bc47088e1a5f49530fddaa Mon Sep 17 00:00:00 2001
> > +From: Alexander Kanavin <alex.kanavin@gmail.com>
> > +Date: Sun, 16 Feb 2020 16:29:53 +0100
> > +Subject: [PATCH] meson.build: find the native wayland-scanner directly
> in PATH
> > +
> > +Otherwise, meson attempts to use the target pkg-config and fails.
> > +
> > +Upstream-Status: Pending
> > +Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
> > +---
> > + src/meson.build | 3 +--
> > + 1 file changed, 1 insertion(+), 2 deletions(-)
> > +
> > +diff --git a/src/meson.build b/src/meson.build
> > +index 3e8c9bf..294aee0 100644
> > +--- a/src/meson.build
> > ++++ b/src/meson.build
> > +@@ -55,8 +55,7 @@ pkgconfig.generate(
> > + )
> > +
> > + if meson.is_cross_build()
> > +- scanner_dep = dependency('wayland-scanner', native: true,
> version: '>=1.14.0')
> > +- wayland_scanner_for_build =
> find_program(scanner_dep.get_pkgconfig_variable('wayland_scanner'))
> > ++ wayland_scanner_for_build = find_program('wayland-scanner')
> > + else
> > + wayland_scanner_for_build = wayland_scanner
> > + endif
> > diff --git
> a/meta/recipes-graphics/wayland/wayland/fixpathinpcfiles.patch
> b/meta/recipes-graphics/wayland/wayland/fixpathinpcfiles.patch
> > deleted file mode 100644
> > index ad3526d984..0000000000
> > --- a/meta/recipes-graphics/wayland/wayland/fixpathinpcfiles.patch
> > +++ /dev/null
> > @@ -1,32 +0,0 @@
> > -Fix wayland-client and wayland-scanner pc files
> > -
> > -Upstream-Status: Pending
> > -
> > -Signed-off-by: Fabien Lahoudere <fabien.lahoudere@collabora.co.uk>
> > -
> > -Index: wayland-1.14.0/src/wayland-client.pc.in
> > -===================================================================
> > ---- wayland-1.14.0.orig/src/wayland-client.pc.in
> > -+++ wayland-1.14.0/src/wayland-client.pc.in
> > -@@ -1,7 +1,7 @@
> > - prefix=@prefix@
> > - exec_prefix=@exec_prefix@
> > - datarootdir=@datarootdir@
> > --pkgdatadir=@datadir@/@PACKAGE@
> > -+pkgdatadir=${pc_sysrootdir}@datadir@/@PACKAGE@
> > - libdir=@libdir@
> > - includedir=@includedir@
> > -
> > -Index: wayland-1.14.0/src/wayland-scanner.pc.in
> > -===================================================================
> > ---- wayland-1.14.0.orig/src/wayland-scanner.pc.in
> > -+++ wayland-1.14.0/src/wayland-scanner.pc.in
> > -@@ -2,7 +2,7 @@ prefix=@prefix@
> > - exec_prefix=@exec_prefix@
> > - datarootdir=@datarootdir@
> > - pkgdatadir=@datadir@/@PACKAGE@
> > --wayland_scanner=@bindir@/wayland-scanner
> > -+wayland_scanner=wayland-scanner
> > -
> > - Name: Wayland Scanner
> > - Description: Wayland scanner
> > diff --git a/meta/recipes-graphics/wayland/wayland_1.18.0.bb
> b/meta/recipes-graphics/wayland/wayland_1.18.0.bb
> > index 7a3f075552..a702b3f6cc 100644
> > --- a/meta/recipes-graphics/wayland/wayland_1.18.0.bb
> > +++ b/meta/recipes-graphics/wayland/wayland_1.18.0.bb
> > @@ -13,20 +13,21 @@ LIC_FILES_CHKSUM =
> "file://COPYING;md5=b31d8f53b6aaf2b4985d7dd7810a70d1 \
> > DEPENDS = "expat libffi wayland-native"
> >
> > SRC_URI = "https://wayland.freedesktop.org/releases/${BPN}-${PV}.tar.xz
> \
> > - file://fixpathinpcfiles.patch \
> > +
> file://0002-meson.build-find-the-native-wayland-scanner-directly.patch \
> > +
> file://0002-Do-not-hardcode-the-path-to-wayland-scanner.patch \
> > "
> > SRC_URI[md5sum] = "23317697b6e3ff2e1ac8c5ba3ed57b65"
> > SRC_URI[sha256sum] =
> "4675a79f091020817a98fd0484e7208c8762242266967f55a67776936c2e294d"
> >
> > UPSTREAM_CHECK_URI = "https://wayland.freedesktop.org/releases.html"
> >
> > -inherit autotools pkgconfig
> > +inherit meson pkgconfig
> >
> > PACKAGECONFIG ??= "dtd-validation"
> > -PACKAGECONFIG[dtd-validation] =
> "--enable-dtd-validation,--disable-dtd-validation,libxml2,,"
> > +PACKAGECONFIG[dtd-validation] =
> "-Ddtd_validation=true,-Ddtd_validation=false,libxml2,,"
> >
> > -EXTRA_OECONF = "--disable-documentation --with-host-scanner"
> > -EXTRA_OECONF_class-native = "--disable-documentation
> --disable-libraries"
> > +EXTRA_OEMESON = "-Ddocumentation=false"
> > +EXTRA_OEMESON_class-native = "-Ddocumentation=false -Dlibraries=false"
> >
> > # Wayland installs a M4 macro for other projects to use, which uses the
> target
> > # pkg-config to find files. Replace pkg-config with pkg-config-native.
> > --
> > 2.25.0
> >
> > --
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
[-- Attachment #2: Type: text/html, Size: 11340 bytes --]
^ permalink raw reply
* Re: [PATCH 11/19] target/arm: Replace ARM_FEATURE_VFP4 with isar_feature_aa32_simdfmac
From: Peter Maydell @ 2020-02-20 16:37 UTC (permalink / raw)
To: Richard Henderson; +Cc: QEMU Developers
In-Reply-To: <20200214181547.21408-12-richard.henderson@linaro.org>
On Fri, 14 Feb 2020 at 18:16, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> All remaining tests for VFP4 are for fused multiply-add insns.
>
> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
> ---
> target/arm/cpu.h | 5 +++++
> target/arm/translate-vfp.inc.c | 12 ++++++++----
> target/arm/translate.c | 2 +-
> 3 files changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> index 4ff28418df..f27b8e35df 100644
> --- a/target/arm/cpu.h
> +++ b/target/arm/cpu.h
> @@ -3468,6 +3468,11 @@ static inline bool isar_feature_aa32_fp16_dpconv(const ARMISARegisters *id)
> return FIELD_EX32(id->mvfr1, MVFR1, FPHP) > 1;
> }
>
> +static inline bool isar_feature_aa32_simdfmac(const ARMISARegisters *id)
> +{
> + return FIELD_EX32(id->mvfr1, MVFR1, SIMDFMAC) != 0;
> +}
This is tricky, because the SIMDFMAC register
field indicates "do we have fused-multiply-accumulate
for either VFP or Neon", so in a VFP-no-Neon core or
a Neon-no-VFP core it will be 1 but can't be used on its
own as a gate on "should this insn be present".
Currently in the part of arm_cpu_realize() which handles
the user having selected vfp=off and/or neon=off we
do allow (for AArch32 cores) both of those combinations.
trans_VFM_dp already tests aa32_fpdp_v2, so I think the
main thing we need to do is add a test on aa32_fpsp_v2 to
trans_VFM_sp.
We clear the SIMDFMAC field to 0 in the !has_neon condition,
and I think that should actually be in the !neon && !vfp part.
I propose to squash in the following and beef up the commit message:
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index f641478fc80..d4c73a20b6a 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -3506,6 +3506,13 @@ static inline bool
isar_feature_aa32_fp16_dpconv(const ARMISARegisters *id)
return FIELD_EX32(id->mvfr1, MVFR1, FPHP) > 1;
}
+/*
+ * Note that this ID register field covers both VFP and Neon FMAC,
+ * so should usually be tested in combination with some other
+ * check that confirms the presence of whichever of VFP or Neon is
+ * relevant, to avoid accidentally enabling a Neon feature on
+ * a VFP-no-Neon core or vice-versa.
+ */
static inline bool isar_feature_aa32_simdfmac(const ARMISARegisters *id)
{
return FIELD_EX32(id->mvfr1, MVFR1, SIMDFMAC) != 0;
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index d5a75c265ac..95ada81ebae 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -1510,7 +1510,6 @@ static void arm_cpu_realizefn(DeviceState *dev,
Error **errp)
u = FIELD_DP32(u, MVFR1, SIMDINT, 0);
u = FIELD_DP32(u, MVFR1, SIMDSP, 0);
u = FIELD_DP32(u, MVFR1, SIMDHP, 0);
- u = FIELD_DP32(u, MVFR1, SIMDFMAC, 0);
cpu->isar.mvfr1 = u;
u = cpu->isar.mvfr2;
@@ -1533,6 +1532,11 @@ static void arm_cpu_realizefn(DeviceState *dev,
Error **errp)
u = cpu->isar.mvfr0;
u = FIELD_DP32(u, MVFR0, SIMDREG, 0);
cpu->isar.mvfr0 = u;
+
+ /* Despite the name, this field covers both VFP and Neon */
+ u = cpu->isar.mvfr1;
+ u = FIELD_DP32(u, MVFR1, SIMDFMAC, 0);
+ cpu->isar.mvfr1;
}
if (arm_feature(env, ARM_FEATURE_M) && !cpu->has_dsp) {
diff --git a/target/arm/translate-vfp.inc.c b/target/arm/translate-vfp.inc.c
index f6f7601fe2a..69052d840a4 100644
--- a/target/arm/translate-vfp.inc.c
+++ b/target/arm/translate-vfp.inc.c
@@ -1805,8 +1805,13 @@ static bool trans_VFM_sp(DisasContext *s, arg_VFM_sp *a)
* Present in VFPv4 only.
* In v7A, UNPREDICTABLE with non-zero vector length/stride; from
* v8A, must UNDEF. We choose to UNDEF for both v7A and v8A.
+ * Note that we can't rely on the SIMDFMAC check alone, because
+ * in a Neon-no-VFP core that ID register field will be non-zero.
*/
- if (!dc_isar_feature(aa32_simdfmac, s)) {
+ if (!dc_isar_feature(aa32_simdfmac, s) ||
+ !dc_isar_feature(aa32_fpsp_v2, s)) {
+ return false;
+ }
return false;
}
if (s->vec_len != 0 || s->vec_stride != 0) {
thanks
-- PMM
^ permalink raw reply related
* Re: Kernel 5.5.4 build fail for BPF-selftests with latest LLVM
From: Jesper Dangaard Brouer @ 2020-02-20 16:37 UTC (permalink / raw)
To: shuah
Cc: Alexei Starovoitov, Daniel Díaz, Andrii Nakryiko,
Andrii Nakryiko, netdev@vger.kernel.org, BPF-dev-list,
Daniel Borkmann, David Miller, LKML, Greg Kroah-Hartman,
Anders Roxell, Toke Høiland-Jørgensen,
open list:KERNEL SELFTEST FRAMEWORK, brouer
In-Reply-To: <4a26e6c6-500e-7b92-1e26-16e1e0233889@kernel.org>
On Wed, 19 Feb 2020 17:47:23 -0700
shuah <shuah@kernel.org> wrote:
> On 2/19/20 5:27 PM, Alexei Starovoitov wrote:
> > On Wed, Feb 19, 2020 at 03:59:41PM -0600, Daniel Díaz wrote:
> >>>
> >>> When I download a specific kernel release, how can I know what LLVM
> >>> git-hash or version I need (to use BPF-selftests)?
> >
> > as discussed we're going to add documentation-like file that will
> > list required commits in tools.
> > This will be enforced for future llvm/pahole commits.
> >
> >>> Do you think it is reasonable to require end-users to compile their own
> >>> bleeding edge version of LLVM, to use BPF-selftests?
> >
> > absolutely.
>
> + linux-kselftest@vger.kernel.org
>
> End-users in this context are users and not necessarily developers.
I agree. And I worry that we are making it increasingly hard for
non-developer users.
> > If a developer wants to send a patch they must run all selftests and
> > all of them must pass in their environment.
> > "but I'm adding a tracing feature and don't care about networking tests
> > failing"... is not acceptable.
>
> This is a reasonable expectation when a developers sends bpf patches.
Sure. I have several versions on LLVM that I've compiled manually.
> >
> >>> I do hope that some end-users of BPF-selftests will be CI-systems.
> >>> That also implies that CI-system maintainers need to constantly do
> >>> "latest built from sources" of LLVM git-tree to keep up. Is that a
> >>> reasonable requirement when buying a CI-system in the cloud?
> >
> > "buying CI-system in the cloud" ?
> > If I could buy such system I would pay for it out of my own pocket to save
> > maintainer's and developer's time.
And Daniel Díaz want to provide his help below (to tests it on arch
that you likely don't even have access to). That sounds like a good
offer, and you don't even have to pay.
> >
> >> We [1] are end users of kselftests and many other test suites [2]. We
> >> run all of our testing on every git-push on linux-stable-rc, mainline,
> >> and linux-next -- approximately 1 million tests per week. We have a
> >> dedicated engineering team looking after this CI infrastructure and
> >> test results, and as such, I can wholeheartedly echo Jesper's
> >> sentiment here: We would really like to help kernel maintainers and
> >> developers by automatically testing their code in real hardware, but
> >> the BPF kselftests are difficult to work with from a CI perspective.
> >> We have caught and reported [3] many [4] build [5] failures [6] in the
> >> past for libbpf/Perf, but building is just one of the pieces. We are
> >> unable to run the entire BPF kselftests because only a part of the
> >> code builds, so our testing is very limited there.
> >>
> >> We hope that this situation can be improved and that our and everyone
> >> else's automated testing can help you guys too. For this to work out,
> >> we need some help.
> >
>
> It would be helpful understand what "help" is in this context.
>
> > I don't understand what kind of help you need. Just install the
> > latest tools.
I admire that you want to push *everybody* forward to use the latest
LLVM, but saying latest is LLVM devel git tree HEAD is too extreme.
I can support saying latest LLVM release is required.
As soon as your LLVM patches are accepted into llvm-git-tree, you will
add some BPF selftests that util this. Then CI-systems pull latest
bpf-next they will start to fail to compile BPF-selftests, and CI
stops. Now you want to force CI-system maintainer to recompile LLVM
from git. This will likely take some time. Until that happens
CI-system doesn't catch stuff. E.g. I really want the ARM tests that
Linaro can run for us (which isn't run before you apply patches...).
> What would be helpful is to write bpf tests such that older tests that
> worked on older llvm versions continue to work and with some indication
> on which tests require new bleeding edge tools.
>
> > Both the latest llvm and the latest pahole are required.
>
> It would be helpful if you can elaborate why latest tools are a
> requirement.
>
> > If by 'help' you mean to tweak selftests to skip tests then it's a nack.
> > We have human driven CI. Every developer must run selftests/bpf before
> > emailing the patches. Myself and Daniel run them as well before applying.
> > These manual runs is the only thing that keeps bpf tree going.
> > If selftests get to skip tests humans will miss those errors.
> > When I don't see '0 SKIPPED, 0 FAILED' I go and investigate.
> > Anything but zero is a path to broken kernels.
> >
> > Imagine the tests would get skipped when pahole is too old.
> > That would mean all of the kernel features from year 2019
> > would get skipped. Is there a point of running such selftests?
> > I think the value is not just zero. The value is negative.
> > Such selftests that run old stuff would give false believe
> > that they do something meaningful.
> > "but CI can do build only tests"... If 'helping' such CI means hurting the
> > key developer/maintainer workflow such CI is on its own.
> >
>
> Skipping tests will be useless. I am with you on that. However,
> figuring out how to maintain some level of backward compatibility
> to run at least older tests and warn users to upgrade would be
> helpful.
What I propose is that a BPF-selftest that use a new LLVM feature,
should return FAIL (or perhaps SKIP), when it is compiled with say one
release old LLVM. This will allow new-tests to show up in CI-systems
reports as FAIL, and give everybody breathing room to upgrade their LLVM
compiler.
> I suspect currently users are ignoring bpf failures because they
> are unable to keep up with the requirement to install newer tools
> to run the tests. This isn't great either.
Yes, my worry is also that we are simply making it too difficult for
non-developer users to run these tests. And I specifically want to
attract CI-systems to run these. And especially Linaro, who have
dedicated engineering team looking after their CI infrastructure, and
they explicitly in this email confirm my worry.
> Users that care are sharing their pain to see if they can get some
> help or explanation on why new tools are required every so often.
> I don't think everybody understands why. :)
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH 1/3] bcache: ignore pending signals when creating gc and allocator thread
From: Christoph Hellwig @ 2020-02-20 16:38 UTC (permalink / raw)
To: Coly Li; +Cc: Christoph Hellwig, axboe, linux-bcache, linux-block
In-Reply-To: <1f6cd622-3476-068b-3593-f918ab011156@suse.de>
On Thu, Feb 20, 2020 at 09:20:49PM +0800, Coly Li wrote:
> Therefore I need to explicitly call pending_signal() before calling
> kthread_run().
Right now you have to. But the proper fix is to not require this and
fix kthread_run to work from a thread that has been selected by the OOM
killer. In the most trivial version by moving your code into
kthread_run, but there probably are better ways as well.
^ permalink raw reply
* Re: omap-secure.c:undefined reference to `__arm_smccc_smc'
From: Tony Lindgren @ 2020-02-20 16:37 UTC (permalink / raw)
To: Andrew F. Davis
Cc: kbuild-all, kbuild test robot, Aaro Koskinen, Marc Zyngier,
linux-kernel, linux-omap, linux-arm-kernel
In-Reply-To: <d7b685b6-16a2-3743-1786-a5240726ed9c@ti.com>
* Andrew F. Davis <afd@ti.com> [200220 16:24]:
> On 2/20/20 11:20 AM, Tony Lindgren wrote:
> > * Andrew F. Davis <afd@ti.com> [200220 16:04]:
> >> On 2/20/20 10:54 AM, Tony Lindgren wrote:
> >>> Andrew,
> >>>
> >>> * kbuild test robot <lkp@intel.com> [200213 10:27]:
> >>>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> >>>> head: 0bf999f9c5e74c7ecf9dafb527146601e5c848b9
> >>>> commit: c37baa06f8a970e4a533d41f7d33e5e57de5ad25 ARM: OMAP2+: Fix undefined reference to omap_secure_init
> >>>> date: 3 weeks ago
> >>>> config: arm-randconfig-a001-20200213 (attached as .config)
> >>>> compiler: arm-linux-gnueabi-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 c37baa06f8a970e4a533d41f7d33e5e57de5ad25
> >>>> # save the attached .config to linux build tree
> >>>> GCC_VERSION=7.5.0 make.cross ARCH=arm
> >>>>
> >>>> If you fix the issue, kindly add following tag
> >>>> Reported-by: kbuild test robot <lkp@intel.com>
> >>>>
> >>>> All errors (new ones prefixed by >>):
> >>>>
> >>>> arch/arm/mach-omap2/omap-secure.o: In function `omap_smccc_smc':
> >>>>>> omap-secure.c:(.text+0x94): undefined reference to `__arm_smccc_smc'
> >>>
> >>> Have you looked at this one? Looks like there's still an unhandled
> >>> randconfig build case.
> >>>
> >>
> >>
> >> I've had a quick look, all the ARM config does:
> >>
> >> select HAVE_ARM_SMCCC if CPU_V7
> >>
> >> so I don't think this will happen in any real config, but if we want to
> >> prevent randconfig issue this we could force ARCH_OMAP2PLUS to "depend"
> >> on it.
> >
> > Seems to happen at least with omap2 only config where we don't have
> > CPU_V7. Something like below seems to fix it.
> >
> > If that looks OK to you, I'll send out a proper fix.
> >
>
>
> This looks fine to me.
>
> A better later fix might be to later stub out the actual __arm_smccc_smc
> in common code if CONFIG_HAVE_ARM_SMCCC is not set, so any platform will
> get the fix.
Yeah seems that might be better. Adding Aaro and Marc to Cc.
Regards,
Tony
> > 8< -----------------------
> > diff --git a/arch/arm/mach-omap2/omap-secure.c b/arch/arm/mach-omap2/omap-secure.c
> > --- a/arch/arm/mach-omap2/omap-secure.c
> > +++ b/arch/arm/mach-omap2/omap-secure.c
> > @@ -77,6 +77,7 @@ u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs, u32 arg1, u32 arg2,
> > return ret;
> > }
> >
> > +#ifdef CONFIG_HAVE_ARM_SMCCC
> > void omap_smccc_smc(u32 fn, u32 arg)
> > {
> > struct arm_smccc_res res;
> > @@ -85,6 +86,11 @@ void omap_smccc_smc(u32 fn, u32 arg)
> > 0, 0, 0, 0, 0, 0, &res);
> > WARN(res.a0, "Secure function call 0x%08x failed\n", fn);
> > }
> > +#else
> > +void omap_smccc_smc(u32 fn, u32 arg)
> > +{
> > +}
> > +#endif
> >
> > void omap_smc1(u32 fn, u32 arg)
> > {
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [Xen-devel] [PATCH v6 1/6] libxl: add infrastructure to track and query 'recent' domids
From: Durrant, Paul @ 2020-02-20 16:36 UTC (permalink / raw)
To: Ian Jackson; +Cc: Anthony Perard, xen-devel@lists.xenproject.org, Wei Liu
In-Reply-To: <24142.45469.349140.521462@mariner.uk.xensource.com>
> -----Original Message-----
> From: Ian Jackson <ian.jackson@citrix.com>
> Sent: 20 February 2020 16:20
> To: Durrant, Paul <pdurrant@amazon.co.uk>
> Cc: xen-devel@lists.xenproject.org; Wei Liu <wl@xen.org>; Anthony Perard
> <anthony.perard@citrix.com>
> Subject: Re: [PATCH v6 1/6] libxl: add infrastructure to track and query
> 'recent' domids
>
> Paul Durrant writes ("[PATCH v6 1/6] libxl: add infrastructure to track
> and query 'recent' domids"):
> > A domid is considered recent if the domain it represents was destroyed
> > less than a specified number of seconds ago. For debugging and/or
> testing
> > purposes the number can be set using the environment variable
> > LIBXL_DOMID_REUSE_TIMEOUT. If the variable does not exist then a default
> > value of 60s is used.
> ...
>
> Quoting only the parts which are neither specific to the particular
> function, nor calls to the functions into which common code has
> currently been moved:
>
> > +static int libxl__mark_domid_recent(libxl__gc *gc, uint32_t domid)
> > +{
> + long timeout = libxl__get_domid_reuse_timeout();
> ...
> > + if (clock_gettime(CLOCK_MONOTONIC, &ts)) {
> > + LOGED(ERROR, domid, "failed to get time");
> > + goto out;
> > + }
> ...
> > + if (ts.tv_sec - sec > timeout)
> > + continue; /* Ignore expired entries */
>
> > +int libxl__is_domid_recent(libxl__gc *gc, uint32_t domid, bool *recent)
> > +{
> > + long timeout = libxl__get_domid_reuse_timeout();
> ...
> > + if (clock_gettime(CLOCK_MONOTONIC, &ts)) {
> > + LOGED(ERROR, domid, "failed to get time");
> > + goto out;
> > + }
> ...
> > + if (val == domid && ts.tv_sec - sec <= timeout) {
>
> I'm afraid I am still making style comments:
>
> IMO the reuse timeout call and the clock_gettime call should be put in
> libxl__open_domid_history; and the time filtering check should be
> folded into libxl__read_recent.
Ok. I was having a hard time guessing just exactly what you're looking for. I think that makes it a little clearer.
>
> In my review of v4 I wrote:
>
> Do you think this can be combined somehow ? Possibilities seem to
> include: explicit read_recent_{init,entry,finish} functions; a single
> function with a "per-entry" callback; same but with a macro. If you
> do that you can also have it have handle the "file does not exist"
> special case.
>
> You've provided the read_recent_entry function but the "init" function
> libxl__open_domid_history does too little. This series seems to be
> moving towards what I called read_recent_{init,entry,finish} (which
> should probably have the timestamp and FILE* in a struct together) but
> it seems to be doing so quite slowly.
Now again I'm not sure *exactly* what you want me to do, but I'll have another guess.
>
> In your factored out functions you generally do this:
>
> int some_function(){
> r = do_the_thing();
> if (r == 0) return 0;
>
> LOGE(....)
> return ERROR_FAIL;
> }
>
> This structure is not ideal because:
>
> - It makes it hard to extend this function to do more, later.
> For example, refactoring the clock_gettime call into
> what is now libxl__open_domid_history would involve reorganising
> the function.
Ok, but it makes the code shorter done the way I have it and I don't really see why any necessary future re-organisation would be such a problem.
>
> - It encourages vacuous log messages whose content is mainly in the
> function and line number framing:
> + LOGE(ERROR, "failed");
> + return ERROR_FAIL;
> +}
> rather than
> if (!*f) {
> LOGE(ERROR, "failed to open recent domid file `%s'", path);
> rc = ERROR_FAIL;
> goto out;
> }
> (and the latter is to be preferred).
But by asking me to put the error handling inside the sub-functions I lost context such as 'path' which was present in the previous structure. I could pass in an argument purely for the benefit of a log function but that seems excessive. I guess I will pull the error logging out again, but that seemed to be against your requirement to de-duplicate code.
>
> - It is nonstandard. See ERROR_HANDLING in CODING_STYLE.
>
> > + ret = fclose(nf);
>
> This should be called `r', not `ret'. See CODING_STYLE.
Ok, I clearly didn't pick up all the subtleties.
>
> Sorry that some of the other code which you are having to edit here
> sets a bad example. (See the apology at the top of CODING_STYLE.)
> (Existing uses of `ret' in libxl are sometimes a syscall return value
> and sometimes a libxl error code, which is one reason that name is now
> deprecated.)
>
> > +static int libxl__replace_domid_history(libxl__gc *gc, char *new)
> > +{
>
> For the record: it was not necessary to break this out into its own
> function, because there is only one call site, so open-coding it would
> not duplicate anything. On the other hand if you think it is clearer,
> I have no objection.
>
> I think the actual behaviour is correct now but I would like to read
> it again when it is in the conventional style.
>
I will spin it again shortly.
Paul
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: omap-secure.c:undefined reference to `__arm_smccc_smc'
From: Tony Lindgren @ 2020-02-20 16:37 UTC (permalink / raw)
To: Andrew F. Davis
Cc: kbuild-all, linux-kernel, kbuild test robot, linux-omap,
Aaro Koskinen, Marc Zyngier, linux-arm-kernel
In-Reply-To: <d7b685b6-16a2-3743-1786-a5240726ed9c@ti.com>
* Andrew F. Davis <afd@ti.com> [200220 16:24]:
> On 2/20/20 11:20 AM, Tony Lindgren wrote:
> > * Andrew F. Davis <afd@ti.com> [200220 16:04]:
> >> On 2/20/20 10:54 AM, Tony Lindgren wrote:
> >>> Andrew,
> >>>
> >>> * kbuild test robot <lkp@intel.com> [200213 10:27]:
> >>>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> >>>> head: 0bf999f9c5e74c7ecf9dafb527146601e5c848b9
> >>>> commit: c37baa06f8a970e4a533d41f7d33e5e57de5ad25 ARM: OMAP2+: Fix undefined reference to omap_secure_init
> >>>> date: 3 weeks ago
> >>>> config: arm-randconfig-a001-20200213 (attached as .config)
> >>>> compiler: arm-linux-gnueabi-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 c37baa06f8a970e4a533d41f7d33e5e57de5ad25
> >>>> # save the attached .config to linux build tree
> >>>> GCC_VERSION=7.5.0 make.cross ARCH=arm
> >>>>
> >>>> If you fix the issue, kindly add following tag
> >>>> Reported-by: kbuild test robot <lkp@intel.com>
> >>>>
> >>>> All errors (new ones prefixed by >>):
> >>>>
> >>>> arch/arm/mach-omap2/omap-secure.o: In function `omap_smccc_smc':
> >>>>>> omap-secure.c:(.text+0x94): undefined reference to `__arm_smccc_smc'
> >>>
> >>> Have you looked at this one? Looks like there's still an unhandled
> >>> randconfig build case.
> >>>
> >>
> >>
> >> I've had a quick look, all the ARM config does:
> >>
> >> select HAVE_ARM_SMCCC if CPU_V7
> >>
> >> so I don't think this will happen in any real config, but if we want to
> >> prevent randconfig issue this we could force ARCH_OMAP2PLUS to "depend"
> >> on it.
> >
> > Seems to happen at least with omap2 only config where we don't have
> > CPU_V7. Something like below seems to fix it.
> >
> > If that looks OK to you, I'll send out a proper fix.
> >
>
>
> This looks fine to me.
>
> A better later fix might be to later stub out the actual __arm_smccc_smc
> in common code if CONFIG_HAVE_ARM_SMCCC is not set, so any platform will
> get the fix.
Yeah seems that might be better. Adding Aaro and Marc to Cc.
Regards,
Tony
> > 8< -----------------------
> > diff --git a/arch/arm/mach-omap2/omap-secure.c b/arch/arm/mach-omap2/omap-secure.c
> > --- a/arch/arm/mach-omap2/omap-secure.c
> > +++ b/arch/arm/mach-omap2/omap-secure.c
> > @@ -77,6 +77,7 @@ u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs, u32 arg1, u32 arg2,
> > return ret;
> > }
> >
> > +#ifdef CONFIG_HAVE_ARM_SMCCC
> > void omap_smccc_smc(u32 fn, u32 arg)
> > {
> > struct arm_smccc_res res;
> > @@ -85,6 +86,11 @@ void omap_smccc_smc(u32 fn, u32 arg)
> > 0, 0, 0, 0, 0, 0, &res);
> > WARN(res.a0, "Secure function call 0x%08x failed\n", fn);
> > }
> > +#else
> > +void omap_smccc_smc(u32 fn, u32 arg)
> > +{
> > +}
> > +#endif
> >
> > void omap_smc1(u32 fn, u32 arg)
> > {
> >
^ permalink raw reply
* Re: [PULL 06/18] qemu-img: Add --target-is-zero to convert
From: Eric Blake @ 2020-02-20 16:36 UTC (permalink / raw)
To: Max Reitz, qemu-block
Cc: Kevin Wolf, Peter Maydell, David Edmondson, qemu-devel
In-Reply-To: <20200220160710.533297-7-mreitz@redhat.com>
On 2/20/20 10:06 AM, Max Reitz wrote:
> From: David Edmondson <david.edmondson@oracle.com>
>
> In many cases the target of a convert operation is a newly provisioned
> target that the user knows is blank (reads as zero). In this situation
> there is no requirement for qemu-img to wastefully zero out the entire
> device.
>
> Add a new option, --target-is-zero, allowing the user to indicate that
> an existing target device will return zeros for all reads.
>
> Signed-off-by: David Edmondson <david.edmondson@oracle.com>
> Message-Id: <20200205110248.2009589-2-david.edmondson@oracle.com>
> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> Reviewed-by: Eric Blake <eblake@redhat.com>
> Signed-off-by: Max Reitz <mreitz@redhat.com>
> ---
> docs/interop/qemu-img.rst | 9 ++++++++-
> qemu-img-cmds.hx | 4 ++--
> qemu-img.c | 26 +++++++++++++++++++++++---
> 3 files changed, 33 insertions(+), 6 deletions(-)
>
> diff --git a/docs/interop/qemu-img.rst b/docs/interop/qemu-img.rst
> index 42e4451db4..5f40137c10 100644
> --- a/docs/interop/qemu-img.rst
> +++ b/docs/interop/qemu-img.rst
> @@ -214,6 +214,13 @@ Parameters to convert subcommand:
> will still be printed. Areas that cannot be read from the source will be
> treated as containing only zeroes.
>
> +.. option:: --target-is-zero
> +
> + Assume that reading the destination image will always return
> + zeros. This parameter is mutually exclusive with a destination image
Late tweak now that this is in a pull request, so we may want a followup
patch, but:
The image doesn't always return zeros after we write to it, maybe we
should tweak this sentence:
Assume that reading the destination image will initially return all zeros.
Also, my earlier comment about 'zeroes' one line before 'zeros' still
applies - although both spellings are valid, we look inconsistent when
we can't make up our mind within two adjacent paragraphs.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
^ permalink raw reply
* Re: [PATCH] Set default CONNECTIVITY_CHECK_URIS to https://www.yoctoproject.org/
From: Ross Burton @ 2020-02-20 16:36 UTC (permalink / raw)
To: Nataliya Korovkina; +Cc: OE-core
In-Reply-To: <CADz_WD7JjTriaEv2Yo0WpjxfMAuR4o-ML70zbZJne+6kYR+5TQ@mail.gmail.com>
On Thu, 20 Feb 2020 at 16:30, Nataliya Korovkina
<malus.brandywine@gmail.com> wrote:
> https://www.yoctoproject.org/ is good enough until the project is on.
> https://www.example.com/ doesn't exist for at least a year while I'm
> witnessing it, so the instructions of "Quick build" don't work
> out-of-the-box.
$ GET www.example.com
<!doctype html>
<html>
<head>
<title>Example Domain</title>
...
<body>
<div>
<h1>Example Domain</h1>
<p>This domain is for use in illustrative examples in documents.
You may use this
domain in literature without prior coordination or asking for
permission.</p>
<p><a href="https://www.iana.org/domains/example">More
information...</a></p>
</div>
</body>
</html>
Works for me, and everyone else presumably.
What specific issues are you seeing?
Ross
^ permalink raw reply
* Re: omap-secure.c:undefined reference to `__arm_smccc_smc'
From: Tony Lindgren @ 2020-02-20 16:37 UTC (permalink / raw)
To: kbuild-all
In-Reply-To: <d7b685b6-16a2-3743-1786-a5240726ed9c@ti.com>
[-- Attachment #1: Type: text/plain, Size: 3053 bytes --]
* Andrew F. Davis <afd@ti.com> [200220 16:24]:
> On 2/20/20 11:20 AM, Tony Lindgren wrote:
> > * Andrew F. Davis <afd@ti.com> [200220 16:04]:
> >> On 2/20/20 10:54 AM, Tony Lindgren wrote:
> >>> Andrew,
> >>>
> >>> * kbuild test robot <lkp@intel.com> [200213 10:27]:
> >>>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> >>>> head: 0bf999f9c5e74c7ecf9dafb527146601e5c848b9
> >>>> commit: c37baa06f8a970e4a533d41f7d33e5e57de5ad25 ARM: OMAP2+: Fix undefined reference to omap_secure_init
> >>>> date: 3 weeks ago
> >>>> config: arm-randconfig-a001-20200213 (attached as .config)
> >>>> compiler: arm-linux-gnueabi-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 c37baa06f8a970e4a533d41f7d33e5e57de5ad25
> >>>> # save the attached .config to linux build tree
> >>>> GCC_VERSION=7.5.0 make.cross ARCH=arm
> >>>>
> >>>> If you fix the issue, kindly add following tag
> >>>> Reported-by: kbuild test robot <lkp@intel.com>
> >>>>
> >>>> All errors (new ones prefixed by >>):
> >>>>
> >>>> arch/arm/mach-omap2/omap-secure.o: In function `omap_smccc_smc':
> >>>>>> omap-secure.c:(.text+0x94): undefined reference to `__arm_smccc_smc'
> >>>
> >>> Have you looked at this one? Looks like there's still an unhandled
> >>> randconfig build case.
> >>>
> >>
> >>
> >> I've had a quick look, all the ARM config does:
> >>
> >> select HAVE_ARM_SMCCC if CPU_V7
> >>
> >> so I don't think this will happen in any real config, but if we want to
> >> prevent randconfig issue this we could force ARCH_OMAP2PLUS to "depend"
> >> on it.
> >
> > Seems to happen at least with omap2 only config where we don't have
> > CPU_V7. Something like below seems to fix it.
> >
> > If that looks OK to you, I'll send out a proper fix.
> >
>
>
> This looks fine to me.
>
> A better later fix might be to later stub out the actual __arm_smccc_smc
> in common code if CONFIG_HAVE_ARM_SMCCC is not set, so any platform will
> get the fix.
Yeah seems that might be better. Adding Aaro and Marc to Cc.
Regards,
Tony
> > 8< -----------------------
> > diff --git a/arch/arm/mach-omap2/omap-secure.c b/arch/arm/mach-omap2/omap-secure.c
> > --- a/arch/arm/mach-omap2/omap-secure.c
> > +++ b/arch/arm/mach-omap2/omap-secure.c
> > @@ -77,6 +77,7 @@ u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs, u32 arg1, u32 arg2,
> > return ret;
> > }
> >
> > +#ifdef CONFIG_HAVE_ARM_SMCCC
> > void omap_smccc_smc(u32 fn, u32 arg)
> > {
> > struct arm_smccc_res res;
> > @@ -85,6 +86,11 @@ void omap_smccc_smc(u32 fn, u32 arg)
> > 0, 0, 0, 0, 0, 0, &res);
> > WARN(res.a0, "Secure function call 0x%08x failed\n", fn);
> > }
> > +#else
> > +void omap_smccc_smc(u32 fn, u32 arg)
> > +{
> > +}
> > +#endif
> >
> > void omap_smc1(u32 fn, u32 arg)
> > {
> >
^ permalink raw reply
* Re: [PATCH 0/4] nvmet: add set feature based timestamp support
From: Chaitanya Kulkarni @ 2020-02-20 16:36 UTC (permalink / raw)
To: Sagi Grimberg, Christoph Hellwig, Keith Busch
Cc: linux-nvme@lists.infradead.org
In-Reply-To: <51465fc5-6f49-5790-4d85-df5f841e2f8e@grimberg.me>
On 02/19/2020 11:48 PM, Sagi Grimberg wrote:
>
>>>> The last three ought to be a single patch IMO since those should really
>>>> from an inseparable package deal for this feature.
>>>
>>> Agreed.
>>>
>> Agree, just made series into small chunks so that it will be easier
>> for a reviewer to go through changes in a botttom up manner.
>>>> As to why we'd support this feature, the spec says "The use of the
>>>> Timestamp is outside the scope of this specification". Is there anything
>>>> interesting we can do with this?
>>>
>>> I can't really think of why this is useful either..
>>>
>> If a host is dealing with different controllers which are on a different
>> machines it will be easier to sync timestamp and read it's value.
>>
>> Although spec doesn't specify the right use, having this feature will
>> allow application(s) (if any) to use it if needed.
>
> Do we know why is that needed?
>
As of now I don't have an application which needs this ASAP.
When I was reading the host/core.c I found that we do set the
timestamp as a part of initializing the controller so it is nice to
have feature with a small code change which makes target controller
spec compliant.
_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply
* [PATCH] net: bcmgenet: Don't set ID_MODE_DIS when not using RGMII
From: Nicolas Saenz Julienne @ 2020-02-20 16:36 UTC (permalink / raw)
To: u-boot
As per Linux's driver, ID_MODE_DIS is only set when the PHY interface is
RGMII. Don't enable it for the rest of setups.
This has been seen to misconfigure RPi4's PHY when booting Linux.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
drivers/net/bcmgenet.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/bcmgenet.c b/drivers/net/bcmgenet.c
index 8f4848aec6..e971b556ac 100644
--- a/drivers/net/bcmgenet.c
+++ b/drivers/net/bcmgenet.c
@@ -448,7 +448,10 @@ static int bcmgenet_adjust_link(struct bcmgenet_eth_priv *priv)
}
clrsetbits_32(priv->mac_reg + EXT_RGMII_OOB_CTRL, OOB_DISABLE,
- RGMII_LINK | RGMII_MODE_EN | ID_MODE_DIS);
+ RGMII_LINK | RGMII_MODE_EN);
+
+ if (phy_dev->interface == PHY_INTERFACE_MODE_RGMII)
+ setbits_32(priv->mac_reg + EXT_RGMII_OOB_CTRL, ID_MODE_DIS);
writel(speed << CMD_SPEED_SHIFT, (priv->mac_reg + UMAC_CMD));
--
2.25.0
^ permalink raw reply related
* Re: [Xen-devel] [PATCH] MAINTAINERS: make Roger VPCI maintainer
From: Roger Pau Monné @ 2020-02-20 16:35 UTC (permalink / raw)
To: Jan Beulich
Cc: Stefano Stabellini, Julien Grall, Wei Liu, Konrad Rzeszutek Wilk,
George Dunlap, Andrew Cooper, Ian Jackson, Xen Development List
In-Reply-To: <834f04c9-e164-e03e-7793-69145b8d5ad0@suse.com>
On Thu, Feb 20, 2020 at 05:01:02PM +0100, Jan Beulich wrote:
> On 20.02.2020 16:58, Wei Liu wrote:
> > Roger has kindly agreed to take on the burden.
> >
> > Signed-off-by: Wei Liu <wl@xen.org>
>
> Acked-by: Jan Beulich <jbeulich@suse.com>
> with ...
>
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -500,6 +500,12 @@ F: xen/include/*/vm_event.h
> > F: xen/include/asm-x86/hvm/monitor.h
> > F: xen/include/asm-x86/hvm/vm_event.h
> >
> > +VPCI
> > +M: Roger Pau Monné <roger.pau@citrix.com>
> > +S: Supported
> > +F: xen/drivers/vpci
>
> ... a trailing slash added here to indicate it's a directory.
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH] arm64: dts: meson-gxl-s905x-p212: add bluetooth nodes
From: Neil Armstrong @ 2020-02-20 16:35 UTC (permalink / raw)
To: Christian Hewitt, Rob Herring, Mark Rutland, Kevin Hilman,
devicetree, linux-arm-kernel, linux-amlogic, linux-kernel
In-Reply-To: <1582216366-12964-1-git-send-email-christianshewitt@gmail.com>
On 20/02/2020 17:32, Christian Hewitt wrote:
> This removes the uart_A alias (no longer required) and adds the bluetooth
> node to the P212 device tree.
>
> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi
> index 43eb7d1..6ac678f 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi
> @@ -15,7 +15,6 @@
> / {
> aliases {
> serial0 = &uart_AO;
> - serial1 = &uart_A;
> ethernet0 = ðmac;
> };
>
> @@ -180,6 +179,14 @@
> pinctrl-0 = <&uart_a_pins>, <&uart_a_cts_rts_pins>;
> pinctrl-names = "default";
> uart-has-rtscts;
> +
> + bluetooth {
> + compatible = "brcm,bcm43438-bt";
> + shutdown-gpios = <&gpio GPIOX_17 GPIO_ACTIVE_HIGH>;
> + max-speed = <2000000>;
> + clocks = <&wifi32k>;
> + clock-names = "lpo";
> + };
> };
>
> &uart_AO {
>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply
* Re: [PATCH] arm64: dts: meson-gxl-s905x-p212: add bluetooth nodes
From: Neil Armstrong @ 2020-02-20 16:35 UTC (permalink / raw)
To: Christian Hewitt, Rob Herring, Mark Rutland, Kevin Hilman,
devicetree, linux-arm-kernel, linux-amlogic, linux-kernel
In-Reply-To: <1582216366-12964-1-git-send-email-christianshewitt@gmail.com>
On 20/02/2020 17:32, Christian Hewitt wrote:
> This removes the uart_A alias (no longer required) and adds the bluetooth
> node to the P212 device tree.
>
> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi
> index 43eb7d1..6ac678f 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi
> @@ -15,7 +15,6 @@
> / {
> aliases {
> serial0 = &uart_AO;
> - serial1 = &uart_A;
> ethernet0 = ðmac;
> };
>
> @@ -180,6 +179,14 @@
> pinctrl-0 = <&uart_a_pins>, <&uart_a_cts_rts_pins>;
> pinctrl-names = "default";
> uart-has-rtscts;
> +
> + bluetooth {
> + compatible = "brcm,bcm43438-bt";
> + shutdown-gpios = <&gpio GPIOX_17 GPIO_ACTIVE_HIGH>;
> + max-speed = <2000000>;
> + clocks = <&wifi32k>;
> + clock-names = "lpo";
> + };
> };
>
> &uart_AO {
>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
_______________________________________________
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] arm64: dts: meson-gxl-s905x-p212: add bluetooth nodes
From: Neil Armstrong @ 2020-02-20 16:35 UTC (permalink / raw)
To: Christian Hewitt, Rob Herring, Mark Rutland, Kevin Hilman,
devicetree, linux-arm-kernel, linux-amlogic, linux-kernel
In-Reply-To: <1582216366-12964-1-git-send-email-christianshewitt@gmail.com>
On 20/02/2020 17:32, Christian Hewitt wrote:
> This removes the uart_A alias (no longer required) and adds the bluetooth
> node to the P212 device tree.
>
> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi
> index 43eb7d1..6ac678f 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi
> @@ -15,7 +15,6 @@
> / {
> aliases {
> serial0 = &uart_AO;
> - serial1 = &uart_A;
> ethernet0 = ðmac;
> };
>
> @@ -180,6 +179,14 @@
> pinctrl-0 = <&uart_a_pins>, <&uart_a_cts_rts_pins>;
> pinctrl-names = "default";
> uart-has-rtscts;
> +
> + bluetooth {
> + compatible = "brcm,bcm43438-bt";
> + shutdown-gpios = <&gpio GPIOX_17 GPIO_ACTIVE_HIGH>;
> + max-speed = <2000000>;
> + clocks = <&wifi32k>;
> + clock-names = "lpo";
> + };
> };
>
> &uart_AO {
>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
^ permalink raw reply
* Re: [RFC PATCH v3 07/27] qcow2: Add subcluster-related fields to BDRVQcow2State
From: Alberto Garcia @ 2020-02-20 16:34 UTC (permalink / raw)
To: Eric Blake, qemu-devel
Cc: Kevin Wolf, Anton Nefedov, qemu-block, Max Reitz,
Vladimir Sementsov-Ogievskiy, Denis V . Lunev
In-Reply-To: <bc469fab-244c-6b26-c5b4-55cc42a7d8cc@redhat.com>
On Thu 20 Feb 2020 04:28:07 PM CET, Eric Blake wrote:
>> Images without subclusters are treated as if they had exactly one,
>> with subcluster_size = cluster_size.
>
> The qcow2 spec changes earlier in the series made it sound like your
> choices are exactly 1 or 32,
>> +#define QCOW_MAX_SUBCLUSTERS_PER_CLUSTER 32
>> +
>
> ...but this name sounds like other values (2, 4, 8, 16) might be
> possible?
I guess I didn't want to call it QCOW_SUBCLUSTERS_PER_CLUSTER because
there's already BDRVQcow2State.subclusters_per_cluster. And that one can
have two possible values (1 and 32) so 32 would be the maximum.
I get your point, however, and I'm open to suggestions.
Berto
^ permalink raw reply
* Re: crash on connect
From: Glauber Costa @ 2020-02-20 16:34 UTC (permalink / raw)
To: Jens Axboe; +Cc: io-uring, Avi Kivity
In-Reply-To: <7fa66eac-73d0-c461-98dd-2818434e8bc8@kernel.dk>
On Thu, Feb 20, 2020 at 11:29 AM Jens Axboe <axboe@kernel.dk> wrote:
>
> On 2/20/20 9:17 AM, Jens Axboe wrote:
> > On 2/20/20 7:19 AM, Glauber Costa wrote:
> >> Hi there, me again
> >>
> >> Kernel is at 043f0b67f2ab8d1af418056bc0cc6f0623d31347
> >>
> >> This test is easier to explain: it essentially issues a connect and a
> >> shutdown right away.
> >>
> >> It currently fails due to no fault of io_uring. But every now and then
> >> it crashes (you may have to run more than once to get it to crash)
> >>
> >> Instructions are similar to my last test.
> >> Except the test to build is now "tests/unit/connect_test"
> >> Code is at git@github.com:glommer/seastar.git branch io-uring-connect-crash
> >>
> >> Run it with ./build/release/tests/unit/connect_test -- -c1
> >> --reactor-backend=uring
> >>
> >> Backtrace attached
> >
> > Perfect thanks, I'll take a look!
>
> Haven't managed to crash it yet, but every run complains:
>
> got to shutdown of 10 with refcnt: 2
> Refs being all dropped, calling forget for 10
> terminate called after throwing an instance of 'fmt::v6::format_error'
> what(): argument index out of range
> unknown location(0): fatal error: in "unixdomain_server": signal: SIGABRT (application abort requested)
>
> Not sure if that's causing it not to fail here.
Ok, that means it "passed". (I was in the process of figuring out
where I got this wrong when I started seeing the crashes)
>
> --
> Jens Axboe
>
^ permalink raw reply
* Re: syzkaller wireguard key situation [was: Re: [PATCH net-next v2] net: WireGuard secure network tunnel]
From: Jason A. Donenfeld @ 2020-02-20 16:33 UTC (permalink / raw)
To: Dmitry Vyukov; +Cc: netdev, syzbot, WireGuard mailing list
In-Reply-To: <CACT4Y+aTBNZAekX_D+QdofqBdUuG9BkzLq+TFDxr8-sSqL9hdQ@mail.gmail.com>
Hi Dmitry,
On Thu, Feb 20, 2020 at 5:14 PM Dmitry Vyukov <dvyukov@google.com> wrote:
> I got some coverage in wg_netdevice_notification:
> https://imgur.com/a/1sJZKtp
>
> Or you mean the parts that are still red?
Yes, it's the red parts that interest me. Intermixing those with
various wireguard-specific netlink calls and setting devices up and
down and putting traffic through those sockets, in weird ways, could
dig up bugs.
> I think theoretically these parts should be reachable too because
> syzkaller can do unshare and obtain net ns fd's.
>
> It's quite hard to test because it just crashes all the time on known bugs.
> So maybe the most profitable way to get more coverage throughout the
> networking subsystem now is to fix the top layer of crashers ;)
Ahhh, interesting, so the issue is that syzkaller is finding too many
other networking stack bugs before it gets to being able to play with
wireguard. Shucks.
Jason
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply
* Re: syzkaller wireguard key situation [was: Re: [PATCH net-next v2] net: WireGuard secure network tunnel]
From: Jason A. Donenfeld @ 2020-02-20 16:33 UTC (permalink / raw)
To: Dmitry Vyukov; +Cc: netdev, syzbot, WireGuard mailing list
In-Reply-To: <CACT4Y+aTBNZAekX_D+QdofqBdUuG9BkzLq+TFDxr8-sSqL9hdQ@mail.gmail.com>
Hi Dmitry,
On Thu, Feb 20, 2020 at 5:14 PM Dmitry Vyukov <dvyukov@google.com> wrote:
> I got some coverage in wg_netdevice_notification:
> https://imgur.com/a/1sJZKtp
>
> Or you mean the parts that are still red?
Yes, it's the red parts that interest me. Intermixing those with
various wireguard-specific netlink calls and setting devices up and
down and putting traffic through those sockets, in weird ways, could
dig up bugs.
> I think theoretically these parts should be reachable too because
> syzkaller can do unshare and obtain net ns fd's.
>
> It's quite hard to test because it just crashes all the time on known bugs.
> So maybe the most profitable way to get more coverage throughout the
> networking subsystem now is to fix the top layer of crashers ;)
Ahhh, interesting, so the issue is that syzkaller is finding too many
other networking stack bugs before it gets to being able to play with
wireguard. Shucks.
Jason
^ permalink raw reply
* [PATCH] arm64: dts: meson-gxl-s905x-p212: add bluetooth nodes
From: Christian Hewitt @ 2020-02-20 16:32 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Kevin Hilman, devicetree,
linux-arm-kernel, linux-amlogic, linux-kernel
Cc: Christian Hewitt
This removes the uart_A alias (no longer required) and adds the bluetooth
node to the P212 device tree.
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi
index 43eb7d1..6ac678f 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi
@@ -15,7 +15,6 @@
/ {
aliases {
serial0 = &uart_AO;
- serial1 = &uart_A;
ethernet0 = ðmac;
};
@@ -180,6 +179,14 @@
pinctrl-0 = <&uart_a_pins>, <&uart_a_cts_rts_pins>;
pinctrl-names = "default";
uart-has-rtscts;
+
+ bluetooth {
+ compatible = "brcm,bcm43438-bt";
+ shutdown-gpios = <&gpio GPIOX_17 GPIO_ACTIVE_HIGH>;
+ max-speed = <2000000>;
+ clocks = <&wifi32k>;
+ clock-names = "lpo";
+ };
};
&uart_AO {
--
2.7.4
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply related
* Re: [PATCH] x86/xen: Distribute switch variables for initialization
From: Boris Ostrovsky @ 2020-02-20 16:33 UTC (permalink / raw)
To: Jürgen Groß, Kees Cook
Cc: Alexander Potapenko, Stefano Stabellini, xen-devel, linux-kernel
In-Reply-To: <16a166da-c6e7-aa36-53a0-1b56197c8fc0@suse.com>
On 2/20/20 1:37 AM, Jürgen Groß wrote:
> On 20.02.20 07:23, Kees Cook wrote:
>> Variables declared in a switch statement before any case statements
>> cannot be automatically initialized with compiler instrumentation (as
>> they are not part of any execution flow). With GCC's proposed automatic
>> stack variable initialization feature, this triggers a warning (and they
>> don't get initialized). Clang's automatic stack variable initialization
>> (via CONFIG_INIT_STACK_ALL=y) doesn't throw a warning, but it also
>> doesn't initialize such variables[1]. Note that these warnings (or
>> silent
>> skipping) happen before the dead-store elimination optimization phase,
>> so even when the automatic initializations are later elided in favor of
>> direct initializations, the warnings remain.
>>
>> To avoid these problems, move such variables into the "case" where
>> they're used or lift them up into the main function body.
>>
>> arch/x86/xen/enlighten_pv.c: In function ‘xen_write_msr_safe’:
>> arch/x86/xen/enlighten_pv.c:904:12: warning: statement will never be
>> executed [-Wswitch-unreachable]
>> 904 | unsigned which;
>> | ^~~~~
>>
>> [1] https://bugs.llvm.org/show_bug.cgi?id=44916
>>
>> Signed-off-by: Kees Cook <keescook@chromium.org>
>
> Reviewed-by: Juergen Gross <jgross@suse.com>
>
Applied to for-linus-5.6.
(I replaced 'unsigned' with 'unsigned int' to quiet down checkpatch )
-boris
^ permalink raw reply
* [PATCH] arm64: dts: meson-gxl-s905x-p212: add bluetooth nodes
From: Christian Hewitt @ 2020-02-20 16:32 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Kevin Hilman, devicetree,
linux-arm-kernel, linux-amlogic, linux-kernel
Cc: Christian Hewitt
This removes the uart_A alias (no longer required) and adds the bluetooth
node to the P212 device tree.
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi
index 43eb7d1..6ac678f 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi
@@ -15,7 +15,6 @@
/ {
aliases {
serial0 = &uart_AO;
- serial1 = &uart_A;
ethernet0 = ðmac;
};
@@ -180,6 +179,14 @@
pinctrl-0 = <&uart_a_pins>, <&uart_a_cts_rts_pins>;
pinctrl-names = "default";
uart-has-rtscts;
+
+ bluetooth {
+ compatible = "brcm,bcm43438-bt";
+ shutdown-gpios = <&gpio GPIOX_17 GPIO_ACTIVE_HIGH>;
+ max-speed = <2000000>;
+ clocks = <&wifi32k>;
+ clock-names = "lpo";
+ };
};
&uart_AO {
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
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.