* [PATCH v2 2/9] arm64: dts: rockchip: add pd_sd power node for rk3399
From: Caesar Wang @ 2016-11-09 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478697721-2323-1-git-send-email-wxt@rock-chips.com>
From: zhangqing <zhangqing@rock-chips.com>
1.add pd node for RK3399 Soc
2.create power domain tree
3.add qos node for domain
4.add the pd_sd consumers node
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
---
Changes in v2:
- v1 on https://patchwork.kernel.org/patch/9322553/
- Reviewed-on: https://chromium-review.googlesource.com/386483
- Verified on ChromeOS kernel4.4
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index b401176..e5b5b3d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -253,6 +253,7 @@
<&cru SCLK_SDMMC_DRV>, <&cru SCLK_SDMMC_SAMPLE>;
clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
fifo-depth = <0x100>;
+ power-domains = <&power RK3399_PD_SD>;
status = "disabled";
};
@@ -691,6 +692,11 @@
status = "disabled";
};
+ qos_sd: qos at ffa74000 {
+ compatible = "syscon";
+ reg = <0x0 0xffa74000 0x0 0x20>;
+ };
+
qos_emmc: qos at ffa58000 {
compatible = "syscon";
reg = <0x0 0xffa58000 0x0 0x20>;
@@ -839,6 +845,12 @@
clocks = <&cru ACLK_GMAC>;
pm_qos = <&qos_gmac>;
};
+ pd_sd at RK3399_PD_SD {
+ reg = <RK3399_PD_SD>;
+ clocks = <&cru HCLK_SDMMC>,
+ <&cru SCLK_SDMMC>;
+ pm_qos = <&qos_sd>;
+ };
pd_vio at RK3399_PD_VIO {
reg = <RK3399_PD_VIO>;
#address-cells = <1>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/9] arm64: dts: rockchip: add pd_sd power node for rk3399
From: Caesar Wang @ 2016-11-09 13:21 UTC (permalink / raw)
To: Heiko Stuebner
Cc: eddie.cai-TNX95d0MmH7DzftRWevZcw, tfiga-F7+t8E8rja9g9hUCZPvPmw,
zhangqing, Caesar Wang, Douglas Anderson, David Wu, Jianqun Xu,
Yakir Yang, Brian Norris, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Will Deacon,
Mark Rutland, Catalin Marinas,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1478697721-2323-1-git-send-email-wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
From: zhangqing <zhangqing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
1.add pd node for RK3399 Soc
2.create power domain tree
3.add qos node for domain
4.add the pd_sd consumers node
Signed-off-by: Elaine Zhang <zhangqing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Signed-off-by: Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
---
Changes in v2:
- v1 on https://patchwork.kernel.org/patch/9322553/
- Reviewed-on: https://chromium-review.googlesource.com/386483
- Verified on ChromeOS kernel4.4
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index b401176..e5b5b3d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -253,6 +253,7 @@
<&cru SCLK_SDMMC_DRV>, <&cru SCLK_SDMMC_SAMPLE>;
clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
fifo-depth = <0x100>;
+ power-domains = <&power RK3399_PD_SD>;
status = "disabled";
};
@@ -691,6 +692,11 @@
status = "disabled";
};
+ qos_sd: qos@ffa74000 {
+ compatible = "syscon";
+ reg = <0x0 0xffa74000 0x0 0x20>;
+ };
+
qos_emmc: qos@ffa58000 {
compatible = "syscon";
reg = <0x0 0xffa58000 0x0 0x20>;
@@ -839,6 +845,12 @@
clocks = <&cru ACLK_GMAC>;
pm_qos = <&qos_gmac>;
};
+ pd_sd@RK3399_PD_SD {
+ reg = <RK3399_PD_SD>;
+ clocks = <&cru HCLK_SDMMC>,
+ <&cru SCLK_SDMMC>;
+ pm_qos = <&qos_sd>;
+ };
pd_vio@RK3399_PD_VIO {
reg = <RK3399_PD_VIO>;
#address-cells = <1>;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 1/9] arm64: dts: rockchip: add eMMC's power domain support for rk3399
From: Caesar Wang @ 2016-11-09 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478697721-2323-1-git-send-email-wxt@rock-chips.com>
From: Ziyuan Xu <xzy.xu@rock-chips.com>
Control power domain for eMMC via genpd to reduce power consumption.
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
---
Changes in v2:
- Reviewed-on: https://chromium-review.googlesource.com/376558
- Verified on ChromeOS kernel4.4
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index cbb7f8b..b401176 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -269,6 +269,7 @@
#clock-cells = <0>;
phys = <&emmc_phy>;
phy-names = "phy_arasan";
+ power-domains = <&power RK3399_PD_EMMC>;
status = "disabled";
};
@@ -690,6 +691,11 @@
status = "disabled";
};
+ qos_emmc: qos at ffa58000 {
+ compatible = "syscon";
+ reg = <0x0 0xffa58000 0x0 0x20>;
+ };
+
qos_gmac: qos at ffa5c000 {
compatible = "syscon";
reg = <0x0 0xffa5c000 0x0 0x20>;
@@ -823,6 +829,11 @@
};
/* These power domains are grouped by VD_LOGIC */
+ pd_emmc at RK3399_PD_EMMC {
+ reg = <RK3399_PD_EMMC>;
+ clocks = <&cru ACLK_EMMC>;
+ pm_qos = <&qos_emmc>;
+ };
pd_gmac at RK3399_PD_GMAC {
reg = <RK3399_PD_GMAC>;
clocks = <&cru ACLK_GMAC>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 1/9] arm64: dts: rockchip: add eMMC's power domain support for rk3399
From: Caesar Wang @ 2016-11-09 13:21 UTC (permalink / raw)
To: Heiko Stuebner
Cc: eddie.cai, tfiga, Ziyuan Xu, Elaine Zhang, Caesar Wang,
Douglas Anderson, David Wu, Jianqun Xu, Yakir Yang, Brian Norris,
linux-kernel, linux-rockchip, devicetree, Rob Herring,
Will Deacon, Mark Rutland, Catalin Marinas, linux-arm-kernel
In-Reply-To: <1478697721-2323-1-git-send-email-wxt@rock-chips.com>
From: Ziyuan Xu <xzy.xu@rock-chips.com>
Control power domain for eMMC via genpd to reduce power consumption.
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
---
Changes in v2:
- Reviewed-on: https://chromium-review.googlesource.com/376558
- Verified on ChromeOS kernel4.4
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index cbb7f8b..b401176 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -269,6 +269,7 @@
#clock-cells = <0>;
phys = <&emmc_phy>;
phy-names = "phy_arasan";
+ power-domains = <&power RK3399_PD_EMMC>;
status = "disabled";
};
@@ -690,6 +691,11 @@
status = "disabled";
};
+ qos_emmc: qos@ffa58000 {
+ compatible = "syscon";
+ reg = <0x0 0xffa58000 0x0 0x20>;
+ };
+
qos_gmac: qos@ffa5c000 {
compatible = "syscon";
reg = <0x0 0xffa5c000 0x0 0x20>;
@@ -823,6 +829,11 @@
};
/* These power domains are grouped by VD_LOGIC */
+ pd_emmc@RK3399_PD_EMMC {
+ reg = <RK3399_PD_EMMC>;
+ clocks = <&cru ACLK_EMMC>;
+ pm_qos = <&qos_emmc>;
+ };
pd_gmac@RK3399_PD_GMAC {
reg = <RK3399_PD_GMAC>;
clocks = <&cru ACLK_GMAC>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 0/9] rockchip: add more power domain and devices dts for rk3399
From: Caesar Wang @ 2016-11-09 13:21 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Please allow me to integrate these patches.
They are missing or losing for upstream, then there are some patches
are always depending on them.
The following patches are releated to PD.
git log --oneline
827198c arm64: dts: rockchip: add the usb3 pd for rk3399
95e95b4 arm64: dts: rockchip: support dwc3 USB for rk3399
3ced49c arm64: dts: rockchip: add pd_edp node for rk3399
e19db3f arm64: dts: rockchip: introduce pclk_vio_grf in eDP device node
eb92079 arm64: dts: rockchip: add backlight support for rk3399 evb board
20b8135 arm64: dts: rockchip: add eDP device node for rk3399
480a1bb arm64: dts: rockchip: add VOP and VOP iommu node for rk3399
4964c0a arm64: dts: rockchip: add pd_sd power node for rk3399
c407a4c arm64: dts: rockchip: add eMMC's power domain support for rk3399
----
Hi Heiko & guys,
This series patches support the below PDs.
1) sd & emmc pd
4964c0a arm64: dts: rockchip: add pd_sd power node for rk3399
c407a4c arm64: dts: rockchip: add eMMC's power domain support for rk3399
2) edp pd
3ced49c arm64: dts: rockchip: add pd_edp node for rk3399
e19db3f arm64: dts: rockchip: introduce pclk_vio_grf in eDP device node
eb92079 arm64: dts: rockchip: add backlight support for rk3399 evb board
20b8135 arm64: dts: rockchip: add eDP device node for rk3399
480a1bb arm64: dts: rockchip: add VOP and VOP iommu node for rk3399
3) usb3 pd
827198c arm64: dts: rockchip: add the usb3 pd for rk3399
95e95b4 arm64: dts: rockchip: support dwc3 USB for rk3399
Thanks,
Caesar
Changes in v2:
- Reviewed-on: https://chromium-review.googlesource.com/376558
- Verified on ChromeOS kernel4.4
- v1 on https://patchwork.kernel.org/patch/9322553/
- Reviewed-on: https://chromium-review.googlesource.com/386483
- Verified on ChromeOS kernel4.4
- Yakir posted the original patch on
- https://patchwork.kernel.org/patch/9191777
- the original patches from brian posting on
https://chromium-review.googlesource.com/343603
- Reviewed-on: https://chromium-review.googlesource.com/384280
Brian Norris (1):
arm64: dts: rockchip: support dwc3 USB for rk3399
Caesar Wang (1):
arm64: dts: rockchip: add the usb3 pd for rk3399
Mark Yao (1):
arm64: dts: rockchip: add VOP and VOP iommu node for rk3399
Yakir Yang (3):
arm64: dts: rockchip: add eDP device node for rk3399
arm64: dts: rockchip: add backlight support for rk3399 evb board
arm64: dts: rockchip: introduce pclk_vio_grf in eDP device node
Ziyuan Xu (1):
arm64: dts: rockchip: add eMMC's power domain support for rk3399
zhangqing (2):
arm64: dts: rockchip: add pd_sd power node for rk3399
arm64: dts: rockchip: add pd_edp node for rk3399
arch/arm64/boot/dts/rockchip/rk3399-evb.dts | 40 ++++++
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 210 ++++++++++++++++++++++++++++
2 files changed, 250 insertions(+)
--
2.7.4
^ permalink raw reply
* [PATCH v2 0/9] rockchip: add more power domain and devices dts for rk3399
From: Caesar Wang @ 2016-11-09 13:21 UTC (permalink / raw)
To: Heiko Stuebner
Cc: eddie.cai-TNX95d0MmH7DzftRWevZcw, tfiga-F7+t8E8rja9g9hUCZPvPmw,
Caesar Wang, Arnd Bergmann, Frank Wang, Yakir Yang, zhangqing,
Rob Herring, Shawn Lin, Catalin Marinas, David Wu, Brian Norris,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Douglas Anderson,
Will Deacon, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Jianqun Xu,
Masahiro Yamada, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Ziyuan Xu,
Mark
Hi all,
Please allow me to integrate these patches.
They are missing or losing for upstream, then there are some patches
are always depending on them.
The following patches are releated to PD.
git log --oneline
827198c arm64: dts: rockchip: add the usb3 pd for rk3399
95e95b4 arm64: dts: rockchip: support dwc3 USB for rk3399
3ced49c arm64: dts: rockchip: add pd_edp node for rk3399
e19db3f arm64: dts: rockchip: introduce pclk_vio_grf in eDP device node
eb92079 arm64: dts: rockchip: add backlight support for rk3399 evb board
20b8135 arm64: dts: rockchip: add eDP device node for rk3399
480a1bb arm64: dts: rockchip: add VOP and VOP iommu node for rk3399
4964c0a arm64: dts: rockchip: add pd_sd power node for rk3399
c407a4c arm64: dts: rockchip: add eMMC's power domain support for rk3399
----
Hi Heiko & guys,
This series patches support the below PDs.
1) sd & emmc pd
4964c0a arm64: dts: rockchip: add pd_sd power node for rk3399
c407a4c arm64: dts: rockchip: add eMMC's power domain support for rk3399
2) edp pd
3ced49c arm64: dts: rockchip: add pd_edp node for rk3399
e19db3f arm64: dts: rockchip: introduce pclk_vio_grf in eDP device node
eb92079 arm64: dts: rockchip: add backlight support for rk3399 evb board
20b8135 arm64: dts: rockchip: add eDP device node for rk3399
480a1bb arm64: dts: rockchip: add VOP and VOP iommu node for rk3399
3) usb3 pd
827198c arm64: dts: rockchip: add the usb3 pd for rk3399
95e95b4 arm64: dts: rockchip: support dwc3 USB for rk3399
Thanks,
Caesar
Changes in v2:
- Reviewed-on: https://chromium-review.googlesource.com/376558
- Verified on ChromeOS kernel4.4
- v1 on https://patchwork.kernel.org/patch/9322553/
- Reviewed-on: https://chromium-review.googlesource.com/386483
- Verified on ChromeOS kernel4.4
- Yakir posted the original patch on
- https://patchwork.kernel.org/patch/9191777
- the original patches from brian posting on
https://chromium-review.googlesource.com/343603
- Reviewed-on: https://chromium-review.googlesource.com/384280
Brian Norris (1):
arm64: dts: rockchip: support dwc3 USB for rk3399
Caesar Wang (1):
arm64: dts: rockchip: add the usb3 pd for rk3399
Mark Yao (1):
arm64: dts: rockchip: add VOP and VOP iommu node for rk3399
Yakir Yang (3):
arm64: dts: rockchip: add eDP device node for rk3399
arm64: dts: rockchip: add backlight support for rk3399 evb board
arm64: dts: rockchip: introduce pclk_vio_grf in eDP device node
Ziyuan Xu (1):
arm64: dts: rockchip: add eMMC's power domain support for rk3399
zhangqing (2):
arm64: dts: rockchip: add pd_sd power node for rk3399
arm64: dts: rockchip: add pd_edp node for rk3399
arch/arm64/boot/dts/rockchip/rk3399-evb.dts | 40 ++++++
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 210 ++++++++++++++++++++++++++++
2 files changed, 250 insertions(+)
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v10 6/7] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID
From: Borislav Petkov @ 2016-11-09 13:21 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Kyle Huey, Robert O'Callahan, Andy Lutomirski, Ingo Molnar,
H. Peter Anvin, x86, Paolo Bonzini, Radim Krčmář,
Jeff Dike, Richard Weinberger, Alexander Viro, Shuah Khan,
Dave Hansen, Peter Zijlstra, Boris Ostrovsky, Len Brown,
Rafael J. Wysocki, Dmitry Safonov, David Matlack, linux-kernel
In-Reply-To: <alpine.DEB.2.20.1611082007010.3501@nanos>
On Tue, Nov 08, 2016 at 09:06:31PM +0100, Thomas Gleixner wrote:
> The upcoming ring3 mwait stuff can add its magic to tweak that MSR into
> this function.
>
> Stick the call at the end of init_scattered_cpuid_features() for now. I
> still need to figure out a proper place for it.
So Thomas and I discussed this more on IRC and I think we can get rid
of the MSR iterating in scattered.c and integrate both the R3 MWAIT and
CPUID faulting like this:
---
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index fcd484d2bb03..5c38a85af2e7 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -452,6 +457,39 @@ static void intel_bsp_resume(struct cpuinfo_x86 *c)
init_intel_energy_perf(c);
}
+static void init_misc_enables(struct cpuinfo_x86 *c)
+{
+ u64 val, misc_en;
+
+ if (rdmsrl_safe(MSR_MISC_FEATURES_ENABLES, &misc_en))
+ return;
+
+ misc_en &= ~MSR_MISC_ENABLES_CPUID_FAULT_ENABLE;
+
+ if (!rdmsrl_safe(MSR_PLATFORM_INFO, &val)) {
+ if (val & PLATINFO_CPUID_FAULT_BIT)
+ set_cpu_cap(c, X86_FEATURE_CPUID_FAULT);
+ }
+
+ wrmsrl(MSR_MISC_FEATURES_ENABLES, misc_en);
+ this_cpu_write(msr_misc_features_enables_shadow, misc_en);
+}
+
static void init_intel(struct cpuinfo_x86 *c)
{
unsigned int l2 = 0;
@@ -565,6 +603,8 @@ static void init_intel(struct cpuinfo_x86 *c)
detect_vmx_virtcap(c);
init_intel_energy_perf(c);
+
+ init_misc_enables(c);
}
#ifdef CONFIG_X86_32
---
Please redo your patchset and add the detection to init_intel() like above.
Also, let's call that MSR mask MSR_MISC_ENABLES_CPUID_FAULT_ENABLE like
the rest of the bits in msr-index.h
Thanks.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply related
* Re: [PATCH v10 6/7] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID
From: Borislav Petkov @ 2016-11-09 13:21 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Kyle Huey, Robert O'Callahan, Andy Lutomirski, Ingo Molnar,
H. Peter Anvin, x86, Paolo Bonzini, Radim Krčmář,
Jeff Dike, Richard Weinberger, Alexander Viro, Shuah Khan,
Dave Hansen, Peter Zijlstra, Boris Ostrovsky, Len Brown,
Rafael J. Wysocki, Dmitry Safonov, David Matlack, linux-kernel,
user-mode-linux-devel, user-mode-linux-user, linux-fsdevel,
linux-kselftest, kvm
In-Reply-To: <alpine.DEB.2.20.1611082007010.3501@nanos>
On Tue, Nov 08, 2016 at 09:06:31PM +0100, Thomas Gleixner wrote:
> The upcoming ring3 mwait stuff can add its magic to tweak that MSR into
> this function.
>
> Stick the call at the end of init_scattered_cpuid_features() for now. I
> still need to figure out a proper place for it.
So Thomas and I discussed this more on IRC and I think we can get rid
of the MSR iterating in scattered.c and integrate both the R3 MWAIT and
CPUID faulting like this:
---
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index fcd484d2bb03..5c38a85af2e7 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -452,6 +457,39 @@ static void intel_bsp_resume(struct cpuinfo_x86 *c)
init_intel_energy_perf(c);
}
+static void init_misc_enables(struct cpuinfo_x86 *c)
+{
+ u64 val, misc_en;
+
+ if (rdmsrl_safe(MSR_MISC_FEATURES_ENABLES, &misc_en))
+ return;
+
+ misc_en &= ~MSR_MISC_ENABLES_CPUID_FAULT_ENABLE;
+
+ if (!rdmsrl_safe(MSR_PLATFORM_INFO, &val)) {
+ if (val & PLATINFO_CPUID_FAULT_BIT)
+ set_cpu_cap(c, X86_FEATURE_CPUID_FAULT);
+ }
+
+ wrmsrl(MSR_MISC_FEATURES_ENABLES, misc_en);
+ this_cpu_write(msr_misc_features_enables_shadow, misc_en);
+}
+
static void init_intel(struct cpuinfo_x86 *c)
{
unsigned int l2 = 0;
@@ -565,6 +603,8 @@ static void init_intel(struct cpuinfo_x86 *c)
detect_vmx_virtcap(c);
init_intel_energy_perf(c);
+
+ init_misc_enables(c);
}
#ifdef CONFIG_X86_32
---
Please redo your patchset and add the detection to init_intel() like above.
Also, let's call that MSR mask MSR_MISC_ENABLES_CPUID_FAULT_ENABLE like
the rest of the bits in msr-index.h
Thanks.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply related
* Re: [PATCH] crypto: fix AEAD tag memory handling
From: Stephan Mueller @ 2016-11-09 13:20 UTC (permalink / raw)
To: Mat Martineau; +Cc: herbert, linux-crypto
In-Reply-To: <alpine.OSX.2.20.1610311456250.4111@mjmartin-mac01.local>
[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]
Am Montag, 31. Oktober 2016, 16:18:32 CET schrieb Mat Martineau:
Hi Mat,
>
> My main concern is getting the semantics correct and consistent in a
> single patch series. It would be a big problem to explain that AF_ALG AEAD
> read and write works one way in 4.x, another way in 4.y, and some
> different way in 4.z.
I do have a patch now available that exactly does what you suggest. See the
patch attached. It works with the following exception.
In the case of sendpage and using an in-place cipher operation, the patch
breaks as follows. When the caller sends the same buffer for a sendpage
operation, the cipher operation now will write the ciphertext to the beginning
of the buffer where the AAD used to be. The subsequent tag calculation will
now use the data it finds where the AAD is expected. As the cipher operation
has already replaced the AAD with the ciphertext, the tag calculation will
take the ciphertext as AAD and thus calculate a wrong tag.
Thus, the only way to avoid that would be to duplicate the AAD into an
internal buffer. But that would defeat the entire purpose of sendpage.
The patch, however, works with sendmsg as well as sendpage when the src and
dst buffers are different.
Ciao
Stephan
[-- Attachment #2: fix_read_offset.diff --]
[-- Type: text/x-patch, Size: 7509 bytes --]
diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
index c54bcb8..c8efd01 100644
--- a/crypto/algif_aead.c
+++ b/crypto/algif_aead.c
@@ -32,6 +32,7 @@ struct aead_sg_list {
struct aead_async_rsgl {
struct af_alg_sgl sgl;
struct list_head list;
+ bool new_page;
};
struct aead_async_req {
@@ -405,6 +406,61 @@ static void aead_async_cb(struct crypto_async_request *_req, int err)
iocb->ki_complete(iocb, err, err);
}
+/**
+ * scatterwalk_get_part() - get subset a scatterlist
+ *
+ * @dst: destination SGL to receive the pointers from source SGL
+ * @src: source SGL
+ * @len: data length in bytes to get from source SGL
+ * @max_sgs: number of SGs present in dst SGL to prevent overstepping boundaries
+ *
+ * @return: number of SG entries in dst
+ */
+static inline int scatterwalk_get_part(struct scatterlist *dst,
+ struct scatterlist *src,
+ unsigned int len, unsigned int max_sgs)
+{
+ /* leave one SG entry for chaining */
+ unsigned int j = 1;
+
+ while (len && j < max_sgs) {
+ unsigned int todo = min_t(unsigned int, len, src->length);
+
+ sg_set_page(dst, sg_page(src), todo, src->offset);
+ if (src->length >= len) {
+ sg_mark_end(dst);
+ break;
+ }
+ len -= todo;
+ j++;
+ src = sg_next(src);
+ dst = sg_next(dst);
+ }
+
+ return j;
+}
+
+static inline int aead_alloc_rsgl(struct sock *sk, struct aead_async_rsgl **ret)
+{
+ struct aead_async_rsgl *rsgl =
+ sock_kmalloc(sk, sizeof(*rsgl), GFP_KERNEL);
+ if (unlikely(!rsgl))
+ return -ENOMEM;
+ *ret = rsgl;
+ return 0;
+}
+
+static inline int aead_get_rsgl_areq(struct sock *sk,
+ struct aead_async_req *areq,
+ struct aead_async_rsgl **ret)
+{
+ if (list_empty(&areq->list)) {
+ *ret = &areq->first_rsgl;
+ return 0;
+ } else
+ return aead_alloc_rsgl(sk, ret);
+}
+
static int aead_recvmsg_async(struct socket *sock, struct msghdr *msg,
int flags)
{
@@ -433,7 +489,7 @@ static int aead_recvmsg_async(struct socket *sock, struct msghdr *msg,
if (!aead_sufficient_data(ctx))
goto unlock;
- used = ctx->used;
+ used = ctx->used - ctx->aead_assoclen;
if (ctx->enc)
outlen = used + as;
else
@@ -452,7 +508,6 @@ static int aead_recvmsg_async(struct socket *sock, struct msghdr *msg,
aead_request_set_ad(req, ctx->aead_assoclen);
aead_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
aead_async_cb, sk);
- used -= ctx->aead_assoclen;
/* take over all tx sgls from ctx */
areq->tsgl = sock_kmalloc(sk, sizeof(*areq->tsgl) * sgl->cur,
@@ -467,21 +522,26 @@ static int aead_recvmsg_async(struct socket *sock, struct msghdr *msg,
areq->tsgls = sgl->cur;
+ /* set AAD buffer */
+ err = aead_get_rsgl_areq(sk, areq, &rsgl);
+ if (err)
+ goto free;
+ list_add_tail(&rsgl->list, &areq->list);
+ sg_init_table(rsgl->sgl.sg, ALG_MAX_PAGES);
+ rsgl->sgl.npages = scatterwalk_get_part(rsgl->sgl.sg, sgl->sg,
+ ctx->aead_assoclen,
+ ALG_MAX_PAGES);
+ rsgl->new_page = false;
+ last_rsgl = rsgl;
+
/* create rx sgls */
while (outlen > usedpages && iov_iter_count(&msg->msg_iter)) {
size_t seglen = min_t(size_t, iov_iter_count(&msg->msg_iter),
(outlen - usedpages));
- if (list_empty(&areq->list)) {
- rsgl = &areq->first_rsgl;
-
- } else {
- rsgl = sock_kmalloc(sk, sizeof(*rsgl), GFP_KERNEL);
- if (unlikely(!rsgl)) {
- err = -ENOMEM;
- goto free;
- }
- }
+ err = aead_get_rsgl_areq(sk, areq, &rsgl);
+ if (err)
+ goto free;
rsgl->sgl.npages = 0;
list_add_tail(&rsgl->list, &areq->list);
@@ -491,6 +551,7 @@ static int aead_recvmsg_async(struct socket *sock, struct msghdr *msg,
goto free;
usedpages += err;
+ rsgl->new_page = true;
/* chain the new scatterlist with previous one */
if (last_rsgl)
@@ -531,7 +592,8 @@ static int aead_recvmsg_async(struct socket *sock, struct msghdr *msg,
free:
list_for_each_entry(rsgl, &areq->list, list) {
- af_alg_free_sg(&rsgl->sgl);
+ if (rsgl->new_page)
+ af_alg_free_sg(&rsgl->sgl);
if (rsgl != &areq->first_rsgl)
sock_kfree_s(sk, rsgl, sizeof(*rsgl));
}
@@ -545,6 +607,16 @@ static int aead_recvmsg_async(struct socket *sock, struct msghdr *msg,
return err ? err : outlen;
}
+static inline int aead_get_rsgl_ctx(struct sock *sk, struct aead_ctx *ctx,
+ struct aead_async_rsgl **ret)
+{
+ if (list_empty(&ctx->list)) {
+ *ret = &ctx->first_rsgl;
+ return 0;
+ } else
+ return aead_alloc_rsgl(sk, ret);
+}
+
static int aead_recvmsg_sync(struct socket *sock, struct msghdr *msg, int flags)
{
struct sock *sk = sock->sk;
@@ -582,9 +654,6 @@ static int aead_recvmsg_sync(struct socket *sock, struct msghdr *msg, int flags)
goto unlock;
}
- /* data length provided by caller via sendmsg/sendpage */
- used = ctx->used;
-
/*
* Make sure sufficient data is present -- note, the same check is
* is also present in sendmsg/sendpage. The checks in sendpage/sendmsg
@@ -598,6 +667,12 @@ static int aead_recvmsg_sync(struct socket *sock, struct msghdr *msg, int flags)
goto unlock;
/*
+ * The cipher operation input data is reduced by the associated data
+ * as the destination buffer will not hold the AAD.
+ */
+ used = ctx->used - ctx->aead_assoclen;
+
+ /*
* Calculate the minimum output buffer size holding the result of the
* cipher operation. When encrypting data, the receiving buffer is
* larger by the tag length compared to the input buffer as the
@@ -611,25 +686,29 @@ static int aead_recvmsg_sync(struct socket *sock, struct msghdr *msg, int flags)
outlen = used - as;
/*
- * The cipher operation input data is reduced by the associated data
- * length as this data is processed separately later on.
+ * Pre-pend the AAD buffer from the source SGL to the destination SGL.
+ * As the AAD buffer is not touched by the AEAD operation, the source
+ * SG buffers remain unchanged.
*/
- used -= ctx->aead_assoclen;
+ err = aead_get_rsgl_ctx(sk, ctx, &rsgl);
+ if (err)
+ goto unlock;
+ list_add_tail(&rsgl->list, &ctx->list);
+ sg_init_table(rsgl->sgl.sg, ALG_MAX_PAGES);
+ rsgl->sgl.npages = scatterwalk_get_part(rsgl->sgl.sg, sgl->sg,
+ ctx->aead_assoclen,
+ ALG_MAX_PAGES);
+ rsgl->new_page = false;
+ last_rsgl = rsgl;
/* convert iovecs of output buffers into scatterlists */
while (outlen > usedpages && iov_iter_count(&msg->msg_iter)) {
size_t seglen = min_t(size_t, iov_iter_count(&msg->msg_iter),
(outlen - usedpages));
- if (list_empty(&ctx->list)) {
- rsgl = &ctx->first_rsgl;
- } else {
- rsgl = sock_kmalloc(sk, sizeof(*rsgl), GFP_KERNEL);
- if (unlikely(!rsgl)) {
- err = -ENOMEM;
- goto unlock;
- }
- }
+ err = aead_get_rsgl_ctx(sk, ctx, &rsgl);
+ if (err)
+ goto unlock;
rsgl->sgl.npages = 0;
list_add_tail(&rsgl->list, &ctx->list);
@@ -637,7 +716,10 @@ static int aead_recvmsg_sync(struct socket *sock, struct msghdr *msg, int flags)
err = af_alg_make_sg(&rsgl->sgl, &msg->msg_iter, seglen);
if (err < 0)
goto unlock;
+
usedpages += err;
+ rsgl->new_page = true;
+
/* chain the new scatterlist with previous one */
if (last_rsgl)
af_alg_link_sg(&last_rsgl->sgl, &rsgl->sgl);
@@ -688,7 +770,8 @@ static int aead_recvmsg_sync(struct socket *sock, struct msghdr *msg, int flags)
unlock:
list_for_each_entry_safe(rsgl, tmp, &ctx->list, list) {
- af_alg_free_sg(&rsgl->sgl);
+ if (rsgl->new_page)
+ af_alg_free_sg(&rsgl->sgl);
if (rsgl != &ctx->first_rsgl)
sock_kfree_s(sk, rsgl, sizeof(*rsgl));
list_del(&rsgl->list);
^ permalink raw reply related
* Re: [PATCH v3 2/2] Partially revert 21550029f709072aacf3b90edd574e7d3021b400
From: Julien Grall @ 2016-11-09 13:20 UTC (permalink / raw)
To: Stefano Stabellini, xen-devel; +Cc: wei.liu2
In-Reply-To: <1478634163-27368-2-git-send-email-sstabellini@kernel.org>
Hi Stefano,
On 08/11/16 19:42, Stefano Stabellini wrote:
> @@ -1189,7 +1194,10 @@ static int __init gicv2_init(void)
> printk(XENLOG_WARNING
> "GICv2: Adjusting CPU interface base to %#"PRIx64"\n",
> cbase + aliased_offset);
> - }
> + } else if ( csize == SZ_128K )
> + printk(XENLOG_WARNING
> + "GICv2: GICC size=%lu but not aliased\n",
> + csize);
The indentation looks wrong here.
With that:
Acked-by: Julien Grall <julien.grall@arm.com>
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH net] r8152: Fix broken RX checksums.
From: Mark Lord @ 2016-11-09 13:19 UTC (permalink / raw)
To: Hayes Wang, David Miller
Cc: nic_swsd, netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <0835B3720019904CB8F7AA43166CEEB20104A0FD@RTITMBSV03.realtek.com.tw>
On 16-11-09 08:09 AM, Hayes Wang wrote:
> Mark Lord [mailto:mlord@pobox.com]
..
>> The MTU/MRU on this link is the standard 1500 bytes, so a pkt_len of 2045 isn't
>> valid here.
>> And the rx_desc values look an awful lot like the rx_data values that follow it.
>>
>> There's definitely more broken here than just TCP RX checksums.
>
> I don't think it is the issue of our hw. If it happens, windows or
> other OS may have problems, too. It is like the memory issue described
> in commit 990c9b347245("Merge branch 'r8152-fixes'"). It seems that
> the data in memory is not same with the one from the device.
I am still doing long-term testing of various tweaks to the driver,
and can now confirm that changing from kmalloc() to usb_alloc_coherent()
vastly improves reliability, and re-enabling RX checksums works fine
with that change.
However, even with coherent URB buffers, I still see the occasional bad rx_desc:
like, twice in 36 hours of continuous bashing at it.
So having code in the driver to sanitize the rx_desc is essential.
My current test code (shared with Hayes already) includes validation of various
key fields of the rx_desc, and detects when the chip/driver/whatever gets confused.
Hopefully r8152.c will get updated to take more care before trusting
what it sees in the rx_desc fields.
Cheers
--
Mark Lord
mlord@pobox.com
^ permalink raw reply
* Re: Postinsts question
From: Burton, Ross @ 2016-11-09 13:18 UTC (permalink / raw)
To: Vuille, Martin (Martin); +Cc: yocto@yoctoproject.org
In-Reply-To: <30C2D590D16A5C46ADFE6521910377987FF75F11@AZ-US1EXMB02.global.avaya.com>
[-- Attachment #1: Type: text/plain, Size: 784 bytes --]
On 8 November 2016 at 23:23, Vuille, Martin (Martin) <vmartin@avaya.com>
wrote:
> We are running with our rootfs mounted read-only.
>
> Consequently, any postinsts that get deferred to first boot fail.
>
>
>
> Is there a way to fail the build for any postinsts that can’t
>
> be performed during the build and have to be deferred?
>
>
I was looking at some other selftests today and a test suggested that this
already happens, and it's true.
If you add 'read-only-rootfs' to IMAGE_FEATURES then delayed postists are
fatal:
ERROR: core-image-sato-base-1.0-r0 do_rootfs: The following packages could
not be configured offline and rootfs is read-only: ['postinst-test-delayed']
ERROR: core-image-sato-base-1.0-r0 do_rootfs: Function failed: do_rootfs
Ross
[-- Attachment #2: Type: text/html, Size: 1782 bytes --]
^ permalink raw reply
* [Qemu-devel] [PATCH] vhost: Use vbus var instead of VIRTIO_BUS() macro
From: Felipe Franciosi @ 2016-11-09 13:18 UTC (permalink / raw)
To: Paolo Bonzini, Stefan Hajnoczi, Michael S. Tsirkin
Cc: qemu-devel@nongnu.org, Felipe Franciosi
Recent changes on vhost_dev_enable/disable_notifiers() produced a
VirtioBusState vbus variable which can be used instead of the
VIRTIO_BUS() macro. This commit just makes the code a little bit cleaner
and more consistent.
Signed-off-by: Felipe Franciosi <felipe@nutanix.com>
---
hw/virtio/vhost.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
index 1290963..7d29dad 100644
--- a/hw/virtio/vhost.c
+++ b/hw/virtio/vhost.c
@@ -1198,20 +1198,18 @@ int vhost_dev_enable_notifiers(struct vhost_dev *hdev, VirtIODevice *vdev)
virtio_device_stop_ioeventfd(vdev);
for (i = 0; i < hdev->nvqs; ++i) {
- r = virtio_bus_set_host_notifier(VIRTIO_BUS(qbus), hdev->vq_index + i,
- true);
+ r = virtio_bus_set_host_notifier(vbus, hdev->vq_index + i, true);
if (r < 0) {
error_report("vhost VQ %d notifier binding failed: %d", i, -r);
goto fail_vq;
}
}
- VIRTIO_BUS(qbus)->ioeventfd_started = true;
+ vbus->ioeventfd_started = true;
return 0;
fail_vq:
while (--i >= 0) {
- e = virtio_bus_set_host_notifier(VIRTIO_BUS(qbus), hdev->vq_index + i,
- false);
+ e = virtio_bus_set_host_notifier(vbus, hdev->vq_index + i, false);
if (e < 0) {
error_report("vhost VQ %d notifier cleanup error: %d", i, -r);
}
@@ -1230,17 +1228,17 @@ fail:
void vhost_dev_disable_notifiers(struct vhost_dev *hdev, VirtIODevice *vdev)
{
BusState *qbus = BUS(qdev_get_parent_bus(DEVICE(vdev)));
+ VirtioBusState *vbus = VIRTIO_BUS(qbus);
int i, r;
for (i = 0; i < hdev->nvqs; ++i) {
- r = virtio_bus_set_host_notifier(VIRTIO_BUS(qbus), hdev->vq_index + i,
- false);
+ r = virtio_bus_set_host_notifier(vbus, hdev->vq_index + i, false);
if (r < 0) {
error_report("vhost VQ %d notifier cleanup failed: %d", i, -r);
}
assert (r >= 0);
}
- VIRTIO_BUS(qbus)->ioeventfd_started = false;
+ vbus->ioeventfd_started = false;
virtio_device_start_ioeventfd(vdev);
}
--
1.9.4
^ permalink raw reply related
* Re: [PATCH v2] fs/nfsd/nfs4callback: Remove deprecated create_singlethread_workqueue
From: Jeff Layton @ 2016-11-09 13:18 UTC (permalink / raw)
To: J. Bruce Fields, Tejun Heo; +Cc: Bhaktipriya Shridhar, linux-nfs, linux-kernel
In-Reply-To: <20161109012725.GA29930@fieldses.org>
On Tue, 2016-11-08 at 20:27 -0500, J. Bruce Fields wrote:
> On Tue, Nov 08, 2016 at 05:52:21PM -0500, Tejun Heo wrote:
> >
> > Hello, Bruce.
> >
> > On Tue, Nov 08, 2016 at 04:39:11PM -0500, J. Bruce Fields wrote:
> > >
> > > Apologies, just cleaning out old mail and finding some I should have
> > > responded to long ago:
> > >
> > > On Wed, Aug 31, 2016 at 02:23:48AM +0530, Bhaktipriya Shridhar wrote:
> > > >
> > > > The workqueue "callback_wq" queues a single work item &cb->cb_work per
> > > > nfsd4_callback instance and thus, it doesn't require execution ordering.
> > >
> > > What's "execution ordering"?
> > >
AIUI, it means that jobs are always run in the order queued and are
serialized.
> > > We definitely do depend on the fact that at most one of these is running
> > > at a time.
> >
We do?
> > If there can be multiple cb's and thus cb->cb_work's per callback_wq,
> > it'd need explicit ordering. Is that the case?
>
These are basically client RPC tasks, and the cb_work just handles the
submission into the client RPC state machine. Just because we're running
several callbacks at the same time doesn't mean that they need to be
strictly ordered. The client state machine can certainly handle running
these in parallel.
> Yes, there can be multiple cb_work's.
>
Yes, but each is effectively a separate work unit. I see no reason why
we'd need to order them at all.
--
Jeff Layton <jlayton@poochiereds.net>
^ permalink raw reply
* Re: [PATCH 0/5] wic: bugfixes & --fixed-size support
From: Burton, Ross @ 2016-11-09 13:17 UTC (permalink / raw)
To: Maciej Borzecki; +Cc: Maciej Borzecki, OE-core
In-Reply-To: <cover.1478619682.git.maciej.borzecki@rndity.com>
[-- Attachment #1: Type: text/plain, Size: 4207 bytes --]
I pulled this series into a test run on the autobuilder and it is throwing
quite a lot of exceptions, such as:
Traceback (most recent call last):
File
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64-lsb/build/scripts/wic",
line 319, in <module>
sys.exit(main(sys.argv[1:]))
File
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64-lsb/build/scripts/wic",
line 314, in main
return hlp.invoke_subcommand(args, parser, hlp.wic_help_usage,
subcommands)
File
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64-lsb/build/scripts/lib/wic/help.py",
line 95, in invoke_subcommand
subcommands.get(args[0], subcommand_error)[0](args[1:], usage)
File
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64-lsb/build/scripts/wic",
line 247, in wic_create_subcommand
options.compressor, options.bmap, options.debug)
File
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64-lsb/build/scripts/lib/wic/engine.py",
line 195, in wic_create
crobj.main(cmdline)
File
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64-lsb/build/scripts/lib/wic/creator.py",
line 125, in main
return self._subcmds[pname](options, *args[1:])
File
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64-lsb/build/scripts/lib/wic/plugins/imager/direct_plugin.py",
line 93, in do_create
creator.create()
File
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64-lsb/build/scripts/lib/wic/imager/baseimager.py",
line 159, in create
self._create()
File
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64-lsb/build/scripts/lib/wic/imager/direct.py",
line 305, in _create
system_id=part.system_id)
File
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64-lsb/build/scripts/lib/wic/utils/partitionedfs.py",
line 101, in add_partition
size = size * 1024 // self.sector_size
TypeError: unsupported operand type(s) for //: 'str' and 'int'
WARNING:
TOPDIR/tmp/work/genericx86_64-poky-linux/core-image-lsb/1.0-r0/temp/run.do_image_wic.15783:1
exit 1 from 'BUILDDIR="TOPDIR" wic create "$wks" --vars
"TOPDIR/tmp/sysroots/genericx86-64/imgdata/" -e "core-image-lsb" -o "$out/"'
See
http://errors.yoctoproject.org/Errors/Latest/Autobuilder/?filter=a44a6a635c9ed02edb2a3dee0a13b0067becc425&type=commit
for more examples and context.
Ross
On 8 November 2016 at 15:56, Maciej Borzecki <maciej.borzecki@rndity.com>
wrote:
> The patch series is a follow-up after a previous attempt of adding
> --reserved-size option to wic[1].
>
> The series introduces a number of fixes in patches 1 - 4.
>
> The last patch in the series introduces --fixed-size option as discussed
> in [1].
> The patch also introduces minor refactoring to code responsible for
> computing
> partition size.
>
> Aside from new option, another user-visible change is how the size rootfs
> partitions with vfat is calculated. In previous code, vfat rootfs
> partition size
> did not account for --extra-space nor --overhead-factor. Now, all rootfs
> partitions (except for squashfs) are subject to the same rules of partition
> sizing.
>
> http://lists.openembedded.org/pipermail/openembedded-core/
> 2016-October/127634.html
>
> Maciej Borzecki (5):
> wic: make sure that partition size is always an integer in internal
> processing
> wic: use partition size when creating empty partition files
> wic: check that filesystem is specified for a rootfs partition
> wic: fix function comment typos
> wic: add --fixed-size wks option
>
> scripts/lib/wic/help.py | 14 +++--
> scripts/lib/wic/imager/direct.py | 2 +-
> scripts/lib/wic/ksparser.py | 41 +++++++++++++--
> scripts/lib/wic/partition.py | 93 +++++++++++++++++++++---------
> ----
> scripts/lib/wic/utils/partitionedfs.py | 6 +--
> 5 files changed, 109 insertions(+), 47 deletions(-)
>
> --
> 2.5.0
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
[-- Attachment #2: Type: text/html, Size: 5439 bytes --]
^ permalink raw reply
* Re: [PATCH 0/4] perf tools: Assorted fixes for hierarchy mode
From: Markus Trippelsdorf @ 2016-11-09 13:15 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Namhyung Kim, Ingo Molnar, Peter Zijlstra, Jiri Olsa, LKML
In-Reply-To: <20161109131115.GC12125@kernel.org>
On 2016.11.09 at 10:11 -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Nov 08, 2016 at 02:21:17PM +0100, Markus Trippelsdorf escreveu:
> > On 2016.11.08 at 22:08 +0900, Namhyung Kim wrote:
> > > Hello,
> > >
> > > This patches fix problems in hierarchy output Markus reported some
> > > time ago. The code is available on the 'perf/hierarchy-fix-v1' branch
> > > in my tree:
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git
> > >
> > > Any feedbacks are welcomed.
> >
> > It looks perfect now. Many thanks for your fixes.
>
> Ok, I'll take that as a Tested-by: Markus, ok?
Sure, feel free.
Thanks.
--
Markus
^ permalink raw reply
* Re: [PATCH net-next 2/3] ptp: igb: Use the high resolution frequency method.
From: Richard Cochran @ 2016-11-09 13:15 UTC (permalink / raw)
To: Keller, Jacob E
Cc: netdev@vger.kernel.org, tglx@linutronix.de,
Manfred.Rudigier@omicron.at, ulrik.debie-os@e2big.org,
stefan.sorensen@spectralink.com, davem@davemloft.net,
Kirsher, Jeffrey T, john.stultz@linaro.org,
intel-wired-lan@lists.osuosl.org
In-Reply-To: <1478642646.7545.39.camel@intel.com>
On Tue, Nov 08, 2016 at 10:04:23PM +0000, Keller, Jacob E wrote:
> Additionally, what about min/max frequency check? Wouldn't this need to
> be updated for the new adjfine operation?
In theory you might increase the max by some sub-ppb value, but we
cannot express that as the resolution of the user space interface is
in ppb, and that little extra is not important anyhow.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH 0/4] perf tools: Assorted fixes for hierarchy mode
From: Markus Trippelsdorf @ 2016-11-09 13:15 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Namhyung Kim, Ingo Molnar, Peter Zijlstra, Jiri Olsa, LKML
In-Reply-To: <20161109131041.GB12125@kernel.org>
On 2016.11.09 at 10:10 -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Nov 08, 2016 at 04:10:23PM +0100, Markus Trippelsdorf escreveu:
> > On 2016.11.09 at 00:05 +0900, Namhyung Kim wrote:
> > > On Tue, Nov 8, 2016 at 10:43 PM, Markus Trippelsdorf
> > > <markus@trippelsdorf.de> wrote:
> > > > On 2016.11.08 at 22:08 +0900, Namhyung Kim wrote:
> > > >> This patches fix problems in hierarchy output Markus reported some
> > > >> time ago. The code is available on the 'perf/hierarchy-fix-v1' branch
> > > >> in my tree:
>
> > > >> git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git
>
> > > >> Any feedbacks are welcomed.
>
> > > > By the way, I hope that:
> > > > https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=perf/core&id=8a06b0be6507f97f3aa92ca814335b8b65fd3de2
> > > > doesn't fall through the cracks.
>
> > > What do you mean? It's already in the tip/perf/core so will be merged
> > > to the mainline eventually.
>
> > Ok. I was just wondering, because it sits there for two weeks already...
>
> If you think something qualifies for perf/urgent, i.e. to go to a kernel
> that is in -rc stage, v4.9-rc4 now, for instance, please point that out
> and I'll consider it.
Because "perf top --hierarchy" is new in 4.9, I think all fixes for that
feature qualify for perf/urgent by default.
--
Markus
^ permalink raw reply
* [Intel-wired-lan] [PATCH net-next 2/3] ptp: igb: Use the high resolution frequency method.
From: Richard Cochran @ 2016-11-09 13:15 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <1478642646.7545.39.camel@intel.com>
On Tue, Nov 08, 2016 at 10:04:23PM +0000, Keller, Jacob E wrote:
> Additionally, what about min/max frequency check? Wouldn't this need to
> be updated for the new adjfine operation?
In theory you might increase the max by some sub-ppb value, but we
cannot express that as the resolution of the user space interface is
in ppb, and that little extra is not important anyhow.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH] perf tools pt: Remove obsolete paragraph in intel-pt.c
From: Arnaldo Carvalho de Melo @ 2016-11-09 13:14 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-kernel, Andi Kleen, adrian.hunter
In-Reply-To: <1478650260-30140-1-git-send-email-andi@firstfloor.org>
Em Tue, Nov 08, 2016 at 04:11:00PM -0800, Andi Kleen escreveu:
> From: Andi Kleen <ak@linux.intel.com>
>
> Since the unprivileged sched switch event was added in perf,
> PT doesn't need need perf_event_paranoid=-1 anymore for
> per cpu decoding. So remove the obsolete paragraph in
> the documentation.
Thanks for pointing that out, I'll do something slightly different tho,
pointing out that from kernel X.Y.Z, when the unprivileged
PERF_RECORD_SWITCH metadata event was introduced, this is no longer an
issue, having to be considered only on older kernels.
- Arnaldo
> Cc: adrian.hunter@intel.com
> Signed-off-by: Andi Kleen <ak@linux.intel.com>
> ---
> tools/perf/Documentation/intel-pt.txt | 10 ----------
> 1 file changed, 10 deletions(-)
>
> diff --git a/tools/perf/Documentation/intel-pt.txt b/tools/perf/Documentation/intel-pt.txt
> index c6c8318e38a2..c7f817fd3611 100644
> --- a/tools/perf/Documentation/intel-pt.txt
> +++ b/tools/perf/Documentation/intel-pt.txt
> @@ -550,16 +550,6 @@ Unless /proc/sys/kernel/perf_event_paranoid is set to -1, unprivileged users
> have memory limits imposed upon them. That affects what buffer sizes they can
> have as outlined above.
>
> -Unless /proc/sys/kernel/perf_event_paranoid is set to -1, unprivileged users are
> -not permitted to use tracepoints which means there is insufficient side-band
> -information to decode Intel PT in per-cpu mode, and potentially workload-only
> -mode too if the workload creates new processes.
> -
> -Note also, that to use tracepoints, read-access to debugfs is required. So if
> -debugfs is not mounted or the user does not have read-access, it will again not
> -be possible to decode Intel PT in per-cpu mode.
> -
> -
> sched_switch tracepoint
> -----------------------
>
> --
> 2.5.5
^ permalink raw reply
* Re: [v3 4/5] vfio: implement APIs to set/put kvm to/from vfio group
From: Xiao Guangrong @ 2016-11-09 13:06 UTC (permalink / raw)
To: Jike Song, Paolo Bonzini
Cc: Alex Williamson, kwankhede, cjia, kevin.tian, kvm
In-Reply-To: <58231B5C.3010506@intel.com>
On 11/09/2016 08:49 PM, Jike Song wrote:
> +void vfio_group_attach_kvm(struct vfio_group *group, struct kvm *kvm,
> + void (*fn)(struct kvm *))
> +{
> + mutex_lock(&group->udata.lock);
This lock is needed, please see below.
> +
> + fn(kvm);
> + blocking_notifier_call_chain(&group->udata.notifier,
> + VFIO_GROUP_NOTIFY_ATTACH_KVM, kvm);
As this is a callback before KVM releases its last refcount, i do not
think vendor driver need to get additional KVM refcount.
^ permalink raw reply
* Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()
From: Daniel Vetter @ 2016-11-09 13:13 UTC (permalink / raw)
To: Eric Engestrom
Cc: Eric Engestrom, Linux Kernel Mailing List, David Airlie,
dri-devel, Wei Yongjun, Daniel Vetter, Flora Cui, Gustavo Padovan,
Tom St Denis, Chunming Zhou, Thomas Hellstrom, Laurent Pinchart,
Sinclair Yeh, Xinliang Liu, Xinwei Kong, VMware Graphics,
Vitaly Prosyak, Alexandre Demers, Jani Nikula, intel-gfx,
Emily Deng, Colin Ian King, Junwei Zhang, Michel Dänzer,
Alex Deucher, Christian König
In-Reply-To: <20161109114217.GO25290@imgtec.com>
On Wed, Nov 9, 2016 at 12:42 PM, Eric Engestrom
<eric.engestrom@imgtec.com> wrote:
>> Well, had to drop it again since it didn't compile:
>>
>>
>> CC [M] drivers/gpu/drm/drm_blend.o
>> drivers/gpu/drm/drm_atomic.c: In function ‘drm_atomic_plane_print_state’:
>> drivers/gpu/drm/drm_atomic.c:920:5: error: too few arguments to function ‘drm_get_format_name’
>> drm_get_format_name(fb->pixel_format));
>> ^~~~~~~~~~~~~~~~~~~
>> In file included from ./include/drm/drmP.h:71:0,
>> from drivers/gpu/drm/drm_atomic.c:29:
>> ./include/drm/drm_fourcc.h:65:7: note: declared here
>> char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf);
>> ^~~~~~~~~~~~~~~~~~~
>>
>> Can you pls rebase onto drm-misc or linux-next or something?
>
> That was based on airlied/drm-next (last fetched on Sunday I think),
> I can rebase it on drm-misc if it helps, but it seems older than
> drm-next.
> Should I just rebase on top of current head of drm-next?
It needs to be drm-misc (linux-next doesn't have it yet) due to the
new atomic debug work that we just landed. I'm working on drm-tip as a
drm local integration tree to ease pains like these a bit, but that
doesn't really exist yet.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()
From: Daniel Vetter @ 2016-11-09 13:13 UTC (permalink / raw)
To: Eric Engestrom
Cc: dri-devel, Wei Yongjun, Daniel Vetter, Flora Cui, Gustavo Padovan,
Tom St Denis, Thomas Hellstrom, Laurent Pinchart, Xinliang Liu,
VMware Graphics, Vitaly Prosyak, Alexandre Demers, Jani Nikula,
intel-gfx, Eric Engestrom, Emily Deng, Junwei Zhang,
Michel Dänzer, Linux Kernel Mailing List, Alex Deucher
In-Reply-To: <20161109114217.GO25290@imgtec.com>
On Wed, Nov 9, 2016 at 12:42 PM, Eric Engestrom
<eric.engestrom@imgtec.com> wrote:
>> Well, had to drop it again since it didn't compile:
>>
>>
>> CC [M] drivers/gpu/drm/drm_blend.o
>> drivers/gpu/drm/drm_atomic.c: In function ‘drm_atomic_plane_print_state’:
>> drivers/gpu/drm/drm_atomic.c:920:5: error: too few arguments to function ‘drm_get_format_name’
>> drm_get_format_name(fb->pixel_format));
>> ^~~~~~~~~~~~~~~~~~~
>> In file included from ./include/drm/drmP.h:71:0,
>> from drivers/gpu/drm/drm_atomic.c:29:
>> ./include/drm/drm_fourcc.h:65:7: note: declared here
>> char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf);
>> ^~~~~~~~~~~~~~~~~~~
>>
>> Can you pls rebase onto drm-misc or linux-next or something?
>
> That was based on airlied/drm-next (last fetched on Sunday I think),
> I can rebase it on drm-misc if it helps, but it seems older than
> drm-next.
> Should I just rebase on top of current head of drm-next?
It needs to be drm-misc (linux-next doesn't have it yet) due to the
new atomic debug work that we just landed. I'm working on drm-tip as a
drm local integration tree to ease pains like these a bit, but that
doesn't really exist yet.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v10 6/7] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID
From: Borislav Petkov @ 2016-11-09 13:12 UTC (permalink / raw)
To: Kyle Huey
Cc: Robert O'Callahan, Thomas Gleixner, Andy Lutomirski,
Ingo Molnar, H. Peter Anvin, x86, Paolo Bonzini,
Radim Krčmář, Jeff Dike, Richard Weinberger,
Alexander Viro, Shuah Khan, Dave Hansen, Peter Zijlstra,
Boris Ostrovsky, Len Brown, Rafael J. Wysocki, Dmitry Safonov,
David Matlack, linux-kernel
In-Reply-To: <20161108183956.4521-7-khuey@kylehuey.com>
On Tue, Nov 08, 2016 at 10:39:55AM -0800, Kyle Huey wrote:
> Intel supports faulting on the CPUID instruction beginning with Ivy Bridge.
> When enabled, the processor will fault on attempts to execute the CPUID
> instruction with CPL>0. Exposing this feature to userspace will allow a
> ptracer to trap and emulate the CPUID instruction.
>
> When supported, this feature is controlled by toggling bit 0 of
> MSR_MISC_FEATURES_ENABLES. It is documented in detail in Section 2.3.2 of
> http://www.intel.com/content/dam/www/public/us/en/documents/application-notes/virtualization-technology-flexmigration-application-note.pdf
>
> Implement a new pair of arch_prctls, available on both x86-32 and x86-64.
>
> ARCH_GET_CPUID: Returns the current CPUID faulting state, either
> ARCH_CPUID_ENABLE or ARCH_CPUID_SIGSEGV. arg2 must be 0.
>
> ARCH_SET_CPUID: Set the CPUID faulting state to arg2, which must be either
> ARCH_CPUID_ENABLE or ARCH_CPUID_SIGSEGV. Returns EINVAL if arg2 is
> another value or CPUID faulting is not supported on this system.
>
> The state of the CPUID faulting flag is propagated across forks, but reset
> upon exec.
>
> Signed-off-by: Kyle Huey <khuey@kylehuey.com>
> ---
...
> diff --git a/tools/testing/selftests/x86/cpuid-fault.c b/tools/testing/selftests/x86/cpuid-fault.c
> new file mode 100644
> index 0000000..65419de
> --- /dev/null
> +++ b/tools/testing/selftests/x86/cpuid-fault.c
> @@ -0,0 +1,250 @@
> +
> +/*
> + * Tests for arch_prctl(ARCH_GET_CPUID, ...) / arch_prctl(ARCH_SET_CPUID, ...)
> + *
> + * Basic test to test behaviour of ARCH_GET_CPUID and ARCH_SET_CPUID
> + */
> +
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <unistd.h>
> +#include <signal.h>
> +#include <inttypes.h>
> +#include <cpuid.h>
> +#include <err.h>
> +#include <errno.h>
> +#include <sys/wait.h>
> +
> +#include <sys/prctl.h>
> +#include <linux/prctl.h>
> +
> +/*
> +#define ARCH_GET_CPUID 0x1005
> +#define ARCH_SET_CPUID 0x1006
> +#define ARCH_CPUID_ENABLE 1
> +#define ARCH_CPUID_SIGSEGV 2
> +#ifdef __x86_64__
> +#define SYS_arch_prctl 158
> +#else
> +#define SYS_arch_prctl 385
> +#endif
> +*/
> +
> +const char *cpuid_names[] = {
> + [0] = "[not set]",
> + [ARCH_CPUID_ENABLE] = "ARCH_CPUID_ENABLE",
> + [ARCH_CPUID_SIGSEGV] = "ARCH_CPUID_SIGSEGV",
> +};
> +
> +int arch_prctl(int code, unsigned long arg2)
> +{
> + return syscall(SYS_arch_prctl, code, arg2);
> +}
> +
> +int cpuid(unsigned int *eax, unsigned int *ebx, unsigned int *ecx,
> + unsigned int *edx)
> +{
> + return __get_cpuid(0, eax, ebx, ecx, edx);
> +}
> +
> +int do_child_exec_test(int eax, int ebx, int ecx, int edx)
> +{
> + int cpuid_val = 0, child = 0, status = 0;
> +
> + printf("arch_prctl(ARCH_GET_CPUID); ");
> +
> + cpuid_val = arch_prctl(ARCH_GET_CPUID, 0);
> + if (cpuid_val < 0)
> + errx(1, "ARCH_GET_CPUID fails now, but not before?");
> +
> + printf("cpuid_val == %s\n", cpuid_names[cpuid_val]);
> + if (cpuid_val != ARCH_CPUID_SIGSEGV)
> + errx(1, "How did cpuid get re-enabled on fork?");
> +
> + if ((child = fork()) == 0) {
ERROR: do not use assignment in if condition
#513: FILE: tools/testing/selftests/x86/cpuid-fault.c:64:
+ if ((child = fork()) == 0) {
There are more in that file.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply
* Re: [PATCH v10 6/7] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID
From: Borislav Petkov @ 2016-11-09 13:12 UTC (permalink / raw)
To: Kyle Huey
Cc: Robert O'Callahan, Thomas Gleixner, Andy Lutomirski,
Ingo Molnar, H. Peter Anvin, x86, Paolo Bonzini,
Radim Krčmář, Jeff Dike, Richard Weinberger,
Alexander Viro, Shuah Khan, Dave Hansen, Peter Zijlstra,
Boris Ostrovsky, Len Brown, Rafael J. Wysocki, Dmitry Safonov,
David Matlack, linux-kernel, user-mode-linux-devel,
user-mode-linux-user, linux-fsdevel, linux-kselftest, kvm
In-Reply-To: <20161108183956.4521-7-khuey@kylehuey.com>
On Tue, Nov 08, 2016 at 10:39:55AM -0800, Kyle Huey wrote:
> Intel supports faulting on the CPUID instruction beginning with Ivy Bridge.
> When enabled, the processor will fault on attempts to execute the CPUID
> instruction with CPL>0. Exposing this feature to userspace will allow a
> ptracer to trap and emulate the CPUID instruction.
>
> When supported, this feature is controlled by toggling bit 0 of
> MSR_MISC_FEATURES_ENABLES. It is documented in detail in Section 2.3.2 of
> http://www.intel.com/content/dam/www/public/us/en/documents/application-notes/virtualization-technology-flexmigration-application-note.pdf
>
> Implement a new pair of arch_prctls, available on both x86-32 and x86-64.
>
> ARCH_GET_CPUID: Returns the current CPUID faulting state, either
> ARCH_CPUID_ENABLE or ARCH_CPUID_SIGSEGV. arg2 must be 0.
>
> ARCH_SET_CPUID: Set the CPUID faulting state to arg2, which must be either
> ARCH_CPUID_ENABLE or ARCH_CPUID_SIGSEGV. Returns EINVAL if arg2 is
> another value or CPUID faulting is not supported on this system.
>
> The state of the CPUID faulting flag is propagated across forks, but reset
> upon exec.
>
> Signed-off-by: Kyle Huey <khuey@kylehuey.com>
> ---
...
> diff --git a/tools/testing/selftests/x86/cpuid-fault.c b/tools/testing/selftests/x86/cpuid-fault.c
> new file mode 100644
> index 0000000..65419de
> --- /dev/null
> +++ b/tools/testing/selftests/x86/cpuid-fault.c
> @@ -0,0 +1,250 @@
> +
> +/*
> + * Tests for arch_prctl(ARCH_GET_CPUID, ...) / arch_prctl(ARCH_SET_CPUID, ...)
> + *
> + * Basic test to test behaviour of ARCH_GET_CPUID and ARCH_SET_CPUID
> + */
> +
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <unistd.h>
> +#include <signal.h>
> +#include <inttypes.h>
> +#include <cpuid.h>
> +#include <err.h>
> +#include <errno.h>
> +#include <sys/wait.h>
> +
> +#include <sys/prctl.h>
> +#include <linux/prctl.h>
> +
> +/*
> +#define ARCH_GET_CPUID 0x1005
> +#define ARCH_SET_CPUID 0x1006
> +#define ARCH_CPUID_ENABLE 1
> +#define ARCH_CPUID_SIGSEGV 2
> +#ifdef __x86_64__
> +#define SYS_arch_prctl 158
> +#else
> +#define SYS_arch_prctl 385
> +#endif
> +*/
> +
> +const char *cpuid_names[] = {
> + [0] = "[not set]",
> + [ARCH_CPUID_ENABLE] = "ARCH_CPUID_ENABLE",
> + [ARCH_CPUID_SIGSEGV] = "ARCH_CPUID_SIGSEGV",
> +};
> +
> +int arch_prctl(int code, unsigned long arg2)
> +{
> + return syscall(SYS_arch_prctl, code, arg2);
> +}
> +
> +int cpuid(unsigned int *eax, unsigned int *ebx, unsigned int *ecx,
> + unsigned int *edx)
> +{
> + return __get_cpuid(0, eax, ebx, ecx, edx);
> +}
> +
> +int do_child_exec_test(int eax, int ebx, int ecx, int edx)
> +{
> + int cpuid_val = 0, child = 0, status = 0;
> +
> + printf("arch_prctl(ARCH_GET_CPUID); ");
> +
> + cpuid_val = arch_prctl(ARCH_GET_CPUID, 0);
> + if (cpuid_val < 0)
> + errx(1, "ARCH_GET_CPUID fails now, but not before?");
> +
> + printf("cpuid_val == %s\n", cpuid_names[cpuid_val]);
> + if (cpuid_val != ARCH_CPUID_SIGSEGV)
> + errx(1, "How did cpuid get re-enabled on fork?");
> +
> + if ((child = fork()) == 0) {
ERROR: do not use assignment in if condition
#513: FILE: tools/testing/selftests/x86/cpuid-fault.c:64:
+ if ((child = fork()) == 0) {
There are more in that file.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ 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.