* [Xen-devel] [linux-5.4 test] 147001: regressions - FAIL
From: osstest service owner @ 2020-02-14 19:18 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 147001 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147001/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 146121
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 146121
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 146121
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail REGR. vs. 146121
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-pvshim 12 guest-start fail never pass
test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-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-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass
test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass
test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass
test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass
test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass
test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass
test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass
test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass
test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop 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-libvirt 13 migrate-support-check fail never pass
test-armhf-armhf-libvirt 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-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-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass
test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass
test-arm64-arm64-xl 13 migrate-support-check fail never pass
test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass
test-arm64-arm64-xl 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-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 13 migrate-support-check fail never pass
test-armhf-armhf-xl 14 saverestore-support-check fail never pass
test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass
test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass
test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass
test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
version targeted for testing:
linux d6591ea2dd1a44b1c72c5a3e3b6555d7585acdae
baseline version:
linux 122179cb7d648a6f36b20dd6bf34f953cb384c30
Last test of basis 146121 2020-01-15 17:42:04 Z 30 days
Failing since 146178 2020-01-17 02:59:07 Z 28 days 59 attempts
Testing same since 146876 2020-02-11 13:39:51 Z 3 days 3 attempts
------------------------------------------------------------
1007 people touched revisions under test,
not listing them all
jobs:
build-amd64-xsm pass
build-arm64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-arm64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-arm64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvops pass
build-arm64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-arm64-arm64-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-arm64-arm64-libvirt-xsm pass
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-arm64-arm64-xl-xsm pass
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvhv2-amd pass
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 fail
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-arm64-arm64-xl-credit1 pass
test-armhf-armhf-xl-credit1 pass
test-amd64-amd64-xl-credit2 pass
test-arm64-arm64-xl-credit2 pass
test-armhf-armhf-xl-credit2 pass
test-armhf-armhf-xl-cubietruck pass
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass
test-amd64-amd64-examine pass
test-arm64-arm64-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 pass
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt pass
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-xl-pvshim pass
test-amd64-i386-xl-pvshim fail
test-amd64-amd64-pygrub pass
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw pass
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds fail
test-armhf-armhf-xl-rtds pass
test-arm64-arm64-xl-seattle 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-arm64-arm64-xl-thunderx 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 52571 lines long.)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* [PATCH v2] arm: dts: imx8mq-evk: add phy-reset-gpios for fec1
From: Alifer Moraes @ 2020-02-14 19:18 UTC (permalink / raw)
To: u-boot
Instead of resetting the ethernet phy through functions in imx8mq_evk.c, let the
driver reset the phy via dts description adding a reset duration of 10 ms
following atheros 8031's datasheet recommendation.
Signed-off-by: Alifer Moraes <alifer.wsdm@gmail.com>
---
Changes since v1:
Improve commit log (Michael Trimarchi)
arch/arm/dts/imx8mq-evk.dts | 2 ++
board/freescale/imx8mq_evk/imx8mq_evk.c | 18 ------------------
2 files changed, 2 insertions(+), 18 deletions(-)
diff --git a/arch/arm/dts/imx8mq-evk.dts b/arch/arm/dts/imx8mq-evk.dts
index 3693933451..55294ba9c8 100644
--- a/arch/arm/dts/imx8mq-evk.dts
+++ b/arch/arm/dts/imx8mq-evk.dts
@@ -104,6 +104,8 @@
pinctrl-0 = <&pinctrl_fec1>;
phy-mode = "rgmii-id";
phy-handle = <ðphy0>;
+ phy-reset-gpios = <&gpio1 9 GPIO_ACTIVE_LOW>;
+ phy-reset-duration = <10>;
fsl,magic-packet;
status = "okay";
diff --git a/board/freescale/imx8mq_evk/imx8mq_evk.c b/board/freescale/imx8mq_evk/imx8mq_evk.c
index cb39d0f2d6..b2f464abb1 100644
--- a/board/freescale/imx8mq_evk/imx8mq_evk.c
+++ b/board/freescale/imx8mq_evk/imx8mq_evk.c
@@ -64,29 +64,11 @@ int dram_init(void)
}
#ifdef CONFIG_FEC_MXC
-#define FEC_RST_PAD IMX_GPIO_NR(1, 9)
-static iomux_v3_cfg_t const fec1_rst_pads[] = {
- IMX8MQ_PAD_GPIO1_IO09__GPIO1_IO9 | MUX_PAD_CTRL(NO_PAD_CTRL),
-};
-
-static void setup_iomux_fec(void)
-{
- imx_iomux_v3_setup_multiple_pads(fec1_rst_pads,
- ARRAY_SIZE(fec1_rst_pads));
-
- gpio_request(IMX_GPIO_NR(1, 9), "fec1_rst");
- gpio_direction_output(IMX_GPIO_NR(1, 9), 0);
- udelay(500);
- gpio_direction_output(IMX_GPIO_NR(1, 9), 1);
-}
-
static int setup_fec(void)
{
struct iomuxc_gpr_base_regs *gpr =
(struct iomuxc_gpr_base_regs *)IOMUXC_GPR_BASE_ADDR;
- setup_iomux_fec();
-
/* Use 125M anatop REF_CLK1 for ENET1, not from external */
clrsetbits_le32(&gpr->gpr[1], BIT(13) | BIT(17), 0);
return set_clk_enet(ENET_125MHZ);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] arm64: dts: meson-sm1-sei610: add missing interrupt-names
From: Kevin Hilman @ 2020-02-14 19:18 UTC (permalink / raw)
To: Neil Armstrong, Guillaume La Roque, devicetree
Cc: linux-amlogic, linux-kernel, linux-arm-kernel
In-Reply-To: <42e82841-067d-245b-6196-183503da389b@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> On 17/01/2020 14:34, Guillaume La Roque wrote:
>> add missing "host-wakeup interrupt names
>>
>> Fixes: 30388cc07572 ("arm64: dts: meson-sm1-sei610: add gpio bluetooth interrupt")
>>
>> Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
>> ---
>> arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts b/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts
>> index a8bb3fa9fec9..cb1b48f5b8b1 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts
>> @@ -593,6 +593,7 @@
>> compatible = "brcm,bcm43438-bt";
>> interrupt-parent = <&gpio_intc>;
>> interrupts = <95 IRQ_TYPE_LEVEL_HIGH>;
>> + interrupt-names = "host-wakeup";
>> shutdown-gpios = <&gpio GPIOX_17 GPIO_ACTIVE_HIGH>;
>> max-speed = <2000000>;
>> clocks = <&wifi32k>;
>>
>
> Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Queued as a fix for v5.6-rc1.
Thanks,
Kevin
_______________________________________________
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-sm1-sei610: add missing interrupt-names
From: Kevin Hilman @ 2020-02-14 19:18 UTC (permalink / raw)
To: Neil Armstrong, Guillaume La Roque, devicetree
Cc: linux-amlogic, linux-kernel, linux-arm-kernel
In-Reply-To: <42e82841-067d-245b-6196-183503da389b@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> On 17/01/2020 14:34, Guillaume La Roque wrote:
>> add missing "host-wakeup interrupt names
>>
>> Fixes: 30388cc07572 ("arm64: dts: meson-sm1-sei610: add gpio bluetooth interrupt")
>>
>> Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
>> ---
>> arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts b/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts
>> index a8bb3fa9fec9..cb1b48f5b8b1 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts
>> @@ -593,6 +593,7 @@
>> compatible = "brcm,bcm43438-bt";
>> interrupt-parent = <&gpio_intc>;
>> interrupts = <95 IRQ_TYPE_LEVEL_HIGH>;
>> + interrupt-names = "host-wakeup";
>> shutdown-gpios = <&gpio GPIOX_17 GPIO_ACTIVE_HIGH>;
>> max-speed = <2000000>;
>> clocks = <&wifi32k>;
>>
>
> Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Queued as a fix for v5.6-rc1.
Thanks,
Kevin
_______________________________________________
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-sm1-sei610: add missing interrupt-names
From: Kevin Hilman @ 2020-02-14 19:18 UTC (permalink / raw)
To: Neil Armstrong, Guillaume La Roque, devicetree
Cc: linux-amlogic, linux-kernel, linux-arm-kernel
In-Reply-To: <42e82841-067d-245b-6196-183503da389b@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> On 17/01/2020 14:34, Guillaume La Roque wrote:
>> add missing "host-wakeup interrupt names
>>
>> Fixes: 30388cc07572 ("arm64: dts: meson-sm1-sei610: add gpio bluetooth interrupt")
>>
>> Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
>> ---
>> arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts b/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts
>> index a8bb3fa9fec9..cb1b48f5b8b1 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts
>> @@ -593,6 +593,7 @@
>> compatible = "brcm,bcm43438-bt";
>> interrupt-parent = <&gpio_intc>;
>> interrupts = <95 IRQ_TYPE_LEVEL_HIGH>;
>> + interrupt-names = "host-wakeup";
>> shutdown-gpios = <&gpio GPIOX_17 GPIO_ACTIVE_HIGH>;
>> max-speed = <2000000>;
>> clocks = <&wifi32k>;
>>
>
> Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Queued as a fix for v5.6-rc1.
Thanks,
Kevin
^ permalink raw reply
* Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
From: Tejun Heo @ 2020-02-14 19:17 UTC (permalink / raw)
To: Kenny Ho
Cc: juan.zuniga-anaya, Kenny Ho, Kuehling, Felix, jsparks, nirmoy.das,
Maling list - DRI developers, lkaplan, Greathouse, Joseph,
amd-gfx mailing list, Jason Ekstrand, Johannes Weiner,
Alex Deucher, cgroups, Christian König, damon.mcdougall
In-Reply-To: <CAOWid-caJHeXUnQv3MOi=9U+vdBLfewN+CrA-7jRrz0VXqatbQ@mail.gmail.com>
Hello, Kenny, Daniel.
(cc'ing Johannes)
On Fri, Feb 14, 2020 at 01:51:32PM -0500, Kenny Ho wrote:
> On Fri, Feb 14, 2020 at 1:34 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> >
> > I think guidance from Tejun in previos discussions was pretty clear that
> > he expects cgroups to be both a) standardized and c) sufficient clear
> > meaning that end-users have a clear understanding of what happens when
> > they change the resource allocation.
> >
> > I'm not sure lgpu here, at least as specified, passes either.
>
> I disagree (at least on the characterization of the feedback
> provided.) I believe this series satisfied the sprite of Tejun's
> guidance so far (the weight knob for lgpu, for example, was
> specifically implemented base on his input.) But, I will let Tejun
> speak for himself after he considered the implementation in detail.
I have to agree with Daniel here. My apologies if I weren't clear
enough. Here's one interface I can think of:
* compute weight: The same format as io.weight. Proportional control
of gpu compute.
* memory low: Please see how the system memory.low behaves. For gpus,
it'll need per-device entries.
Note that for both, there one number to configure and conceptually
it's pretty clear to everybody what that number means, which is not to
say that it's clear to implement but it's much better to deal with
that on this side of the interface than the other.
cc'ing Johannes. Do you have anything on mind regarding how gpu memory
configuration should look like? e.g. should it go w/ weights rather
than absoulte units (I don't think so given that it'll most likely
need limits at some point too but still and there are benefits from
staying consistent with system memory).
Also, a rather trivial high level question. Is drm a good controller
name given that other controller names are like cpu, memory, io?
Thanks.
--
tejun
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
From: Tejun Heo @ 2020-02-14 19:17 UTC (permalink / raw)
To: Kenny Ho
Cc: juan.zuniga-anaya, Daniel Vetter, Kenny Ho, Kuehling, Felix,
jsparks, nirmoy.das, Maling list - DRI developers, lkaplan,
Greathouse, Joseph, amd-gfx mailing list, Jason Ekstrand,
Johannes Weiner, Alex Deucher, cgroups, Christian König,
damon.mcdougall
In-Reply-To: <CAOWid-caJHeXUnQv3MOi=9U+vdBLfewN+CrA-7jRrz0VXqatbQ@mail.gmail.com>
Hello, Kenny, Daniel.
(cc'ing Johannes)
On Fri, Feb 14, 2020 at 01:51:32PM -0500, Kenny Ho wrote:
> On Fri, Feb 14, 2020 at 1:34 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> >
> > I think guidance from Tejun in previos discussions was pretty clear that
> > he expects cgroups to be both a) standardized and c) sufficient clear
> > meaning that end-users have a clear understanding of what happens when
> > they change the resource allocation.
> >
> > I'm not sure lgpu here, at least as specified, passes either.
>
> I disagree (at least on the characterization of the feedback
> provided.) I believe this series satisfied the sprite of Tejun's
> guidance so far (the weight knob for lgpu, for example, was
> specifically implemented base on his input.) But, I will let Tejun
> speak for himself after he considered the implementation in detail.
I have to agree with Daniel here. My apologies if I weren't clear
enough. Here's one interface I can think of:
* compute weight: The same format as io.weight. Proportional control
of gpu compute.
* memory low: Please see how the system memory.low behaves. For gpus,
it'll need per-device entries.
Note that for both, there one number to configure and conceptually
it's pretty clear to everybody what that number means, which is not to
say that it's clear to implement but it's much better to deal with
that on this side of the interface than the other.
cc'ing Johannes. Do you have anything on mind regarding how gpu memory
configuration should look like? e.g. should it go w/ weights rather
than absoulte units (I don't think so given that it'll most likely
need limits at some point too but still and there are benefits from
staying consistent with system memory).
Also, a rather trivial high level question. Is drm a good controller
name given that other controller names are like cpu, memory, io?
Thanks.
--
tejun
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
From: Tejun Heo @ 2020-02-14 19:17 UTC (permalink / raw)
To: Kenny Ho
Cc: Daniel Vetter, Jason Ekstrand, Kenny Ho,
cgroups-u79uwXL29TY76Z2rM5mHXA, Maling list - DRI developers,
amd-gfx mailing list, Alex Deucher, Christian König,
Kuehling, Felix, Greathouse, Joseph, jsparks-WVYJKLFxKCc,
lkaplan-WVYJKLFxKCc, nirmoy.das-5C7GfCeVMHo,
damon.mcdougall-5C7GfCeVMHo, juan.zuniga-anaya-5C7GfCeVMHo,
Johannes Weiner
In-Reply-To: <CAOWid-caJHeXUnQv3MOi=9U+vdBLfewN+CrA-7jRrz0VXqatbQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hello, Kenny, Daniel.
(cc'ing Johannes)
On Fri, Feb 14, 2020 at 01:51:32PM -0500, Kenny Ho wrote:
> On Fri, Feb 14, 2020 at 1:34 PM Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org> wrote:
> >
> > I think guidance from Tejun in previos discussions was pretty clear that
> > he expects cgroups to be both a) standardized and c) sufficient clear
> > meaning that end-users have a clear understanding of what happens when
> > they change the resource allocation.
> >
> > I'm not sure lgpu here, at least as specified, passes either.
>
> I disagree (at least on the characterization of the feedback
> provided.) I believe this series satisfied the sprite of Tejun's
> guidance so far (the weight knob for lgpu, for example, was
> specifically implemented base on his input.) But, I will let Tejun
> speak for himself after he considered the implementation in detail.
I have to agree with Daniel here. My apologies if I weren't clear
enough. Here's one interface I can think of:
* compute weight: The same format as io.weight. Proportional control
of gpu compute.
* memory low: Please see how the system memory.low behaves. For gpus,
it'll need per-device entries.
Note that for both, there one number to configure and conceptually
it's pretty clear to everybody what that number means, which is not to
say that it's clear to implement but it's much better to deal with
that on this side of the interface than the other.
cc'ing Johannes. Do you have anything on mind regarding how gpu memory
configuration should look like? e.g. should it go w/ weights rather
than absoulte units (I don't think so given that it'll most likely
need limits at some point too but still and there are benefits from
staying consistent with system memory).
Also, a rather trivial high level question. Is drm a good controller
name given that other controller names are like cpu, memory, io?
Thanks.
--
tejun
^ permalink raw reply
* [Virtio-fs] fedora packages for virtiofsd
From: Vivek Goyal @ 2020-02-14 19:17 UTC (permalink / raw)
To: Dr. David Alan Gilbert; +Cc: virtio-fs-list, Mrunal Patel
Hi David,
Are fedora packages for latest qemu with virtiofsd now available. Can one
try it?
Dan Walsh and Mrunal are looking for it (CCed in email).
Keeping this thread on virtio-fs list as others might be interested as
well.
Thanks
Vivek
^ permalink raw reply
* Re: [PATCH 1/2] dp264: use pci_create() to initialise the cmd646 device
From: Mark Cave-Ayland @ 2020-02-14 19:16 UTC (permalink / raw)
To: Philippe Mathieu-Daudé; +Cc: John Snow, QEMU Developers, Richard Henderson
In-Reply-To: <CAP+75-X1pbKfG8+17Zif-ZsQNbFk34_AzVWy=U_Hr+Rz7=pgOA@mail.gmail.com>
On 14/02/2020 11:47, Philippe Mathieu-Daudé wrote:
> Hi Mark,
>
> On Fri, Feb 14, 2020 at 9:48 AM Mark Cave-Ayland
> <mark.cave-ayland@ilande.co.uk> wrote:
>>
>> Remove the call to pci_cmd646_ide_init() since global device init functions
>> are deprecated in preference of using qdev directly.
>>
>> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
>> ---
>> hw/alpha/dp264.c | 8 +++++++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/hw/alpha/dp264.c b/hw/alpha/dp264.c
>> index a8f9a89cc4..e91989bf9a 100644
>> --- a/hw/alpha/dp264.c
>> +++ b/hw/alpha/dp264.c
>> @@ -16,6 +16,7 @@
>> #include "sysemu/sysemu.h"
>> #include "hw/rtc/mc146818rtc.h"
>> #include "hw/ide.h"
>> +#include "hw/ide/pci.h"
>> #include "hw/timer/i8254.h"
>> #include "hw/isa/superio.h"
>> #include "hw/dma/i8257.h"
>> @@ -100,9 +101,14 @@ static void clipper_init(MachineState *machine)
>> /* IDE disk setup. */
>> {
>> DriveInfo *hd[MAX_IDE_BUS * MAX_IDE_DEVS];
>> + PCIDevice *pci_dev;
>> +
>> ide_drive_get(hd, ARRAY_SIZE(hd));
>>
>> - pci_cmd646_ide_init(pci_bus, hd, 0);
>> + pci_dev = pci_create(pci_bus, -1, "cmd646-ide");
>
> Not this patch problem, but it would be nice to have a TYPE_CMD646_IDE.
Yeah - there are quite a few places where this could be improved, but certainly a
patch for another day.
>> + qdev_prop_set_uint32(DEVICE(pci_dev), "secondary", 0);
>
> Secondary_ide disabled is the default in cmd646_ide_properties[], can
> we avoid this call?
Sure. The patch in its current form is a very simple like-for-like conversion, but it
can be easily be removed.
If we're going to do this then another thing to consider is if we want to replace the
-1 in pci_create() with a specific PCI_DEVFN value to make things a bit more robust.
ATB,
Mark.
^ permalink raw reply
* [PATCH] sandbox: also restore terminal settings when killed by SIGINT
From: Simon Glass @ 2020-02-14 19:16 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20200214105810.14588-1-rasmus.villemoes@prevas.dk>
On Fri, 14 Feb 2020 at 03:58, Rasmus Villemoes
<rasmus.villemoes@prevas.dk> wrote:
>
> Hitting Ctrl-C is a documented way to exit the sandbox, but it is not
> actually equivalent to the reset command. The latter, since it follows
> normal process exit, takes care to reset terminal settings and
> restoring the O_NONBLOCK behaviour of stdin (and, in a terminal, that
> is usually the same file description as stdout and stderr, i.e. some
> /dev/pts/NN).
>
> Failure to restore (remove) O_NONBLOCK from stdout/stderr can cause
> very surprising and hard to debug problems back in the terminal. For
> example, I had "make -j8" consistently failing without much
> information about just exactly what went wrong, but sometimes I did
> get a "echo: write error". I was at first afraid my disk was getting
> bad, but then a simple "dmesg" _also_ failed with write error - so it
> was writing to the terminal that was buggered. And both "make -j8" and
> dmesg in another terminal window worked just fine.
>
> So install a SIGINT handler so that if the chosen terminal
> mode (cooked or raw-with-sigs) means Ctrl-C sends a SIGINT, we will
> still call os_fd_restore(), then reraise the signal and die as usual
> from SIGINT.
>
> Before:
>
> $ grep flags /proc/$$/fdinfo/1
> flags: 0102002
> $ ./u-boot
> # hit Ctrl-C
> $ grep flags /proc/$$/fdinfo/1
> flags: 0106002
>
> After:
>
> $ grep flags /proc/$$/fdinfo/1
> flags: 0102002
> $ ./u-boot
> # hit Ctrl-C
> $ grep flags /proc/$$/fdinfo/1
> flags: 0102002
>
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
> ---
> arch/sandbox/cpu/os.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
Nice explanation, thank you.
Reviewed-by: Simon Glass <sjg@chromium.org>
^ permalink raw reply
* [PATCH 10/33] mtd: Rename free() to rfree()
From: Simon Glass @ 2020-02-14 19:16 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAAh8qszRx9mtcXOCibb2iZ3pnbUSr-YM2p91Hmnm=5OhaFPvEw@mail.gmail.com>
Hi Simon,
On Thu, 13 Feb 2020 at 02:06, Simon Goldschmidt
<simon.k.r.goldschmidt@gmail.com> wrote:
>
> On Wed, Feb 12, 2020 at 6:14 PM Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Masahiro,
> >
> > On Wed, 12 Feb 2020 at 06:14, Masahiro Yamada <masahiroy@kernel.org> wrote:
> > >
> > > On Mon, Jan 13, 2020 at 4:08 AM Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > This function name conflicts with our desire to #define free() to
> > > > something else on sandbox. Since it deals with resources, rename it to
> > > > rfree().
> > > >
> > > > Signed-off-by: Simon Glass <sjg@chromium.org>
> > >
> > >
> > > I noticed this commit was merged recently.
> > >
> > > Now 'free' is a reserved keyword
> > > you cannot use in U-Boot.
> > >
> > >
> > > Commit cc92c3c thru cf23c7c are horrible.
> > >
> > >
> > > Commit cfda60f should have used
> > > 'static inline' instead of #define.
> > >
> > > I cannot believe it.
> >
> > Are you sure you understand the problem I was trying to solve? I am
> > using dlmalloc's existing means of adding a prefix, but I'm sure we
> > could change it to another way.
> >
> > If we define malloc() as dlmalloc() in dlmalloc.c, then we could add a
> > declaration in dlmalloc.h that uses static inline to convert calls to
> > malloc() to call dlmalloc(). Then anything that doesn't include
> > malloc.h would still call the C library malloc(). Is that what you are
> > thinking?
>
> There is no "malloc()" in dlmalloc.c. It is called "mALLOc()" and by defining
> USE_DL_PREFIX, you already have converted that to be linked as "dlmalloc()".
>
> I think there should be no difference in who calls what when converting your
> defines to static inline functions.
>
> And yes, I also dislike the other patches that remove all occurrences of
> 'free'. I think without knowing the backgrounds of your patches, that just
> looks strange.
OK I think that will work. I was trying to use what is there already,
but it is a bit ugly.
Regards,
Simon
^ permalink raw reply
* [PATCH] ARM: bootm: take into account gd->ram_top
From: Simon Glass @ 2020-02-14 19:16 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20200213182950.10744-1-patrick.delaunay@st.com>
Hi Patrick,
On Thu, 13 Feb 2020 at 11:30, Patrick Delaunay <patrick.delaunay@st.com> wrote:
>
> From: Patrice Chotard <patrice.chotard@st.com>
>
> If gd->ram_top has been tuned using board_get_usable_ram_top(),
> it must be taken into account when reserving arch lmb.
>
> Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
> Reviewed-by: Patrick DELAUNAY <patrick.delaunay@st.com>
> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
> ---
>
> arch/arm/lib/bootm.c | 3 +++
> 1 file changed, 3 insertions(+)
Is this something we can test in test/lib/lmb.c ?
Regards,
Simon
^ permalink raw reply
* sandbox: CONFIG_SYS_RELOC_GD_ENV_ADDR?
From: Simon Glass @ 2020-02-14 19:16 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20200214013935.GA22953@linaro.org>
Hi AKASHI,
On Thu, 13 Feb 2020 at 18:39, AKASHI Takahiro
<takahiro.akashi@linaro.org> wrote:
>
> Tom, Simon,
>
> Is CONFIG_SYS_RELOC_GD_ENV_ADDR really needed on sandbox?
>
> When I try to have a variable environment on emulated SPI flash,
> the U-Boot binary always crashes: (NOTE: assuming CONFIG_ENV_ADDR == 0)
> $ dd if=/dev/zero of=./spi.bin bs=1M count=4
> $ u-boot -T
> U-Boot 2020.04-rc2-00015-gc9afef2b1938-dirty (Feb 14 2020 - 10:24:59 +0900)
>
> Model: sandbox
> DRAM: 128 MiB
> WDT: Started with servicing (60s timeout)
> MMC: mmc2: 2 (SD), mmc1: 1 (SD), mmc0: 0 (SD)
> Loading Environment from SPI Flash... SF: Detected m25p16 with page size 256 Bytes, erase size 64 KiB, total 2 MiB
> *** Warning - bad CRC, using default environment
>
> Segmentation fault (core dumped)
>
> If this configuration is disabled, panic doesn't happen.
> I think that it should be turned off in any sandbox*_defconfig.
>
> In addition, please update
> - doc/arch/sandbox.rst
> - doc/SPI/README.sandbox-spi
> Both two still mention already-removed command line option, --spi_sf.
> It is confusing.
I'm not an expert on this, but I can't see any use for this in
sandbox. One problem might be that it should be using map_sysmem()
instead of a cast.
Regards,
Simon
^ permalink raw reply
* [PATCH AUTOSEL 4.14 104/186] soc: fsl: qe: remove set but not used variable 'mm_gc'
From: Sasha Levin @ 2020-02-14 16:15 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Chen Zhou, YueHaibing, Li Yang, Hulk Robot,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <20200214161715.18113-1-sashal@kernel.org>
From: YueHaibing <yuehaibing@huawei.com>
[ Upstream commit 6e62bd36e9ad85a22d92b1adce6a0336ea549733 ]
drivers/soc/fsl/qe/gpio.c: In function qe_pin_request:
drivers/soc/fsl/qe/gpio.c:163:26: warning: variable mm_gc set but not used [-Wunused-but-set-variable]
commit 1e714e54b5ca ("powerpc: qe_lib-gpio: use gpiochip data pointer")
left behind this unused variable.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Chen Zhou <chenzhou10@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Li Yang <leoyang.li@nxp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/soc/fsl/qe/gpio.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/soc/fsl/qe/gpio.c b/drivers/soc/fsl/qe/gpio.c
index 5cbc5ce5ac159..38643e84f355a 100644
--- a/drivers/soc/fsl/qe/gpio.c
+++ b/drivers/soc/fsl/qe/gpio.c
@@ -137,7 +137,6 @@ struct qe_pin *qe_pin_request(struct device_node *np, int index)
{
struct qe_pin *qe_pin;
struct gpio_chip *gc;
- struct of_mm_gpio_chip *mm_gc;
struct qe_gpio_chip *qe_gc;
int err;
unsigned long flags;
@@ -163,7 +162,6 @@ struct qe_pin *qe_pin_request(struct device_node *np, int index)
goto err0;
}
- mm_gc = to_of_mm_gpio_chip(gc);
qe_gc = gpiochip_get_data(gc);
spin_lock_irqsave(&qe_gc->lock, flags);
--
2.20.1
^ permalink raw reply related
* Re: [Intel-gfx] [PATCH i-g-t] lib/i915/gem_engine_topology.c - intel_get_current_engine invalid result
From: Chris Wilson @ 2020-02-14 19:14 UTC (permalink / raw)
To: Antonio Argenziano, Dale B Stimson, igt-dev, intel-gfx
In-Reply-To: <158170648335.15393.7332630257064965325@skylake-alporthouse-com>
Quoting Chris Wilson (2020-02-14 18:54:43)
> +static void libapi(int i915)
> +{
> + I915_DEFINE_CONTEXT_PARAM_ENGINES(engines, 0);
I915_DEFINE_CONTEXT_PARAM_ENGINES(engines, 0) = {};
or
struct i915_gem_context_param_engines engines = {};
> + struct drm_i915_gem_context_param p = {
> + .ctx_id = gem_context_create(i915),
> + .param = I915_CONTEXT_PARAM_ENGINES,
> + .value = to_user_pointer(&engines),
> + .size = sizeof(engines),
> + };
> + const struct intel_execution_engine2 *e;
> + unsigned int count = 0;
> +
> + gem_context_set_param(i915, &p);
> +
> + for_each_context_engine(i915, p.ctx_id, e)
> + count++;
> + igt_assert_eq(count, 0);
Of course this says that this for_each_context_engine() loop doesn't
work anyway.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v6 0/4] arm64: meson: add support for A1 Power Domains
From: Kevin Hilman @ 2020-02-14 19:14 UTC (permalink / raw)
To: Jianxin Pan, linux-amlogic
Cc: devicetree, Hanjie Lin, Victor Wan, Jianxin Pan, linux-pm,
Martin Blumenstingl, Neil Armstrong, linux-kernel, Rob Herring,
Jian Hu, Xingyu Chen, linux-arm-kernel, Jerome Brunet
In-Reply-To: <1579087831-94965-1-git-send-email-jianxin.pan@amlogic.com>
Jianxin Pan <jianxin.pan@amlogic.com> writes:
> This patchset introduces a "Secure Power Doamin Controller". In A1/C1, power
> controller registers such as PWRCTRL_FOCRSTN, PWRCTRL_PWR_OFF, PWRCTRL_MEM_PD
> and PWRCTRL_ISO_EN, are in the secure domain, and should be accessed from ATF
> by smc.
Series queued for v5.7 with Rob's ack on the DT bindings.
Thanks,
Kevin
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply
* Re: [PATCH v6 0/4] arm64: meson: add support for A1 Power Domains
From: Kevin Hilman @ 2020-02-14 19:14 UTC (permalink / raw)
To: Jianxin Pan, linux-amlogic
Cc: devicetree, Hanjie Lin, Victor Wan, Jianxin Pan, linux-pm,
Martin Blumenstingl, Neil Armstrong, linux-kernel, Rob Herring,
Jian Hu, Xingyu Chen, linux-arm-kernel, Jerome Brunet
In-Reply-To: <1579087831-94965-1-git-send-email-jianxin.pan@amlogic.com>
Jianxin Pan <jianxin.pan@amlogic.com> writes:
> This patchset introduces a "Secure Power Doamin Controller". In A1/C1, power
> controller registers such as PWRCTRL_FOCRSTN, PWRCTRL_PWR_OFF, PWRCTRL_MEM_PD
> and PWRCTRL_ISO_EN, are in the secure domain, and should be accessed from ATF
> by smc.
Series queued for v5.7 with Rob's ack on the DT bindings.
Thanks,
Kevin
_______________________________________________
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 v6 0/4] arm64: meson: add support for A1 Power Domains
From: Kevin Hilman @ 2020-02-14 19:14 UTC (permalink / raw)
To: Jianxin Pan, linux-amlogic
Cc: Jianxin Pan, Rob Herring, Neil Armstrong, Jerome Brunet,
Martin Blumenstingl, linux-pm, linux-kernel, linux-arm-kernel,
devicetree, Jian Hu, Hanjie Lin, Victor Wan, Xingyu Chen
In-Reply-To: <1579087831-94965-1-git-send-email-jianxin.pan@amlogic.com>
Jianxin Pan <jianxin.pan@amlogic.com> writes:
> This patchset introduces a "Secure Power Doamin Controller". In A1/C1, power
> controller registers such as PWRCTRL_FOCRSTN, PWRCTRL_PWR_OFF, PWRCTRL_MEM_PD
> and PWRCTRL_ISO_EN, are in the secure domain, and should be accessed from ATF
> by smc.
Series queued for v5.7 with Rob's ack on the DT bindings.
Thanks,
Kevin
^ permalink raw reply
* Re: [igt-dev] [PATCH i-g-t] lib/i915/gem_engine_topology.c - intel_get_current_engine invalid result
From: Chris Wilson @ 2020-02-14 19:14 UTC (permalink / raw)
To: Antonio Argenziano, Dale B Stimson, igt-dev, intel-gfx; +Cc: Petri Latvala
In-Reply-To: <158170648335.15393.7332630257064965325@skylake-alporthouse-com>
Quoting Chris Wilson (2020-02-14 18:54:43)
> +static void libapi(int i915)
> +{
> + I915_DEFINE_CONTEXT_PARAM_ENGINES(engines, 0);
I915_DEFINE_CONTEXT_PARAM_ENGINES(engines, 0) = {};
or
struct i915_gem_context_param_engines engines = {};
> + struct drm_i915_gem_context_param p = {
> + .ctx_id = gem_context_create(i915),
> + .param = I915_CONTEXT_PARAM_ENGINES,
> + .value = to_user_pointer(&engines),
> + .size = sizeof(engines),
> + };
> + const struct intel_execution_engine2 *e;
> + unsigned int count = 0;
> +
> + gem_context_set_param(i915, &p);
> +
> + for_each_context_engine(i915, p.ctx_id, e)
> + count++;
> + igt_assert_eq(count, 0);
Of course this says that this for_each_context_engine() loop doesn't
work anyway.
-Chris
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* Re: [PATCH v2 12/12] MIPS: DTS: CI20: fix interrupt for pcf8563 RTC
From: Paul Cercueil @ 2020-02-14 19:13 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Paul Boddie, Rob Herring, Mark Rutland, Ralf Baechle, Paul Burton,
David Airlie, Daniel Vetter, Andi Kleen, Miquel Raynal, Kees Cook,
devicetree, linux-mips, linux-kernel, dri-devel, letux-kernel,
kernel
In-Reply-To: <42aed0c7c063fa6c289fcbf361645056e15f513c.1581696624.git.hns@goldelico.com>
Hi Nikolaus,
Le ven., févr. 14, 2020 at 17:10, H. Nikolaus Schaller
<hns@goldelico.com> a écrit :
> Interrupts should not be specified by interrupt line but by
> gpio parent and reference.
>
> Fixes: 73f2b940474d ("MIPS: CI20: DTS: Add I2C nodes")
If you add a Fixes tag, you should also add:
Cc: stable@vger.kernel.org
if you're fixing something older than -rc1, which is the case here
(alternatively Cc them manually, but just for these patches).
Same remark for your patch 05/12.
Cheers,
-Paul
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> ---
> arch/mips/boot/dts/ingenic/ci20.dts | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/mips/boot/dts/ingenic/ci20.dts
> b/arch/mips/boot/dts/ingenic/ci20.dts
> index 8f9d182566db..4bacefa2cfce 100644
> --- a/arch/mips/boot/dts/ingenic/ci20.dts
> +++ b/arch/mips/boot/dts/ingenic/ci20.dts
> @@ -298,7 +298,9 @@ Optional input supply properties:
> rtc@51 {
> compatible = "nxp,pcf8563";
> reg = <0x51>;
> - interrupts = <110>;
> +
> + interrupt-parent = <&gpf>;
> + interrupts = <30 IRQ_TYPE_LEVEL_LOW>;
> };
> };
>
> --
> 2.23.0
>
^ permalink raw reply
* Re: [PATCH v2 19/19] tests/tcg: take into account expected clashes pauth-4
From: Robert Foley @ 2020-02-14 19:12 UTC (permalink / raw)
To: Alex Bennée
Cc: fam, Peter Maydell, berrange, pbonzini, stefanb,
Richard Henderson, qemu-devel, robhenry, f4bug, marcandre.lureau,
aaron, cota, stefanha, kuhn.chenqun, Peter Puhov,
open list:ARM TCG CPUs, aurelien
In-Reply-To: <20200213225109.13120-20-alex.bennee@linaro.org>
On Thu, 13 Feb 2020 at 18:00, Alex Bennée <alex.bennee@linaro.org> wrote:
>
> Pointer authentication isn't perfect so measure the percentage of
> failed checks. As we want to vary the pointer that is authenticated we
> recurse down the stack.
>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Robert Foley <robert.foley@linaro.org>
^ permalink raw reply
* Re: [PATCH] kvm/emulate: fix a -Werror=cast-function-type
From: Qian Cai @ 2020-02-14 19:14 UTC (permalink / raw)
To: Jim Mattson
Cc: Sean Christopherson, Paolo Bonzini, Vitaly Kuznetsov, Wanpeng Li,
Joerg Roedel, kvm list, LKML
In-Reply-To: <CALMp9eTRn-46oKg5a9h79EZOvHGwT=8ZZN15Zmy5NUYsd+r8wQ@mail.gmail.com>
On Fri, 2020-02-14 at 09:40 -0800, Jim Mattson wrote:
> On Fri, Feb 14, 2020 at 9:08 AM Qian Cai <cai@lca.pw> wrote:
> >
> > On Fri, 2020-02-14 at 08:59 -0800, Sean Christopherson wrote:
> > > On Fri, Feb 14, 2020 at 10:56:08AM -0500, Qian Cai wrote:
> > > > arch/x86/kvm/emulate.c: In function 'x86_emulate_insn':
> > > > arch/x86/kvm/emulate.c:5686:22: error: cast between incompatible
> > > > function types from 'int (*)(struct x86_emulate_ctxt *)' to 'void
> > > > (*)(struct fastop *)' [-Werror=cast-function-type]
> > > > rc = fastop(ctxt, (fastop_t)ctxt->execute);
> > > >
> > > > Fixes: 3009afc6e39e ("KVM: x86: Use a typedef for fastop functions")
> > > > Signed-off-by: Qian Cai <cai@lca.pw>
> > > > ---
> > > > arch/x86/kvm/emulate.c | 8 +++++---
> > > > 1 file changed, 5 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
> > > > index ddbc61984227..17ae820cf59d 100644
> > > > --- a/arch/x86/kvm/emulate.c
> > > > +++ b/arch/x86/kvm/emulate.c
> > > > @@ -5682,10 +5682,12 @@ int x86_emulate_insn(struct x86_emulate_ctxt *ctxt)
> > > > ctxt->eflags &= ~X86_EFLAGS_RF;
> > > >
> > > > if (ctxt->execute) {
> > > > - if (ctxt->d & Fastop)
> > > > - rc = fastop(ctxt, (fastop_t)ctxt->execute);
> > >
> > > Alternatively, can we do -Wno-cast-function-type? That's a silly warning
> > > IMO.
> >
> > I am doing W=1 on linux-next where some of the warnings might be silly but the
> > recent commit changes all warnings to errors forces me having to silence those
> > somehow.
> >
> > >
> > > If not, will either of these work?
> > >
> > > rc = fastop(ctxt, (void *)ctxt->execute);
> > >
> > > or
> > > rc = fastop(ctxt, (fastop_t)(void *)ctxt->execute);
> >
> > I have no strong preference. I originally thought just to go back the previous
> > code style where might be more acceptable, but it is up to maintainers.
>
> It seems misguided to define a local variable just to get an implicit
> cast from (void *) to (fastop_t). Sean's first suggestion gives you
> the same implicit cast without the local variable. The second
> suggestion makes both casts explicit.
OK, I'll do a v2 using the first suggestion which looks simpler once it passed
compilations.
^ permalink raw reply
* [meta-python][PATCH] python3-blinker: consolidate inc and bb files into a single bb file
From: Derek Straka @ 2020-02-14 19:13 UTC (permalink / raw)
To: openembedded-devel
Signed-off-by: Derek Straka <derek@asterius.io>
---
meta-python/recipes-devtools/python/python-blinker.inc | 7 -------
.../recipes-devtools/python/python3-blinker_1.4.bb | 8 +++++++-
2 files changed, 7 insertions(+), 8 deletions(-)
delete mode 100644 meta-python/recipes-devtools/python/python-blinker.inc
diff --git a/meta-python/recipes-devtools/python/python-blinker.inc b/meta-python/recipes-devtools/python/python-blinker.inc
deleted file mode 100644
index eaf3908370..0000000000
--- a/meta-python/recipes-devtools/python/python-blinker.inc
+++ /dev/null
@@ -1,7 +0,0 @@
-DESCRIPTION = "Fast, simple object-to-object and broadcast signaling."
-LICENSE = "MIT"
-LIC_FILES_CHKSUM = "file://PKG-INFO;md5=946d7e89af6f7733aeaebed5635d2682"
-
-SRC_URI[md5sum] = "8b3722381f83c2813c52de3016b68d33"
-SRC_URI[sha256sum] = "471aee25f3992bd325afa3772f1063dbdbbca947a041b8b89466dc00d606f8b6"
-
diff --git a/meta-python/recipes-devtools/python/python3-blinker_1.4.bb b/meta-python/recipes-devtools/python/python3-blinker_1.4.bb
index 924b3cf51d..e2f76c33d8 100644
--- a/meta-python/recipes-devtools/python/python3-blinker_1.4.bb
+++ b/meta-python/recipes-devtools/python/python3-blinker_1.4.bb
@@ -1,2 +1,8 @@
+DESCRIPTION = "Fast, simple object-to-object and broadcast signaling."
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://PKG-INFO;md5=946d7e89af6f7733aeaebed5635d2682"
+
+SRC_URI[md5sum] = "8b3722381f83c2813c52de3016b68d33"
+SRC_URI[sha256sum] = "471aee25f3992bd325afa3772f1063dbdbbca947a041b8b89466dc00d606f8b6"
+
inherit pypi setuptools3
-require python-blinker.inc
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v2 19/19] tests/tcg: take into account expected clashes pauth-4
From: Robert Foley @ 2020-02-14 19:12 UTC (permalink / raw)
To: Alex Bennée
Cc: qemu-devel, cota, aaron, Peter Puhov, kuhn.chenqun, robhenry, fam,
berrange, f4bug, Richard Henderson, balrogg, aurelien, pbonzini,
stefanha, stefanb, marcandre.lureau, Peter Maydell,
open list:ARM TCG CPUs
In-Reply-To: <20200213225109.13120-20-alex.bennee@linaro.org>
On Thu, 13 Feb 2020 at 18:00, Alex Bennée <alex.bennee@linaro.org> wrote:
>
> Pointer authentication isn't perfect so measure the percentage of
> failed checks. As we want to vary the pointer that is authenticated we
> recurse down the stack.
>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Robert Foley <robert.foley@linaro.org>
^ 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.