[PATCH] MAINTAINERS: altera-sysmgr: Fix typo in a filepath
Fix typo (s/sysgmr/sysmgr/) in the header filepath.
Cc: Thor Thayer
Cc: Arnd Bergmann
Cc: Lee Jones
Fixes: f36e789a1f8d ("mfd: altera-sysmgr: Add SOCFPGA System Manager")
Signed-off-by: Denis Efremov
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index e81e60bd7c26..bf5f0467988c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -723,7 +723,7 @@ ALTERA SYSTEM MANAGER DRIVER
M: Thor Thayer
S: Maintained
F: drivers/mfd/altera-sysmgr.c
-F: include/linux/mfd/altera-sysgmr.h
+F: include/linux/mfd/altera-sysmgr.h
ALTERA SYSTEM RESOURCE DRIVER FOR ARRIA10 DEVKIT
M: Thor Thayer
--
2.21.0
linux-next: manual merge of the driver-core tree with the rcu tree
Hi all,
Today's linux-next merge of the driver-core tree got a conflict in:
drivers/base/power/runtime.c
between commit:
4a3a5474b4c1 ("driver/core: Convert to use built-in RCU list checking")
from the rcu tree and commit:
515db266a9da ("driver core: Remove device link creation limitation")
from the driver-core tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/base/power/runtime.c
index 50def99df970,45a8fbe6987a..
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@@ -1642,9 -1640,8 +1642,9 @@@ void pm_runtime_clean_up_links(struct d
idx = device_links_read_lock();
- list_for_each_entry_rcu(link, >links.consumers, s_node) {
+ list_for_each_entry_rcu(link, >links.consumers, s_node,
+ device_links_read_lock_held()) {
- if (link->flags & DL_FLAG_STATELESS)
+ if (!(link->flags & DL_FLAG_MANAGED))
continue;
while (refcount_dec_not_one(>rpm_active))
pgpdazhAyZSmo.pgp
Description: OpenPGP digital signature
Re: [PATCH v4 13/14] net: phy: adin: add ethtool get_stats support
On Mon, 2019-08-12 at 16:33 +0200, Andrew Lunn wrote:
> [External]
>
> > +static int adin_read_mmd_stat_regs(struct phy_device *phydev,
> > + struct adin_hw_stat *stat,
> > + u32 *val)
> > +{
> > + int ret;
> > +
> > + ret = phy_read_mmd(phydev, MDIO_MMD_VEND1, stat->reg1);
> > + if (ret < 0)
> > + return ret;
> > +
> > + *val = (ret & 0x);
> > +
> > + if (stat->reg2 == 0)
> > + return 0;
> > +
> > + ret = phy_read_mmd(phydev, MDIO_MMD_VEND1, stat->reg2);
> > + if (ret < 0)
> > + return ret;
> > +
> > + *val <<= 16;
> > + *val |= (ret & 0x);
> > +
> > + return 0;
> > +}
>
> It still looks like you have not dealt with overflow from the LSB into
> the MSB between the two reads.
Apologies for forgetting to address this.
I did not intentionally leave it out; this item got lost after V1 [which had
the most remarks].
Changelog V1 -> V2 was quite bulky, and I did not look at V1 remarks after I
finished V2.
Thanks for snippet.
>
> do {
> hi1 = phy_read_mmd(phydev, MDIO_MMD_VEND1, stat->reg2);
> if (hi1 < 0)
> return hi1;
>
> low = phy_read_mmd(phydev, MDIO_MMD_VEND1, stat->reg1);
> if (low < 0)
> return low;
>
> hi2 = phy_read_mmd(phydev, MDIO_MMD_VEND1, stat->reg2);
> if (hi2 < 0)
> return hi1;
> } while (hi1 != hi2)
>
> return low | (hi << 16);
>
> Andrew
Re: [PATCH v6 4/8] KVM: VMX: Pass through CET related MSRs to Guest
On Mon, Aug 12, 2019 at 04:53:41PM -0700, Sean Christopherson wrote:
> On Thu, Jul 25, 2019 at 11:12:42AM +0800, Yang Weijiang wrote:
> > CET MSRs pass through Guest directly to enhance performance.
> > CET runtime control settings are stored in MSR_IA32_{U,S}_CET,
> > Shadow Stack Pointer(SSP) are stored in MSR_IA32_PL{0,1,2,3}_SSP,
> > SSP table base address is stored in MSR_IA32_INT_SSP_TAB,
> > these MSRs are defined in kernel and re-used here.
> >
> > MSR_IA32_U_CET and MSR_IA32_PL3_SSP are used for user mode protection,
> > the contents could differ from process to process, therefore,
> > kernel needs to save/restore them during context switch, it makes
> > sense to pass through them so that the guest kernel can
> > use xsaves/xrstors to operate them efficiently. Other MSRs are used
> > for non-user mode protection. See CET spec for detailed info.
> >
> > The difference between CET VMCS state fields and xsave components is that,
> > the former used for CET state storage during VMEnter/VMExit,
> > whereas the latter used for state retention between Guest task/process
> > switch.
> >
> > Co-developed-by: Zhang Yi Z
> > Signed-off-by: Zhang Yi Z
> > Signed-off-by: Yang Weijiang
> > ---
> > arch/x86/kvm/vmx/vmx.c | 14 ++
> > 1 file changed, 14 insertions(+)
> >
> > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> > index ce1d6fe21780..ce5d1e45b7a5 100644
> > --- a/arch/x86/kvm/vmx/vmx.c
> > +++ b/arch/x86/kvm/vmx/vmx.c
> > @@ -6952,6 +6952,7 @@ static void update_intel_pt_cfg(struct kvm_vcpu *vcpu)
> > static void vmx_cpuid_update(struct kvm_vcpu *vcpu)
> > {
> > struct vcpu_vmx *vmx = to_vmx(vcpu);
> > + unsigned long *msr_bitmap;
> >
> > if (cpu_has_secondary_exec_ctrls()) {
> > vmx_compute_secondary_exec_control(vmx);
> > @@ -6973,6 +6974,19 @@ static void vmx_cpuid_update(struct kvm_vcpu *vcpu)
> > if (boot_cpu_has(X86_FEATURE_INTEL_PT) &&
> > guest_cpuid_has(vcpu, X86_FEATURE_INTEL_PT))
> > update_intel_pt_cfg(vcpu);
> > +
> > + msr_bitmap = vmx->vmcs01.msr_bitmap;
> > +
> > + if (guest_cpuid_has(vcpu, X86_FEATURE_SHSTK) ||
> > + guest_cpuid_has(vcpu, X86_FEATURE_IBT)) {
>
> These should be exposed to the guest if and only if they're supported in
> the host and guest, i.e. kvm_supported_xss() needs to be checked. And,
> again assuming USER and KERNEL can be virtualized independently, the logic
> needs to account for exposting USER but KERNEL and vice versa.
>
this patch serial is supposed to enable both USER and KERNEL mode CET as
long as platform and host kernel support so. I'll add condition check
before pass through correspond MSR to guest OS.
> > + vmx_disable_intercept_for_msr(msr_bitmap, MSR_IA32_U_CET,
> > MSR_TYPE_RW);
> > + vmx_disable_intercept_for_msr(msr_bitmap, MSR_IA32_S_CET,
> > MSR_TYPE_RW);
> > + vmx_disable_intercept_for_msr(msr_bitmap, MSR_IA32_INT_SSP_TAB,
> > MSR_TYPE_RW);
> > + vmx_disable_intercept_for_msr(msr_bitmap, MSR_IA32_PL0_SSP,
> > MSR_TYPE_RW);
> > + vmx_disable_intercept_for_msr(msr_bitmap, MSR_IA32_PL1_SSP,
> > MSR_TYPE_RW);
> > + vmx_disable_intercept_for_msr(msr_bitmap, MSR_IA32_PL2_SSP,
> > MSR_TYPE_RW);
> > + vmx_disable_intercept_for_msr(msr_bitmap, MSR_IA32_PL3_SSP,
> > MSR_TYPE_RW);
>
> The SSP MSRs should only be passed through if the guest has SHSTK, e.g.
> KVM should intercept RDMSR and WRMSR to inject #GP in those cases.
>
> > + }
> > }
> >
> > static void vmx_set_supported_cpuid(u32 func, struct kvm_cpuid_entry2
> > *entry)
> > --
> > 2.17.2
> >
Re: How to add multiple example with conflicting includes
Hi Rob,
On Fri, Jul 26, 2019 at 08:11:08PM +0200, Corentin Labbe wrote:
> When I try to check the following examples of a devicetree schema:
> examples:
> - |
> #include
> #include
> #include
>
> crypto: crypto@1c15000 {
> compatible = "allwinner,sun8i-h3-crypto";
> reg = <0x01c15000 0x1000>;
> interrupts = ;
> clocks = < CLK_BUS_CE>, < CLK_CE>;
> clock-names = "ahb", "mod";
> resets = < RST_BUS_CE>;
> reset-names = "ahb";
> };
>
> - |
> #include
> #include
> #include
>
> crypto: crypto@1904000 {
> compatible = "allwinner,sun50i-h6-crypto";
> reg = <0x01904000 0x1000>;
> interrupts = ;
> clocks = < CLK_BUS_CE>, < CLK_CE>, < CLK_MBUS_CE>;
> clock-names = "ahb", "mod", "mbus";
> resets = < RST_BUS_CE>;
> reset-names = "ahb";
> };
>
> I get:
> In file included from
> Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.example.dts:42:
> /linux-next/scripts/dtc/include-prefixes/dt-bindings/clock/sun50i-h6-ccu.h:9:
> warning: "CLK_PLL_PERIPH0" redefined
> #define CLK_PLL_PERIPH0 3
> [...]
>
> So how can I add multiple examples which need somes conflicting
> #include to be validated.
I'm having the same issue right now, is there a proper fix /
workaround?
Thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [PATCH v4 10/14] net: phy: adin: implement PHY subsystem software reset
On Mon, 2019-08-12 at 16:19 +0200, Andrew Lunn wrote:
> [External]
>
> > +static int adin_reset(struct phy_device *phydev)
> > +{
> > + /* If there is a reset GPIO just exit */
> > + if (!IS_ERR_OR_NULL(phydev->mdio.reset_gpio))
> > + return 0;
>
> I'm not so happy with this.
>
> First off, there are two possible GPIO configurations. The GPIO can be
> applied to all PHYs on the MDIO bus. That GPIO is used when the bus is
> probed. There can also be a per PHY GPIO, which is what you are
> looking at here.
>
> The idea of putting the GPIO handling in the core is that PHYs don't
> need to worry about it. How much of a difference does it make if the
> PHY is both reset via GPIO and then again in software? How slow is the
> software reset? Maybe just unconditionally do the reset, if it is not
> too slow.
>
Ack.
Will do it unconditionally.
The reset is not too slow.
> > +
> > + /* Reset PHY core regs & subsystem regs */
> > + return adin_subsytem_soft_reset(phydev);
> > +}
> > +
> > +static int adin_probe(struct phy_device *phydev)
> > +{
> > + return adin_reset(phydev);
> > +}
>
> Why did you decide to do this as part of probe, and not use the
> .soft_reset member of phy_driver?
Hmmm.
This is a left-over from when I had the GPIO handling in this PHY driver.
It's also a habit picked up from writing IIO drivers, where there is no
{soft_}reset hook.
Typically, the reset is done in the probe.
>
> > +
> > static struct phy_driver adin_driver[] = {
> > {
> > PHY_ID_MATCH_MODEL(PHY_ID_ADIN1200),
> > .name = "ADIN1200",
> > .config_init= adin_config_init,
> > + .probe = adin_probe,
> > .config_aneg= adin_config_aneg,
> > .read_status= adin_read_status,
> > .ack_interrupt = adin_phy_ack_intr,
> > @@ -461,6 +503,7 @@ static struct phy_driver adin_driver[] = {
> > PHY_ID_MATCH_MODEL(PHY_ID_ADIN1300),
> > .name = "ADIN1300",
> > .config_init= adin_config_init,
> > + .probe = adin_probe,
> > .config_aneg= adin_config_aneg,
> > .read_status= adin_read_status,
> > .ack_interrupt = adin_phy_ack_intr,
>
> Thanks
> Andrew
Re: [PATCH v6 8/8] KVM: x86: Add user-space access interface for CET MSRs
On Mon, Aug 12, 2019 at 04:43:36PM -0700, Sean Christopherson wrote: > On Thu, Jul 25, 2019 at 11:12:46AM +0800, Yang Weijiang wrote: > > There're two different places storing Guest CET states, the states > > managed with XSAVES/XRSTORS, as restored/saved > > in previous patch, can be read/write directly from/to the MSRs. > > For those stored in VMCS fields, they're access via vmcs_read/ > > vmcs_write. > > > > Signed-off-by: Yang Weijiang > > --- > > arch/x86/kvm/vmx/vmx.c | 43 ++ > > 1 file changed, 43 insertions(+) > > > > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c > > index 123285177c6b..e5eacd01e984 100644 > > --- a/arch/x86/kvm/vmx/vmx.c > > +++ b/arch/x86/kvm/vmx/vmx.c > > @@ -1774,6 +1774,27 @@ static int vmx_get_msr(struct kvm_vcpu *vcpu, struct > > msr_data *msr_info) > > else > > msr_info->data = vmx->pt_desc.guest.addr_a[index / 2]; > > break; > > + case MSR_IA32_S_CET: > > + msr_info->data = vmcs_readl(GUEST_S_CET); > > + break; > > + case MSR_IA32_U_CET: > > + rdmsrl(MSR_IA32_U_CET, msr_info->data); > > + break; > > + case MSR_IA32_INT_SSP_TAB: > > + msr_info->data = vmcs_readl(GUEST_INTR_SSP_TABLE); > > + break; > > + case MSR_IA32_PL0_SSP: > > + rdmsrl(MSR_IA32_PL0_SSP, msr_info->data); > > + break; > > + case MSR_IA32_PL1_SSP: > > + rdmsrl(MSR_IA32_PL1_SSP, msr_info->data); > > + break; > > + case MSR_IA32_PL2_SSP: > > + rdmsrl(MSR_IA32_PL2_SSP, msr_info->data); > > + break; > > + case MSR_IA32_PL3_SSP: > > + rdmsrl(MSR_IA32_PL3_SSP, msr_info->data); > > + break; > > These all need appropriate checks on guest and host support. The guest > checks won't come into play very often, if ever, for the MSRs that exist > if IBT *or* SHSTK is supported due to passing the MSRs through to the > guest, but I don't think we want this code reliant on the interception > logic. E.g.: > > case MSR_IA32_S_CET: > if (!(host_xss & XFEATURE_MASK_CET_KERNEL)) > return 1; > > if (!msr_info->host_initiated && > !guest_cpuid_has(vcpu, X86_FEATURE_SHSTK) && > !guest_cpuid_has(vcpu, X86_FEATURE_IBT)) > return 1; > > MSR_IA32_U_CET is same as above, s/KERNEL/USER. > > case MSR_IA32_INT_SSP_TAB: > if (!(host_xss & (XFEATURE_MASK_CET_KERNEL | > XFEATURE_MASK_CET_USER))) > return 1; > > if (!msr_info->host_initiated && > !guest_cpuid_has(vcpu, X86_FEATURE_SHSTK)) > return 1; > > MSR_IA32_PL[0-3]_SSP are same as above, but only check the appropriate > KERNEL or USER bit. > > Note, the PL[0-2]_SSP MSRs can be collapsed into a single case, e.g.: > > case MSR_IA32_PL0_SSP ... MSR_IA32_PL2_SSP: > ; > > rdmsrl(msr_index, msr_info->data); > break; > > > Rinse and repeat for vmx_set_msr(). > Thanks you, will modify this part of code. > > case MSR_TSC_AUX: > > if (!msr_info->host_initiated && > > !guest_cpuid_has(vcpu, X86_FEATURE_RDTSCP)) > > @@ -2007,6 +2028,28 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu, struct > > msr_data *msr_info) > > else > > vmx->pt_desc.guest.addr_a[index / 2] = data; > > break; > > + case MSR_IA32_S_CET: > > + vmcs_writel(GUEST_S_CET, data); > > + break; > > + case MSR_IA32_U_CET: > > + wrmsrl(MSR_IA32_U_CET, data); > > + break; > > + case MSR_IA32_INT_SSP_TAB: > > + vmcs_writel(GUEST_INTR_SSP_TABLE, data); > > + break; > > + case MSR_IA32_PL0_SSP: > > + wrmsrl(MSR_IA32_PL0_SSP, data); > > + break; > > + case MSR_IA32_PL1_SSP: > > + wrmsrl(MSR_IA32_PL1_SSP, data); > > + break; > > + case MSR_IA32_PL2_SSP: > > + wrmsrl(MSR_IA32_PL2_SSP, data); > > + break; > > + case MSR_IA32_PL3_SSP: > > + wrmsrl(MSR_IA32_PL3_SSP, data); > > + break; > > + > > case MSR_TSC_AUX: > > if (!msr_info->host_initiated && > > !guest_cpuid_has(vcpu, X86_FEATURE_RDTSCP)) > > -- > > 2.17.2 > >
Re: [PATCH v2] gpiolib: Take MUX usage into account
Hi Ramon,
On 13.08.19 03:42, Ramon Fried wrote:
> From: Stefan Wahren
>
> The user space like gpioinfo only see the GPIO usage but not the
> MUX usage (e.g. I2C or SPI usage) of a pin. As a user we want to know which
> pin is free/safe to use. So take the MUX usage of strict pinmux controllers
> into account to get a more realistic view for ioctl GPIO_GET_LINEINFO_IOCTL.
>
> Signed-off-by: Stefan Wahren
> Tested-by: Ramon Fried
> Signed-off-by: Ramon Fried
> ---
> v2: Address review from linus:
> * ** Please notive logic was reversed **
> * renamed pinctrl_gpio_is_in_use() to pinctrl_gpio_can_use_line()
> * renamed pinmux_is_in_use() to pinmux_can_be_used_for_gpio()
> * changed dev_err to dev_dbg (Linus suggested removing it altogether, I
> find it better to keep it for debug).
thanks for taking care of this.
>
> drivers/gpio/gpiolib.c | 3 ++-
> drivers/pinctrl/core.c | 28
> drivers/pinctrl/pinmux.c | 27 +++
> drivers/pinctrl/pinmux.h | 8
> include/linux/pinctrl/consumer.h | 6 ++
> 5 files changed, 71 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index f497003f119c..52937bf8e514 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -1084,7 +1084,8 @@ static long gpio_ioctl(struct file *filp, unsigned int
> cmd, unsigned long arg)
> test_bit(FLAG_IS_HOGGED, >flags) ||
> test_bit(FLAG_USED_AS_IRQ, >flags) ||
> test_bit(FLAG_EXPORT, >flags) ||
> - test_bit(FLAG_SYSFS, >flags))
> + test_bit(FLAG_SYSFS, >flags) ||
> + !pinctrl_gpio_can_use_line(chip->base +
> lineinfo.line_offset))
> lineinfo.flags |= GPIOLINE_FLAG_KERNEL;
> if (test_bit(FLAG_IS_OUT, >flags))
> lineinfo.flags |= GPIOLINE_FLAG_IS_OUT;
> diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
> index b70df27874d1..2bbd8ee93507 100644
> --- a/drivers/pinctrl/core.c
> +++ b/drivers/pinctrl/core.c
> @@ -736,6 +736,34 @@ int pinctrl_get_group_selector(struct pinctrl_dev
> *pctldev,
> return -EINVAL;
> }
>
> +bool pinctrl_gpio_can_use_line(unsigned gpio)
> +{
> + struct pinctrl_dev *pctldev;
> + struct pinctrl_gpio_range *range;
> + bool result;
> + int pin;
> +
> + /*
> + * Try to obtain GPIO range, if it fails
> + * we're probably dealing with GPIO driver
> + * without a backing pin controller - bail out.
> + */
> + if (pinctrl_get_device_gpio_range(gpio, , ))
> + return true;
> +
> + mutex_lock(>mutex);
> +
> + /* Convert to the pin controllers number space */
> + pin = gpio_to_pin(range, gpio);
> +
> + result = pinmux_can_be_used_for_gpio(pctldev, pin);
> +
> + mutex_unlock(>mutex);
> +
> + return result;
> +}
> +EXPORT_SYMBOL_GPL(pinctrl_gpio_can_use_line);
> +
> /**
> * pinctrl_gpio_request() - request a single pin to be used as GPIO
> * @gpio: the GPIO pin number from the GPIO subsystem number space
> diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
> index 020e54f843f9..7e42a5738d82 100644
> --- a/drivers/pinctrl/pinmux.c
> +++ b/drivers/pinctrl/pinmux.c
> @@ -70,6 +70,33 @@ int pinmux_validate_map(const struct pinctrl_map *map, int
> i)
> return 0;
> }
>
> +/**
> + * pinmux_can_be_used_for_gpio() - check if a specific pin
> + * is either muxed to a different function or used as gpio.
> + *
> + * @pin: the pin number in the global pin space
> + *
> + * Controllers not defined as strict will always return true,
> + * menaning that the gpio can be used.
> + */
> +bool pinmux_can_be_used_for_gpio(struct pinctrl_dev *pctldev, unsigned pin)
> +{
> + struct pin_desc *desc = pin_desc_get(pctldev, pin);
> + const struct pinmux_ops *ops = pctldev->desc->pmxops;
> +
> + if (!desc) {
> + dev_dbg(pctldev->dev,
> + "pin %u is not registered so it cannot be requested\n",
> + pin);
> + return true;
This return value looks strange to me.
Stefan
Re: [PATCH v6 5/8] KVM: VMX: Load Guest CET via VMCS when CET is enabled in Guest
On Mon, Aug 12, 2019 at 04:56:32PM -0700, Sean Christopherson wrote:
> On Thu, Jul 25, 2019 at 11:12:43AM +0800, Yang Weijiang wrote:
> > "Load Guest CET state" bit controls whether Guest CET states
> > will be loaded at Guest entry. Before doing that, KVM needs
> > to check if CPU CET feature is enabled on host and available
> > to Guest.
> >
> > Note: SHSTK and IBT features share one control MSR:
> > MSR_IA32_{U,S}_CET, which means it's difficult to hide
> > one feature from another in the case of SHSTK != IBT,
> > after discussed in community, it's agreed to allow Guest
> > control two features independently as it won't introduce
> > security hole.
> >
> > Co-developed-by: Zhang Yi Z
> > Signed-off-by: Zhang Yi Z
> > Signed-off-by: Yang Weijiang
> > ---
> > arch/x86/kvm/vmx/vmx.c | 13 +
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> > index ce5d1e45b7a5..fbf9c335cf7b 100644
> > --- a/arch/x86/kvm/vmx/vmx.c
> > +++ b/arch/x86/kvm/vmx/vmx.c
> > @@ -44,6 +44,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "capabilities.h"
> > #include "cpuid.h"
> > @@ -2923,6 +2924,18 @@ int vmx_set_cr4(struct kvm_vcpu *vcpu, unsigned long
> > cr4)
> > if (!nested_vmx_allowed(vcpu) || is_smm(vcpu))
> > return 1;
> > }
> > + if (cpu_x86_cet_enabled() &&
>
> It'd probably be better to check a KVM function here, e.g. a wrapper of
> kvm_supported_xss(). I don't think it will ever matter, but it'd be nice
> to have a single kill switch given the variety of different enable bits
> for CET.
>
OK, will try to make it nicer in next version.
> > + (guest_cpuid_has(vcpu, X86_FEATURE_SHSTK) ||
> > + guest_cpuid_has(vcpu, X86_FEATURE_IBT))) {
> > + if (cr4 & X86_CR4_CET)
> > + vmcs_set_bits(VM_ENTRY_CONTROLS,
> > + VM_ENTRY_LOAD_GUEST_CET_STATE);
> > + else
> > + vmcs_clear_bits(VM_ENTRY_CONTROLS,
> > + VM_ENTRY_LOAD_GUEST_CET_STATE);
> > + } else if (cr4 & X86_CR4_CET) {
> > + return 1;
> > + }
> >
> > if (to_vmx(vcpu)->nested.vmxon && !nested_cr4_valid(vcpu, cr4))
> > return 1;
> > --
> > 2.17.2
> >
Re: [PATCH RFC v1 1/2] rcu/tree: Add basic support for kfree_rcu batching
On Mon, Aug 12, 2019 at 09:12:34AM -0400, Joel Fernandes wrote: > On Mon, Aug 12, 2019 at 07:10:52PM +0900, Byungchul Park wrote: > > On Sun, Aug 11, 2019 at 04:49:39PM -0700, Paul E. McKenney wrote: > > > Maybe. Note well that I said "potential issue". When I checked a few > > > years ago, none of the uses of rcu_barrier() cared about kfree_rcu(). > > > They cared instead about call_rcu() callbacks that accessed code or data > > > that was going to disappear soon, for example, due to module unload or > > > filesystem unmount. > > > > > > So it -might- be that rcu_barrier() can stay as it is, but with changes > > > as needed to documentation. > > Right, we should update the docs. Byungchul, do you mind sending a patch that > documents the rcu_barrier() behavior? Are you trying to give me the chance? I feel thankful. It doens't matter to try it at the moment though, I can't follow-up until September. I'd better do that in Septamber or give it up this time. Thanks, Byungchul > > > It also -might- be, maybe now or maybe some time in the future, that > > > there will need to be a kfree_rcu_barrier() or some such. But if so, > > > let's not create it until it is needed. For one thing, it is reasonably > > > likely that something other than a kfree_rcu_barrier() would really > > > be what was needed. After all, the main point would be to make sure > > > that the old memory really was freed before allocating new memory. > > > > Now I fully understand what you meant thanks to you. Thank you for > > explaining it in detail. > > > > > But if the system had ample memory, why wait? In that case you don't > > > really need to wait for all the old memory to be freed, but rather for > > > sufficient memory to be available for allocation. > > > > Agree. Totally make sense. > > Agreed, all makes sense. > > thanks, > > - Joel > > [snip]
Re: [PATCH 4/7] pwm: jz4740: Improve algorithm of clock calculation
Hello Paul, [adding Stephen Boyd to Cc] On Tue, Aug 13, 2019 at 12:16:23AM +0200, Paul Cercueil wrote: > Le lun. 12 août 2019 à 23:48, Uwe Kleine-König a écrit : > > On Mon, Aug 12, 2019 at 10:43:10PM +0200, Paul Cercueil wrote: > > > Le lun. 12 août 2019 à 8:15, Uwe Kleine-König a écrit : > > > > On Fri, Aug 09, 2019 at 07:14:45PM +0200, Paul Cercueil wrote: > > > > > Le ven. 9 août 2019 à 19:05, Uwe Kleine-König a écrit : > > > > > > On Fri, Aug 09, 2019 at 02:30:28PM +0200, Paul Cercueil wrote: > > > > > > > [...] > > > > > > > +/* Reset the clock to the maximum rate, and we'll > > > > > > > reduce it if needed */ > > > > > > > +ret = clk_set_max_rate(clk, parent_rate); > > > > > > > > > > > > What is the purpose of this call? IIUC this limits the allowed > > > > > > range of > > > > > > rates for clk. I assume the idea is to prevent other consumers to > > > > > > change > > > > > > the rate in a way that makes it unsuitable for this pwm. But this > > > > > > only > > > > > > makes sense if you had a notifier for clk changes, doesn't it? I'm > > > > > > confused. > > > > > > > > > > Nothing like that. The second call to clk_set_max_rate() might have > > > > > set > > > > > a maximum clock rate that's lower than the parent's rate, and we want > > > > > to > > > > > undo that. > > > > > > > > I still don't get the purpose of this call. Why do you limit the clock > > > > rate at all? > > > > > > As it says below, we "limit the clock to a maximum rate that still gives > > > us a period value which fits in 16 bits". So that the computed hardware > > > values won't overflow. > > > > But why not just using clk_set_rate? You want to have the clock running > > at a certain rate, not any rate below that certain rate, don't you? > > I'll let yourself answer yourself: > https://patchwork.ozlabs.org/patch/1018969/ In that thread I claimed that you used clk_round_rate wrongly, not that you should use clk_set_max_rate(). (The claim was somewhat weakend by Stephen, but still I think that clk_round_rate is the right approach.) The upside of clk_round_rate is that it allows you to test for the capabilities of the clock without actually changing it before you found a setting you consider to be good. > It's enough to run it below a certain rate, yes. The actual rate doesn't > actually matter that much. 1 Hz would be fine? I doubt it. > > > E.g. if at a rate of 12 MHz your computed hardware value for the period > > > is 0xf000, then at a rate of 24 MHz it won't fit in 16 bits. So the clock > > > rate must be reduced to the highest possible that will still give you a > > > < 16-bit value. > > > > > > We always want the highest possible clock rate that works, for the sake > > > of > > > precision. > > > > This is dubious; but ok to keep the driver simple. (Consider a PWM that > > can run at i MHz for i in [1, .. 30]. If a period of 120 ns and a duty > > cycle of 40 ns is requested you can get an exact match with 25 MHz, but > > not with 30 MHz.) > > The clock rate is actually (parent_rate >> (2 * x) ) > for x = 0, 1, 2, ... > > So if your parent_rate is 30 MHz the next valid one is 7.5 MHz, and the > next one is 1.875 MHz. It'd be very unlikely that you get a better match at > a lower clock. If the smaller freqs are all dividers of the fastest that's fine. Please note in a code comment that you're assuming this. > > > > > Basically, we start from the maximum clock rate we can get for that > > > PWM > > > > > - which is the rate of the parent clk - and from that compute the > > > maximum > > > > > clock rate that we can support that still gives us < 16-bits > > > hardware > > > > > values for the period and duty. > > > > > > > > > > We then pass that computed maximum clock rate to > > > clk_set_max_rate(), which > > > > > may or may not update the current PWM clock's rate to match the new > > > limits. > > > > > Finally we read back the PWM clock's rate and compute the period > > > and duty > > > > > from that. > > > > > > > > If you change the clk rate, is this externally visible on the PWM > > > > output? Does this affect other PWM instances? > > > > > > The clock rate doesn't change the PWM output because the hardware values > > > for > > > the period and duty are adapted accordingly to reflect the change. > > > > It doesn't change it in the end. But in the (short) time frame between > > the call to change the clock and the update of the PWM registers there > > is a glitch, right? > > The PWM is disabled, so the line is in inactive state, and will be in that > state > until the PWM is enabled again. No glitch to fear. ok, please note in the commit log that the reordering doesn't affect the output because the PWM is off and are done to make it more obvious what happens. > > You didn't answer to the question about other PWM instances. Does that > > mean others are not affected? > > Sorry. Yes, they are not affected - all PWM channels are
Re: [PATCH] mm/mmap.c: rb_parent is not necessary in __vma_link_list
On Mon, Aug 12, 2019 at 08:39:58PM -0700, Matthew Wilcox wrote:
>On Tue, Aug 13, 2019 at 11:26:56AM +0800, Wei Yang wrote:
>> Now we use rb_parent to get next, while this is not necessary.
>>
>> When prev is NULL, this means vma should be the first element in the
>> list. Then next should be current first one (mm->mmap), no matter
>> whether we have parent or not.
>>
>> After removing it, the code shows the beauty of symmetry.
>
>Uhh ... did you test this?
>
I reboot successfully with this patch.
>> @@ -273,12 +273,8 @@ void __vma_link_list(struct mm_struct *mm, struct
>> vm_area_struct *vma,
>> next = prev->vm_next;
>> prev->vm_next = vma;
>> } else {
>> +next = mm->mmap;
>> mm->mmap = vma;
>> -if (rb_parent)
>> -next = rb_entry(rb_parent,
>> -struct vm_area_struct, vm_rb);
>> -else
>> -next = NULL;
>> }
>
>The full context is:
>
>if (prev) {
>next = prev->vm_next;
>prev->vm_next = vma;
>} else {
>mm->mmap = vma;
>if (rb_parent)
>next = rb_entry(rb_parent,
>struct vm_area_struct, vm_rb);
>else
>next = NULL;
>}
>
>Let's imagine we have a small tree with three ranges in it.
>
>A: 5-7
>B: 8-10
>C: 11-13
>
>I would imagine an rbtree for this case has B at the top with A
>to its left and B to its right.
>
>Now we're going to add range D at 3-4. 'next' should clearly be range A.
>It will have NULL prev. Your code is going to make 'B' next, not A.
>Right?
mm->mmap is not the rb_root.
mm->mmap is the first element in the ordered list, if my understanding is
correct.
--
Wei Yang
Help you, Help me
Re: [PATCH v6 3/8] KVM: x86: Implement CET CPUID enumeration for Guest
On Mon, Aug 12, 2019 at 05:06:04PM -0700, Sean Christopherson wrote:
> On Thu, Jul 25, 2019 at 11:12:41AM +0800, Yang Weijiang wrote:
> > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> > index 652b3876ea5c..ce1d6fe21780 100644
> > --- a/arch/x86/kvm/vmx/vmx.c
> > +++ b/arch/x86/kvm/vmx/vmx.c
> > @@ -1637,6 +1637,11 @@ static inline bool
> > vmx_feature_control_msr_valid(struct kvm_vcpu *vcpu,
> > return !(val & ~valid_bits);
> > }
> >
> > +static inline u64 vmx_supported_xss(void)
> > +{
> > + return host_xss;
>
> Do you know if the kernel will ever enable CET_USER but not CET_KERNEL,
> and vice versa? I tried hunting down the logic in the main CET enabling
> series but couldn't find the relevant code.
>
> If the kernel does enable USER vs. KERNEL independently, are we sure that
> KVM can correctly virtualize that state and that the guest OS won't die
> due to expecting all CET features or no CET features?
>
> In other words, do we want to return host_xss as is, or do we want to
> make CET_USER and CET_KERNEL a bundle deal and avoid the headache, e.g.:
>
> if (!(host_xss & XFEATURE_MASK_CET_USER) ||
> !(host_xss & XFEATURE_MASK_CET_KERNEL))
> return host_xss & ~(XFEATURE_MASK_CET_USER |
> XFEATURE_MASK_CET_KERNEL);
> return host_xss;
>
Hi, Sean,
Thanks for review! CET_USER and CET_KERNEL are two independent parts of
CET, but CET_KERNEL part has not been fully implemented yet, the final target
is to enable CET_USER + CET_KERNEL in kernel. In the VMM patch, it's supposed
to enable both CET_USER and CET_KERNEL mode at one time, so the patches expose
all the features of CET to guest OS as long as platform and host kernel
support so.
> > +}
> > +
> > static int vmx_get_msr_feature(struct kvm_msr_entry *msr)
> > {
> > switch (msr->index) {
> > @@ -7724,6 +7729,7 @@ static struct kvm_x86_ops vmx_x86_ops __ro_after_init
> > = {
> > .get_vmcs12_pages = NULL,
> > .nested_enable_evmcs = NULL,
> > .need_emulation_on_page_fault = vmx_need_emulation_on_page_fault,
> > + .supported_xss = vmx_supported_xss,
> > };
> >
> > static void vmx_cleanup_l1d_flush(void)
> > diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h
> > index a470ff0868c5..6a1870044752 100644
> > --- a/arch/x86/kvm/x86.h
> > +++ b/arch/x86/kvm/x86.h
> > @@ -288,6 +288,10 @@ int x86_emulate_instruction(struct kvm_vcpu *vcpu,
> > unsigned long cr2,
> > | XFEATURE_MASK_YMM | XFEATURE_MASK_BNDREGS \
> > | XFEATURE_MASK_BNDCSR | XFEATURE_MASK_AVX512 \
> > | XFEATURE_MASK_PKRU)
> > +
> > +#define KVM_SUPPORTED_XSS (XFEATURE_MASK_CET_USER \
> > + | XFEATURE_MASK_CET_KERNEL)
> > +
> > extern u64 host_xcr0;
> >
> > extern u64 kvm_supported_xcr0(void);
> > --
> > 2.17.2
> >
Re: linux-next: build failure after merge of the rcu tree
Hi Paul,
On Mon, 12 Aug 2019 09:19:34 -0700 "Paul E. McKenney"
wrote:
>
> Huh. "It has been building fine for me." I added
>
> #include
> #include
>
> to include/linux/rcu_segcblist.h, which hopefully fixes it at your end.
That did not work as I got a lot of errors from
include/asm-generic/atomic-long.h. I have added the following patch
for today (which does build). These errors come from having
CONFIG_{,KERNEL_,UAPI_}HEADER_TEST set (which allmodconfig a should do).
From: Stephen Rothwell
Date: Tue, 13 Aug 2019 15:12:00 +1000
Subject: [PATCH] rcu: use the correct includes
Signed-off-by: Stephen Rothwell
---
include/linux/rcu_segcblist.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/rcu_segcblist.h b/include/linux/rcu_segcblist.h
index 43e2935e8966..646759042333 100644
--- a/include/linux/rcu_segcblist.h
+++ b/include/linux/rcu_segcblist.h
@@ -14,8 +14,8 @@
#ifndef __INCLUDE_LINUX_RCU_SEGCBLIST_H
#define __INCLUDE_LINUX_RCU_SEGCBLIST_H
-#include
-#include
+#include
+#include
/* Simple unsegmented callback lists. */
struct rcu_cblist {
--
2.20.1
--
Cheers,
Stephen Rothwell
pgpTTguUASQMl.pgp
Description: OpenPGP digital signature
[PATCH] tools build: Fix clang detection with clang >= 8.0
The 8.0 release of clang/llvm moved the VirtualFileSystem.h header to from clang to llvm. This change causes a compile error, causing perf to not detect clang/llvm. Fix by including the right header for the different versions of llvm, using the older header for llvm < 8, and the new header for llvm >= 8. Signed-off-by: Matthew Dawson --- tools/build/feature/test-clang.cpp | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/tools/build/feature/test-clang.cpp b/tools/build/feature/test-clang.cpp index a2b3f092d2f0..313ef1568880 100644 --- a/tools/build/feature/test-clang.cpp +++ b/tools/build/feature/test-clang.cpp @@ -1,10 +1,14 @@ // SPDX-License-Identifier: GPL-2.0 -#include "clang/Basic/VirtualFileSystem.h" #include "clang/Driver/Driver.h" #include "clang/Frontend/TextDiagnosticPrinter.h" #include "llvm/ADT/IntrusiveRefCntPtr.h" #include "llvm/Support/ManagedStatic.h" #include "llvm/Support/raw_ostream.h" +#if LLVM_VERSION_MAJOR >= 8 +#include "llvm/Support/VirtualFileSystem.h" +#else +#include "clang/Basic/VirtualFileSystem.h" +#endif using namespace clang; using namespace clang::driver; -- 2.21.0
Re: [PATCH 5/5] memremap: provide a not device managed memremap_pages
On Mon, Aug 12, 2019 at 05:00:12PM +0200, Christoph Hellwig wrote: > On Mon, Aug 12, 2019 at 08:20:58PM +0530, Bharata B Rao wrote: > > On Sun, Aug 11, 2019 at 10:12:47AM +0200, Christoph Hellwig wrote: > > > The kvmppc ultravisor code wants a device private memory pool that is > > > system wide and not attached to a device. Instead of faking up one > > > provide a low-level memremap_pages for it. Note that this function is > > > not exported, and doesn't have a cleanup routine associated with it to > > > discourage use from more driver like users. > > > > The kvmppc secure pages management code will be part of kvm-hv which > > can be built as module too. So it would require memremap_pages() to be > > exported. > > > > Additionally, non-dev version of the cleanup routine > > devm_memremap_pages_release() or equivalent would also be requried. > > With device being present, put_device() used to take care of this > > cleanup. > > Oh well. We can add them fairly easily if we really need to, but I > tried to avoid that. Can you try to see if this works non-modular > for you for now until we hear more feedback from Dan? Yes, this patchset works non-modular and with kvm-hv as module, it works with devm_memremap_pages_release() and release_mem_region() in the cleanup path. The cleanup path will be required in the non-modular case too for proper recovery from failures. Regards, Bharata.
Re: [PATCH v12 03/18] kunit: test: add string_stream a std::stream like string builder
Quoting Brendan Higgins (2019-08-12 17:41:05) > On Mon, Aug 12, 2019 at 4:59 PM Stephen Boyd wrote: > > > > > kunit_resource_destroy (respective equivalents to devm_kfree, and > > > devres_destroy) and use kunit_kfree here? > > > > > > > Yes, or drop the API entirely? Does anything need this functionality? > > Drop the kunit_resource API? I would strongly prefer not to. No. I mean this API, string_stream_clear(). Does anything use it?
[PATCH v2 2/4] drm/komeda: Introduce komeda_color_manager/state
Many komeda component support color management like layer and IPS, so
komeda_color_manager/state are introduced to manager gamma, csc and degamma
together for easily share it to multiple componpent.
And for komeda_color_manager which:
- convert drm 3d gamma lut to komeda specific gamma coeffs
- gamma table management and hide the HW difference for komeda-CORE
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../arm/display/komeda/komeda_color_mgmt.c| 126 ++
.../arm/display/komeda/komeda_color_mgmt.h| 32 -
2 files changed, 156 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
index 9d14a92dbb17..bf2388d641b9 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
@@ -4,7 +4,9 @@
* Author: James.Qian.Wang
*
*/
+#include
+#include "malidp_utils.h"
#include "komeda_color_mgmt.h"
/* 10bit precision YUV2RGB matrix */
@@ -65,3 +67,127 @@ const s32 *komeda_select_yuv2rgb_coeffs(u32 color_encoding,
u32 color_range)
return coeffs;
}
+
+struct gamma_curve_sector {
+ u32 boundary_start;
+ u32 num_of_segments;
+ u32 segment_width;
+};
+
+struct gamma_curve_segment {
+ u32 start;
+ u32 end;
+};
+
+static struct gamma_curve_sector sector_tbl[] = {
+ { 0,4, 4 },
+ { 16, 4, 4 },
+ { 32, 4, 8 },
+ { 64, 4, 16 },
+ { 128, 4, 32 },
+ { 256, 4, 64 },
+ { 512, 16, 32 },
+ { 1024, 24, 128 },
+};
+
+static struct gamma_curve_sector igamma_sector_tbl[] = {
+ {0, 64, 64},
+};
+
+static void
+drm_lut_to_coeffs(struct drm_property_blob *lut_blob, u32 *coeffs,
+ struct gamma_curve_sector *sector_tbl, u32 num_sectors)
+{
+ struct drm_color_lut *lut;
+ u32 i, j, in, num = 0;
+
+ if (!lut_blob)
+ return;
+
+ lut = lut_blob->data;
+
+ for (i = 0; i < num_sectors; i++) {
+ for (j = 0; j < sector_tbl[i].num_of_segments; j++) {
+ in = sector_tbl[i].boundary_start +
+j * sector_tbl[i].segment_width;
+
+ coeffs[num++] = drm_color_lut_extract(lut[in].red,
+ KOMEDA_COLOR_PRECISION);
+ }
+ }
+
+ coeffs[num] = BIT(KOMEDA_COLOR_PRECISION);
+}
+
+void drm_lut_to_igamma_coeffs(struct drm_property_blob *lut_blob, u32 *coeffs)
+{
+ drm_lut_to_coeffs(lut_blob, coeffs,
+ igamma_sector_tbl, ARRAY_SIZE(igamma_sector_tbl));
+}
+
+void drm_lut_to_fgamma_coeffs(struct drm_property_blob *lut_blob, u32 *coeffs)
+{
+ drm_lut_to_coeffs(lut_blob, coeffs,
+ sector_tbl, ARRAY_SIZE(sector_tbl));
+}
+
+void drm_ctm_to_coeffs(struct drm_property_blob *ctm_blob, u32 *coeffs)
+{
+ struct drm_color_ctm *ctm;
+ u32 i;
+
+ if (!ctm_blob)
+ return;
+
+ ctm = ctm_blob->data;
+
+ for (i = 0; i < KOMEDA_N_CTM_COEFFS; ++i) {
+ /* Convert from S31.32 to Q3.12. */
+ s64 v = ctm->matrix[i];
+
+ coeffs[i] = clamp_val(v, 1 - (1LL << 34), (1LL << 34) - 1) >>
20;
+ }
+}
+
+void komeda_color_duplicate_state(struct komeda_color_state *new,
+ struct komeda_color_state *old)
+{
+ new->igamma = komeda_coeffs_get(old->igamma);
+ new->fgamma = komeda_coeffs_get(old->fgamma);
+}
+
+void komeda_color_cleanup_state(struct komeda_color_state *color_st)
+{
+ komeda_coeffs_put(color_st->igamma);
+ komeda_coeffs_put(color_st->fgamma);
+}
+
+int komeda_color_validate(struct komeda_color_manager *mgr,
+ struct komeda_color_state *st,
+ struct drm_property_blob *igamma_blob,
+ struct drm_property_blob *fgamma_blob)
+{
+ u32 coeffs[KOMEDA_N_GAMMA_COEFFS];
+
+ komeda_color_cleanup_state(st);
+
+ if (igamma_blob) {
+ drm_lut_to_igamma_coeffs(igamma_blob, coeffs);
+ st->igamma = komeda_coeffs_request(mgr->igamma_mgr, coeffs);
+ if (!st->igamma) {
+ DRM_DEBUG_ATOMIC("request igamma table failed.\n");
+ return -EBUSY;
+ }
+ }
+
+ if (fgamma_blob) {
+ drm_lut_to_fgamma_coeffs(fgamma_blob, coeffs);
+ st->fgamma = komeda_coeffs_request(mgr->fgamma_mgr, coeffs);
+ if (!st->fgamma) {
+ DRM_DEBUG_ATOMIC("request fgamma table failed.\n");
+ return -EBUSY;
+ }
+ }
+
+ return 0;
+}
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h
b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h
index
Re: [PATCH] libnvdimm: change disk name of virtio pmem disk
Ping.
>
> This patch adds prefix 'v' in disk name for virtio pmem.
> This differentiates virtio-pmem disks from the pmem disks.
>
> Signed-off-by: Pankaj Gupta
> ---
> drivers/nvdimm/namespace_devs.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/nvdimm/namespace_devs.c
> b/drivers/nvdimm/namespace_devs.c
> index a16e52251a30..8e5d29266fb0 100644
> --- a/drivers/nvdimm/namespace_devs.c
> +++ b/drivers/nvdimm/namespace_devs.c
> @@ -182,8 +182,12 @@ const char *nvdimm_namespace_disk_name(struct
> nd_namespace_common *ndns,
> char *name)
> {
> struct nd_region *nd_region = to_nd_region(ndns->dev.parent);
> + const char *prefix = "";
> const char *suffix = NULL;
>
> + if (!is_nvdimm_sync(nd_region))
> + prefix = "v";
> +
> if (ndns->claim && is_nd_btt(ndns->claim))
> suffix = "s";
>
> @@ -201,7 +205,7 @@ const char *nvdimm_namespace_disk_name(struct
> nd_namespace_common *ndns,
> sprintf(name, "pmem%d.%d%s", nd_region->id, nsidx,
> suffix ? suffix : "");
> else
> - sprintf(name, "pmem%d%s", nd_region->id,
> + sprintf(name, "%spmem%d%s", prefix, nd_region->id,
> suffix ? suffix : "");
> } else if (is_namespace_blk(>dev)) {
> struct nd_namespace_blk *nsblk;
> --
> 2.20.1
>
>
[PATCH] x86/cpu: Add Atom Tremont (Elkhart Lake)
Add the Atom Tremont model number to the Intel family list. Signed-off-by: Kyung Min Park --- arch/x86/include/asm/intel-family.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h index 0278aa6..02d675d 100644 --- a/arch/x86/include/asm/intel-family.h +++ b/arch/x86/include/asm/intel-family.h @@ -79,6 +79,7 @@ #define INTEL_FAM6_ATOM_GOLDMONT_PLUS 0x7A /* Gemini Lake */ #define INTEL_FAM6_ATOM_TREMONT_X 0x86 /* Jacobsville */ +#define INTEL_FAM6_ATOM_TREMONT0x96 /* Elkhart Lake */ /* Xeon Phi */ -- 2.7.4
Re: [PATCH v9 1/7] powerpc/mce: Schedule work from irq_work
On 8/12/19 2:52 PM, Santosh Sivaraj wrote:
> schedule_work() cannot be called from MCE exception context as MCE can
> interrupt even in interrupt disabled context.
>
> fixes: 733e4a4c ("powerpc/mce: hookup memory_failure for UE errors")
> Suggested-by: Mahesh Salgaonkar
> Signed-off-by: Santosh Sivaraj
> Cc: sta...@vger.kernel.org # v4.15+
> ---
> arch/powerpc/kernel/mce.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
Reviewed-by: Mahesh Salgaonkar
Thanks,
-Mahesh.
>
> diff --git a/arch/powerpc/kernel/mce.c b/arch/powerpc/kernel/mce.c
> index b18df633eae9..cff31d4a501f 100644
> --- a/arch/powerpc/kernel/mce.c
> +++ b/arch/powerpc/kernel/mce.c
> @@ -33,6 +33,7 @@ static DEFINE_PER_CPU(struct
> machine_check_event[MAX_MC_EVT],
> mce_ue_event_queue);
>
> static void machine_check_process_queued_event(struct irq_work *work);
> +static void machine_check_ue_irq_work(struct irq_work *work);
> void machine_check_ue_event(struct machine_check_event *evt);
> static void machine_process_ue_event(struct work_struct *work);
>
> @@ -40,6 +41,10 @@ static struct irq_work mce_event_process_work = {
> .func = machine_check_process_queued_event,
> };
>
> +static struct irq_work mce_ue_event_irq_work = {
> + .func = machine_check_ue_irq_work,
> +};
> +
> DECLARE_WORK(mce_ue_event_work, machine_process_ue_event);
>
> static void mce_set_error_info(struct machine_check_event *mce,
> @@ -199,6 +204,10 @@ void release_mce_event(void)
> get_mce_event(NULL, true);
> }
>
> +static void machine_check_ue_irq_work(struct irq_work *work)
> +{
> + schedule_work(_ue_event_work);
> +}
>
> /*
> * Queue up the MCE event which then can be handled later.
> @@ -216,7 +225,7 @@ void machine_check_ue_event(struct machine_check_event
> *evt)
> memcpy(this_cpu_ptr(_ue_event_queue[index]), evt, sizeof(*evt));
>
> /* Queue work to process this event later. */
> - schedule_work(_ue_event_work);
> + irq_work_queue(_ue_event_irq_work);
> }
>
> /*
>
Re: [PATCH linux-next] drivers: dma: Fix sparse warning for mux_configure32
On 12-08-19, 15:42, Mao Wenan wrote:
Patch title is incorrect, it should mention the changes in patch, for
example make mux_configure32 static
Do read up on Documentation/process/submitting-patches.rst again!
> There is one sparse warning in drivers/dma/fsl-edma-common.c,
It will help to explain the warning before the fix
> fix it by setting mux_configure32() as static.
>
> make allmodconfig ARCH=mips CROSS_COMPILE=mips-linux-gnu-
> make C=2 drivers/dma/fsl-edma-common.o ARCH=mips CROSS_COMPILE=mips-linux-gnu-
Make cmds are not relevant for the log
> drivers/dma/fsl-edma-common.c:93:6: warning: symbol 'mux_configure32' was not
> declared. Should it be static?
This one is and should be retained
>
> Fixes: 232a7f18cf8ec ("dmaengine: fsl-edma: add i.mx7ulp edma2 version
> support")
> Signed-off-by: Mao Wenan
> ---
> drivers/dma/fsl-edma-common.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma/fsl-edma-common.c b/drivers/dma/fsl-edma-common.c
> index 6d6d8a4..7dbf7df 100644
> --- a/drivers/dma/fsl-edma-common.c
> +++ b/drivers/dma/fsl-edma-common.c
> @@ -90,8 +90,8 @@ static void mux_configure8(struct fsl_edma_chan *fsl_chan,
> void __iomem *addr,
> iowrite8(val8, addr + off);
> }
>
> -void mux_configure32(struct fsl_edma_chan *fsl_chan, void __iomem *addr,
> - u32 off, u32 slot, bool enable)
> +static void mux_configure32(struct fsl_edma_chan *fsl_chan, void __iomem
> *addr,
just change this to static
> + u32 off, u32 slot, bool enable)
and dont change anything else.
If you feel to change this, propose a new patch for this line explaining
why this should be changed
> {
> u32 val;
>
> --
> 2.7.4
--
~Vinod
Re: [PATCH] dmaengine: fsldma: Mark expected switch fall-through
On 11-08-19, 19:22, Gustavo A. R. Silva wrote: > Mark switch cases where we are expecting to fall through. > > Fix the following warning (Building: powerpc-ppa8548_defconfig powerpc): > > drivers/dma/fsldma.c: In function ‘fsl_dma_chan_probe’: > drivers/dma/fsldma.c:1165:26: warning: this statement may fall through > [-Wimplicit-fallthrough=] >chan->toggle_ext_pause = fsl_chan_toggle_ext_pause; >~~~^~~ > drivers/dma/fsldma.c:1166:2: note: here > case FSL_DMA_IP_83XX: > ^~~~ Applied, thanks -- ~Vinod
Re: [PATCHv4 1/2] PCI: layerscape: Add the bar_fixed_64bit property in EP driver.
On 13/08/19 8:23 AM, Xiaowei Bao wrote: > The PCIe controller of layerscape just have 4 BARs, BAR0 and BAR1 > is 32bit, BAR3 and BAR4 is 64bit, this is determined by hardware, Do you mean BAR2 instead of BAR3 here? Thanks Kishon > so set the bar_fixed_64bit with 0x14. > > Signed-off-by: Xiaowei Bao > --- > v2: > - Replace value 0x14 with a macro. > v3: > - No change. > v4: > - send the patch again with '--to'. > > drivers/pci/controller/dwc/pci-layerscape-ep.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c > b/drivers/pci/controller/dwc/pci-layerscape-ep.c > index be61d96..227c33b 100644 > --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c > +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c > @@ -44,6 +44,7 @@ static int ls_pcie_establish_link(struct dw_pcie *pci) > .linkup_notifier = false, > .msi_capable = true, > .msix_capable = false, > + .bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4), > }; > > static const struct pci_epc_features* >
Re: [PATCH] [v2] dma: ti: unexport filter functions
On 12-08-19, 12:11, Arnd Bergmann wrote: > The two filter functions are now marked static, but still exported, > which triggers a coming build-time check: > > WARNING: "omap_dma_filter_fn" [vmlinux] is a static EXPORT_SYMBOL_GPL > WARNING: "edma_filter_fn" [vmlinux] is a static EXPORT_SYMBOL > > Remove the unneeded exports as well, as originally intended. Change title to: "dmaengine: ti: unexport filter functions" and applied, thanks -- ~Vinod
Re: [PATCH 1/4] dt-bingings: PCI: Remove the num-lanes from Required properties
Hi, On 13/08/19 8:37 AM, Z.q. Hou wrote: > Hi Andrew, > > Thanks a lot for your comments! > >> -Original Message- >> From: Andrew Murray >> Sent: 2019年8月12日 16:45 >> To: Z.q. Hou >> Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; >> linux-kernel@vger.kernel.org; gustavo.pimen...@synopsys.com; >> jingooh...@gmail.com; bhelg...@google.com; robh...@kernel.org; >> mark.rutl...@arm.com; shawn...@kernel.org; Leo Li >> ; lorenzo.pieral...@arm.com; M.h. Lian >> ; Kishon Vijay Abraham I ; >> Gabriele Paoloni >> Subject: Re: [PATCH 1/4] dt-bingings: PCI: Remove the num-lanes from >> Required properties >> >> On Mon, Aug 12, 2019 at 04:22:16AM +, Z.q. Hou wrote: >>> From: Hou Zhiqiang >>> >>> The num-lanes is not a mandatory property, e.g. on FSL Layerscape >>> SoCs, the PCIe link training is completed automatically base on the >>> selected SerDes protocol, it doesn't need the num-lanes to set-up the >>> link width. >>> >>> It has been added in the Optional properties. This patch is to remove >>> it from the Required properties. >> >> For clarity, maybe this paragraph can be reworded to: >> >> "It is previously in both Required and Optional properties, let's remove it >> from the Required properties". > > Agree and will change in v2. > >> >> I don't understand why this property is previously in both required and >> optional... >> >> It looks like num-lanes was first made optional back in >> 2015 and removed from the Required section (907fce090253). >> But then re-added back into the Required section in 2017 with the adition of >> bindings for EP mode (b12befecd7de). >> >> Is num-lanes actually required for EP mode? > > Kishon, please help to answer this query? It should be optional for EP too. Thanks Kishon
Re: [PATCH v2 1/2] serial: 8250_pci: Add support for Sunix serial boards
Hi Andy,
at 21:18, Andy Shevchenko wrote:
On Fri, Aug 9, 2019 at 10:05 PM Kai-Heng Feng
wrote:
Add support to Sunix serial boards with up to 16 ports.
Sunix board need its own setup callback instead of using Timedia's, to
properly support more than 4 ports.
Can you, please, split out the Sunix quirk driver to a separate module
(see examples like: 8250_exar, 8250_lpss, 8250_mid)?
And then with a fewer LOCs add a new boards.
Greg asked Sunix to use existing 8250_pci.c instead of its own module.
It only needs a special setup function, other parts are just 8250_pci.
Why does split them a better idea? I even think of squashing 8250_moxa into
8250_pci.
Kai-Heng
Cc: Morris Ku
Cc: Debbie Liu
Signed-off-by: Kai-Heng Feng
---
v2:
use div64_s64() instead of do_div()
drivers/tty/serial/8250/8250_pci.c | 93 +++--
drivers/tty/serial/8250/8250_port.c | 8 +++
include/uapi/linux/serial_core.h| 3 +
3 files changed, 87 insertions(+), 17 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_pci.c
b/drivers/tty/serial/8250/8250_pci.c
index 7f740b37700b..b2a5c2228858 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -1692,6 +1692,30 @@ pci_wch_ch38x_setup(struct serial_private *priv,
return pci_default_setup(priv, board, port, idx);
}
+static int
+pci_sunix_setup(struct serial_private *priv,
+ const struct pciserial_board *board,
+ struct uart_8250_port *port, int idx)
+{
+ int bar;
+ int offset;
+
+ port->port.flags |= UPF_FIXED_TYPE;
+ port->port.type = PORT_SUNIX;
+
+ if (idx < 4) {
+ bar = 0;
+ offset = idx * board->uart_offset;
+ } else {
+ bar = 1;
+ idx -= 4;
+ idx = div_s64_rem(idx, 4, );
+ offset = idx * 64 + offset * board->uart_offset;
+ }
+
+ return setup_port(priv, port, bar, offset, 0);
+}
+
#define PCI_VENDOR_ID_SBSMODULARIO 0x124B
#define PCI_SUBVENDOR_ID_SBSMODULARIO 0x124B
#define PCI_DEVICE_ID_OCTPRO 0x0001
@@ -2289,21 +2313,14 @@ static struct pci_serial_quirk
pci_serial_quirks[] __refdata = {
.setup = pci_timedia_setup,
},
/*
-* SUNIX (Timedia) cards
-* Do not "probe" for these cards as there is at least one
combination
-* card that should be handled by parport_pc that doesn't match
the
-* rule in pci_timedia_probe.
-* It is part number is MIO5079A but its subdevice ID is 0x0102.
-* There are some boards with part number SER5037AL that report
-* subdevice ID 0x0002.
+* Sunix PCI serial boards
*/
{
.vendor = PCI_VENDOR_ID_SUNIX,
.device = PCI_DEVICE_ID_SUNIX_1999,
.subvendor = PCI_VENDOR_ID_SUNIX,
.subdevice = PCI_ANY_ID,
- .init = pci_timedia_init,
- .setup = pci_timedia_setup,
+ .setup = pci_sunix_setup,
},
/*
* Xircom cards
@@ -2757,6 +2774,11 @@ enum pci_board_num_t {
pbn_pericom_PI7C9X7952,
pbn_pericom_PI7C9X7954,
pbn_pericom_PI7C9X7958,
+ pbn_sunix_pci_1s,
+ pbn_sunix_pci_2s,
+ pbn_sunix_pci_4s,
+ pbn_sunix_pci_8s,
+ pbn_sunix_pci_16s,
};
/*
@@ -3494,6 +3516,31 @@ static struct pciserial_board pci_boards[] = {
.base_baud = 921600,
.uart_offset= 0x8,
},
+ [pbn_sunix_pci_1s] = {
+ .num_ports = 1,
+ .base_baud = 921600,
+ .uart_offset= 0x8,
+ },
+ [pbn_sunix_pci_2s] = {
+ .num_ports = 2,
+ .base_baud = 921600,
+ .uart_offset= 0x8,
+ },
+ [pbn_sunix_pci_4s] = {
+ .num_ports = 4,
+ .base_baud = 921600,
+ .uart_offset= 0x8,
+ },
+ [pbn_sunix_pci_8s] = {
+ .num_ports = 8,
+ .base_baud = 921600,
+ .uart_offset= 0x8,
+ },
+ [pbn_sunix_pci_16s] = {
+ .num_ports = 16,
+ .base_baud = 921600,
+ .uart_offset= 0x8,
+ },
};
static const struct pci_device_id blacklist[] = {
@@ -4532,17 +4579,29 @@ static const struct pci_device_id
serial_pci_tbl[] = {
pbn_b0_bt_1_921600 },
/*
-* SUNIX (TIMEDIA)
+* Sunix PCI serial boards
*/
{ PCI_VENDOR_ID_SUNIX, PCI_DEVICE_ID_SUNIX_1999,
- PCI_VENDOR_ID_SUNIX, PCI_ANY_ID,
- PCI_CLASS_COMMUNICATION_SERIAL << 8, 0x00,
- pbn_b0_bt_1_921600 },
-
+ PCI_VENDOR_ID_SUNIX, 0x0001, 0, 0,
+ pbn_sunix_pci_1s },
Re: [PATCH] bus: ti-sysc: Remove if-block in sysc_check_children()
On 08/08/19 7:25 PM, Roger Quadros wrote:
Nishka,
On 08/08/2019 10:40, Nishka Dasgupta wrote:
In function sysc_check_children, there is an if-statement checking
whether the value returned by function sysc_check_one_child is non-zero.
However, sysc_check_one_child always returns 0, and hence this check is
not needed. Hence remove this if-block.
Signed-off-by: Nishka Dasgupta
---
drivers/bus/ti-sysc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
index e6deabd8305d..bc8082ae7cb5 100644
--- a/drivers/bus/ti-sysc.c
+++ b/drivers/bus/ti-sysc.c
@@ -637,8 +637,6 @@ static int sysc_check_children(struct sysc *ddata)
for_each_child_of_node(ddata->dev->of_node, child) {
error = sysc_check_one_child(ddata, child);
- if (error)
- return error;
We cannot assume that sysc_check_one_child() will never return error in the
future.
If it can never return an error then why does it have an int return type?
I'm not sure why it has an int return type, unfortunately. This is the
function in its entirety:
static int sysc_check_one_child(struct sysc *ddata,
struct device_node *np)
{
const char *name;
name = of_get_property(np, "ti,hwmods", NULL);
if (name)
dev_warn(ddata->dev, "really a child ti,hwmods property?");
sysc_check_quirk_stdout(ddata, np);
sysc_parse_dts_quirks(ddata, np, true);
return 0;
}
I'm not sure how to understand this function. Do dev_warn() or
sysc_check_quirk_stdout() or sysc_parse_dts_quirks() cause a non-zero
return from sysc_check_one_child()? Should I drop my patch?
Thanking you,
Nishka
}
return 0;
cheers,
-roger
Re: [PATCH 3/7] dma: iop-adma: use correct printk format strings
On 09-08-19, 18:33, Arnd Bergmann wrote:
> When compile-testing on other architectures, we get lots of warnings
> about incorrect format strings, like:
>
>drivers/dma/iop-adma.c: In function 'iop_adma_alloc_slots':
>drivers/dma/iop-adma.c:307:6: warning: format '%x' expects argument of
> type 'unsigned int', but argument 6 has type 'dma_addr_t {aka long long
> unsigned int}' [-Wformat=]
>
>drivers/dma/iop-adma.c: In function 'iop_adma_prep_dma_memcpy':
> >> drivers/dma/iop-adma.c:518:40: warning: format '%u' expects argument of
> >> type 'unsigned int', but argument 5 has type 'size_t {aka long unsigned
> >> int}' [-Wformat=]
>
> Use %zu for printing size_t as required, and cast the dma_addr_t
> arguments to 'u64' for printing with %llx. Ideally this should use
> the %pad format string, but that requires an lvalue argument that
> doesn't work here.
Please change title to "dmaengine: iop-adma: use correct printk format strings"
After that:
Acked-by: Vinod Koul
>
> Signed-off-by: Arnd Bergmann
> ---
> drivers/dma/iop-adma.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/dma/iop-adma.c b/drivers/dma/iop-adma.c
> index 7857b54770d1..aebdd671651a 100644
> --- a/drivers/dma/iop-adma.c
> +++ b/drivers/dma/iop-adma.c
> @@ -117,9 +117,9 @@ static void __iop_adma_slot_cleanup(struct iop_adma_chan
> *iop_chan)
> list_for_each_entry_safe(iter, _iter, _chan->chain,
> chain_node) {
> pr_debug("\tcookie: %d slot: %d busy: %d "
> - "this_desc: %#x next_desc: %#x ack: %d\n",
> + "this_desc: %#x next_desc: %#llx ack: %d\n",
> iter->async_tx.cookie, iter->idx, busy,
> - iter->async_tx.phys, iop_desc_get_next_desc(iter),
> + iter->async_tx.phys, (u64)iop_desc_get_next_desc(iter),
> async_tx_test_ack(>async_tx));
> prefetch(_iter);
> prefetch(&_iter->async_tx);
> @@ -307,9 +307,9 @@ iop_adma_alloc_slots(struct iop_adma_chan *iop_chan, int
> num_slots,
> int i;
> dev_dbg(iop_chan->device->common.dev,
> "allocated slot: %d "
> - "(desc %p phys: %#x) slots_per_op %d\n",
> + "(desc %p phys: %#llx) slots_per_op
> %d\n",
> iter->idx, iter->hw_desc,
> - iter->async_tx.phys, slots_per_op);
> + (u64)iter->async_tx.phys, slots_per_op);
>
> /* pre-ack all but the last descriptor */
> if (num_slots != slots_per_op)
> @@ -517,7 +517,7 @@ iop_adma_prep_dma_memcpy(struct dma_chan *chan,
> dma_addr_t dma_dest,
> return NULL;
> BUG_ON(len > IOP_ADMA_MAX_BYTE_COUNT);
>
> - dev_dbg(iop_chan->device->common.dev, "%s len: %u\n",
> + dev_dbg(iop_chan->device->common.dev, "%s len: %zu\n",
> __func__, len);
>
> spin_lock_bh(_chan->lock);
> @@ -550,7 +550,7 @@ iop_adma_prep_dma_xor(struct dma_chan *chan, dma_addr_t
> dma_dest,
> BUG_ON(len > IOP_ADMA_XOR_MAX_BYTE_COUNT);
>
> dev_dbg(iop_chan->device->common.dev,
> - "%s src_cnt: %d len: %u flags: %lx\n",
> + "%s src_cnt: %d len: %zu flags: %lx\n",
> __func__, src_cnt, len, flags);
>
> spin_lock_bh(_chan->lock);
> @@ -583,7 +583,7 @@ iop_adma_prep_dma_xor_val(struct dma_chan *chan,
> dma_addr_t *dma_src,
> if (unlikely(!len))
> return NULL;
>
> - dev_dbg(iop_chan->device->common.dev, "%s src_cnt: %d len: %u\n",
> + dev_dbg(iop_chan->device->common.dev, "%s src_cnt: %d len: %zu\n",
> __func__, src_cnt, len);
>
> spin_lock_bh(_chan->lock);
> @@ -621,7 +621,7 @@ iop_adma_prep_dma_pq(struct dma_chan *chan, dma_addr_t
> *dst, dma_addr_t *src,
> BUG_ON(len > IOP_ADMA_XOR_MAX_BYTE_COUNT);
>
> dev_dbg(iop_chan->device->common.dev,
> - "%s src_cnt: %d len: %u flags: %lx\n",
> + "%s src_cnt: %d len: %zu flags: %lx\n",
> __func__, src_cnt, len, flags);
>
> if (dmaf_p_disabled_continue(flags))
> @@ -684,7 +684,7 @@ iop_adma_prep_dma_pq_val(struct dma_chan *chan,
> dma_addr_t *pq, dma_addr_t *src,
> return NULL;
> BUG_ON(len > IOP_ADMA_XOR_MAX_BYTE_COUNT);
>
> - dev_dbg(iop_chan->device->common.dev, "%s src_cnt: %d len: %u\n",
> + dev_dbg(iop_chan->device->common.dev, "%s src_cnt: %d len: %zu\n",
> __func__, src_cnt, len);
>
> spin_lock_bh(_chan->lock);
> --
> 2.20.0
--
~Vinod
Re: [PATCH 2/7] dma: iop-adma: include prefetch.h
On 09-08-19, 18:33, Arnd Bergmann wrote: > Compile-testing this driver fails on m68k without the > extra header inclusion. Please change title to "dmaengine: iop-adma: include prefetch.h" After that: Acked-by: Vinod Koul > Reported-by: kbuild test robot > Signed-off-by: Arnd Bergmann > --- > drivers/dma/iop-adma.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/dma/iop-adma.c b/drivers/dma/iop-adma.c > index c6c0143670d9..7857b54770d1 100644 > --- a/drivers/dma/iop-adma.c > +++ b/drivers/dma/iop-adma.c > @@ -16,6 +16,7 @@ > #include > #include > #include > +#include > #include > #include > #include > -- > 2.20.0 -- ~Vinod
Re: [PATCH v2] regulator: core: Add of_node_put() before return
On 08/08/19 5:57 PM, Mark Brown wrote: On Thu, Aug 08, 2019 at 12:35:53PM +0530, Nishka Dasgupta wrote: In function of_get_child_regulator(), the loop for_each_child_of_node() contains two mid-loop return statements. Ordinarily the loop gets the node child at the beginning of every iteration and automatically puts Please do not submit new versions of already applied patches, please submit incremental updates to the existing code. Modifying existing commits creates problems for other users building on top of those commits so it's best practice to only change pubished git commits if absolutely essential. I am very sorry about this; I wasn't sure whether this particular commit had been applied. Should I split the commit and resend only the change to the old commit, or should I leave it as it is? Thanking you, Nishka
Re: [PATCH] nbd: add a missed nbd_config_put() in nbd_xmit_timeout()
Thanks for your review.
在 2019/8/12 23:34, Mike Christie 写道:
On 08/12/2019 07:31 AM, Sun Ke wrote:
When try to get the lock failed, before return, execute the
nbd_config_put() to decrease the nbd->config_refs.
If the nbd->config_refs is added but not decreased. Then will not
execute nbd_clear_sock() in nbd_config_put(). bd->task_setup will
not be cleared away. Finally, print"Device being setup by another
task" in nbd_add_sock() and nbd device can not be reused.
Fixes: 8f3ea35929a0 ("nbd: handle unexpected replies better")
Signed-off-by: Sun Ke
---
drivers/block/nbd.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index e21d2de..a69a90a 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -357,8 +357,10 @@ static enum blk_eh_timer_return nbd_xmit_timeout(struct
request *req,
}
config = nbd->config;
- if (!mutex_trylock(>lock))
+ if (!mutex_trylock(>lock)) {
+ nbd_config_put(nbd);
return BLK_EH_RESET_TIMER;
+ }
if (config->num_connections > 1) {
dev_err_ratelimited(nbd_to_dev(nbd),
I just sent the same patch
https://www.spinics.net/lists/linux-block/msg43718.html
here
https://www.spinics.net/lists/linux-block/msg43715.html
so it looks good to me.
Reviewed-by: Mike Christie
.
[PATCH] staging: rtl8723bs: Remove debugging information exposed via procfs
The procfs provides many useful information for debugging, but it may be
too much for normal usage, routines like proc_get_sec_info() reports
various security related information.
So let's remove it.
Signed-off-by: Kai-Heng Feng
---
drivers/staging/rtl8723bs/Makefile|1 -
drivers/staging/rtl8723bs/core/rtw_cmd.c |5 -
drivers/staging/rtl8723bs/core/rtw_debug.c| 1307 -
drivers/staging/rtl8723bs/include/autoconf.h |4 -
drivers/staging/rtl8723bs/include/drv_types.h |2 -
.../staging/rtl8723bs/include/osdep_intf.h|2 -
drivers/staging/rtl8723bs/include/rtw_debug.h | 77 -
drivers/staging/rtl8723bs/os_dep/os_intfs.c |8 -
drivers/staging/rtl8723bs/os_dep/rtw_proc.c | 779 --
drivers/staging/rtl8723bs/os_dep/rtw_proc.h | 37 -
drivers/staging/rtl8723bs/os_dep/sdio_intf.c |3 -
11 files changed, 2225 deletions(-)
delete mode 100644 drivers/staging/rtl8723bs/os_dep/rtw_proc.c
delete mode 100644 drivers/staging/rtl8723bs/os_dep/rtw_proc.h
diff --git a/drivers/staging/rtl8723bs/Makefile
b/drivers/staging/rtl8723bs/Makefile
index a12cf8dd8ed9..dfe410283ca0 100644
--- a/drivers/staging/rtl8723bs/Makefile
+++ b/drivers/staging/rtl8723bs/Makefile
@@ -60,7 +60,6 @@ r8723bs-y = \
os_dep/osdep_service.o \
os_dep/os_intfs.o \
os_dep/recv_linux.o \
- os_dep/rtw_proc.o \
os_dep/sdio_intf.o \
os_dep/sdio_ops_linux.o \
os_dep/wifi_regd.o \
diff --git a/drivers/staging/rtl8723bs/core/rtw_cmd.c
b/drivers/staging/rtl8723bs/core/rtw_cmd.c
index c6565b0e502c..8d93c2f26890 100644
--- a/drivers/staging/rtl8723bs/core/rtw_cmd.c
+++ b/drivers/staging/rtl8723bs/core/rtw_cmd.c
@@ -1817,11 +1817,6 @@ static void rtw_btinfo_hdl(struct adapter *adapter, u8
*buf, u16 buf_len)
len = info->len;
}
-/* define DBG_PROC_SET_BTINFO_EVT */
-#ifdef DBG_PROC_SET_BTINFO_EVT
- btinfo_evt_dump(RTW_DBGDUMP, info);
-#endif
-
/* transform BT-FW btinfo to WiFI-FW C2H format and notify */
if (cmd_idx == BTINFO_WIFI_FETCH)
buf[1] = 0;
diff --git a/drivers/staging/rtl8723bs/core/rtw_debug.c
b/drivers/staging/rtl8723bs/core/rtw_debug.c
index 695a85999270..c48a8b80af4c 100644
--- a/drivers/staging/rtl8723bs/core/rtw_debug.c
+++ b/drivers/staging/rtl8723bs/core/rtw_debug.c
@@ -132,1310 +132,3 @@ void rf_reg_dump(void *sel, struct adapter *adapter)
}
}
}
-
-#ifdef PROC_DEBUG
-ssize_t proc_set_write_reg(struct file *file, const char __user *buffer,
size_t count, loff_t *pos, void *data)
-{
- struct net_device *dev = data;
- struct adapter *padapter = (struct adapter *)rtw_netdev_priv(dev);
- char tmp[32];
- u32 addr, val, len;
-
- if (count < 3) {
- DBG_871X("argument size is less than 3\n");
- return -EFAULT;
- }
-
- if (buffer && !copy_from_user(tmp, buffer, sizeof(tmp))) {
-
- int num = sscanf(tmp, "%x %x %x", , , );
-
- if (num != 3) {
- DBG_871X("invalid write_reg parameter!\n");
- return count;
- }
-
- switch (len) {
- case 1:
- rtw_write8(padapter, addr, (u8)val);
- break;
- case 2:
- rtw_write16(padapter, addr, (u16)val);
- break;
- case 4:
- rtw_write32(padapter, addr, val);
- break;
- default:
- DBG_871X("error write length =%d", len);
- break;
- }
-
- }
-
- return count;
-
-}
-
-static u32 proc_get_read_addr = 0x;
-static u32 proc_get_read_len = 0x4;
-
-int proc_get_read_reg(struct seq_file *m, void *v)
-{
- struct net_device *dev = m->private;
- struct adapter *padapter = (struct adapter *)rtw_netdev_priv(dev);
-
- if (proc_get_read_addr == 0x) {
- DBG_871X_SEL_NL(m, "address not initialized\n");
- return 0;
- }
-
- switch (proc_get_read_len) {
- case 1:
- DBG_871X_SEL_NL(m, "rtw_read8(0x%x) = 0x%x\n",
proc_get_read_addr, rtw_read8(padapter, proc_get_read_addr));
- break;
- case 2:
- DBG_871X_SEL_NL(m, "rtw_read16(0x%x) = 0x%x\n",
proc_get_read_addr, rtw_read16(padapter, proc_get_read_addr));
- break;
- case 4:
- DBG_871X_SEL_NL(m, "rtw_read32(0x%x) = 0x%x\n",
proc_get_read_addr, rtw_read32(padapter, proc_get_read_addr));
- break;
- default:
- DBG_871X_SEL_NL(m, "error read length =%d\n",
proc_get_read_len);
- break;
- }
-
- return 0;
-}
-
-ssize_t proc_set_read_reg(struct file *file, const char __user *buffer,
Re: [PATCH v5 4/7] PCI/ATS: Add PRI support for PCIe VF devices
On Thu, Aug 01, 2019 at 05:06:01PM -0700,
sathyanarayanan.kuppusw...@linux.intel.com wrote:
> From: Kuppuswamy Sathyanarayanan
>
> When IOMMU tries to enable Page Request Interface (PRI) for VF device
> in iommu_enable_dev_iotlb(), it always fails because PRI support for
> PCIe VF device is currently broken. Current implementation expects
> the given PCIe device (PF & VF) to implement PRI capability before
> enabling the PRI support. But this assumption is incorrect. As per PCIe
> spec r4.0, sec 9.3.7.11, all VFs associated with PF can only use the
> PRI of the PF and not implement it. Hence we need to create exception
> for handling the PRI support for PCIe VF device.
>
> Also, since PRI is a shared resource between PF/VF, following rules
> should apply.
>
> 1. Use proper locking before accessing/modifying PF resources in VF
>PRI enable/disable call.
> 2. Use reference count logic to track the usage of PRI resource.
> 3. Disable PRI only if the PRI reference count (pri_ref_cnt) is zero.
>
> Cc: Ashok Raj
> Cc: Keith Busch
> Suggested-by: Ashok Raj
> Signed-off-by: Kuppuswamy Sathyanarayanan
>
> ---
> drivers/pci/ats.c | 143 ++--
> include/linux/pci.h | 2 +
> 2 files changed, 112 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c
> index 1f4be27a071d..079dc544 100644
> --- a/drivers/pci/ats.c
> +++ b/drivers/pci/ats.c
> @@ -189,6 +189,8 @@ void pci_pri_init(struct pci_dev *pdev)
> if (pdev->is_virtfn)
> return;
>
> + mutex_init(>pri_lock);
> +
> pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_PRI);
> if (!pos)
> return;
> @@ -221,29 +223,57 @@ int pci_enable_pri(struct pci_dev *pdev, u32 reqs)
> {
> u16 control, status;
> u32 max_requests;
> + int ret = 0;
> + struct pci_dev *pf = pci_physfn(pdev);
>
> - if (WARN_ON(pdev->pri_enabled))
> - return -EBUSY;
> + mutex_lock(>pri_lock);
>
> - if (!pdev->pri_cap)
> - return -EINVAL;
> + if (WARN_ON(pdev->pri_enabled)) {
> + ret = -EBUSY;
> + goto pri_unlock;
> + }
>
> - pci_read_config_word(pdev, pdev->pri_cap + PCI_PRI_STATUS, );
> - if (!(status & PCI_PRI_STATUS_STOPPED))
> - return -EBUSY;
> + if (!pf->pri_cap) {
> + ret = -EINVAL;
> + goto pri_unlock;
> + }
> +
> + if (pdev->is_virtfn && pf->pri_enabled)
> + goto update_status;
> +
> + /*
> + * Before updating PRI registers, make sure there is no
> + * outstanding PRI requests.
> + */
> + pci_read_config_word(pf, pf->pri_cap + PCI_PRI_STATUS, );
> + if (!(status & PCI_PRI_STATUS_STOPPED)) {
> + ret = -EBUSY;
> + goto pri_unlock;
> + }
>
> - pci_read_config_dword(pdev, pdev->pri_cap + PCI_PRI_MAX_REQ,
> - _requests);
> + pci_read_config_dword(pf, pf->pri_cap + PCI_PRI_MAX_REQ, _requests);
> reqs = min(max_requests, reqs);
> - pdev->pri_reqs_alloc = reqs;
> - pci_write_config_dword(pdev, pdev->pri_cap + PCI_PRI_ALLOC_REQ, reqs);
> + pf->pri_reqs_alloc = reqs;
> + pci_write_config_dword(pf, pf->pri_cap + PCI_PRI_ALLOC_REQ, reqs);
>
> control = PCI_PRI_CTRL_ENABLE;
> - pci_write_config_word(pdev, pdev->pri_cap + PCI_PRI_CTRL, control);
> + pci_write_config_word(pf, pf->pri_cap + PCI_PRI_CTRL, control);
>
> - pdev->pri_enabled = 1;
> + /*
> + * If PRI is not already enabled in PF, increment the PF
> + * pri_ref_cnt to track the usage of PRI interface.
> + */
> + if (pdev->is_virtfn && !pf->pri_enabled) {
> + atomic_inc(>pri_ref_cnt);
> + pf->pri_enabled = 1;
> + }
>
> - return 0;
> +update_status:
> + atomic_inc(>pri_ref_cnt);
> + pdev->pri_enabled = 1;
> +pri_unlock:
> + mutex_unlock(>pri_lock);
> + return ret;
> }
> EXPORT_SYMBOL_GPL(pci_enable_pri);
>
> @@ -256,18 +286,30 @@ EXPORT_SYMBOL_GPL(pci_enable_pri);
> void pci_disable_pri(struct pci_dev *pdev)
> {
> u16 control;
> + struct pci_dev *pf = pci_physfn(pdev);
>
> - if (WARN_ON(!pdev->pri_enabled))
> - return;
> + mutex_lock(>pri_lock);
>
> - if (!pdev->pri_cap)
> - return;
> + if (WARN_ON(!pdev->pri_enabled) || !pf->pri_cap)
> + goto pri_unlock;
> +
> + atomic_dec(>pri_ref_cnt);
>
> - pci_read_config_word(pdev, pdev->pri_cap + PCI_PRI_CTRL, );
> + /*
> + * If pri_ref_cnt is not zero, then don't modify hardware
> + * registers.
> + */
> + if (atomic_read(>pri_ref_cnt))
> + goto done;
> +
> + pci_read_config_word(pf, pf->pri_cap + PCI_PRI_CTRL, );
> control &= ~PCI_PRI_CTRL_ENABLE;
> - pci_write_config_word(pdev, pdev->pri_cap + PCI_PRI_CTRL, control);
> + pci_write_config_word(pf, pf->pri_cap +
Re: [PATCH v3] perf diff: Report noisy for cycles diff
On 8/12/2019 4:35 PM, Jiri Olsa wrote:
On Sat, Aug 10, 2019 at 07:30:29AM +0800, Jin Yao wrote:
SNIP
+ if (vals[i] != 0)
+ return 0;
+ return 1;
+}
+
+static int print_cycles_spark(char *bf, int size, unsigned long *svals, u64 n)
+{
+ int len = n, printed;
+
+ if (len <= 1)
+ return 0;
+
+ if (len > NUM_SPARKS)
+ len = NUM_SPARKS;
+ if (all_zero(svals, len))
+ return 0;
+
+ printed = print_spark(bf, size, svals, len);
+ printed += scnprintf(bf + printed, size - printed, " ");
+
+ if (n > NUM_SPARKS)
+ printed += scnprintf(bf + printed, size - printed, "..");
will this '..' ever be printed? I can't see that even if I enlarge
the column width..
jirka
@@ -83,6 +85,8 @@ struct hist_entry_diff {
/* PERF_HPP_DIFF__CYCLES */
s64 cycles;
};
+ struct statsstats;
+ unsigned long svals[NUM_SPARKS];
};
Now we only save 8 items in svals[] (NUM_PARKS = 8). So '..' will not be
printed. The code of printing '..' is for future possible case.
If you think it's not necessary, I would remove this.
Thanks
Jin Yao
Re: [PATCH v5 2/7] PCI/ATS: Initialize PRI in pci_ats_init()
On Mon, Aug 12, 2019 at 02:35:32PM -0700, sathyanarayanan kuppuswamy wrote:
> On 8/12/19 1:04 PM, Bjorn Helgaas wrote:
> > On Thu, Aug 01, 2019 at 05:05:59PM -0700,
> > sathyanarayanan.kuppusw...@linux.intel.com wrote:
> > > From: Kuppuswamy Sathyanarayanan
> > >
> > >
> > > Currently, PRI Capability checks are repeated across all PRI API's.
> > > Instead, cache the capability check result in pci_pri_init() and use it
> > > in other PRI API's. Also, since PRI is a shared resource between PF/VF,
> > > initialize default values for common PRI features in pci_pri_init().
> > This patch does two things, and it would be better if they were split:
> >
> >1) Cache the PRI capability offset
> >2) Separate the PF and VF paths
> Ok. I will split it into two patches in next version.
> >
> > > Signed-off-by: Kuppuswamy Sathyanarayanan
> > >
> > > ---
> > > drivers/pci/ats.c | 80 -
> > > include/linux/pci-ats.h | 5 +++
> > > include/linux/pci.h | 1 +
> > > 3 files changed, 61 insertions(+), 25 deletions(-)
> > >
> > > diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c
> > > index cdd936d10f68..280be911f190 100644
> > > --- a/drivers/pci/ats.c
> > > +++ b/drivers/pci/ats.c
> > > @@ -28,6 +28,8 @@ void pci_ats_init(struct pci_dev *dev)
> > > return;
> > > dev->ats_cap = pos;
> > > +
> > > + pci_pri_init(dev);
> > > }
> > > /**
> > > @@ -170,36 +172,72 @@ int pci_ats_page_aligned(struct pci_dev *pdev)
> > > EXPORT_SYMBOL_GPL(pci_ats_page_aligned);
> > > #ifdef CONFIG_PCI_PRI
> > > +
> > > +void pci_pri_init(struct pci_dev *pdev)
> > > +{
> > > + u32 max_requests;
> > > + int pos;
> > > +
> > > + /*
> > > + * As per PCIe r4.0, sec 9.3.7.11, only PF is permitted to
> > > + * implement PRI and all associated VFs can only use it.
> > > + * Since PF already initialized the PRI parameters there is
> > > + * no need to proceed further.
> > > + */
> > > + if (pdev->is_virtfn)
> > > + return;
> > > +
> > > + pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_PRI);
> > > + if (!pos)
> > > + return;
> > > +
> > > + pci_read_config_dword(pdev, pos + PCI_PRI_MAX_REQ, _requests);
> > > +
> > > + /*
> > > + * Since PRI is a shared resource between PF and VF, we must not
> > > + * configure Outstanding Page Allocation Quota as a per device
> > > + * resource in pci_enable_pri(). So use maximum value possible
> > > + * as default value.
> > > + */
> > > + pci_write_config_dword(pdev, pos + PCI_PRI_ALLOC_REQ, max_requests);
> > > +
> > > + pdev->pri_reqs_alloc = max_requests;
> > > + pdev->pri_cap = pos;
> > > +}
> > > +
> > > /**
> > >* pci_enable_pri - Enable PRI capability
> > >* @ pdev: PCI device structure
> > >*
> > >* Returns 0 on success, negative value on error
> > > + *
> > > + * TODO: Since PRI is a shared resource between PF/VF, don't update
> > > + * Outstanding Page Allocation Quota in the same API as a per device
> > > + * feature.
> > >*/
> > > int pci_enable_pri(struct pci_dev *pdev, u32 reqs)
> > > {
> > > u16 control, status;
> > > u32 max_requests;
> > > - int pos;
> > > if (WARN_ON(pdev->pri_enabled))
> > > return -EBUSY;
> > > - pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_PRI);
> > > - if (!pos)
> > > + if (!pdev->pri_cap)
> > > return -EINVAL;
> > > - pci_read_config_word(pdev, pos + PCI_PRI_STATUS, );
> > > + pci_read_config_word(pdev, pdev->pri_cap + PCI_PRI_STATUS, );
> > > if (!(status & PCI_PRI_STATUS_STOPPED))
> > > return -EBUSY;
> > > - pci_read_config_dword(pdev, pos + PCI_PRI_MAX_REQ, _requests);
> > > + pci_read_config_dword(pdev, pdev->pri_cap + PCI_PRI_MAX_REQ,
> > > + _requests);
> > > reqs = min(max_requests, reqs);
> > > pdev->pri_reqs_alloc = reqs;
> > > - pci_write_config_dword(pdev, pos + PCI_PRI_ALLOC_REQ, reqs);
> > > + pci_write_config_dword(pdev, pdev->pri_cap + PCI_PRI_ALLOC_REQ, reqs);
> > The comment above says "don't update Outstanding Page Allocation
> > Quota" but it looks like that's what this is doing.
>
> I don't want to fix it in the current patch-set. It needs further scrutiny.
> That's why I have added the TODO comment for it.
You don't have to fix everything in this patch set, but the comment
should match what the code does. If you desire, it can go on to
explain why the current behavior is incorrect. But the current
comment is confusing.
I think the series would read better if the patch that changed from
trying to use the PRI capability on the VF (which always fails) to
using the one on the PF were *first*, i.e., if this change:
- pci_write_config_dword(pdev, ... + PCI_PRI_ALLOC_REQ, reqs);
+ pci_write_config_dword(pf, ... + PCI_PRI_ALLOC_REQ, reqs);
were before adding the pri_cap cache:
- pci_write_config_dword(pf, pos + PCI_PRI_ALLOC_REQ, reqs);
+
Re: [PATCH 3.16 043/157] ext4: brelse all indirect buffer inext4_ind_remove_space()
Ben Hutchings wrote:
> From: "zhangyi (F)"
>
> commit 674a2b27234d1b7afcb0a9162e81b2e53aeef217 upstream.
[snip]
> --- a/fs/ext4/indirect.c
> +++ b/fs/ext4/indirect.c
> @@ -1481,10 +1481,14 @@ end_range:
>partial->p + 1,
>partial2->p,
>(chain+n-1) - partial);
> - BUFFER_TRACE(partial->bh, "call brelse");
> - brelse(partial->bh);
> - BUFFER_TRACE(partial2->bh, "call brelse");
> - brelse(partial2->bh);
> + while (partial > chain) {
> + BUFFER_TRACE(partial->bh, "call brelse");
> + brelse(partial->bh);
> + }
> + while (partial2 > chain2) {
> + BUFFER_TRACE(partial2->bh, "call brelse");
> + brelse(partial2->bh);
> + }
> return 0;
> }
>
Above patch is really messed up. Alone that patch is livelocking
and file system corrupting. Look at those new while loops. Once the
while condition is true once, it is ALWAYS true, so it livelocks.
It absolutely needs follow-up patch from
"ext4: cleanup bh release code in ext4_ind_remove_space()"
upstream commit 5e86bdda41534e17621d5a071b294943cae4376e.
For more info about how to trigger that bug, see this earlier email
https://marc.info/?l=linux-kernel=155419973129522=2
For 3.16 kernels you may need to set CONFIG_EXT4_USE_FOR_EXT23=y
so that ext4 code handles ext3 file systems.
--
Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Re: [PATCH v5 1/7] PCI/ATS: Fix pci_prg_resp_pasid_required() dependency issues
On Mon, Aug 12, 2019 at 01:20:55PM -0700, sathyanarayanan kuppuswamy wrote:
> On 8/12/19 1:04 PM, Bjorn Helgaas wrote:
> > On Thu, Aug 01, 2019 at 05:05:58PM -0700,
> > sathyanarayanan.kuppusw...@linux.intel.com wrote:
> > > From: Kuppuswamy Sathyanarayanan
> > >
> > >
> > > Since pci_prg_resp_pasid_required() function has dependency on both
> > > PASID and PRI, define it only if both CONFIG_PCI_PRI and
> > > CONFIG_PCI_PASID config options are enabled.
> > I don't really like this. It makes the #ifdefs more complicated and I
> > don't think it really buys us anything. Will anything break if we
> > just drop this patch?
> Yes, this function uses "pri_lock" mutex which is only defined if
> CONFIG_PCI_PRI is enabled. So not protecting this function within
> CONFIG_PCI_PRI will lead to compilation issues.
Ah, OK. That helps a lot. "pri_lock" doesn't exist at this point in
the series, so the patch makes no sense without knowing that.
I'm still not convinced this is the right thing because I'm not sure
the lock is necessary. I'll respond to the patch that adds the lock.
> > > Fixes: e5567f5f6762 ("PCI/ATS: Add pci_prg_resp_pasid_required()
> > > interface.")
> > > Signed-off-by: Kuppuswamy Sathyanarayanan
> > >
> > > ---
> > > drivers/pci/ats.c | 10 ++
> > > include/linux/pci-ats.h | 12 +---
> > > 2 files changed, 15 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c
> > > index e18499243f84..cdd936d10f68 100644
> > > --- a/drivers/pci/ats.c
> > > +++ b/drivers/pci/ats.c
> > > @@ -395,6 +395,8 @@ int pci_pasid_features(struct pci_dev *pdev)
> > > }
> > > EXPORT_SYMBOL_GPL(pci_pasid_features);
> > > +#ifdef CONFIG_PCI_PRI
> > > +
> > > /**
> > >* pci_prg_resp_pasid_required - Return PRG Response PASID Required bit
> > >* status.
> > > @@ -402,10 +404,8 @@ EXPORT_SYMBOL_GPL(pci_pasid_features);
> > >*
> > >* Returns 1 if PASID is required in PRG Response Message, 0 otherwise.
> > >*
> > > - * Even though the PRG response PASID status is read from PRI Status
> > > - * Register, since this API will mainly be used by PASID users, this
> > > - * function is defined within #ifdef CONFIG_PCI_PASID instead of
> > > - * CONFIG_PCI_PRI.
> > > + * Since this API has dependency on both PRI and PASID, protect it
> > > + * with both CONFIG_PCI_PRI and CONFIG_PCI_PASID.
> > >*/
> > > int pci_prg_resp_pasid_required(struct pci_dev *pdev)
> > > {
> > > @@ -425,6 +425,8 @@ int pci_prg_resp_pasid_required(struct pci_dev *pdev)
> > > }
> > > EXPORT_SYMBOL_GPL(pci_prg_resp_pasid_required);
> > > +#endif
> > > +
> > > #define PASID_NUMBER_SHIFT 8
> > > #define PASID_NUMBER_MASK (0x1f << PASID_NUMBER_SHIFT)
> > > /**
> > > diff --git a/include/linux/pci-ats.h b/include/linux/pci-ats.h
> > > index 1ebb88e7c184..1a0bdaee2f32 100644
> > > --- a/include/linux/pci-ats.h
> > > +++ b/include/linux/pci-ats.h
> > > @@ -40,7 +40,6 @@ void pci_disable_pasid(struct pci_dev *pdev);
> > > void pci_restore_pasid_state(struct pci_dev *pdev);
> > > int pci_pasid_features(struct pci_dev *pdev);
> > > int pci_max_pasids(struct pci_dev *pdev);
> > > -int pci_prg_resp_pasid_required(struct pci_dev *pdev);
> > > #else /* CONFIG_PCI_PASID */
> > > @@ -67,11 +66,18 @@ static inline int pci_max_pasids(struct pci_dev *pdev)
> > > return -EINVAL;
> > > }
> > > +#endif /* CONFIG_PCI_PASID */
> > > +
> > > +#if defined(CONFIG_PCI_PRI) && defined(CONFIG_PCI_PASID)
> > > +
> > > +int pci_prg_resp_pasid_required(struct pci_dev *pdev);
> > > +
> > > +#else /* CONFIG_PCI_PASID && CONFIG_PCI_PRI */
> > > +
> > > static inline int pci_prg_resp_pasid_required(struct pci_dev *pdev)
> > > {
> > > return 0;
> > > }
> > > -#endif /* CONFIG_PCI_PASID */
> > > -
> > > +#endif
> > > #endif /* LINUX_PCI_ATS_H*/
> > > --
> > > 2.21.0
> > >
> --
> Sathyanarayanan Kuppuswamy
> Linux kernel developer
>
[PATCH] ASoC: ti: Fix typos in ti/Kconfig
This patch fixes some spelling typo in Kconfig. Signed-off-by: Masanari Iida --- sound/soc/ti/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/ti/Kconfig b/sound/soc/ti/Kconfig index 2197f3e1eaed..87a9b9dd4e98 100644 --- a/sound/soc/ti/Kconfig +++ b/sound/soc/ti/Kconfig @@ -12,7 +12,7 @@ config SND_SOC_TI_SDMA_PCM comment "Texas Instruments DAI support for:" config SND_SOC_DAVINCI_ASP - tristate "daVinci Audio Serial Port (ASP) or McBSP suport" + tristate "daVinci Audio Serial Port (ASP) or McBSP support" depends on ARCH_DAVINCI || COMPILE_TEST select SND_SOC_TI_EDMA_PCM help @@ -33,7 +33,7 @@ config SND_SOC_DAVINCI_MCASP - Keystone devices config SND_SOC_DAVINCI_VCIF - tristate "daVinci Voice Interface (VCIF) suport" + tristate "daVinci Voice Interface (VCIF) support" depends on ARCH_DAVINCI || COMPILE_TEST select SND_SOC_TI_EDMA_PCM help -- 2.23.0.rc2
Re: [PATCH] mm/mmap.c: rb_parent is not necessary in __vma_link_list
On Tue, Aug 13, 2019 at 11:26:56AM +0800, Wei Yang wrote:
> Now we use rb_parent to get next, while this is not necessary.
>
> When prev is NULL, this means vma should be the first element in the
> list. Then next should be current first one (mm->mmap), no matter
> whether we have parent or not.
>
> After removing it, the code shows the beauty of symmetry.
Uhh ... did you test this?
> @@ -273,12 +273,8 @@ void __vma_link_list(struct mm_struct *mm, struct
> vm_area_struct *vma,
> next = prev->vm_next;
> prev->vm_next = vma;
> } else {
> + next = mm->mmap;
> mm->mmap = vma;
> - if (rb_parent)
> - next = rb_entry(rb_parent,
> - struct vm_area_struct, vm_rb);
> - else
> - next = NULL;
> }
The full context is:
if (prev) {
next = prev->vm_next;
prev->vm_next = vma;
} else {
mm->mmap = vma;
if (rb_parent)
next = rb_entry(rb_parent,
struct vm_area_struct, vm_rb);
else
next = NULL;
}
Let's imagine we have a small tree with three ranges in it.
A: 5-7
B: 8-10
C: 11-13
I would imagine an rbtree for this case has B at the top with A
to its left and B to its right.
Now we're going to add range D at 3-4. 'next' should clearly be range A.
It will have NULL prev. Your code is going to make 'B' next, not A.
Right?
[patch] mm, page_alloc: move_freepages should not examine struct page of reserved memory
After commit 907ec5fca3dc ("mm: zero remaining unavailable struct pages"),
struct page of reserved memory is zeroed. This causes page->flags to be 0
and fixes issues related to reading /proc/kpageflags, for example, of
reserved memory.
The VM_BUG_ON() in move_freepages_block(), however, assumes that
page_zone() is meaningful even for reserved memory. That assumption is no
longer true after the aforementioned commit.
There's no reason why move_freepages_block() should be testing the
legitimacy of page_zone() for reserved memory; its scope is limited only
to pages on the zone's freelist.
Note that pfn_valid() can be true for reserved memory: there is a backing
struct page. The check for page_to_nid(page) is also buggy but reserved
memory normally only appears on node 0 so the zeroing doesn't affect this.
Move the debug checks to after verifying PageBuddy is true. This isolates
the scope of the checks to only be for buddy pages which are on the zone's
freelist which move_freepages_block() is operating on. In this case, an
incorrect node or zone is a bug worthy of being warned about (and the
examination of struct page is acceptable bcause this memory is not
reserved).
Signed-off-by: David Rientjes
---
mm/page_alloc.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2238,27 +2238,12 @@ static int move_freepages(struct zone *zone,
unsigned int order;
int pages_moved = 0;
-#ifndef CONFIG_HOLES_IN_ZONE
- /*
-* page_zone is not safe to call in this context when
-* CONFIG_HOLES_IN_ZONE is set. This bug check is probably redundant
-* anyway as we check zone boundaries in move_freepages_block().
-* Remove at a later date when no bug reports exist related to
-* grouping pages by mobility
-*/
- VM_BUG_ON(pfn_valid(page_to_pfn(start_page)) &&
- pfn_valid(page_to_pfn(end_page)) &&
- page_zone(start_page) != page_zone(end_page));
-#endif
for (page = start_page; page <= end_page;) {
if (!pfn_valid_within(page_to_pfn(page))) {
page++;
continue;
}
- /* Make sure we are not inadvertently changing nodes */
- VM_BUG_ON_PAGE(page_to_nid(page) != zone_to_nid(zone), page);
-
if (!PageBuddy(page)) {
/*
* We assume that pages that could be isolated for
@@ -2273,6 +2258,10 @@ static int move_freepages(struct zone *zone,
continue;
}
+ /* Make sure we are not inadvertently changing nodes */
+ VM_BUG_ON_PAGE(page_to_nid(page) != zone_to_nid(zone), page);
+ VM_BUG_ON_PAGE(page_zone(page) != zone, page);
+
order = page_order(page);
move_to_free_area(page, >free_area[order], migratetype);
page += 1 << order;
[PATCH] mm/mmap.c: rb_parent is not necessary in __vma_link_list
Now we use rb_parent to get next, while this is not necessary.
When prev is NULL, this means vma should be the first element in the
list. Then next should be current first one (mm->mmap), no matter
whether we have parent or not.
After removing it, the code shows the beauty of symmetry.
Signed-off-by: Wei Yang
---
mm/internal.h | 2 +-
mm/mmap.c | 2 +-
mm/nommu.c| 2 +-
mm/util.c | 8 ++--
4 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/mm/internal.h b/mm/internal.h
index e32390802fd3..41a49574acc3 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -290,7 +290,7 @@ static inline bool is_data_mapping(vm_flags_t flags)
/* mm/util.c */
void __vma_link_list(struct mm_struct *mm, struct vm_area_struct *vma,
- struct vm_area_struct *prev, struct rb_node *rb_parent);
+ struct vm_area_struct *prev);
#ifdef CONFIG_MMU
extern long populate_vma_page_range(struct vm_area_struct *vma,
diff --git a/mm/mmap.c b/mm/mmap.c
index f7ed0afb994c..b8072630766f 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -632,7 +632,7 @@ __vma_link(struct mm_struct *mm, struct vm_area_struct *vma,
struct vm_area_struct *prev, struct rb_node **rb_link,
struct rb_node *rb_parent)
{
- __vma_link_list(mm, vma, prev, rb_parent);
+ __vma_link_list(mm, vma, prev);
__vma_link_rb(mm, vma, rb_link, rb_parent);
}
diff --git a/mm/nommu.c b/mm/nommu.c
index fed1b6e9c89b..12a66fbeb988 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -637,7 +637,7 @@ static void add_vma_to_mm(struct mm_struct *mm, struct
vm_area_struct *vma)
if (rb_prev)
prev = rb_entry(rb_prev, struct vm_area_struct, vm_rb);
- __vma_link_list(mm, vma, prev, parent);
+ __vma_link_list(mm, vma, prev);
}
/*
diff --git a/mm/util.c b/mm/util.c
index e6351a80f248..80632db29247 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -264,7 +264,7 @@ void *memdup_user_nul(const void __user *src, size_t len)
EXPORT_SYMBOL(memdup_user_nul);
void __vma_link_list(struct mm_struct *mm, struct vm_area_struct *vma,
- struct vm_area_struct *prev, struct rb_node *rb_parent)
+ struct vm_area_struct *prev)
{
struct vm_area_struct *next;
@@ -273,12 +273,8 @@ void __vma_link_list(struct mm_struct *mm, struct
vm_area_struct *vma,
next = prev->vm_next;
prev->vm_next = vma;
} else {
+ next = mm->mmap;
mm->mmap = vma;
- if (rb_parent)
- next = rb_entry(rb_parent,
- struct vm_area_struct, vm_rb);
- else
- next = NULL;
}
vma->vm_next = next;
if (next)
--
2.17.1
[rcu:dev.2019.08.09a 65/67] ERROR: "tick_nohz_full_running" [kernel/rcu/rcutorture.ko] undefined!
Hi Paul, First bad commit (maybe != root cause): tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev.2019.08.09a head: 8997cc705c8156fd638c6296c800ceb4f2cd4eb0 commit: 7bcd11ce830f32631a378ff0e75836f27b202f1b [65/67] squash! idle: Prevent late-arriving interrupts from disrupting offline config: x86_64-rhel (attached as .config) compiler: gcc-7 (Debian 7.4.0-10) 7.4.0 reproduce: git checkout 7bcd11ce830f32631a378ff0e75836f27b202f1b # save the attached .config to linux build tree make ARCH=x86_64 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): >> ERROR: "tick_nohz_full_running" [kernel/rcu/rcutorture.ko] undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: linux-next: build failure after merge of the sound-asoc tree
Hi all,
On Fri, 9 Aug 2019 13:08:11 +1000 Stephen Rothwell
wrote:
>
> After merging the sound-asoc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from include/linux/kobject.h:19,
> from include/linux/device.h:16,
> from include/sound/hdaudio.h:9,
> from include/sound/hdaudio_ext.h:5,
> from sound/soc/sof/intel/hda-dsp.c:18:
> sound/soc/sof/intel/hda-dsp.c: In function 'hda_resume':
> sound/soc/sof/intel/hda-dsp.c:360:22: error: 'hlink' undeclared (first use in
> this function)
> list_for_each_entry(hlink, >hlink_list, list)
> ^
> include/linux/list.h:577:7: note: in definition of macro 'list_for_each_entry'
> for (pos = list_first_entry(head, typeof(*pos), member); \
>^~~
> sound/soc/sof/intel/hda-dsp.c:360:22: note: each undeclared identifier is
> reported only once for each function it appears in
> list_for_each_entry(hlink, >hlink_list, list)
> ^
> include/linux/list.h:577:7: note: in definition of macro 'list_for_each_entry'
> for (pos = list_first_entry(head, typeof(*pos), member); \
>^~~
> In file included from include/linux/list.h:9,
> from include/linux/kobject.h:19,
> from include/linux/device.h:16,
> from include/sound/hdaudio.h:9,
> from include/sound/hdaudio_ext.h:5,
> from sound/soc/sof/intel/hda-dsp.c:18:
> sound/soc/sof/intel/hda-dsp.c:360:30: error: 'bus' undeclared (first use in
> this function)
> list_for_each_entry(hlink, >hlink_list, list)
> ^~~
> include/linux/kernel.h:972:26: note: in definition of macro 'container_of'
> void *__mptr = (void *)(ptr); \
> ^~~
> include/linux/list.h:490:2: note: in expansion of macro 'list_entry'
> list_entry((ptr)->next, type, member)
> ^~
> include/linux/list.h:577:13: note: in expansion of macro 'list_first_entry'
> for (pos = list_first_entry(head, typeof(*pos), member); \
> ^~~~
> sound/soc/sof/intel/hda-dsp.c:360:2: note: in expansion of macro
> 'list_for_each_entry'
> list_for_each_entry(hlink, >hlink_list, list)
> ^~~
> sound/soc/sof/intel/hda-dsp.c:364:2: error: #else without #if
> #else
> ^~~~
> sound/soc/sof/intel/hda-dsp.c:390:2: error: #endif without #if
> #endif
> ^
>
> Caused by commit
>
> c2f16a94a804 ("Merge branch 'topic/hda-bus-ops-cleanup' of
> https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound into asoc-5.4")
>
> Looks like the merge resolution is not quite right.
>
> I have used the sound-asoc tree from next-20190808 for today.
I am still getting this failure ...
--
Cheers,
Stephen Rothwell
pgpMgsfOck1_4.pgp
Description: OpenPGP digital signature
RE: [PATCH 4/4] arm64: dts: fsl: Remove num-lanes property from PCIe nodes
Hi Andrew, Thanks a lot for your review! Regards, Zhiqiang > -Original Message- > From: Andrew Murray > Sent: 2019年8月12日 16:36 > To: Z.q. Hou > Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; gustavo.pimen...@synopsys.com; > jingooh...@gmail.com; bhelg...@google.com; robh...@kernel.org; > mark.rutl...@arm.com; shawn...@kernel.org; Leo Li > ; lorenzo.pieral...@arm.com; M.h. Lian > > Subject: Re: [PATCH 4/4] arm64: dts: fsl: Remove num-lanes property from > PCIe nodes > > On Mon, Aug 12, 2019 at 04:22:33AM +, Z.q. Hou wrote: > > From: Hou Zhiqiang > > > > On FSL Layerscape SoCs, the number of lanes assigned to PCIe > > controller is not fixed, it is determined by the selected SerDes > > protocol in the RCW (Reset Configuration Word), and the PCIe link > > training is completed automatically base on the selected SerDes > > protocol, and the link width set-up is updated by hardware. So the > > num-lanes is not needed to specify the link width. > > > > The current num-lanes indicates the max lanes PCIe controller can > > support up to, instead of the lanes assigned to the PCIe controller. > > This can result in PCIe link training fail after hot-reset. So remove > > the num-lanes to avoid set-up to incorrect link width. > > > > Signed-off-by: Hou Zhiqiang > > --- > > arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 1 - > > arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 3 --- > > arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 6 -- > > arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 3 --- > > arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 4 > > 5 files changed, 17 deletions(-) > > > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi > > b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi > > index ec6257a5b251..119c597ca867 100644 > > --- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi > > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi > > @@ -486,7 +486,6 @@ > > #address-cells = <3>; > > #size-cells = <2>; > > device_type = "pci"; > > - num-lanes = <4>; > > num-viewport = <2>; > > bus-range = <0x0 0xff>; > > ranges = <0x8100 0x0 0x 0x40 0x0001 0x0 > 0x0001 /* downstream I/O */ > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi > > b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi > > index 71d9ed9ff985..c084c7a4b6a6 100644 > > --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi > > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi > > @@ -677,7 +677,6 @@ > > #size-cells = <2>; > > device_type = "pci"; > > dma-coherent; > > - num-lanes = <4>; > > num-viewport = <6>; > > bus-range = <0x0 0xff>; > > ranges = <0x8100 0x0 0x 0x40 0x0001 0x0 > 0x0001 /* downstream I/O */ > > @@ -704,7 +703,6 @@ > > #size-cells = <2>; > > device_type = "pci"; > > dma-coherent; > > - num-lanes = <2>; > > num-viewport = <6>; > > bus-range = <0x0 0xff>; > > ranges = <0x8100 0x0 0x 0x48 0x0001 0x0 > 0x0001 /* downstream I/O */ > > @@ -731,7 +729,6 @@ > > #size-cells = <2>; > > device_type = "pci"; > > dma-coherent; > > - num-lanes = <2>; > > num-viewport = <6>; > > bus-range = <0x0 0xff>; > > ranges = <0x8100 0x0 0x 0x50 0x0001 0x0 > 0x0001 /* downstream I/O */ > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi > > b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi > > index b0ef08b090dd..d4c1da3d4bde 100644 > > --- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi > > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi > > @@ -649,7 +649,6 @@ > > #size-cells = <2>; > > device_type = "pci"; > > dma-coherent; > > - num-lanes = <4>; > > num-viewport = <8>; > > bus-range = <0x0 0xff>; > > ranges = <0x8100 0x0 0x 0x40 0x0001 0x0 > 0x0001 /* downstream I/O */ > > @@ -671,7 +670,6 @@ > > reg-names = "regs", "addr_space"; > > num-ib-windows = <6>; > > num-ob-windows = <8>; > > - num-lanes = <2>; > > status = "disabled"; > > }; > > > > @@ -687,7 +685,6 @@ > > #size-cells = <2>; > > device_type = "pci"; > > dma-coherent; > > - num-lanes = <2>; > >
RE: [PATCH 3/4] ARM: dts: ls1021a: Remove num-lanes property from PCIe nodes
Hi Andrew, Thanks a lot for your review! Regards, Zhiqiang > -Original Message- > From: Andrew Murray > Sent: 2019年8月12日 16:35 > To: Z.q. Hou > Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; gustavo.pimen...@synopsys.com; > jingooh...@gmail.com; bhelg...@google.com; robh...@kernel.org; > mark.rutl...@arm.com; shawn...@kernel.org; Leo Li > ; lorenzo.pieral...@arm.com; M.h. Lian > > Subject: Re: [PATCH 3/4] ARM: dts: ls1021a: Remove num-lanes property > from PCIe nodes > > On Mon, Aug 12, 2019 at 04:22:27AM +, Z.q. Hou wrote: > > From: Hou Zhiqiang > > > > On FSL Layerscape SoCs, the number of lanes assigned to PCIe > > controller is not fixed, it is determined by the selected SerDes > > protocol in the RCW (Reset Configuration Word), and the PCIe link > > training is completed automatically base on the selected SerDes > > protocol, and the link width set-up is updated by hardware. So the > > num-lanes is not needed to specify the link width. > > > > The current num-lanes indicates the max lanes PCIe controller can > > support up to, instead of the lanes assigned to the PCIe controller. > > This can result in PCIe link training fail after hot-reset. So remove > > the num-lanes to avoid set-up to incorrect link width. > > > > Signed-off-by: Hou Zhiqiang > > --- > > arch/arm/boot/dts/ls1021a.dtsi | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/arch/arm/boot/dts/ls1021a.dtsi > > b/arch/arm/boot/dts/ls1021a.dtsi index 464df4290ffc..2f6977ada447 > > 100644 > > --- a/arch/arm/boot/dts/ls1021a.dtsi > > +++ b/arch/arm/boot/dts/ls1021a.dtsi > > @@ -874,7 +874,6 @@ > > #address-cells = <3>; > > #size-cells = <2>; > > device_type = "pci"; > > - num-lanes = <4>; > > num-viewport = <6>; > > bus-range = <0x0 0xff>; > > ranges = <0x8100 0x0 0x 0x40 0x0001 0x0 > 0x0001 /* downstream I/O */ > > @@ -899,7 +898,6 @@ > > #address-cells = <3>; > > #size-cells = <2>; > > device_type = "pci"; > > - num-lanes = <4>; > > num-viewport = <6>; > > bus-range = <0x0 0xff>; > > ranges = <0x8100 0x0 0x 0x48 0x0001 0x0 > 0x0001 /* downstream I/O */ > > Reviewed-by: Andrew Murray > > > -- > > 2.17.1 > >
RE: [PATCH 2/4] PCI: dwc: Return directly when num-lanes is not found
Hi Andrew,
Thanks a lot for your review!
B.R,
Zhiqiang
> -Original Message-
> From: Andrew Murray
> Sent: 2019年8月12日 16:34
> To: Z.q. Hou
> Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org; gustavo.pimen...@synopsys.com;
> jingooh...@gmail.com; bhelg...@google.com; robh...@kernel.org;
> mark.rutl...@arm.com; shawn...@kernel.org; Leo Li
> ; lorenzo.pieral...@arm.com; M.h. Lian
>
> Subject: Re: [PATCH 2/4] PCI: dwc: Return directly when num-lanes is not
> found
>
> On Mon, Aug 12, 2019 at 04:22:22AM +, Z.q. Hou wrote:
> > From: Hou Zhiqiang
> >
> > The num-lanes is optional, so probably it isn't added on some
> > platforms. The subsequent programming is base on the num-lanes, hence
> > return when it is not found.
> >
> > Signed-off-by: Hou Zhiqiang
> > ---
> > drivers/pci/controller/dwc/pcie-designware.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> > b/drivers/pci/controller/dwc/pcie-designware.c
> > index 7d25102c304c..0a89bfd1636e 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > @@ -423,8 +423,10 @@ void dw_pcie_setup(struct dw_pcie *pci)
> >
> >
> > ret = of_property_read_u32(np, "num-lanes", );
> > - if (ret)
> > - lanes = 0;
> > + if (ret) {
> > + dev_dbg(pci->dev, "property num-lanes isn't found\n");
> > + return;
> > + }
>
> The existing code would assign a value of 0 to lanes when num-lanes isn't
> specified, however this value isn't supported by the following switch
> statement - thus we'd also print an error and return.
>
> Therefore the only and subtle effect effect of this patch is to change a
> dev_err to a dev_dbg when num-lanes isn't specified and avoid a read of
> PCIE_PORT_LINK_CONTROL.
>
> Given that num-lanes is described as optional this makes perfect sense.
> Though the commit message/hunk does give the apperance that this
> provides a more functional change.
>
> Anyway:
>
> Reviewed-by: Andrew Murray
>
>
> >
> > /* Set the number of lanes */
> > val = dw_pcie_readl_dbi(pci, PCIE_PORT_LINK_CONTROL);
> > --
> > 2.17.1
> >
[v7,1/2] rtc/fsl: add FTM alarm driver as the wakeup source
For the paltforms including LS1012A, LS1021A, LS1028A, LS1043A,
LS1046A, LS1088A, LS208xA that has the FlexTimer
module, implementing alarm functions within RTC subsystem
to wakeup the system when system going to sleep (work with RCPM driver).
Signed-off-by: Biwen Li
---
Change in v7:
- None
Change in v6:
- None
Change in v5:
- replace devm_rtc_device_register with devm_rtc_allocate_device
and rtc_register_device
Change in v4:
- clean code
- correct requesting irq
- register as a regular RTC driver
- change return value of ftm_rtc_set_alarm from -EINVAL to -ERANGE
- replace pr_err with dev_err
- sort alphabetically
- auto select RCPM driver
- correct UTC time in ftm_rtc_read_time
Change in v3:
- add some comments about clock source and errata
- adjust format
- replace endian with big_endian of struct ftm_rtc
- remove compatible "fsl,ftm-alarm"
Change in v2:
- remove code about setting rcpm
drivers/rtc/Kconfig | 15 ++
drivers/rtc/Makefile| 1 +
drivers/rtc/rtc-fsl-ftm-alarm.c | 336
3 files changed, 352 insertions(+)
create mode 100644 drivers/rtc/rtc-fsl-ftm-alarm.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 03b60d5c2330..ecc7d6a628f3 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1313,6 +1313,21 @@ config RTC_DRV_IMXDI
This driver can also be built as a module, if so, the module
will be called "rtc-imxdi".
+config RTC_DRV_FSL_FTM_ALARM
+ tristate "Freescale FlexTimer alarm timer"
+ depends on ARCH_LAYERSCAPE
+ select FSL_RCPM
+ default y
+ help
+ For the FlexTimer in LS1012A, LS1021A, LS1028A, LS1043A, LS1046A,
+ LS1088A, LS208xA, we can use FTM as the wakeup source.
+
+ Say y here to enable FTM alarm support. The FTM alarm provides
+ alarm functions for wakeup system from deep sleep.
+
+ This driver can also be built as a module, if so, the module
+ will be called "rtc-fsl-ftm-alarm".
+
config RTC_DRV_MESON
tristate "Amlogic Meson RTC"
depends on (ARM && ARCH_MESON) || COMPILE_TEST
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 9d997faa2c26..563a8b1cc076 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -72,6 +72,7 @@ obj-$(CONFIG_RTC_DRV_EFI) += rtc-efi.o
obj-$(CONFIG_RTC_DRV_EM3027) += rtc-em3027.o
obj-$(CONFIG_RTC_DRV_EP93XX) += rtc-ep93xx.o
obj-$(CONFIG_RTC_DRV_FM3130) += rtc-fm3130.o
+obj-$(CONFIG_RTC_DRV_FSL_FTM_ALARM)+= rtc-fsl-ftm-alarm.o
obj-$(CONFIG_RTC_DRV_FTRTC010) += rtc-ftrtc010.o
obj-$(CONFIG_RTC_DRV_GENERIC) += rtc-generic.o
obj-$(CONFIG_RTC_DRV_GOLDFISH) += rtc-goldfish.o
diff --git a/drivers/rtc/rtc-fsl-ftm-alarm.c b/drivers/rtc/rtc-fsl-ftm-alarm.c
new file mode 100644
index ..4f7259c2d6a3
--- /dev/null
+++ b/drivers/rtc/rtc-fsl-ftm-alarm.c
@@ -0,0 +1,336 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Freescale FlexTimer Module (FTM) alarm device driver.
+ *
+ * Copyright 2014 Freescale Semiconductor, Inc.
+ * Copyright 2019 NXP
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define FTM_SC_CLK(c) ((c) << FTM_SC_CLK_MASK_SHIFT)
+
+/*
+ * Select Fixed frequency clock (32KHz) as clock source
+ * of FlexTimer Module
+ */
+#define FTM_SC_CLKS_FIXED_FREQ 0x02
+#define FIXED_FREQ_CLK 32000
+
+/* Select 128 (2^7) as divider factor */
+#define MAX_FREQ_DIV (1 << FTM_SC_PS_MASK)
+
+/* Maximum counter value in FlexTimer's CNT registers */
+#define MAX_COUNT_VAL 0x
+
+struct ftm_rtc {
+ struct rtc_device *rtc_dev;
+ void __iomem *base;
+ bool big_endian;
+ u32 alarm_freq;
+};
+
+static inline u32 rtc_readl(struct ftm_rtc *dev, u32 reg)
+{
+ if (dev->big_endian)
+ return ioread32be(dev->base + reg);
+ else
+ return ioread32(dev->base + reg);
+}
+
+static inline void rtc_writel(struct ftm_rtc *dev, u32 reg, u32 val)
+{
+ if (dev->big_endian)
+ iowrite32be(val, dev->base + reg);
+ else
+ iowrite32(val, dev->base + reg);
+}
+
+static inline void ftm_counter_enable(struct ftm_rtc *rtc)
+{
+ u32 val;
+
+ /* select and enable counter clock source */
+ val = rtc_readl(rtc, FTM_SC);
+ val &= ~(FTM_SC_PS_MASK | FTM_SC_CLK_MASK);
+ val |= (FTM_SC_PS_MASK | FTM_SC_CLK(FTM_SC_CLKS_FIXED_FREQ));
+ rtc_writel(rtc, FTM_SC, val);
+}
+
+static inline void ftm_counter_disable(struct ftm_rtc *rtc)
+{
+ u32 val;
+
+ /* disable counter clock source */
+ val = rtc_readl(rtc, FTM_SC);
+ val &= ~(FTM_SC_PS_MASK | FTM_SC_CLK_MASK);
+ rtc_writel(rtc, FTM_SC, val);
+}
+
+static inline void ftm_irq_acknowledge(struct ftm_rtc *rtc)
+{
+
[v7,2/2] dt-bindings: rtc: add bindings for FlexTimer Module
The patch adds bindings for FlexTimer Module
Signed-off-by: Biwen Li
---
Change in v7:
- delete aliases
Change in v6:
- correct subject
- delete note
- remove reg property about IP Powerdown exception register
Change in v5:
- None
Change in v4:
- add note about dts and kernel options
- add aliases in example
Change in v3:
- remove reg-names property
- correct cells number
Change in v2:
- replace ls1043a with ls1088a as example
- add rcpm node and fsl,rcpm-wakeup property
.../bindings/rtc/rtc-fsl-ftm-alarm.txt| 35 +++
1 file changed, 35 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt
diff --git a/Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt
b/Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt
new file mode 100644
index ..4bbb97da904c
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt
@@ -0,0 +1,35 @@
+Freescale FlexTimer Module (FTM) Alarm
+
+Required properties:
+- compatible : Should be "fsl,-ftm-alarm", the
+ supported chips include
+ "fsl,ls1012a-ftm-alarm"
+ "fsl,ls1021a-ftm-alarm"
+ "fsl,ls1028a-ftm-alarm"
+ "fsl,ls1043a-ftm-alarm"
+ "fsl,ls1046a-ftm-alarm"
+ "fsl,ls1088a-ftm-alarm"
+ "fsl,ls208xa-ftm-alarm"
+- reg : Specifies base physical address and size of the register sets for the
+ FlexTimer Module.
+- interrupts : Should be the FlexTimer Module interrupt.
+- fsl,rcpm-wakeup property and rcpm node : Please refer
+ Documentation/devicetree/bindings/soc/fsl/rcpm.txt
+
+Optional properties:
+- big-endian: If the host controller is big-endian mode, specify this property.
+ The default endian mode is little-endian.
+
+Example:
+rcpm: rcpm@1e34040 {
+ compatible = "fsl,ls1088a-rcpm", "fsl,qoriq-rcpm-2.1+";
+ reg = <0x0 0x1e34040 0x0 0x18>;
+ #fsl,rcpm-wakeup-cells = <6>;
+};
+
+ftm_alarm0: timer@280 {
+ compatible = "fsl,ls1088a-ftm-alarm";
+ reg = <0x0 0x280 0x0 0x1>;
+ fsl,rcpm-wakeup = < 0x0 0x0 0x0 0x0 0x4000 0x0>;
+ interrupts = <0 44 4>;
+};
--
2.17.1
RE: [PATCH 1/4] dt-bingings: PCI: Remove the num-lanes from Required properties
Hi Andrew, Thanks a lot for your comments! > -Original Message- > From: Andrew Murray > Sent: 2019年8月12日 16:45 > To: Z.q. Hou > Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; gustavo.pimen...@synopsys.com; > jingooh...@gmail.com; bhelg...@google.com; robh...@kernel.org; > mark.rutl...@arm.com; shawn...@kernel.org; Leo Li > ; lorenzo.pieral...@arm.com; M.h. Lian > ; Kishon Vijay Abraham I ; > Gabriele Paoloni > Subject: Re: [PATCH 1/4] dt-bingings: PCI: Remove the num-lanes from > Required properties > > On Mon, Aug 12, 2019 at 04:22:16AM +, Z.q. Hou wrote: > > From: Hou Zhiqiang > > > > The num-lanes is not a mandatory property, e.g. on FSL Layerscape > > SoCs, the PCIe link training is completed automatically base on the > > selected SerDes protocol, it doesn't need the num-lanes to set-up the > > link width. > > > > It has been added in the Optional properties. This patch is to remove > > it from the Required properties. > > For clarity, maybe this paragraph can be reworded to: > > "It is previously in both Required and Optional properties, let's remove it > from the Required properties". Agree and will change in v2. > > I don't understand why this property is previously in both required and > optional... > > It looks like num-lanes was first made optional back in > 2015 and removed from the Required section (907fce090253). > But then re-added back into the Required section in 2017 with the adition of > bindings for EP mode (b12befecd7de). > > Is num-lanes actually required for EP mode? Kishon, please help to answer this query? Thanks, Zhiqiang > > Thanks, > > Andrew Murray > > > > > Signed-off-by: Hou Zhiqiang > > --- > > Documentation/devicetree/bindings/pci/designware-pcie.txt | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt > > b/Documentation/devicetree/bindings/pci/designware-pcie.txt > > index 5561a1c060d0..bd880df39a79 100644 > > --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt > > +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt > > @@ -11,7 +11,6 @@ Required properties: > > the ATU address space. > > (The old way of getting the configuration address space from > "ranges" > > is deprecated and should be avoided.) > > -- num-lanes: number of lanes to use > > RC mode: > > - #address-cells: set to <3> > > - #size-cells: set to <2> > > -- > > 2.17.1 > >
Re: [PATCH v3] trace:Add "gfp_t" support in synthetic_events
On Tue, 13 Aug 2019 09:04:28 +0800
Xing Zhengjun wrote:
> Hi Steve,
>
> Could you help to review? Thanks.
Thanks for the ping. Yes, I'll take a look at it. I'll be pulling in a
lot of patches that have queued up.
-- Steve
>
> On 7/13/2019 12:05 AM, Tom Zanussi wrote:
> > Hi Zhengjun,
> >
> > On Fri, 2019-07-12 at 09:53 +0800, Zhengjun Xing wrote:
> >> Add "gfp_t" support in synthetic_events, then the "gfp_t" type
> >> parameter in some functions can be traced.
> >>
> >> Prints the gfp flags as hex in addition to the human-readable flag
> >> string. Example output:
> >>
> >>whoopsie-630 [000] ...1 78.969452: testevent: bar=b20
> >> (GFP_ATOMIC|__GFP_ZERO)
> >> rcuc/0-11 [000] ...1 81.097555: testevent: bar=a20 (GFP_ATOMIC)
> >> rcuc/0-11 [000] ...1 81.583123: testevent: bar=a20 (GFP_ATOMIC)
> >>
> >> Signed-off-by: Tom Zanussi
> >> Signed-off-by: Zhengjun Xing
> >
> > Looks good to me, thanks!
> >
> > Tom
> >
> >> ---
> >> kernel/trace/trace_events_hist.c | 19 +++
> >> 1 file changed, 19 insertions(+)
> >>
> >> diff --git a/kernel/trace/trace_events_hist.c
> >> b/kernel/trace/trace_events_hist.c
> >> index ca6b0dff60c5..30f0f32aca62 100644
> >> --- a/kernel/trace/trace_events_hist.c
> >> +++ b/kernel/trace/trace_events_hist.c
> >> @@ -13,6 +13,10 @@
> >> #include
> >> #include
> >>
> >> +/* for gfp flag names */
> >> +#include
> >> +#include
> >> +
> >> #include "tracing_map.h"
> >> #include "trace.h"
> >> #include "trace_dynevent.h"
> >> @@ -752,6 +756,8 @@ static int synth_field_size(char *type)
> >>size = sizeof(unsigned long);
> >>else if (strcmp(type, "pid_t") == 0)
> >>size = sizeof(pid_t);
> >> + else if (strcmp(type, "gfp_t") == 0)
> >> + size = sizeof(gfp_t);
> >>else if (synth_field_is_string(type))
> >>size = synth_field_string_size(type);
> >>
> >> @@ -792,6 +798,8 @@ static const char *synth_field_fmt(char *type)
> >>fmt = "%lu";
> >>else if (strcmp(type, "pid_t") == 0)
> >>fmt = "%d";
> >> + else if (strcmp(type, "gfp_t") == 0)
> >> + fmt = "%x";
> >>else if (synth_field_is_string(type))
> >>fmt = "%s";
> >>
> >> @@ -834,9 +842,20 @@ static enum print_line_t
> >> print_synth_event(struct trace_iterator *iter,
> >> i == se->n_fields - 1 ? ""
> >> : " ");
> >>n_u64 += STR_VAR_LEN_MAX / sizeof(u64);
> >>} else {
> >> + struct trace_print_flags __flags[] = {
> >> + __def_gfpflag_names, {-1, NULL} };
> >> +
> >>trace_seq_printf(s, print_fmt, se-
> >>> fields[i]->name,
> >> entry->fields[n_u64],
> >> i == se->n_fields - 1 ? ""
> >> : " ");
> >> +
> >> + if (strcmp(se->fields[i]->type, "gfp_t") ==
> >> 0) {
> >> + trace_seq_puts(s, " (");
> >> + trace_print_flags_seq(s, "|",
> >> +entry-
> >>> fields[n_u64],
> >> +__flags);
> >> + trace_seq_putc(s, ')');
> >> + }
> >>n_u64++;
> >>}
> >>}
>
[PATCHv4 2/2] PCI: layerscape: Add CONFIG_PCI_LAYERSCAPE_EP to build EP/RC separately
Add CONFIG_PCI_LAYERSCAPE_EP to build EP/RC separately. Signed-off-by: Xiaowei Bao --- v2: - No change. v3: - modify the commit message. v4: - send the patch again with '--to'. drivers/pci/controller/dwc/Kconfig | 20 ++-- drivers/pci/controller/dwc/Makefile |3 ++- 2 files changed, 20 insertions(+), 3 deletions(-) diff --git a/drivers/pci/controller/dwc/Kconfig b/drivers/pci/controller/dwc/Kconfig index a6ce1ee..a41ccf5 100644 --- a/drivers/pci/controller/dwc/Kconfig +++ b/drivers/pci/controller/dwc/Kconfig @@ -131,13 +131,29 @@ config PCI_KEYSTONE_EP DesignWare core functions to implement the driver. config PCI_LAYERSCAPE - bool "Freescale Layerscape PCIe controller" + bool "Freescale Layerscape PCIe controller - Host mode" depends on OF && (ARM || ARCH_LAYERSCAPE || COMPILE_TEST) depends on PCI_MSI_IRQ_DOMAIN select MFD_SYSCON select PCIE_DW_HOST help - Say Y here if you want PCIe controller support on Layerscape SoCs. + Say Y here if you want to enable PCIe controller support on Layerscape + SoCs to work in Host mode. + This controller can work either as EP or RC. The RCW[HOST_AGT_PEX] + determines which PCIe controller works in EP mode and which PCIe + controller works in RC mode. + +config PCI_LAYERSCAPE_EP + bool "Freescale Layerscape PCIe controller - Endpoint mode" + depends on OF && (ARM || ARCH_LAYERSCAPE || COMPILE_TEST) + depends on PCI_ENDPOINT + select PCIE_DW_EP + help + Say Y here if you want to enable PCIe controller support on Layerscape + SoCs to work in Endpoint mode. + This controller can work either as EP or RC. The RCW[HOST_AGT_PEX] + determines which PCIe controller works in EP mode and which PCIe + controller works in RC mode. config PCI_HISI depends on OF && (ARM64 || COMPILE_TEST) diff --git a/drivers/pci/controller/dwc/Makefile b/drivers/pci/controller/dwc/Makefile index b085dfd..824fde7 100644 --- a/drivers/pci/controller/dwc/Makefile +++ b/drivers/pci/controller/dwc/Makefile @@ -8,7 +8,8 @@ obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o obj-$(CONFIG_PCI_IMX6) += pci-imx6.o obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone.o -obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o pci-layerscape-ep.o +obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o +obj-$(CONFIG_PCI_LAYERSCAPE_EP) += pci-layerscape-ep.o obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o obj-$(CONFIG_PCIE_ARMADA_8K) += pcie-armada8k.o obj-$(CONFIG_PCIE_ARTPEC6) += pcie-artpec6.o -- 1.7.1
[PATCHv4 1/2] PCI: layerscape: Add the bar_fixed_64bit property in EP driver.
The PCIe controller of layerscape just have 4 BARs, BAR0 and BAR1 is 32bit, BAR3 and BAR4 is 64bit, this is determined by hardware, so set the bar_fixed_64bit with 0x14. Signed-off-by: Xiaowei Bao --- v2: - Replace value 0x14 with a macro. v3: - No change. v4: - send the patch again with '--to'. drivers/pci/controller/dwc/pci-layerscape-ep.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c b/drivers/pci/controller/dwc/pci-layerscape-ep.c index be61d96..227c33b 100644 --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c @@ -44,6 +44,7 @@ static int ls_pcie_establish_link(struct dw_pcie *pci) .linkup_notifier = false, .msi_capable = true, .msix_capable = false, + .bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4), }; static const struct pci_epc_features* -- 1.7.1
RE: [EXT] Re: [v6,2/2] dt-bindings: rtc: add bindings for FlexTimer Module
>
> On Fri, Jul 19, 2019 at 11:54:00AM +0800, Biwen Li wrote:
> > The patch adds bindings for FlexTimer Module
> >
> > Signed-off-by: Biwen Li
> > ---
> > Change in v6:
> > - correct subject
> > - delete note
> > - remove reg property about IP Powerdown exception register
> >
> > Change in v5:
> > - None
> >
> > Change in v4:
> > - add note about dts and kernel options
> > - add aliases in example
> >
> > Change in v3:
> > - remove reg-names property
> > - correct cells number
> >
> > Change in v2:
> > - replace ls1043a with ls1088a as example
> > - add rcpm node and fsl,rcpm-wakeup property
> >
> > .../bindings/rtc/rtc-fsl-ftm-alarm.txt| 41 +++
> > 1 file changed, 41 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt
> > b/Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt
> > new file mode 100644
> > index ..9291b022ffc7
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt
> > @@ -0,0 +1,41 @@
> > +Freescale FlexTimer Module (FTM) Alarm
> > +
> > +Required properties:
> > +- compatible : Should be "fsl,-ftm-alarm", the
> > +supported chips include
> > +"fsl,ls1012a-ftm-alarm"
> > +"fsl,ls1021a-ftm-alarm"
> > +"fsl,ls1028a-ftm-alarm"
> > +"fsl,ls1043a-ftm-alarm"
> > +"fsl,ls1046a-ftm-alarm"
> > +"fsl,ls1088a-ftm-alarm"
> > +"fsl,ls208xa-ftm-alarm"
> > +- reg : Specifies base physical address and size of the register sets
> > +for the
> > + FlexTimer Module.
> > +- interrupts : Should be the FlexTimer Module interrupt.
> > +- fsl,rcpm-wakeup property and rcpm node : Please refer
> > + Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > +
> > +Optional properties:
> > +- big-endian: If the host controller is big-endian mode, specify this
> > property.
> > + The default endian mode is little-endian.
> > +
> > +Example:
> > +aliases {
> > + ...
> > + rtc1 = ftm_alarm0; // Use FlexTimer Module as /dev/rtc1
> > + ...
> > +};
>
> As I said before, drop this. It's not going to work when this is converted to
> schema and the example is compiled. Feel free to convert this to schema and
> see...
Ok, got it. I will drop this in v7.
>
> > +
> > +rcpm: rcpm@1e34040 {
> > + compatible = "fsl,ls1088a-rcpm", "fsl,qoriq-rcpm-2.1+";
> > + reg = <0x0 0x1e34040 0x0 0x18>;
> > + #fsl,rcpm-wakeup-cells = <6>;
> > +};
> > +
> > +ftm_alarm0: timer@280 {
>
> If this is an RTC, then rtc@...
This is not an RTC.
>
> > + compatible = "fsl,ls1088a-ftm-alarm";
> > + reg = <0x0 0x280 0x0 0x1>;
> > + fsl,rcpm-wakeup = < 0x0 0x0 0x0 0x0 0x4000 0x0>;
> > + interrupts = <0 44 4>;
> > +};
> > --
> > 2.17.1
> >
Re: [PATCH v10 01/15] clk: tegra20/30: Add custom EMC clock implementation
13.08.2019 2:12, Michał Mirosław пишет: > On Mon, Aug 12, 2019 at 12:00:29AM +0300, Dmitry Osipenko wrote: >> A proper External Memory Controller clock rounding and parent selection >> functionality is required by the EMC drivers, it is not available using >> the generic clock implementation because only the Memory Controller driver >> is aware of what clock rates are actually available for a particular >> device. EMC drivers will have to register a Tegra-specific CLK-API >> callback which will perform rounding of a requested rate. EMC clock users >> won't be able to request EMC clock by getting -EPROBE_DEFER until EMC >> driver is probed and the callback is set up. > [...] >> diff --git a/drivers/clk/tegra/Makefile b/drivers/clk/tegra/Makefile >> index 4812e45c2214..df966ca06788 100644 >> --- a/drivers/clk/tegra/Makefile >> +++ b/drivers/clk/tegra/Makefile >> @@ -17,7 +17,9 @@ obj-y += >> clk-tegra-fixed.o >> obj-y += clk-tegra-super-gen4.o >> obj-$(CONFIG_TEGRA_CLK_EMC) += clk-emc.o >> obj-$(CONFIG_ARCH_TEGRA_2x_SOC) += clk-tegra20.o >> +obj-$(CONFIG_ARCH_TEGRA_2x_SOC) += clk-tegra20-emc.o >> obj-$(CONFIG_ARCH_TEGRA_3x_SOC) += clk-tegra30.o >> +obj-$(CONFIG_ARCH_TEGRA_3x_SOC) += clk-tegra20-emc.o >> obj-$(CONFIG_ARCH_TEGRA_114_SOC)+= clk-tegra114.o >> obj-$(CONFIG_ARCH_TEGRA_124_SOC)+= clk-tegra124.o >> obj-$(CONFIG_TEGRA_CLK_DFLL)+= clk-tegra124-dfll-fcpu.o > > Doesn't it complain when both CONFIG_ARCH_TEGRA_2x_SOC and > CONFIG_ARCH_TEGRA_3x_SOC are enabled at the same time? No, at least not with my toolchain setup. Are you getting some warning?
Re: [RFC PATCH v3 00/16] Core scheduling v3
On 2019/8/12 23:38, Vineeth Remanan Pillai wrote: >> I have two other small changes that I think are worth sending out. >> >> The first simplify logic in pick_task() and the 2nd avoid task pick all >> over again when max is preempted. I also refined the previous hack patch to >> make schedule always happen only for root cfs rq. Please see below for >> details, thanks. >> > I see a potential issue here. With the simplification in pick_task, > you might introduce a livelock where the match logic spins for ever. > But you avoid that with the patch 2, by removing the loop if a pick > preempts max. The potential problem is that, you miss a case where > the newly picked task might have a match in the sibling on which max > was selected before. By selecting idle, you ignore the potential match. Oh that's right, I missed this. > As of now, the potential match check does not really work because, > sched_core_find will always return the same task and we do not check > the whole core_tree for a next match. This is in my TODO list to have > sched_core_find to return the best next match, if match was preempted. > But its a bit complex and needs more thought. Sounds worth to do :-)
Re: [PATCH] scsi: use __u{8,16,32,64} instead of uint{8,16,32,64}_t in uapi headers
Masahiro, > When CONFIG_UAPI_HEADER_TEST=y, exported headers are compile-tested to > make sure they can be included from user-space. Applied to 5.4/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering
[PATCH v2] arm64: dts: ls1088a: fix gpio node
From: Song Hui
Update the nodes to include little-endian
property to be consistent with the hardware
and add ls1088a gpio specify compatible.
Signed-off-by: Song Hui
---
arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index 20f5ebd..d58d203 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -269,43 +269,47 @@
};
gpio0: gpio@230 {
- compatible = "fsl,qoriq-gpio";
+ compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
reg = <0x0 0x230 0x0 0x1>;
interrupts = <0 36 IRQ_TYPE_LEVEL_HIGH>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+ little-endian;
};
gpio1: gpio@231 {
- compatible = "fsl,qoriq-gpio";
+ compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
reg = <0x0 0x231 0x0 0x1>;
interrupts = <0 36 IRQ_TYPE_LEVEL_HIGH>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+ little-endian;
};
gpio2: gpio@232 {
- compatible = "fsl,qoriq-gpio";
+ compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
reg = <0x0 0x232 0x0 0x1>;
interrupts = <0 37 IRQ_TYPE_LEVEL_HIGH>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+ little-endian;
};
gpio3: gpio@233 {
- compatible = "fsl,qoriq-gpio";
+ compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
reg = <0x0 0x233 0x0 0x1>;
interrupts = <0 37 IRQ_TYPE_LEVEL_HIGH>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+ little-endian;
};
ifc: ifc@224 {
--
2.9.5
[PATCH] irqchip/irq-ingenic-tcu: Fix COMPILE_TEST building
While do COMPILE_TEST building, if GENERIC_IRQ_CHIP is
not selected, it fails:
drivers/irqchip/irq-ingenic-tcu.o: In function `ingenic_tcu_intc_cascade':
irq-ingenic-tcu.c:(.text+0x13f): undefined reference to
`irq_get_domain_generic_chip'
drivers/irqchip/irq-ingenic-tcu.o: In function `ingenic_tcu_irq_init':
irq-ingenic-tcu.c:(.init.text+0x97): undefined reference to
`irq_generic_chip_ops'
irq-ingenic-tcu.c:(.init.text+0xdd): undefined reference to
`__irq_alloc_domain_generic_chips'
irq-ingenic-tcu.c:(.init.text+0x10b): undefined reference to
`irq_get_domain_generic_chip'
select GENERIC_IRQ_CHIP to fix this.
Reported-by: Hulk Robot
Fixes: 9536eba03ec7 ("irqchip: Add irq-ingenic-tcu driver")
Signed-off-by: YueHaibing
---
drivers/irqchip/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 3c8308e..ccbb897 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -320,6 +320,7 @@ config INGENIC_TCU_IRQ
default MACH_INGENIC
depends on MIPS || COMPILE_TEST
select MFD_SYSCON
+ select GENERIC_IRQ_CHIP
help
Support for interrupts in the Timer/Counter Unit (TCU) of the Ingenic
JZ47xx SoCs.
--
2.7.4
RE: [EXT] Re: [PATCHv3 1/2] PCI: layerscape: Add the bar_fixed_64bit property in EP driver.
> -Original Message- > From: Lorenzo Pieralisi > Sent: 2019年8月12日 19:36 > To: Xiaowei Bao > Cc: kis...@ti.com; bhelg...@google.com; robh...@kernel.org; > mark.rutl...@arm.com; shawn...@kernel.org; Leo Li > ; a...@arndb.de; gre...@linuxfoundation.org; M.h. > Lian ; Mingkai Hu ; Roy > Zang ; kstew...@linuxfoundation.org; > pombreda...@nexb.com; shawn@rock-chips.com; > linux-...@vger.kernel.org; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > linuxppc-...@lists.ozlabs.org > Subject: Re: [EXT] Re: [PATCHv3 1/2] PCI: layerscape: Add the bar_fixed_64bit > property in EP driver. > > Caution: EXT Email > > On Mon, Aug 12, 2019 at 10:39:00AM +, Xiaowei Bao wrote: > > > > > > > -Original Message- > > > From: Lorenzo Pieralisi > > > Sent: 2019年8月12日 18:12 > > > To: Xiaowei Bao ; kis...@ti.com > > > Cc: bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com; > > > shawn...@kernel.org; Leo Li ; a...@arndb.de; > > > gre...@linuxfoundation.org; M.h. Lian ; > > > Mingkai Hu ; Roy Zang ; > > > kstew...@linuxfoundation.org; pombreda...@nexb.com; > > > shawn@rock-chips.com; linux-...@vger.kernel.org; > > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > > > linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org > > > Subject: [EXT] Re: [PATCHv3 1/2] PCI: layerscape: Add the > > > bar_fixed_64bit property in EP driver. > > > > > > Caution: EXT Email > > > > > > First off: > > > > > > Trim the CC list, you CC'ed maintainers (and mailing lists) for no > > > reasons whatsover. > > [Xiaowei Bao]Hi Lorenzo, I am not clear why the mail list is the CC, I use > > the > command "git send-email --to", I will try to send the patch again, do I need > to > modify the version is v4 when I send this patch again? > > Yes you do. > > Wrap lines to max 80 characters. There is no need to add [Xiaowei Bao]. OK, thanks a lot. > > 1) Read, email etiquette > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkernel > newbies.org%2FPatchCulturedata=02%7C01%7Cxiaowei.bao%40nxp.c > om%7C73a3b6160aad401b72d208d71f193ae1%7C686ea1d3bc2b4c6fa92cd > 99c5c301635%7C0%7C0%7C637012065548351226sdata=y6xa5nMkB > qkWz7SBFdc%2F0lcQvzI%2F9HjEyC5%2Bk0RxczI%3Dreserved=0 > > 2) get_maintainer.pl -f drivers/pci/controller/dwc/pci-layerscape.c > > Compare the output to the people in CC, trim it accordingly. > > 3) The NXP maintainers in the MAINTAINERS file have not given a single >comment for this patchset. Either they show up or I will remove them >from the MAINTAINERS list. > > 4) Before submitting patches, talk to someone at NXP who can help you >format them in preparation for posting, I do not have time to write >guidelines for everyone posting on linux-pci, sorry, the information >is out there if you care to read it. > > Thanks, > Lorenzo > > > > > > > Then, read this: > > > > > > https://lore.ke > > > > rnel.org%2Flinux-pci%2F20171026223701.GA25649%40bhelgaas-glaptop.roa > > > > m.corp.google.com%2Fdata=02%7C01%7Cxiaowei.bao%40nxp.com%7 > > > > C1c586178e23c423a0e8808d71f0d8f6f%7C686ea1d3bc2b4c6fa92cd99c5c30 > > > > 1635%7C0%7C0%7C637012015426788575sdata=3bx1bDFIzik8FnD0wl > > > duAUv7wtLdD1J3hQ3xNH2xmFY%3Dreserved=0 > > > > > > and make your patches compliant please. > > > > > > On Fri, Jun 28, 2019 at 09:38:25AM +0800, Xiaowei Bao wrote: > > > > The PCIe controller of layerscape just have 4 BARs, BAR0 and BAR1 > > > > is 32bit, BAR3 and BAR4 is 64bit, this is determined by hardware, > > > > so set the bar_fixed_64bit with 0x14. > > > > > > > > Signed-off-by: Xiaowei Bao > > > > --- > > > > v2: > > > > - Replace value 0x14 with a macro. > > > > v3: > > > > - No change. > > > > > > > > drivers/pci/controller/dwc/pci-layerscape-ep.c |1 + > > > > 1 files changed, 1 insertions(+), 0 deletions(-) > > > > > > > > diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c > > > > b/drivers/pci/controller/dwc/pci-layerscape-ep.c > > > > index be61d96..227c33b 100644 > > > > --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c > > > > +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c > > > > @@ -44,6 +44,7 @@ static int ls_pcie_establish_link(struct dw_pcie > *pci) > > > > .linkup_notifier = false, > > > > .msi_capable = true, > > > > .msix_capable = false, > > > > + .bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4), > > > > > > I would appreciate Kishon's ACK on this. > > > > > > Lorenzo > > > > > > > }; > > > > > > > > static const struct pci_epc_features* > > > > -- > > > > 1.7.1 > > > >
[PATCH] mm/hotplug: prevent memory leak when reuse pgdat
When offline a node in try_offline_node, pgdat is not released. So that
pgdat could be reused in hotadd_new_pgdat. While we re-allocate
pgdat->per_cpu_nodestats if this pgdat is reused.
This patch prevents the memory leak by just allocate per_cpu_nodestats
when it is a new pgdat.
NOTE: This is not tested since I didn't manage to create a case to
offline a whole node. If my analysis is not correct, please let me know.
Signed-off-by: Wei Yang
---
mm/memory_hotplug.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index c73f09913165..efaf9e6f580a 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -933,8 +933,11 @@ static pg_data_t __ref *hotadd_new_pgdat(int nid, u64
start)
if (!pgdat)
return NULL;
+ pgdat->per_cpu_nodestats =
+ alloc_percpu(struct per_cpu_nodestat);
arch_refresh_nodedata(nid, pgdat);
} else {
+ int cpu;
/*
* Reset the nr_zones, order and classzone_idx before reuse.
* Note that kswapd will init kswapd_classzone_idx properly
@@ -943,6 +946,12 @@ static pg_data_t __ref *hotadd_new_pgdat(int nid, u64
start)
pgdat->nr_zones = 0;
pgdat->kswapd_order = 0;
pgdat->kswapd_classzone_idx = 0;
+ for_each_online_cpu(cpu) {
+ struct per_cpu_nodestat *p;
+
+ p = per_cpu_ptr(pgdat->per_cpu_nodestats, cpu);
+ memset(p, 0, sizeof(*p));
+ }
}
/* we can use NODE_DATA(nid) from here */
@@ -952,7 +961,6 @@ static pg_data_t __ref *hotadd_new_pgdat(int nid, u64 start)
/* init node's zones as empty zones, we don't have any present pages.*/
free_area_init_core_hotplug(nid);
- pgdat->per_cpu_nodestats = alloc_percpu(struct per_cpu_nodestat);
/*
* The node we allocated has no zone fallback lists. For avoiding
--
2.17.1
Re: [PATCH] scsi: csiostor: Prefer pcie_capability_read_word()
Frederick,
> Commit 8c0d3a02c130 ("PCI: Add accessors for PCI Express Capability")
> added accessors for the PCI Express Capability so that drivers didn't
> need to be aware of differences between v1 and v2 of the PCI Express
> Capability.
>
> Replace pci_read_config_word() and pci_write_config_word() calls with
> pcie_capability_read_word() and pcie_capability_write_word().
Applied to 5.4/scsi-queue. Thanks!
--
Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] scsi: esas2r: Prefer pcie_capability_read_word()
Frederick,
> Commit 8c0d3a02c130 ("PCI: Add accessors for PCI Express Capability")
> added accessors for the PCI Express Capability so that drivers didn't
> need to be aware of differences between v1 and v2 of the PCI
> Express Capability.
>
> Replace pci_read_config_word() and pci_write_config_word() calls with
> pcie_capability_read_word() and pcie_capability_write_word().
Applied to 5.4/scsi-queue, thanks!
--
Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] scsi: sym53c8xx_2: remove redundant assignment to retv
Colin, > Variable retv is initialized to a value that is never read and it is > re-assigned later. The initialization is redundant and can be removed. Applied to 5.4/scsi-queue, thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] scsi: pmcraid: Fix a typo - pcmraid --> pmcraid
Christophe, > This should be 'pmcraid', not 'pcmraid' Applied to 5.4/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] scsi: fas216: Mark expected switch fall-throughs
Gustavo, > Mark switch cases where we are expecting to fall through. Applied to 5.4/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering
[RFC PATCH 2/2] mm/vmscan: Add fragmentation and page starvation prediction to kswapd
This patch adds proactive memory reclamation to kswapd using the
free page exhaustion/fragmentation prediction based upon memory
consumption trend. It uses the least squares fit algorithm introduced
earlier for this prediction. A new function node_trend_analysis()
iterates through all zones and updates trend data in the lookback
window for least square fit algorithm. At the same time it flags any
zones that have potential for exhaustion/fragmentation by setting
ZONE_POTENTIAL_FRAG flag.
prepare_kswapd_sleep() calls node_trend_analysis() to check if the
node has potential exhaustion/fragmentation. If so, kswapd will
continue reclamataion. balance_pgdat has been modified to take
potential fragmentation into account when deciding when to wake
kcompactd up. Any zones that have potential severe fragmentation get
watermark boosted to reclaim and compact free pages proactively.
Signed-off-by: Khalid Aziz
Signed-off-by: Bharath Vedartham
Tested-by: Vandana BN
---
include/linux/mmzone.h | 38 ++
mm/page_alloc.c| 27 --
mm/vmscan.c| 116 ++---
3 files changed, 148 insertions(+), 33 deletions(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 9a0e5cab7171..a523476b5ce1 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -587,6 +587,12 @@ struct zone {
boolcontiguous;
+ /*
+* Structures to use for memory consumption prediction for
+* each order
+*/
+ struct lsq_struct mem_prediction[MAX_ORDER];
+
ZONE_PADDING(_pad3_)
/* Zone statistics */
atomic_long_t vm_stat[NR_VM_ZONE_STAT_ITEMS];
@@ -611,6 +617,9 @@ enum zone_flags {
ZONE_BOOSTED_WATERMARK, /* zone recently boosted watermarks.
* Cleared when kswapd is woken.
*/
+ ZONE_POTENTIAL_FRAG,/* zone detected with a potential
+* external fragmentation event.
+*/
};
extern int mem_predict(struct frag_info *frag_vec, struct zone *zone);
@@ -1130,6 +1139,35 @@ static inline struct zoneref
*first_zones_zonelist(struct zonelist *zonelist,
#define for_each_zone_zonelist(zone, z, zlist, highidx) \
for_each_zone_zonelist_nodemask(zone, z, zlist, highidx, NULL)
+extern int watermark_boost_factor;
+
+static inline void boost_watermark(struct zone *zone)
+{
+ unsigned long max_boost;
+
+ if (!watermark_boost_factor)
+ return;
+
+ max_boost = mult_frac(zone->_watermark[WMARK_HIGH],
+ watermark_boost_factor, 1);
+
+ /*
+* high watermark may be uninitialised if fragmentation occurs
+* very early in boot so do not boost. We do not fall
+* through and boost by pageblock_nr_pages as failing
+* allocations that early means that reclaim is not going
+* to help and it may even be impossible to reclaim the
+* boosted watermark resulting in a hang.
+*/
+ if (!max_boost)
+ return;
+
+ max_boost = max(pageblock_nr_pages, max_boost);
+
+ zone->watermark_boost = min(zone->watermark_boost + pageblock_nr_pages,
+ max_boost);
+}
+
#ifdef CONFIG_SPARSEMEM
#include
#endif
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 272c6de1bf4e..1b4e6ba16f1c 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2351,33 +2351,6 @@ static bool can_steal_fallback(unsigned int order, int
start_mt)
return false;
}
-static inline void boost_watermark(struct zone *zone)
-{
- unsigned long max_boost;
-
- if (!watermark_boost_factor)
- return;
-
- max_boost = mult_frac(zone->_watermark[WMARK_HIGH],
- watermark_boost_factor, 1);
-
- /*
-* high watermark may be uninitialised if fragmentation occurs
-* very early in boot so do not boost. We do not fall
-* through and boost by pageblock_nr_pages as failing
-* allocations that early means that reclaim is not going
-* to help and it may even be impossible to reclaim the
-* boosted watermark resulting in a hang.
-*/
- if (!max_boost)
- return;
-
- max_boost = max(pageblock_nr_pages, max_boost);
-
- zone->watermark_boost = min(zone->watermark_boost + pageblock_nr_pages,
- max_boost);
-}
-
/*
* This function implements actual steal behaviour. If order is large enough,
* we can steal whole pageblock. If not, we first move freepages in this
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 44df66a98f2a..b9cf6658c83d 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -51,6 +51,7 @@
#include
#include
#include
+#include
#include
#include
@@ -3397,14 +3398,82 @@ static void
[PATCH v2] gpiolib: Take MUX usage into account
From: Stefan Wahren
The user space like gpioinfo only see the GPIO usage but not the
MUX usage (e.g. I2C or SPI usage) of a pin. As a user we want to know which
pin is free/safe to use. So take the MUX usage of strict pinmux controllers
into account to get a more realistic view for ioctl GPIO_GET_LINEINFO_IOCTL.
Signed-off-by: Stefan Wahren
Tested-by: Ramon Fried
Signed-off-by: Ramon Fried
---
v2: Address review from linus:
* ** Please notive logic was reversed **
* renamed pinctrl_gpio_is_in_use() to pinctrl_gpio_can_use_line()
* renamed pinmux_is_in_use() to pinmux_can_be_used_for_gpio()
* changed dev_err to dev_dbg (Linus suggested removing it altogether, I
find it better to keep it for debug).
drivers/gpio/gpiolib.c | 3 ++-
drivers/pinctrl/core.c | 28
drivers/pinctrl/pinmux.c | 27 +++
drivers/pinctrl/pinmux.h | 8
include/linux/pinctrl/consumer.h | 6 ++
5 files changed, 71 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index f497003f119c..52937bf8e514 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1084,7 +1084,8 @@ static long gpio_ioctl(struct file *filp, unsigned int
cmd, unsigned long arg)
test_bit(FLAG_IS_HOGGED, >flags) ||
test_bit(FLAG_USED_AS_IRQ, >flags) ||
test_bit(FLAG_EXPORT, >flags) ||
- test_bit(FLAG_SYSFS, >flags))
+ test_bit(FLAG_SYSFS, >flags) ||
+ !pinctrl_gpio_can_use_line(chip->base +
lineinfo.line_offset))
lineinfo.flags |= GPIOLINE_FLAG_KERNEL;
if (test_bit(FLAG_IS_OUT, >flags))
lineinfo.flags |= GPIOLINE_FLAG_IS_OUT;
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index b70df27874d1..2bbd8ee93507 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -736,6 +736,34 @@ int pinctrl_get_group_selector(struct pinctrl_dev *pctldev,
return -EINVAL;
}
+bool pinctrl_gpio_can_use_line(unsigned gpio)
+{
+ struct pinctrl_dev *pctldev;
+ struct pinctrl_gpio_range *range;
+ bool result;
+ int pin;
+
+ /*
+* Try to obtain GPIO range, if it fails
+* we're probably dealing with GPIO driver
+* without a backing pin controller - bail out.
+*/
+ if (pinctrl_get_device_gpio_range(gpio, , ))
+ return true;
+
+ mutex_lock(>mutex);
+
+ /* Convert to the pin controllers number space */
+ pin = gpio_to_pin(range, gpio);
+
+ result = pinmux_can_be_used_for_gpio(pctldev, pin);
+
+ mutex_unlock(>mutex);
+
+ return result;
+}
+EXPORT_SYMBOL_GPL(pinctrl_gpio_can_use_line);
+
/**
* pinctrl_gpio_request() - request a single pin to be used as GPIO
* @gpio: the GPIO pin number from the GPIO subsystem number space
diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
index 020e54f843f9..7e42a5738d82 100644
--- a/drivers/pinctrl/pinmux.c
+++ b/drivers/pinctrl/pinmux.c
@@ -70,6 +70,33 @@ int pinmux_validate_map(const struct pinctrl_map *map, int i)
return 0;
}
+/**
+ * pinmux_can_be_used_for_gpio() - check if a specific pin
+ * is either muxed to a different function or used as gpio.
+ *
+ * @pin: the pin number in the global pin space
+ *
+ * Controllers not defined as strict will always return true,
+ * menaning that the gpio can be used.
+ */
+bool pinmux_can_be_used_for_gpio(struct pinctrl_dev *pctldev, unsigned pin)
+{
+ struct pin_desc *desc = pin_desc_get(pctldev, pin);
+ const struct pinmux_ops *ops = pctldev->desc->pmxops;
+
+ if (!desc) {
+ dev_dbg(pctldev->dev,
+ "pin %u is not registered so it cannot be requested\n",
+ pin);
+ return true;
+ }
+
+ if (ops->strict && desc->mux_usecount)
+ return false;
+
+ return !(ops->strict && !!desc->gpio_owner);
+}
+
/**
* pin_request() - request a single pin to be muxed in, typically for GPIO
* @pin: the pin number in the global pin space
diff --git a/drivers/pinctrl/pinmux.h b/drivers/pinctrl/pinmux.h
index 794cb3a003ff..78c3a31be882 100644
--- a/drivers/pinctrl/pinmux.h
+++ b/drivers/pinctrl/pinmux.h
@@ -15,6 +15,8 @@ int pinmux_check_ops(struct pinctrl_dev *pctldev);
int pinmux_validate_map(const struct pinctrl_map *map, int i);
+bool pinmux_can_be_used_for_gpio(struct pinctrl_dev *pctldev, unsigned pin);
+
int pinmux_request_gpio(struct pinctrl_dev *pctldev,
struct pinctrl_gpio_range *range,
unsigned pin, unsigned gpio);
@@ -42,6 +44,12 @@ static inline int pinmux_validate_map(const struct
pinctrl_map *map, int i)
return 0;
}
+static inline bool pinmux_can_be_used_for_gpio(struct pinctrl_dev *pctldev,
+
[RFC PATCH 0/2] Add predictive memory reclamation and compaction
Page reclamation and compaction is triggered in response to reaching low watermark. This makes reclamation/compaction reactive based upon a snapshot of the system at a point in time. When that point is reached, system is already suffering from free memory shortage and must now try to recover. Recovery can often land system in direct reclamation/compaction path and while recovery happens, workloads start to experience unpredictable memory allocation latencies. In real life, forced direct reclamation has been seen to cause sudden spike in time it takes to populate a new database or an extraordinary unpredictable latency in launching a new server on cloud platform. These events create SLA violations which are expensive for businesses. If the kernel could foresee a potential free page exhaustion or fragmentation event well before it happens, it could start reclamation proactively instead to avoid allocation stalls. A time based trend line for available free pages can show such potential future events by charting the current memory consumption trend on the system. These patches propose a way to capture enough memory usage information to compute a trend line based upon most recent data. Trend line is graphed with x-axis showing time and y-axis showing number of free pages. The proposal is to capture the number of free pages at opportune moments along with the current timestamp. Once system has enough data points (the lookback window for trend analysis), fit a line of the form y=mx+c to these points using least sqaure regression method. As time advances, these points can be updated with new data points and a new best fit line can be computed. Capturing these data points and computing trend line for pages of order 0-MAX_ORDER allows us to not only foresee free pages exhaustion point but also severe fragmentation points in future. If the line representing trend for total free pages has a negative slope (hence trending downward), solving y=mx+c for x with y=0 tells us if the current trend continues, at what point would the system run out of free pages. If average rate of page reclamation is computed by observing page reclamation behavior, that information can be used to compute the time to start reclamation at so that number of free pages does not fall to 0 or below low watermark if current memory consumption trend were to continue. Similarly, if kernel tracks the level of fragmentation for each order page (which can be done by computing the number of free pages below this order), a trend line for each order can be used to compute the point in time when no more pages of that order will be available for allocation. If the trend line represents number of unusable pages for that order, the intersection of this line with line representing number of free pages is the point of 100% fragmentation. This holds true because at this intersection point all free pages are of lower order. Intersetion point for two lines y0=m0x0+c0 and y1=m1x1+c1 can be computed mathematically which yields x and y coordinates on time and free pages graph. If average rate of compaction is computed by timing previous compaction runs, kernel can compute how soon does it need to start compaction to avoid this 100% fragmentation point. Patch 1 adds code to maintain a sliding lookback window of (time, number of free pages) points which can be updated continuously and adds code to compute best fit line across these points. It also adds code to use the best fit lines to determine if kernel must start reclamation or compaction. Patch 2 adds code to collect data points on free pages of various orders at different points in time, uses code in patch 1 to update sliding lookback window with these points and kicks off reclamation or compaction based upon the results it gets. Patch 1 maintains a fixed size lookback window. A fixed size lookback window limits the amount of data that has to be maintained to compute a best fit line. Routine mem_predict() in patch 1 uses best fit line to determine the immediate need for reclamation or compaction. To simplify initial concept implementation, it uses a fixed time threshold when compaction should start in anticipation of impending fragmentation. Similarly it uses a fixed minimum precentage free pages as criteria to detrmine if it is time to start reclamation if the current trend line shows continued drop in number of free pages. Both of these criteria can be improved upon in final implementation by taking rate of compaction and rate of reclamation into account. Patch 2 collects data points for best fit line in kswapd before we decide if kswapd should go to sleep or continue reclamation. It then uses that data to delay kswapd from sleeping and continue reclamation. Potential fragmentation information obtained from best fit line is used to decide if zone watermark should be boosted to avert impending fragmentation. This data is also used in balance_pgdat() to determine if kcompatcd should be woken up to start
[RFC PATCH 1/2] mm: Add trend based prediction algorithm for memory usage
Direct page reclamation and compaction have high and unpredictable
latency costs for applications. This patch adds code to predict if
system is about to run out of free memory by watching the historical
memory consumption trends. It computes a best fit line to this
historical data using method of least squares. it can then compute if
system will run out of memory if the current trend continues.
Historical data is held in a new data structure lsq_struct for each
zone and each order within the zone. Size of the window for historical
data is given by LSQ_LOOKBACK.
Signed-off-by: Khalid Aziz
Signed-off-by: Bharath Vedartham
Reviewed-by: Vandana BN
---
include/linux/mmzone.h | 34 +
mm/Makefile| 2 +-
mm/lsq.c | 273 +
3 files changed, 308 insertions(+), 1 deletion(-)
create mode 100644 mm/lsq.c
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index d77d717c620c..9a0e5cab7171 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -355,6 +355,38 @@ struct per_cpu_nodestat {
#endif /* !__GENERATING_BOUNDS.H */
+/*
+ * Size of lookback window for the free memory exhaustion prediction
+ * algorithm. Keep it to less than 16 to keep data manageable
+ */
+#define LSQ_LOOKBACK 8
+
+/*
+ * How far forward to look when determining if memory exhaustion would
+ * become an issue.
+ */
+extern unsigned long mempredict_threshold;
+
+/*
+ * Structure to keep track of current values required to compute the best
+ * fit line using method of least squares
+ */
+struct lsq_struct {
+ bool ready;
+ int next;
+ u64 x[LSQ_LOOKBACK];
+ unsigned long y[LSQ_LOOKBACK];
+};
+
+struct frag_info {
+ unsigned long free_pages;
+ unsigned long time;
+};
+
+/* Possile bits to be set by mem_predict in its return value */
+#define MEMPREDICT_RECLAIM 0x01
+#define MEMPREDICT_COMPACT 0x02
+
enum zone_type {
#ifdef CONFIG_ZONE_DMA
/*
@@ -581,6 +613,8 @@ enum zone_flags {
*/
};
+extern int mem_predict(struct frag_info *frag_vec, struct zone *zone);
+
static inline unsigned long zone_managed_pages(struct zone *zone)
{
return (unsigned long)atomic_long_read(>managed_pages);
diff --git a/mm/Makefile b/mm/Makefile
index 338e528ad436..fb7b3c19dd13 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -39,7 +39,7 @@ obj-y := filemap.o mempool.o oom_kill.o
fadvise.o \
mm_init.o mmu_context.o percpu.o slab_common.o \
compaction.o vmacache.o \
interval_tree.o list_lru.o workingset.o \
- debug.o gup.o $(mmu-y)
+ debug.o gup.o lsq.o $(mmu-y)
# Give 'page_alloc' its own module-parameter namespace
page-alloc-y := page_alloc.o
diff --git a/mm/lsq.c b/mm/lsq.c
new file mode 100644
index ..6005a2b2f44d
--- /dev/null
+++ b/mm/lsq.c
@@ -0,0 +1,273 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * lsq.c: Provide a prediction on whether free memory exhaustion is
+ * imminent or not by using a best fit line based upon method of
+ * least squares. Best fit line is based upon recent historical
+ * data. This historical data forms the lookback window for the
+ * algorithm.
+ *
+ *
+ * Author: Robert Harris
+ * Author: Khalid Aziz
+ *
+ * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved.
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * This code is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
+ * or visit www.oracle.com if you need additional information or have any
+ * questions.
+ *
+ */
+
+#include
+#include
+#include
+
+/*
+ * How far forward to look when determining if fragmentation would
+ * become an issue. The unit for this is same as the unit for the
+ * x-axis of graph where sample points for memory utilization are being
+ * plotted. We start with a default value of 1000 units but can tweak it
+ * dynamically to get better prediction results. With data points for
+ * memory being gathered with granularity of milliseconds, this translates
+ * to a look ahead of 1 second. If system is 1 second away from severe
+ * fragmentation, start compaction now to avoid direct comapction.
+ */
+unsigned long mempredict_threshold = 1000;
+
+/*
+ * Threshold for number of free pages that should trigger reclamation,
Re: [PATCH RFC tip/core/rcu 14/14] rcu/nohz: Make multi_cpu_stop() enable tick on all online CPUs
On Mon, Aug 12, 2019 at 7:23 PM Paul E. McKenney wrote:
>
> On Mon, Aug 12, 2019 at 11:02:33PM +0200, Frederic Weisbecker wrote:
> > On Fri, Aug 02, 2019 at 08:15:01AM -0700, Paul E. McKenney wrote:
> > > The multi_cpu_stop() function relies on the scheduler to gain control from
> > > whatever is running on the various online CPUs, including any nohz_full
> > > CPUs running long loops in kernel-mode code. Lack of the scheduler-clock
> > > interrupt on such CPUs can delay multi_cpu_stop() for several minutes
> > > and can also result in RCU CPU stall warnings. This commit therefore
> > > causes multi_cpu_stop() to enable the scheduler-clock interrupt on all
> > > online CPUs.
> > >
> > > Signed-off-by: Paul E. McKenney
> > > ---
> > > kernel/stop_machine.c | 9 -
> > > 1 file changed, 8 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
> > > index b4f83f7bdf86..a2659f61ed92 100644
> > > --- a/kernel/stop_machine.c
> > > +++ b/kernel/stop_machine.c
> > > @@ -20,6 +20,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > >
> > > /*
> > > @@ -187,15 +188,19 @@ static int multi_cpu_stop(void *data)
> > > {
> > > struct multi_stop_data *msdata = data;
> > > enum multi_stop_state curstate = MULTI_STOP_NONE;
> > > - int cpu = smp_processor_id(), err = 0;
> > > + int cpu, err = 0;
> > > const struct cpumask *cpumask;
> > > unsigned long flags;
> > > bool is_active;
> > >
> > > + for_each_online_cpu(cpu)
> > > + tick_nohz_dep_set_cpu(cpu, TICK_DEP_MASK_RCU);
> >
> > Looks like it's not the right fix but, should you ever need to set an
> > all-CPUs (system wide) tick dependency in the future, you can use
> > tick_set_dep().
>
> Indeed, I have dropped this patch, but I now do something similar in
> RCU's CPU-hotplug notifiers. Which does have an effect, especially on
> the system that isn't subject to the insane-latency cpu_relax().
>
> Plus I am having to put a similar workaround into RCU's quiescent-state
> forcing logic.
>
> But how should this really be done?
>
> Isn't there some sort of monitoring of nohz_full CPUs for accounting
> purposes? If so, would it make sense for this monitoring to check for
> long-duration kernel execution and enable the tick in this case? The
> RCU dyntick machinery can be used to remotely detect the long-duration
> kernel execution using something like the following:
>
> int nohz_in_kernel_snap = rcu_dynticks_snap_cpu(cpu);
>
> ...
>
> if (rcu_dynticks_in_eqs_cpu(cpu, nohz_in_kernel_snap)
> nohz_in_kernel_snap = rcu_dynticks_snap_cpu(cpu);
> else
> /* Turn on the tick! */
This solution does make sense to me and is simpler than the
rcu_nmi_exit_common() solution you proposed in the other thread.
Though I am not sure about the intricacies of remotely enabling the
timer tick for a CPU. But overall, the above solution does seem
simpler.
thanks,
- Joel
Re: [PATCH v4 03/10] livepatch: Add klp-convert tool
On Sat, Aug 10, 2019 at 3:42 AM Joe Lawrence wrote:
> > > > diff --git a/scripts/livepatch/Makefile b/scripts/livepatch/Makefile
> > > > new file mode 100644
> > > > index ..2842ecdba3fd
> > > > --- /dev/null
> > > > +++ b/scripts/livepatch/Makefile
> > > > @@ -0,0 +1,7 @@
> > > > +hostprogs-y:= klp-convert
> > > > +always := $(hostprogs-y)
> > > > +
> > > > +klp-convert-objs := klp-convert.o elf.o
> > > > +
> > > > +HOST_EXTRACFLAGS := -g -I$(INSTALL_HDR_PATH)/include
> > > > -Wall
> > >
> > > This looks strange.
> > >
> > > Theoretically, you cannot include headers in $(INSTALL_HDR_PATH)/include
> > > from host programs.
> > >
> > > headers_install works for the target architecture, not host architecture.
> > > This may cause a strange result when you are cross-compiling the kernel.
> > >
> > > BTW, which header in $(INSTALL_HDR_PATH)/include do you need to include ?
> > >
> > >
> > > Also, -Wall is redundant because it is set by the top-level Makefile.
> >
> >
> > I deleted HOST_EXTRACFLAGS entirely,
> > and I was still able to build klp-convert.
> >
> >
> > What is the purpose of '-g' ?
> > If it is only needed for local debugging,
> > it should be removed from the upstream code, in my opinion.
> >
>
> HOST_EXTRACFLAGS looks like it was present in the patchset from the
> early RFC days and inherited through each revision.
>
> These are the files that the klp-convert code includes, mostly typical C
> usercode headers like stdio.h and a few local headers like elf.h:
>
> % grep -h '^#include' scripts/livepatch/*.{c,h} | sort -u
> #include "elf.h"
> #include
> #include
> #include "klp-convert.h"
> #include "list.h"
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> If HOST_EXTRACFLAGS is really unneeded, we can easily drop it in the
> next patchset version.
Yes, please do so.
Thanks.
--
Best Regards
Masahiro Yamada
Re: [PATCH] riscv: dts: sifive: Add missing "clock-frequency" to cpu0/cpu1 nodes
On Wed, Aug 7, 2019 at 2:22 PM Bin Meng wrote: > > Add the missing "clock-frequency" property to the cpu0/cpu1 nodes > for consistency with other cpu nodes. > > Signed-off-by: Bin Meng > --- > > arch/riscv/boot/dts/sifive/fu540-c000.dtsi | 2 ++ > 1 file changed, 2 insertions(+) > ping
Re: [PATCH v3] trace:Add "gfp_t" support in synthetic_events
Hi Steve,
Could you help to review? Thanks.
On 7/13/2019 12:05 AM, Tom Zanussi wrote:
Hi Zhengjun,
On Fri, 2019-07-12 at 09:53 +0800, Zhengjun Xing wrote:
Add "gfp_t" support in synthetic_events, then the "gfp_t" type
parameter in some functions can be traced.
Prints the gfp flags as hex in addition to the human-readable flag
string. Example output:
whoopsie-630 [000] ...1 78.969452: testevent: bar=b20
(GFP_ATOMIC|__GFP_ZERO)
rcuc/0-11 [000] ...1 81.097555: testevent: bar=a20 (GFP_ATOMIC)
rcuc/0-11 [000] ...1 81.583123: testevent: bar=a20 (GFP_ATOMIC)
Signed-off-by: Tom Zanussi
Signed-off-by: Zhengjun Xing
Looks good to me, thanks!
Tom
---
kernel/trace/trace_events_hist.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/kernel/trace/trace_events_hist.c
b/kernel/trace/trace_events_hist.c
index ca6b0dff60c5..30f0f32aca62 100644
--- a/kernel/trace/trace_events_hist.c
+++ b/kernel/trace/trace_events_hist.c
@@ -13,6 +13,10 @@
#include
#include
+/* for gfp flag names */
+#include
+#include
+
#include "tracing_map.h"
#include "trace.h"
#include "trace_dynevent.h"
@@ -752,6 +756,8 @@ static int synth_field_size(char *type)
size = sizeof(unsigned long);
else if (strcmp(type, "pid_t") == 0)
size = sizeof(pid_t);
+ else if (strcmp(type, "gfp_t") == 0)
+ size = sizeof(gfp_t);
else if (synth_field_is_string(type))
size = synth_field_string_size(type);
@@ -792,6 +798,8 @@ static const char *synth_field_fmt(char *type)
fmt = "%lu";
else if (strcmp(type, "pid_t") == 0)
fmt = "%d";
+ else if (strcmp(type, "gfp_t") == 0)
+ fmt = "%x";
else if (synth_field_is_string(type))
fmt = "%s";
@@ -834,9 +842,20 @@ static enum print_line_t
print_synth_event(struct trace_iterator *iter,
i == se->n_fields - 1 ? ""
: " ");
n_u64 += STR_VAR_LEN_MAX / sizeof(u64);
} else {
+ struct trace_print_flags __flags[] = {
+ __def_gfpflag_names, {-1, NULL} };
+
trace_seq_printf(s, print_fmt, se-
fields[i]->name,
entry->fields[n_u64],
i == se->n_fields - 1 ? ""
: " ");
+
+ if (strcmp(se->fields[i]->type, "gfp_t") ==
0) {
+ trace_seq_puts(s, " (");
+ trace_print_flags_seq(s, "|",
+ entry-
fields[n_u64],
+ __flags);
+ trace_seq_putc(s, ')');
+ }
n_u64++;
}
}
--
Zhengjun Xing
Re: [PATCH 0/3] Collapse vimc into single monolithic driver
On 8/12/19 5:41 PM, Helen Koike wrote: Hi Shuah, On 8/12/19 7:14 PM, Shuah Khan wrote: On 8/12/19 1:10 PM, Shuah Khan wrote: On 8/12/19 12:52 PM, André Almeida wrote: Hi Shuah, On 8/12/19 11:08 AM, Shuah Khan wrote: On 8/9/19 9:51 PM, Helen Koike wrote: Hi Andre, Thanks for testing this. On 8/9/19 9:24 PM, André Almeida wrote: On 8/9/19 9:17 PM, Shuah Khan wrote: Hi Andre, On 8/9/19 5:52 PM, André Almeida wrote: Hello Shuah, Thanks for the patch, I did some comments below. On 8/9/19 6:45 PM, Shuah Khan wrote: vimc uses Component API to split the driver into functional components. The real hardware resembles a monolith structure than component and component structure added a level of complexity making it hard to maintain without adding any real benefit. The sensor is one vimc component that would makes sense to be a separate module to closely align with the real hardware. It would be easier to collapse vimc into single monolithic driver first and then split the sensor off as a separate module. This patch series emoves the component API and makes minimal changes to the code base preserving the functional division of the code structure. Preserving the functional structure allows us to split the sensor off as a separate module in the future. Major design elements in this change are: - Use existing struct vimc_ent_config and struct vimc_pipeline_config to drive the initialization of the functional components. - Make vimc_ent_config global by moving it to vimc.h - Add two new hooks add and rm to initialize and register, unregister and free subdevs. - All component API is now gone and bind and unbind hooks are modified to do "add" and "rm" with minimal changes to just add and rm subdevs. - vimc-core's bind and unbind are now register and unregister. - vimc-core invokes "add" hooks from its vimc_register_devices(). The "add" hooks remain the same and register subdevs. They don't create platform devices of their own and use vimc's pdev.dev as their reference device. The "add" hooks save their vimc_ent_device(s) in the corresponding vimc_ent_config. - vimc-core invokes "rm" hooks from its unregister to unregister subdevs and cleanup. - vimc-core invokes "add" and "rm" hooks with pointer to struct vimc_device and the corresponding struct vimc_ent_config pointer. The following configure and stream test works on all devices. media-ctl -d platform:vimc -V '"Sensor A":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Debayer A":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Sensor B":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Debayer B":0[fmt:SBGGR8_1X8/640x480]' v4l2-ctl -z platform:vimc -d "RGB/YUV Capture" -v width=1920,height=1440 v4l2-ctl -z platform:vimc -d "Raw Capture 0" -v pixelformat=BA81 v4l2-ctl -z platform:vimc -d "Raw Capture 1" -v pixelformat=BA81 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video1 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video2 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video3 The third patch in the series fixes a general protection fault found when rmmod is done while stream is active. I applied your patch on top of media_tree/master and I did some testing. Not sure if I did something wrong, but just adding and removing the module generated a kernel panic: Thanks for testing. Odd. I tested modprobe and rmmod both.I was working on Linux 5.3-rc2. I will apply these to media latest and work from there. I have to rebase these on top of the reverts from Lucas and Helen Ok, please let me know if I succeeded to reproduce. ~# modprobe vimc ~# rmmod vimc [ 16.452974] stack segment: [#1] SMP PTI [ 16.453688] CPU: 0 PID: 2038 Comm: rmmod Not tainted 5.3.0-rc2+ #36 [ 16.454678] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-20181126_142135-anatol 04/01/2014 [ 16.456191] RIP: 0010:kfree+0x4d/0x240 [ 16.469188] Call Trace: [ 16.469666] vimc_remove+0x35/0x90 [vimc] [ 16.470436] platform_drv_remove+0x1f/0x40 [ 16.471233] device_release_driver_internal+0xd3/0x1b0 [ 16.472184] driver_detach+0x37/0x6b [ 16.472882] bus_remove_driver+0x50/0xc1 [ 16.473569] vimc_exit+0xc/0xca0 [vimc] [ 16.474231] __x64_sys_delete_module+0x18d/0x240 [ 16.475036] do_syscall_64+0x43/0x110 [ 16.475656] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 16.476504] RIP: 0033:0x7fceb8dafa4b [ 16.484853] Modules linked in: vimc(-) videobuf2_vmalloc videobuf2_memops v4l2_tpg videobuf2_v4l2 videobuf2_common [ 16.486187] ---[ end trace 91e5e0894e254d49 ]--- [ 16.486758] RIP: 0010:kfree+0x4d/0x240 fish: “rmmod vimc” terminated by signal SIGSEGV (Address boundary error) I just added the module after booting, no other
Re: [PATCH] cpuidle-haltpoll: Enable kvm guest polling when dedicated physical CPUs are available
On Sun, 4 Aug 2019 at 04:21, Marcelo Tosatti wrote: > > On Thu, Aug 01, 2019 at 06:54:49PM +0200, Paolo Bonzini wrote: > > On 01/08/19 18:51, Rafael J. Wysocki wrote: > > > On 8/1/2019 9:06 AM, Wanpeng Li wrote: > > >> From: Wanpeng Li > > >> > > >> The downside of guest side polling is that polling is performed even > > >> with other runnable tasks in the host. However, even if poll in kvm > > >> can aware whether or not other runnable tasks in the same pCPU, it > > >> can still incur extra overhead in over-subscribe scenario. Now we can > > >> just enable guest polling when dedicated pCPUs are available. > > >> > > >> Cc: Rafael J. Wysocki > > >> Cc: Paolo Bonzini > > >> Cc: Radim Krčmář > > >> Cc: Marcelo Tosatti > > >> Signed-off-by: Wanpeng Li > > > > > > Paolo, Marcelo, any comments? > > > > Yes, it's a good idea. > > > > Acked-by: Paolo Bonzini > > > > Paolo > Hi Marcelo, Sorry for the late response. > I think KVM_HINTS_REALTIME is being abused somewhat. > It has no clear meaning and used in different locations > for different purposes. == = KVM_HINTS_REALTIME 0 guest checks this feature bit to determine that vCPUs are never preempted for an unlimited time allowing optimizations == = Now it disables pv queued spinlock, pv tlb shootdown, pv sched yield which are not expected present in vCPUs are never preempted for an unlimited time scenario. > > For example, i think that using pv queued spinlocks and > haltpoll is a desired scenario, which the patch below disallows. So even if dedicated pCPU is available, pv queued spinlocks should still be chose if something like vhost-kthreads are used instead of DPDK/vhost-user. kvm adaptive halt-polling will compete with vhost-kthreads, however, poll in guest unaware other runnable tasks in the host which will defeat vhost-kthreads. Regards, Wanpeng Li
Re: BUG: corrupted list in rxrpc_local_processor
Hello, syzbot has tested the proposed patch but the reproducer still triggered crash: KASAN: use-after-free Read in rxrpc_queue_local == BUG: KASAN: use-after-free in atomic_read include/asm-generic/atomic-instrumented.h:26 [inline] BUG: KASAN: use-after-free in rxrpc_queue_local+0x7c/0x3e0 net/rxrpc/local_object.c:354 Read of size 4 at addr 8880a82b56d4 by task syz-executor.0/11829 CPU: 1 PID: 11829 Comm: syz-executor.0 Not tainted 5.3.0-rc3+ #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x172/0x1f0 lib/dump_stack.c:113 print_address_description.cold+0xd4/0x306 mm/kasan/report.c:351 __kasan_report.cold+0x1b/0x36 mm/kasan/report.c:482 kasan_report+0x12/0x17 mm/kasan/common.c:612 check_memory_region_inline mm/kasan/generic.c:185 [inline] check_memory_region+0x134/0x1a0 mm/kasan/generic.c:192 __kasan_check_read+0x11/0x20 mm/kasan/common.c:92 atomic_read include/asm-generic/atomic-instrumented.h:26 [inline] rxrpc_queue_local+0x7c/0x3e0 net/rxrpc/local_object.c:354 rxrpc_unuse_local+0x52/0x80 net/rxrpc/local_object.c:408 rxrpc_release_sock net/rxrpc/af_rxrpc.c:904 [inline] rxrpc_release+0x47d/0x840 net/rxrpc/af_rxrpc.c:930 __sock_release+0xce/0x280 net/socket.c:590 sock_close+0x1e/0x30 net/socket.c:1268 __fput+0x2ff/0x890 fs/file_table.c:280 fput+0x16/0x20 fs/file_table.c:313 task_work_run+0x145/0x1c0 kernel/task_work.c:113 tracehook_notify_resume include/linux/tracehook.h:188 [inline] exit_to_usermode_loop+0x316/0x380 arch/x86/entry/common.c:163 prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline] syscall_return_slowpath arch/x86/entry/common.c:274 [inline] do_syscall_64+0x5a9/0x6a0 arch/x86/entry/common.c:299 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x413511 Code: 75 14 b8 03 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 04 1b 00 00 c3 48 83 ec 08 e8 0a fc ff ff 48 89 04 24 b8 03 00 00 00 0f 05 <48> 8b 3c 24 48 89 c2 e8 53 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01 RSP: 002b:7ffc204e87c0 EFLAGS: 0293 ORIG_RAX: 0003 RAX: RBX: 0004 RCX: 00413511 RDX: 001b2e42 RSI: RDI: 0003 RBP: 0001 R08: R09: R10: 7ffc204e88a0 R11: 0293 R12: 0075bf20 R13: 0001ac29 R14: 00760210 R15: Allocated by task 11830: save_stack+0x23/0x90 mm/kasan/common.c:69 set_track mm/kasan/common.c:77 [inline] __kasan_kmalloc mm/kasan/common.c:487 [inline] __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:460 kasan_kmalloc+0x9/0x10 mm/kasan/common.c:501 kmem_cache_alloc_trace+0x158/0x790 mm/slab.c:3550 kmalloc include/linux/slab.h:552 [inline] kzalloc include/linux/slab.h:748 [inline] rxrpc_alloc_local net/rxrpc/local_object.c:79 [inline] rxrpc_lookup_local+0x562/0x1ba0 net/rxrpc/local_object.c:277 rxrpc_sendmsg+0x379/0x5f0 net/rxrpc/af_rxrpc.c:566 sock_sendmsg_nosec net/socket.c:637 [inline] sock_sendmsg+0xd7/0x130 net/socket.c:657 ___sys_sendmsg+0x3e2/0x920 net/socket.c:2311 __sys_sendmmsg+0x1bf/0x4d0 net/socket.c:2413 __do_sys_sendmmsg net/socket.c:2442 [inline] __se_sys_sendmmsg net/socket.c:2439 [inline] __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2439 do_syscall_64+0xfd/0x6a0 arch/x86/entry/common.c:296 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 16: save_stack+0x23/0x90 mm/kasan/common.c:69 set_track mm/kasan/common.c:77 [inline] __kasan_slab_free+0x102/0x150 mm/kasan/common.c:449 kasan_slab_free+0xe/0x10 mm/kasan/common.c:457 __cache_free mm/slab.c:3425 [inline] kfree+0x10a/0x2c0 mm/slab.c:3756 rxrpc_local_rcu+0x62/0x80 net/rxrpc/local_object.c:495 __rcu_reclaim kernel/rcu/rcu.h:222 [inline] rcu_do_batch kernel/rcu/tree.c:2114 [inline] rcu_core+0x67f/0x1580 kernel/rcu/tree.c:2314 rcu_core_si+0x9/0x10 kernel/rcu/tree.c:2323 __do_softirq+0x262/0x98c kernel/softirq.c:292 The buggy address belongs to the object at 8880a82b56c0 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 20 bytes inside of 1024-byte region [8880a82b56c0, 8880a82b5ac0) The buggy address belongs to the page: page:ea0002a0ad00 refcount:1 mapcount:0 mapping:8880aa400c40 index:0x8880a82b5b40 compound_mapcount: 0 flags: 0x1fffc010200(slab|head) raw: 01fffc010200 ea0002a1cb08 ea00023b0c88 8880aa400c40 raw: 8880a82b5b40 8880a82b4040 00010006 page dumped because: kasan: bad access detected Memory state around the buggy address: 8880a82b5580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 8880a82b5600: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc 8880a82b5680: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb ^ 8880a82b5700:
Re: [PATCH v3] perf diff: Report noisy for cycles diff
On 8/12/2019 4:35 PM, Jiri Olsa wrote:
On Sat, Aug 10, 2019 at 07:30:29AM +0800, Jin Yao wrote:
SNIP
+
+ init_stats(>diff.stats);
+ init_spark_values(pair->diff.svals, NUM_SPARKS);
+
+ for (int i = 0; i < pair->block_info->num; i++) {
+ u64 val;
+
+ if (i >= he->block_info->num || i >= NUM_SPARKS)
+ break;
+
+ val = labs(pair->block_info->cycles_spark[i] -
+he->block_info->cycles_spark[i]);
+
+ update_spark_value(pair->diff.svals, NUM_SPARKS,
+ >diff.stats, val);
+ update_stats(>diff.stats, val);
+ }
}
}
@@ -1250,6 +1292,8 @@ static const struct option options[] = {
"Show period values."),
OPT_BOOLEAN('F', "formula", _formula,
"Show formula."),
+ OPT_BOOLEAN('n', "noisy", _noisy,
+ "Show cycles noisy - WARNING: use only with -c cycles."),
this should be more 'cycles' specific like --cycles-noisy or --cycles-hist?
also I dont think we should use 'n' for this, just the long option
jirka
Yes, it's cycles specific. Maybe --cycles-hist is better and the long
option should be enough. We can reserve -n for future feature. :)
Thanks
Jin Yao
Re: [PATCH] `iwlist scan` fails with many networks available
>I suppose we could consider applying a workaround like this if it has a >condition checking that the buffer passed in is the maximum possible >buffer (65535 bytes, due to iw_point::length being u16) This is what the latest patch does (attached to my email from yesterday / https://lkml.org/lkml/2019/8/10/452 ). If you'd like to apply it, I'm happy to make any needed revisions. Otherwise I'm going to have to keep patching my kernels for this issue, unfortunately I don't have the time to try to get wicd to migrate to a better solution. On 8/11/19, Johannes Berg wrote: > On Sun, 2019-08-11 at 02:08 +, James Nylen wrote: >> In 5.x it's still possible for `ieee80211_scan_results` (`iwlist >> scan`) to fail when too many wireless networks are available. This >> code path is used by `wicd`. >> >> Previously: https://lkml.org/lkml/2017/4/2/192 > > This has been known for probably a decade or longer. I don't know why > 'wicd' still insists on using wext, unless it's no longer maintained at > all. nl80211 doesn't have this problem at all, and I think gives more > details about the networks found too. > >> I've been applying this updated patch to my own kernels since 2017 with >> no issues. I am sure it is not the ideal way to solve this problem, but >> I'm making my fix available in case it helps others. > > I don't think silently dropping data is a good solution. > > I suppose we could consider applying a workaround like this if it has a > condition checking that the buffer passed in is the maximum possible > buffer (65535 bytes, due to iw_point::length being u16), but below that > -E2BIG serves well-written implementations as an indicator that they > need to retry with a bigger buffer. > >> Please advise on next steps or if this is a dead end. > > I think wireless extensions are in fact a dead end and all software > (even 'wicd', which seems to be the lone holdout) should migrate to > nl80211 instead. > > johannes > >
Re: [PATCH v3] perf diff: Report noisy for cycles diff
On 8/12/2019 4:35 PM, Jiri Olsa wrote:
On Sat, Aug 10, 2019 at 07:30:29AM +0800, Jin Yao wrote:
SNIP
static int process_block_per_sym(struct hist_entry *he)
@@ -684,6 +694,21 @@ static struct hist_entry *get_block_pair(struct hist_entry
*he,
return NULL;
}
+static void init_spark_values(unsigned long *svals, int num)
+{
+ for (int i = 0; i < num; i++)
+ svals[i] = 0;
+}
+
+static void update_spark_value(unsigned long *svals, int num,
+ struct stats *stats, u64 val)
+{
+ int n = stats->n;
+
+ if (n < num)
+ svals[n] = val;
+}
+
static void compute_cycles_diff(struct hist_entry *he,
struct hist_entry *pair)
{
@@ -692,6 +717,23 @@ static void compute_cycles_diff(struct hist_entry *he,
pair->diff.cycles =
pair->block_info->cycles_aggr /
pair->block_info->num_aggr -
he->block_info->cycles_aggr / he->block_info->num_aggr;
+
should below code be executed only for show_noisy?
jirka
Oh, yes, following code should be executed only when show_noisy is
enabled. Thanks for pointing out this issue. I will refine the code.
Thanks
Jin Yao
+ init_stats(>diff.stats);
+ init_spark_values(pair->diff.svals, NUM_SPARKS);
+
+ for (int i = 0; i < pair->block_info->num; i++) {
+ u64 val;
+
+ if (i >= he->block_info->num || i >= NUM_SPARKS)
+ break;
+
+ val = labs(pair->block_info->cycles_spark[i] -
+he->block_info->cycles_spark[i]);
+
+ update_spark_value(pair->diff.svals, NUM_SPARKS,
+ >diff.stats, val);
+ update_stats(>diff.stats, val);
+ }
}
}
SNIP
Re: [PATCH v2 bpf-next 1/4] tracing/probe: Add PERF_EVENT_IOC_QUERY_PROBE ioctl
On Mon, Aug 12, 2019, at 8:57 AM, Andrii Nakryiko wrote: > On Fri, Aug 9, 2019 at 2:47 PM Daniel Xu wrote: > > > > It's useful to know [uk]probe's nmissed and nhit stats. For example with > > tracing tools, it's important to know when events may have been lost. > > debugfs currently exposes a control file to get this information, but > > it is not compatible with probes registered with the perf API. > > > > While bpf programs may be able to manually count nhit, there is no way > > to gather nmissed. In other words, it is currently not possible to > > retrieve information about FD-based probes. > > > > This patch adds a new ioctl that lets users query nmissed (as well as > > nhit for completeness). We currently only add support for [uk]probes > > but leave the possibility open for other probes like tracepoint. > > > > Signed-off-by: Daniel Xu > > --- > > include/linux/trace_events.h| 12 > > include/uapi/linux/perf_event.h | 19 +++ > > kernel/events/core.c| 20 > > kernel/trace/trace_kprobe.c | 23 +++ > > kernel/trace/trace_uprobe.c | 23 +++ > > 5 files changed, 97 insertions(+) > > [...] > > + struct trace_kprobe *tk = (struct trace_kprobe *)call->data; > > + u64 nmissed, nhit; > > + > > + if (!capable(CAP_SYS_ADMIN)) > > + return -EPERM; > > + if (copy_from_user(, uquery, sizeof(query))) > > what about forward/backward compatibility? Didn't you have a size > field for perf_event_query_probe? I initially did, yes. But after thinking about it more, I'm not convinced it is necessary. It seems the last change to the debugfs counterpart was in the initial comit cd7e7bd5e4, ~10 years ago. I cannot think of any other information that would be useful off the top of my head, so I figured it'd be best if we didn't make more complicated something that doesn't seem likely to change. If we really needed something else, I figured adding another ioctl is pretty cheap. If you (or anyone) feels strongly about adding it back, I can make it a u64 so there's no holes. > > > + return -EFAULT; > > + > > + nhit = trace_kprobe_nhit(tk); > > + nmissed = tk->rp.kp.nmissed; > > + > > + if (put_user(nmissed, >nmissed) || > > + put_user(nhit, >nhit)) > > Wouldn't it be nicer to just do one user put for entire struct (or at > least relevant part of it with backward/forward compatibility?). Not sure how that didn't occur to me. Thanks.
Re: KASAN: use-after-free Read in rxrpc_queue_local
Hello, syzbot has tested the proposed patch but the reproducer still triggered crash: KASAN: use-after-free Read in rxrpc_queue_local == BUG: KASAN: use-after-free in atomic_read include/asm-generic/atomic-instrumented.h:26 [inline] BUG: KASAN: use-after-free in rxrpc_queue_local+0x7c/0x3e0 net/rxrpc/local_object.c:354 Read of size 4 at addr 888081e3db14 by task syz-executor.5/31180 CPU: 0 PID: 31180 Comm: syz-executor.5 Not tainted 5.3.0-rc3+ #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x172/0x1f0 lib/dump_stack.c:113 print_address_description.cold+0xd4/0x306 mm/kasan/report.c:351 __kasan_report.cold+0x1b/0x36 mm/kasan/report.c:482 kasan_report+0x12/0x17 mm/kasan/common.c:612 check_memory_region_inline mm/kasan/generic.c:185 [inline] check_memory_region+0x134/0x1a0 mm/kasan/generic.c:192 __kasan_check_read+0x11/0x20 mm/kasan/common.c:92 atomic_read include/asm-generic/atomic-instrumented.h:26 [inline] rxrpc_queue_local+0x7c/0x3e0 net/rxrpc/local_object.c:354 rxrpc_unuse_local+0x52/0x80 net/rxrpc/local_object.c:408 rxrpc_release_sock net/rxrpc/af_rxrpc.c:904 [inline] rxrpc_release+0x47d/0x840 net/rxrpc/af_rxrpc.c:930 __sock_release+0xce/0x280 net/socket.c:590 sock_close+0x1e/0x30 net/socket.c:1268 __fput+0x2ff/0x890 fs/file_table.c:280 fput+0x16/0x20 fs/file_table.c:313 task_work_run+0x145/0x1c0 kernel/task_work.c:113 tracehook_notify_resume include/linux/tracehook.h:188 [inline] exit_to_usermode_loop+0x316/0x380 arch/x86/entry/common.c:163 prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline] syscall_return_slowpath arch/x86/entry/common.c:274 [inline] do_syscall_64+0x5a9/0x6a0 arch/x86/entry/common.c:299 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x413511 Code: 75 14 b8 03 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 04 1b 00 00 c3 48 83 ec 08 e8 0a fc ff ff 48 89 04 24 b8 03 00 00 00 0f 05 <48> 8b 3c 24 48 89 c2 e8 53 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01 RSP: 002b:7fffc45736d0 EFLAGS: 0293 ORIG_RAX: 0003 RAX: RBX: 0004 RCX: 00413511 RDX: 001b3392 RSI: RDI: 0003 RBP: 0001 R08: R09: R10: 7fffc45737b0 R11: 0293 R12: 0075bf20 R13: 0003624a R14: 00760270 R15: Allocated by task 31182: save_stack+0x23/0x90 mm/kasan/common.c:69 set_track mm/kasan/common.c:77 [inline] __kasan_kmalloc mm/kasan/common.c:487 [inline] __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:460 kasan_kmalloc+0x9/0x10 mm/kasan/common.c:501 kmem_cache_alloc_trace+0x158/0x790 mm/slab.c:3550 kmalloc include/linux/slab.h:552 [inline] kzalloc include/linux/slab.h:748 [inline] rxrpc_alloc_local net/rxrpc/local_object.c:79 [inline] rxrpc_lookup_local+0x562/0x1ba0 net/rxrpc/local_object.c:277 rxrpc_bind+0x34d/0x5e0 net/rxrpc/af_rxrpc.c:149 __sys_bind+0x239/0x290 net/socket.c:1647 __do_sys_bind net/socket.c:1658 [inline] __se_sys_bind net/socket.c:1656 [inline] __x64_sys_bind+0x73/0xb0 net/socket.c:1656 do_syscall_64+0xfd/0x6a0 arch/x86/entry/common.c:296 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 9: save_stack+0x23/0x90 mm/kasan/common.c:69 set_track mm/kasan/common.c:77 [inline] __kasan_slab_free+0x102/0x150 mm/kasan/common.c:449 kasan_slab_free+0xe/0x10 mm/kasan/common.c:457 __cache_free mm/slab.c:3425 [inline] kfree+0x10a/0x2c0 mm/slab.c:3756 rxrpc_local_rcu+0x62/0x80 net/rxrpc/local_object.c:495 __rcu_reclaim kernel/rcu/rcu.h:222 [inline] rcu_do_batch kernel/rcu/tree.c:2114 [inline] rcu_core+0x67f/0x1580 kernel/rcu/tree.c:2314 rcu_core_si+0x9/0x10 kernel/rcu/tree.c:2323 __do_softirq+0x262/0x98c kernel/softirq.c:292 The buggy address belongs to the object at 888081e3db00 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 20 bytes inside of 1024-byte region [888081e3db00, 888081e3df00) The buggy address belongs to the page: page:ea0002078f00 refcount:1 mapcount:0 mapping:8880aa400c40 index:0x0 compound_mapcount: 0 flags: 0x1fffc010200(slab|head) raw: 01fffc010200 ea0002073288 ea00022f1608 8880aa400c40 raw: 888081e3c000 00010007 page dumped because: kasan: bad access detected Memory state around the buggy address: 888081e3da00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 888081e3da80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 888081e3db00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ 888081e3db80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 888081e3dc00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb == Tested on:
Re: [PATCH] mm: memcontrol: flush percpu vmevents before releasing memcg
On Mon, Aug 12, 2019 at 04:37:54PM -0700, Roman Gushchin wrote: > Similar to vmstats, percpu caching of local vmevents leads to an > accumulation of errors on non-leaf levels. This happens because > some leftovers may remain in percpu caches, so that they are > never propagated up by the cgroup tree and just disappear into > nonexistence with on releasing of the memory cgroup. > > To fix this issue let's accumulate and propagate percpu vmevents > values before releasing the memory cgroup similar to what we're > doing with vmstats. > > Since on cpu hotplug we do flush percpu vmstats anyway, we can > iterate only over online cpus. Just to clarify: this patch should be placed on top of two other patches, which I sent a bit earlier today: 1) mm: memcontrol: flush percpu slab vmstats on kmem offlining 2) mm: memcontrol: flush percpu vmstats before releasing memcg Sorry for the inconvenience, I forgot about vmevents during working on the final version, and remembered too late. Thanks!
Re: [PATCH] RISC-V: Issue a local tlb flush if possible.
On Mon, 2019-08-12 at 07:56 -0700, Christoph Hellwig wrote:
> I agree with the comment that we really should move this out of line
> now, and
sure.
> also that we can simplify it further, which also includes
> not bothering with the SBI call if we were the only online CPU.
I already had that optimization in my patch.
> I also thing we need to use get_cpu/put_cpu to be preemption safe.
>
ok. I will update that.
> Also why would we need to do a local flush if we have a mask that
> doesn't include the local CPU?
>
I thought if it recieves an empty cpumask, then it should at least do a
local flush is the expected behavior. Are you saying that we should
just skip all and return ?
> How about something like:
>
> void __riscv_flush_tlb(struct cpumask *cpumask, unsigned long start,
> unsigned long size)
> {
> unsigned int cpu;
>
> if (!cpumask)
> cpumask = cpu_online_mask;
>
> cpu = get_cpu();
> if (!cpumask || cpumask_test_cpu(cpu, cpumask) {
> if ((start == 0 && size == -1) || size > PAGE_SIZE)
> local_flush_tlb_all();
> else if (size == PAGE_SIZE)
> local_flush_tlb_page(start);
> cpumask_clear_cpu(cpuid, cpumask);
This will modify the original cpumask which is not correct. clear part
has to be done on hmask to avoid a copy.
Regards,
Atish
> }
>
> if (!cpumask_empty(cpumask)) {
> struct cpumask hmask;
>
> riscv_cpuid_to_hartid_mask(cpumask, );
> sbi_remote_sfence_vma(hmask.bits, start, size);
> }
> put_cpu();
> }
[rcu:rcu/next 47/86] include/asm-generic/atomic-long.h:17:9: error: unknown type name 'atomic_t'
tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/next head: eee850b8c265f38ab5feeb8fe6793b1b86eb77c7 commit: d3e83668c4df523f74ddf8c1eb8660f625713b87 [47/86] rcu/nocb: Use separate flag to indicate disabled ->cblist config: sh-allmodconfig (attached as .config) compiler: sh4-linux-gcc (GCC) 7.4.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout d3e83668c4df523f74ddf8c1eb8660f625713b87 # save the attached .config to linux build tree GCC_VERSION=7.4.0 make.cross ARCH=sh If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): In file included from include/linux/rcu_segcblist.h:18:0, from :0: >> include/asm-generic/atomic-long.h:17:9: error: unknown type name 'atomic_t' typedef atomic_t atomic_long_t; ^~~~ include/asm-generic/atomic-long.h: In function 'atomic_long_read': >> include/asm-generic/atomic-long.h:522:9: error: implicit declaration of >> function 'atomic_read'; did you mean '__atomic_load'? >> [-Werror=implicit-function-declaration] return atomic_read(v); ^~~ __atomic_load include/asm-generic/atomic-long.h: In function 'atomic_long_read_acquire': >> include/asm-generic/atomic-long.h:528:9: error: implicit declaration of >> function 'atomic_read_acquire'; did you mean 'atomic_long_read_acquire'? >> [-Werror=implicit-function-declaration] return atomic_read_acquire(v); ^~~ atomic_long_read_acquire include/asm-generic/atomic-long.h: In function 'atomic_long_set': >> include/asm-generic/atomic-long.h:534:2: error: implicit declaration of >> function 'atomic_set'; did you mean 'atomic_long_set'? >> [-Werror=implicit-function-declaration] atomic_set(v, i); ^~ atomic_long_set include/asm-generic/atomic-long.h: In function 'atomic_long_set_release': >> include/asm-generic/atomic-long.h:540:2: error: implicit declaration of >> function 'atomic_set_release'; did you mean 'atomic_long_set_release'? >> [-Werror=implicit-function-declaration] atomic_set_release(v, i); ^~ atomic_long_set_release include/asm-generic/atomic-long.h: In function 'atomic_long_add': >> include/asm-generic/atomic-long.h:546:2: error: implicit declaration of >> function 'atomic_add'; did you mean 'atomic_long_add'? >> [-Werror=implicit-function-declaration] atomic_add(i, v); ^~ atomic_long_add include/asm-generic/atomic-long.h: In function 'atomic_long_add_return': >> include/asm-generic/atomic-long.h:552:9: error: implicit declaration of >> function 'atomic_add_return'; did you mean 'atomic_long_add_return'? >> [-Werror=implicit-function-declaration] return atomic_add_return(i, v); ^ atomic_long_add_return include/asm-generic/atomic-long.h: In function 'atomic_long_add_return_acquire': >> include/asm-generic/atomic-long.h:558:9: error: implicit declaration of >> function 'atomic_add_return_acquire'; did you mean >> 'atomic_long_add_return_acquire'? [-Werror=implicit-function-declaration] return atomic_add_return_acquire(i, v); ^ atomic_long_add_return_acquire include/asm-generic/atomic-long.h: In function 'atomic_long_add_return_release': >> include/asm-generic/atomic-long.h:564:9: error: implicit declaration of >> function 'atomic_add_return_release'; did you mean >> 'atomic_long_add_return_release'? [-Werror=implicit-function-declaration] return atomic_add_return_release(i, v); ^ atomic_long_add_return_release include/asm-generic/atomic-long.h: In function 'atomic_long_add_return_relaxed': >> include/asm-generic/atomic-long.h:570:9: error: implicit declaration of >> function 'atomic_add_return_relaxed'; did you mean >> 'atomic_long_add_return_relaxed'? [-Werror=implicit-function-declaration] return atomic_add_return_relaxed(i, v); ^ atomic_long_add_return_relaxed include/asm-generic/atomic-long.h: In function 'atomic_long_fetch_add': >> include/asm-generic/atomic-long.h:576:9: error: implicit declaration of >> function 'atomic_fetch_add'; did you mean '__atomic_fetch_add'? >> [-Werror=implicit-function-declaration] return atomic_fetch_add(i, v); ^~~~ __atomic_fetch_add include/asm-generic/atomic-long.h: In function 'atomic_long_fetch_add_acquire': >> include/asm-generic/atomic-long.h:582:9: error: implicit declaration of >> function 'atomic_fetch_add_acquire'; did you mean >> 'atomic_long_fetch_add_acquire'? [-Werror=implicit-function-declaration] return atomic_fetch_add_acquire(i,
Re: [RFC PATCH 2/2] mm/gup: introduce vaddr_pin_pages_remote()
On 8/12/19 4:49 PM, Ira Weiny wrote:
On Sun, Aug 11, 2019 at 06:50:44PM -0700, john.hubb...@gmail.com wrote:
From: John Hubbard
...
diff --git a/drivers/infiniband/core/umem_odp.c
b/drivers/infiniband/core/umem_odp.c
index 53085896d718..fdff034a8a30 100644
--- a/drivers/infiniband/core/umem_odp.c
+++ b/drivers/infiniband/core/umem_odp.c
@@ -534,7 +534,7 @@ static int ib_umem_odp_map_dma_single_page(
}
out:
- put_user_page(page);
+ vaddr_unpin_pages(, 1, _odp->umem.vaddr_pin);
if (remove_existing_mapping) {
ib_umem_notifier_start_account(umem_odp);
@@ -635,9 +635,10 @@ int ib_umem_odp_map_dma_pages(struct ib_umem_odp
*umem_odp, u64 user_virt,
* complex (and doesn't gain us much performance in most use
* cases).
*/
- npages = get_user_pages_remote(owning_process, owning_mm,
+ npages = vaddr_pin_pages_remote(owning_process, owning_mm,
user_virt, gup_num_pages,
- flags, local_page_list, NULL, NULL);
+ flags, local_page_list, NULL, NULL,
+ _odp->umem.vaddr_pin);
Thinking about this part of the patch... is this pin really necessary? This
code is not doing a long term pin. The page just needs a reference while we
map it into the devices page tables. Once that is done we should get notifiers
if anything changes and we can adjust. right?
OK, now it's a little interesting: the FOLL_PIN is necessary, but maybe not
FOLL_LONGTERM. Illustrating once again that it's actually necessary to allow
these flags to vary independently.
And that leads to another API refinement idea: let's set FOLL_PIN within the
vaddr_pin_pages*() wrappers, and set FOLL_LONGTER in the *callers* of those
wrappers, yes?
thanks,
--
John Hubbard
NVIDIA
Re: [PATCH v6 3/8] KVM: x86: Implement CET CPUID enumeration for Guest
On Thu, Jul 25, 2019 at 11:12:41AM +0800, Yang Weijiang wrote:
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index 652b3876ea5c..ce1d6fe21780 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -1637,6 +1637,11 @@ static inline bool
> vmx_feature_control_msr_valid(struct kvm_vcpu *vcpu,
> return !(val & ~valid_bits);
> }
>
> +static inline u64 vmx_supported_xss(void)
> +{
> + return host_xss;
Do you know if the kernel will ever enable CET_USER but not CET_KERNEL,
and vice versa? I tried hunting down the logic in the main CET enabling
series but couldn't find the relevant code.
If the kernel does enable USER vs. KERNEL independently, are we sure that
KVM can correctly virtualize that state and that the guest OS won't die
due to expecting all CET features or no CET features?
In other words, do we want to return host_xss as is, or do we want to
make CET_USER and CET_KERNEL a bundle deal and avoid the headache, e.g.:
if (!(host_xss & XFEATURE_MASK_CET_USER) ||
!(host_xss & XFEATURE_MASK_CET_KERNEL))
return host_xss & ~(XFEATURE_MASK_CET_USER |
XFEATURE_MASK_CET_KERNEL);
return host_xss;
> +}
> +
> static int vmx_get_msr_feature(struct kvm_msr_entry *msr)
> {
> switch (msr->index) {
> @@ -7724,6 +7729,7 @@ static struct kvm_x86_ops vmx_x86_ops __ro_after_init =
> {
> .get_vmcs12_pages = NULL,
> .nested_enable_evmcs = NULL,
> .need_emulation_on_page_fault = vmx_need_emulation_on_page_fault,
> + .supported_xss = vmx_supported_xss,
> };
>
> static void vmx_cleanup_l1d_flush(void)
> diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h
> index a470ff0868c5..6a1870044752 100644
> --- a/arch/x86/kvm/x86.h
> +++ b/arch/x86/kvm/x86.h
> @@ -288,6 +288,10 @@ int x86_emulate_instruction(struct kvm_vcpu *vcpu,
> unsigned long cr2,
> | XFEATURE_MASK_YMM | XFEATURE_MASK_BNDREGS \
> | XFEATURE_MASK_BNDCSR | XFEATURE_MASK_AVX512 \
> | XFEATURE_MASK_PKRU)
> +
> +#define KVM_SUPPORTED_XSS(XFEATURE_MASK_CET_USER \
> + | XFEATURE_MASK_CET_KERNEL)
> +
> extern u64 host_xcr0;
>
> extern u64 kvm_supported_xcr0(void);
> --
> 2.17.2
>
Re: [PATCH 4.19 04/74] ARM: dts: rockchip: Mark that the rk3288 timer might stop in suspend
Hi,
On Mon, Aug 5, 2019 at 7:47 AM Pavel Machek wrote:
>
> On Mon 2019-08-05 15:02:17, Greg Kroah-Hartman wrote:
> > [ Upstream commit 8ef1ba39a9fa53d2205e633bc9b21840a275908e ]
> >
> > This is similar to commit e6186820a745 ("arm64: dts: rockchip: Arch
> > counter doesn't tick in system suspend"). Specifically on the rk3288
> > it can be seen that the timer stops ticking in suspend if we end up
> > running through the "osc_disable" path in rk3288_slp_mode_set(). In
> > that path the 24 MHz clock will turn off and the timer stops.
> >
> > To test this, I ran this on a Chrome OS filesystem:
> > before=$(date); \
> > suspend_stress_test -c1 --suspend_min=30 --suspend_max=31; \
> > echo ${before}; date
> >
> > ...and I found that unless I plug in a device that requests USB wakeup
> > to be active that the two calls to "date" would show that fewer than
> > 30 seconds passed.
> >
> > NOTE: deep suspend (where the 24 MHz clock gets disabled) isn't
> > supported yet on upstream Linux so this was tested on a downstream
> > kernel.
>
> I guess this does no harm, but deep sleep is unlikely to be suppored
> in the stable kernels, so ... is it good idea there?
People do merge stable kernels into local trees which have extra
patches (which might enable deep sleep). Chrome OS is an example of
this. If the patch does no harm then merging it seems nice.
That being said: we already have this in the Chrome OS tree, so unless
someone else is also mering stable into their tree and trying to
support rk3288 with deep sleep, this patch is unlikely to matter.
...so if everyone doesn't want it then it won't bother me.
-Doug
Re: [PATCH 4.19 03/74] ARM: dts: rockchip: Make rk3288-veyron-mickeys emmc work again
Hi, On Mon, Aug 5, 2019 at 7:45 AM Pavel Machek wrote: > > On Mon 2019-08-05 15:02:16, Greg Kroah-Hartman wrote: > > [ Upstream commit 99fa066710f75f18f4d9a5bc5f6a711968a581d5 ] > > > > When I try to boot rk3288-veyron-mickey I totally fail to make the > > eMMC work. Specifically my logs (on Chrome OS 4.19): > > > > mmc_host mmc1: card is non-removable. > > mmc_host mmc1: Bus speed (slot 0) = 40Hz (slot req 40Hz, actual > > 40HZ div = 0) > > mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot req 5200Hz, > > actual 5000HZ div = 0) > > mmc1: switch to bus width 8 failed > > mmc1: switch to bus width 4 failed > > mmc1: new high speed MMC card at address 0001 > > mmcblk1: mmc1:0001 HAG2e 14.7 GiB > > mmcblk1boot0: mmc1:0001 HAG2e partition 1 4.00 MiB > > mmcblk1boot1: mmc1:0001 HAG2e partition 2 4.00 MiB > > mmcblk1rpmb: mmc1:0001 HAG2e partition 3 4.00 MiB, chardev (243:0) > > mmc_host mmc1: Bus speed (slot 0) = 40Hz (slot req 40Hz, actual > > 40HZ div = 0) > > mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot req 5200Hz, > > actual 5000HZ div = 0) > > mmc1: switch to bus width 8 failed > > mmc1: switch to bus width 4 failed > > mmc1: tried to HW reset card, got error -110 > > mmcblk1: error -110 requesting status > > mmcblk1: recovery failed! > > print_req_error: I/O error, dev mmcblk1, sector 0 > > ... > > > > When I remove the '/delete-property/mmc-hs200-1_8v' then everything is > > hunky dory. > > > > That line comes from the original submission of the mickey dts > > upstream, so presumably at the time the HS200 was failing and just > > enumerating things as a high speed device was fine. ...or maybe it's > > just that some mickey devices work when enumerating at "high speed", > > just not mine? > > > > In any case, hs200 seems good now. Let's turn it on. > > Ok, so this was tested in v4.19; good. But AFAICT it is queued to > 4.14, too... which may not be good idea unless it was tested there...? > > Plus.. if this fixes stuff, that there are other configurations in the > dts that do not work. Should they be disabled or something? In general I don't have a good answer for you, but: * The fact that nobody noticed that things were pretty broken here implies that probably nobody is regularly testing mickey on upstream and presumably nobody is testing mickey on stable, so likely it doesn't matter a whole lot. * The original mickey dts was from "Thu Dec 3 16:55:40 2015 +0100" based upon kernel 4.4. That means there were 10 kernel revisions between it at 4.14. If I had to guess without testing, I'd guess that 4.14 is still better off with this patch than without. -Doug
[PATCH v2 2/3] soundwire: cadence_master: add debugfs register dump
Add debugfs file to dump the Cadence master registers.
Credits: this patch is based on an earlier internal contribution by
Vinod Koul, Sanyog Kale, Shreyas Nc and Hardik Shah.
Signed-off-by: Pierre-Louis Bossart
---
drivers/soundwire/cadence_master.c | 107 +
drivers/soundwire/cadence_master.h | 4 ++
2 files changed, 111 insertions(+)
diff --git a/drivers/soundwire/cadence_master.c
b/drivers/soundwire/cadence_master.c
index 665632dbdeb5..051c3736994a 100644
--- a/drivers/soundwire/cadence_master.c
+++ b/drivers/soundwire/cadence_master.c
@@ -8,6 +8,7 @@
#include
#include
+#include
#include
#include
#include
@@ -223,6 +224,112 @@ static int cdns_clear_bit(struct sdw_cdns *cdns, int
offset, u32 value)
return -EAGAIN;
}
+/*
+ * debugfs
+ */
+#ifdef CONFIG_DEBUG_FS
+
+#define RD_BUF (2 * PAGE_SIZE)
+
+static ssize_t cdns_sprintf(struct sdw_cdns *cdns,
+ char *buf, size_t pos, unsigned int reg)
+{
+ return scnprintf(buf + pos, RD_BUF - pos,
+"%4x\t%8x\n", reg, cdns_readl(cdns, reg));
+}
+
+static int cdns_reg_show(struct seq_file *s, void *data)
+{
+ struct sdw_cdns *cdns = s->private;
+ char *buf;
+ ssize_t ret;
+ int num_ports;
+ int i, j;
+
+ buf = kzalloc(RD_BUF, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ ret = scnprintf(buf, RD_BUF, "Register Value\n");
+ ret += scnprintf(buf + ret, RD_BUF - ret, "\nMCP Registers\n");
+ /* 8 MCP registers */
+ for (i = CDNS_MCP_CONFIG; i <= CDNS_MCP_PHYCTRL; i += sizeof(u32))
+ ret += cdns_sprintf(cdns, buf, ret, i);
+
+ ret += scnprintf(buf + ret, RD_BUF - ret,
+"\nStatus & Intr Registers\n");
+ /* 13 Status & Intr registers (offsets 0x70 and 0x74 not defined) */
+ for (i = CDNS_MCP_STAT; i <= CDNS_MCP_FIFOSTAT; i += sizeof(u32))
+ ret += cdns_sprintf(cdns, buf, ret, i);
+
+ ret += scnprintf(buf + ret, RD_BUF - ret,
+"\nSSP & Clk ctrl Registers\n");
+ ret += cdns_sprintf(cdns, buf, ret, CDNS_MCP_SSP_CTRL0);
+ ret += cdns_sprintf(cdns, buf, ret, CDNS_MCP_SSP_CTRL1);
+ ret += cdns_sprintf(cdns, buf, ret, CDNS_MCP_CLK_CTRL0);
+ ret += cdns_sprintf(cdns, buf, ret, CDNS_MCP_CLK_CTRL1);
+
+ ret += scnprintf(buf + ret, RD_BUF - ret,
+"\nDPn B0 Registers\n");
+
+ /*
+* in sdw_cdns_pdi_init() we filter out the Bulk PDIs,
+* so the indices need to be corrected again
+*/
+ num_ports = cdns->num_ports + CDNS_PCM_PDI_OFFSET;
+
+ for (i = 0; i < num_ports; i++) {
+ ret += scnprintf(buf + ret, RD_BUF - ret,
+"\nDP-%d\n", i);
+ for (j = CDNS_DPN_B0_CONFIG(i);
+j < CDNS_DPN_B0_ASYNC_CTRL(i); j += sizeof(u32))
+ ret += cdns_sprintf(cdns, buf, ret, j);
+ }
+
+ ret += scnprintf(buf + ret, RD_BUF - ret,
+"\nDPn B1 Registers\n");
+ for (i = 0; i < num_ports; i++) {
+ ret += scnprintf(buf + ret, RD_BUF - ret,
+"\nDP-%d\n", i);
+
+ for (j = CDNS_DPN_B1_CONFIG(i);
+j < CDNS_DPN_B1_ASYNC_CTRL(i); j += sizeof(u32))
+ ret += cdns_sprintf(cdns, buf, ret, j);
+ }
+
+ ret += scnprintf(buf + ret, RD_BUF - ret,
+"\nDPn Control Registers\n");
+ for (i = 0; i < num_ports; i++)
+ ret += cdns_sprintf(cdns, buf, ret,
+ CDNS_PORTCTRL + i * CDNS_PORT_OFFSET);
+
+ ret += scnprintf(buf + ret, RD_BUF - ret,
+"\nPDIn Config Registers\n");
+
+ /* number of PDI and ports is interchangeable */
+ for (i = 0; i < num_ports; i++)
+ ret += cdns_sprintf(cdns, buf, ret, CDNS_PDI_CONFIG(i));
+
+ seq_printf(s, "%s", buf);
+ kfree(buf);
+
+ return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(cdns_reg);
+
+/**
+ * sdw_cdns_debugfs_init() - Cadence debugfs init
+ * @cdns: Cadence instance
+ * @root: debugfs root
+ */
+void sdw_cdns_debugfs_init(struct sdw_cdns *cdns, struct dentry *root)
+{
+ debugfs_create_file("cdns-registers", 0400, root, cdns, _reg_fops);
+}
+EXPORT_SYMBOL_GPL(sdw_cdns_debugfs_init);
+
+#endif /* CONFIG_DEBUG_FS */
+
/*
* IO Calls
*/
diff --git a/drivers/soundwire/cadence_master.h
b/drivers/soundwire/cadence_master.h
index fe2af62958b1..2c0adf34e835 100644
--- a/drivers/soundwire/cadence_master.h
+++ b/drivers/soundwire/cadence_master.h
@@ -163,6 +163,10 @@ int sdw_cdns_pdi_init(struct sdw_cdns *cdns,
struct sdw_cdns_stream_config config);
int sdw_cdns_enable_interrupt(struct sdw_cdns *cdns);
+#ifdef CONFIG_DEBUG_FS
+void sdw_cdns_debugfs_init(struct sdw_cdns *cdns, struct dentry *root);
+#endif
[PATCH v2 3/3] soundwire: intel: add debugfs register dump
Add debugfs file to dump the Intel SoundWire registers
Credits: this patch is based on an earlier internal contribution by
Vinod Koul, Sanyog Kale, Shreyas Nc and Hardik Shah.
Signed-off-by: Pierre-Louis Bossart
---
drivers/soundwire/intel.c | 121 ++
1 file changed, 121 insertions(+)
diff --git a/drivers/soundwire/intel.c b/drivers/soundwire/intel.c
index c82ca4e13de7..db3b6afd2f63 100644
--- a/drivers/soundwire/intel.c
+++ b/drivers/soundwire/intel.c
@@ -6,6 +6,7 @@
*/
#include
+#include
#include
#include
#include
@@ -16,6 +17,7 @@
#include
#include
#include "cadence_master.h"
+#include "bus.h"
#include "intel.h"
/* Intel SHIM Registers Definition */
@@ -83,6 +85,7 @@
/* Intel ALH Register definitions */
#define SDW_ALH_STRMZCFG(x)(0x000 + (0x4 * (x)))
+#define SDW_ALH_NUM_STREAMS64
#define SDW_ALH_STRMZCFG_DMAT_VAL 0x3
#define SDW_ALH_STRMZCFG_DMAT GENMASK(7, 0)
@@ -98,6 +101,9 @@ struct sdw_intel {
struct sdw_cdns cdns;
int instance;
struct sdw_intel_link_res *res;
+#ifdef CONFIG_DEBUG_FS
+ struct dentry *debugfs;
+#endif
};
#define cdns_to_intel(_cdns) container_of(_cdns, struct sdw_intel, cdns)
@@ -161,6 +167,118 @@ static int intel_set_bit(void __iomem *base, int offset,
u32 value, u32 mask)
return -EAGAIN;
}
+/*
+ * debugfs
+ */
+#ifdef CONFIG_DEBUG_FS
+
+#define RD_BUF (2 * PAGE_SIZE)
+
+static ssize_t intel_sprintf(void __iomem *mem, bool l,
+char *buf, size_t pos, unsigned int reg)
+{
+ int value;
+
+ if (l)
+ value = intel_readl(mem, reg);
+ else
+ value = intel_readw(mem, reg);
+
+ return scnprintf(buf + pos, RD_BUF - pos, "%4x\t%4x\n", reg, value);
+}
+
+static int intel_reg_show(struct seq_file *s_file, void *data)
+{
+ struct sdw_intel *sdw = s_file->private;
+ void __iomem *s = sdw->res->shim;
+ void __iomem *a = sdw->res->alh;
+ char *buf;
+ ssize_t ret;
+ int i, j;
+ unsigned int links, reg;
+
+ buf = kzalloc(RD_BUF, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ links = intel_readl(s, SDW_SHIM_LCAP) & GENMASK(2, 0);
+
+ ret = scnprintf(buf, RD_BUF, "Register Value\n");
+ ret += scnprintf(buf + ret, RD_BUF - ret, "\nShim\n");
+
+ for (i = 0; i < links; i++) {
+ reg = SDW_SHIM_LCAP + i * 4;
+ ret += intel_sprintf(s, true, buf, ret, reg);
+ }
+
+ for (i = 0; i < links; i++) {
+ ret += scnprintf(buf + ret, RD_BUF - ret, "\nLink%d\n", i);
+ ret += intel_sprintf(s, false, buf, ret, SDW_SHIM_CTLSCAP(i));
+ ret += intel_sprintf(s, false, buf, ret, SDW_SHIM_CTLS0CM(i));
+ ret += intel_sprintf(s, false, buf, ret, SDW_SHIM_CTLS1CM(i));
+ ret += intel_sprintf(s, false, buf, ret, SDW_SHIM_CTLS2CM(i));
+ ret += intel_sprintf(s, false, buf, ret, SDW_SHIM_CTLS3CM(i));
+ ret += intel_sprintf(s, false, buf, ret, SDW_SHIM_PCMSCAP(i));
+
+ ret += scnprintf(buf + ret, RD_BUF - ret, "\n PCMSyCH
registers\n");
+
+ /*
+* the value 10 is the number of PDIs. We will need a
+* cleanup to remove hard-coded Intel configurations
+* from cadence_master.c
+*/
+ for (j = 0; j < 10; j++) {
+ ret += intel_sprintf(s, false, buf, ret,
+ SDW_SHIM_PCMSYCHM(i, j));
+ ret += intel_sprintf(s, false, buf, ret,
+ SDW_SHIM_PCMSYCHC(i, j));
+ }
+ ret += scnprintf(buf + ret, RD_BUF - ret, "\n PDMSCAP, IOCTL,
CTMCTL\n");
+
+ ret += intel_sprintf(s, false, buf, ret, SDW_SHIM_PDMSCAP(i));
+ ret += intel_sprintf(s, false, buf, ret, SDW_SHIM_IOCTL(i));
+ ret += intel_sprintf(s, false, buf, ret, SDW_SHIM_CTMCTL(i));
+ }
+
+ ret += scnprintf(buf + ret, RD_BUF - ret, "\nWake registers\n");
+ ret += intel_sprintf(s, false, buf, ret, SDW_SHIM_WAKEEN);
+ ret += intel_sprintf(s, false, buf, ret, SDW_SHIM_WAKESTS);
+
+ ret += scnprintf(buf + ret, RD_BUF - ret, "\nALH STRMzCFG\n");
+ for (i = 0; i < SDW_ALH_NUM_STREAMS; i++)
+ ret += intel_sprintf(a, true, buf, ret, SDW_ALH_STRMZCFG(i));
+
+ seq_printf(s_file, "%s", buf);
+ kfree(buf);
+
+ return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(intel_reg);
+
+static void intel_debugfs_init(struct sdw_intel *sdw)
+{
+ struct dentry *root = sdw->cdns.bus.debugfs;
+
+ if (!root)
+ return;
+
+ sdw->debugfs = debugfs_create_dir("intel-sdw", root);
+
+ debugfs_create_file("intel-registers", 0400, sdw->debugfs, sdw,
+ _reg_fops);
+
+
[PATCH v2 1/3] soundwire: add debugfs support
Add base debugfs mechanism for SoundWire bus by creating soundwire
root and master-N and slave-x hierarchy.
Also add SDW Slave SCP, DP0 and DP-N register debug file.
Registers not implemented will print as "XX"
Credits: this patch is based on an earlier internal contribution by
Vinod Koul, Sanyog Kale, Shreyas Nc and Hardik Shah.
Signed-off-by: Pierre-Louis Bossart
---
drivers/soundwire/Makefile| 4 +
drivers/soundwire/bus.c | 6 ++
drivers/soundwire/bus.h | 16
drivers/soundwire/bus_type.c | 3 +
drivers/soundwire/debugfs.c | 151 ++
drivers/soundwire/slave.c | 1 +
include/linux/soundwire/sdw.h | 8 ++
7 files changed, 189 insertions(+)
create mode 100644 drivers/soundwire/debugfs.c
diff --git a/drivers/soundwire/Makefile b/drivers/soundwire/Makefile
index 45b7e5001653..563894e5ecaf 100644
--- a/drivers/soundwire/Makefile
+++ b/drivers/soundwire/Makefile
@@ -7,6 +7,10 @@
soundwire-bus-objs := bus_type.o bus.o slave.o mipi_disco.o stream.o
obj-$(CONFIG_SOUNDWIRE) += soundwire-bus.o
+ifdef CONFIG_DEBUG_FS
+soundwire-bus-objs += debugfs.o
+endif
+
#Cadence Objs
soundwire-cadence-objs := cadence_master.o
obj-$(CONFIG_SOUNDWIRE_CADENCE) += soundwire-cadence.o
diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c
index 49f64b2115b9..348d391fc37c 100644
--- a/drivers/soundwire/bus.c
+++ b/drivers/soundwire/bus.c
@@ -49,6 +49,8 @@ int sdw_add_bus_master(struct sdw_bus *bus)
}
}
+ sdw_bus_debugfs_init(bus);
+
/*
* Device numbers in SoundWire are 0 through 15. Enumeration device
* number (0), Broadcast device number (15), Group numbers (12 and
@@ -109,6 +111,8 @@ static int sdw_delete_slave(struct device *dev, void *data)
struct sdw_slave *slave = dev_to_sdw_dev(dev);
struct sdw_bus *bus = slave->bus;
+ sdw_slave_debugfs_exit(slave);
+
mutex_lock(>bus_lock);
if (slave->dev_num) /* clear dev_num if assigned */
@@ -130,6 +134,8 @@ static int sdw_delete_slave(struct device *dev, void *data)
void sdw_delete_bus_master(struct sdw_bus *bus)
{
device_for_each_child(bus->dev, NULL, sdw_delete_slave);
+
+ sdw_bus_debugfs_exit(bus);
}
EXPORT_SYMBOL(sdw_delete_bus_master);
diff --git a/drivers/soundwire/bus.h b/drivers/soundwire/bus.h
index 3048ca153f22..0898c88ee887 100644
--- a/drivers/soundwire/bus.h
+++ b/drivers/soundwire/bus.h
@@ -18,6 +18,22 @@ static inline int sdw_acpi_find_slaves(struct sdw_bus *bus)
void sdw_extract_slave_id(struct sdw_bus *bus,
u64 addr, struct sdw_slave_id *id);
+#ifdef CONFIG_DEBUG_FS
+void sdw_bus_debugfs_init(struct sdw_bus *bus);
+void sdw_bus_debugfs_exit(struct sdw_bus *bus);
+void sdw_slave_debugfs_init(struct sdw_slave *slave);
+void sdw_slave_debugfs_exit(struct sdw_slave *slave);
+void sdw_debugfs_init(void);
+void sdw_debugfs_exit(void);
+#else
+static inline void sdw_bus_debugfs_init(struct sdw_bus *bus) {}
+static inline void sdw_bus_debugfs_exit(struct sdw_bus *bus) {}
+static inline void sdw_slave_debugfs_init(struct sdw_slave *slave) {}
+static inline void sdw_slave_debugfs_exit(struct sdw_slave *slave) {}
+static inline void sdw_debugfs_init(void) {}
+static inline void sdw_debugfs_exit(void) {}
+#endif
+
enum {
SDW_MSG_FLAG_READ = 0,
SDW_MSG_FLAG_WRITE,
diff --git a/drivers/soundwire/bus_type.c b/drivers/soundwire/bus_type.c
index 2655602f0cfb..4a465f55039f 100644
--- a/drivers/soundwire/bus_type.c
+++ b/drivers/soundwire/bus_type.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include "bus.h"
/**
* sdw_get_device_id - find the matching SoundWire device id
@@ -177,11 +178,13 @@ EXPORT_SYMBOL_GPL(sdw_unregister_driver);
static int __init sdw_bus_init(void)
{
+ sdw_debugfs_init();
return bus_register(_bus_type);
}
static void __exit sdw_bus_exit(void)
{
+ sdw_debugfs_exit();
bus_unregister(_bus_type);
}
diff --git a/drivers/soundwire/debugfs.c b/drivers/soundwire/debugfs.c
new file mode 100644
index ..fb1140e82b86
--- /dev/null
+++ b/drivers/soundwire/debugfs.c
@@ -0,0 +1,151 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright(c) 2017-2019 Intel Corporation.
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "bus.h"
+
+static struct dentry *sdw_debugfs_root;
+
+void sdw_bus_debugfs_init(struct sdw_bus *bus)
+{
+ char name[16];
+
+ if (!sdw_debugfs_root)
+ return;
+
+ /* create the debugfs master-N */
+ snprintf(name, sizeof(name), "master-%d", bus->link_id);
+ bus->debugfs = debugfs_create_dir(name, sdw_debugfs_root);
+}
+
+void sdw_bus_debugfs_exit(struct sdw_bus *bus)
+{
+ debugfs_remove_recursive(bus->debugfs);
+}
+
+#define RD_BUF (3 * PAGE_SIZE)
+
+static ssize_t sdw_sprintf(struct sdw_slave *slave,
+ char *buf, size_t pos, unsigned int reg)
+{
+
Re: [PATCH v12 03/18] kunit: test: add string_stream a std::stream like string builder
Quoting Brendan Higgins (2019-08-12 16:33:36)
> On Mon, Aug 12, 2019 at 03:55:19PM -0700, Stephen Boyd wrote:
> > Quoting Brendan Higgins (2019-08-12 11:24:06)
> > > +void string_stream_clear(struct string_stream *stream)
> > > +{
> > > + struct string_stream_fragment *frag_container,
> > > *frag_container_safe;
> > > +
> > > + spin_lock(>lock);
> > > + list_for_each_entry_safe(frag_container,
> > > +frag_container_safe,
> > > +>fragments,
> > > +node) {
> > > + list_del(_container->node);
> >
> > Shouldn't we free the allocation here? Otherwise, if some test is going
> > to add, add, clear, add, it's going to leak until the test is over?
>
> So basically this means I should add a kunit_kfree and
> kunit_resource_destroy (respective equivalents to devm_kfree, and
> devres_destroy) and use kunit_kfree here?
>
Yes, or drop the API entirely? Does anything need this functionality?
[PATCH v2 0/3] soundwire: debugfs support for 5.4
This patchset enables debugfs support and corrects all the feedback
provided on an earlier RFC ('soundwire: updates for 5.4')
There is one remaining hard-coded value in intel.c that will need to
be fixed in a follow-up patchset not specific to debugfs: we need to
remove hard-coded Intel-specific configurations from cadence_master.c
(PDI offsets, etc).
Changes since v1 (Feedback from GKH)
Handle debugfs in a more self-contained way (no dentry as return or parameter)
Used CONFIG_DEBUG_FS in structures and code to make it easier to
remove if need be.
No functional change for register dumps.
Changes since RFC (Feedback from GKH, Vinod, Guennadi, Cezary, Sanyog):
removed error checks
used DEFINE_SHOW_ATTRIBUTE and seq_file
fixed copyright dates
fixed SPDX license info to use GPL2.0 only
fixed Makefile to include debugfs only if CONFIG_DEBUG_FS is selected
used static inlines for fallback compilation
removed intermediate variables
removed hard-coded constants in loops (used registers offsets and
hardware capabilities)
squashed patch 3
Pierre-Louis Bossart (3):
soundwire: add debugfs support
soundwire: cadence_master: add debugfs register dump
soundwire: intel: add debugfs register dump
drivers/soundwire/Makefile | 4 +
drivers/soundwire/bus.c| 6 ++
drivers/soundwire/bus.h| 16 +++
drivers/soundwire/bus_type.c | 3 +
drivers/soundwire/cadence_master.c | 107
drivers/soundwire/cadence_master.h | 4 +
drivers/soundwire/debugfs.c| 151 +
drivers/soundwire/intel.c | 121 +++
drivers/soundwire/slave.c | 1 +
include/linux/soundwire/sdw.h | 8 ++
10 files changed, 421 insertions(+)
create mode 100644 drivers/soundwire/debugfs.c
--
2.20.1
Re: [PATCH] /dev/kmem : Debug preadv() progress.
Hi Tetsuo,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[cannot apply to v5.3-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Tetsuo-Handa/dev-kmem-Debug-preadv-progress/20190813-044328
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=sh
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>):
fs/read_write.c: In function 'do_loop_readv_writev':
>> fs/read_write.c:715:48: warning: format '%ld' expects argument of type 'long
>> int', but argument 2 has type 'size_t {aka unsigned int}' [-Wformat=]
printk("do_loop_readv_writev: iter->count=%ld iovec.iov_len=%ld\n",
iter->count, iovec.iov_len);
~~^
~~~
%d
>> fs/read_write.c:715:66: warning: format '%ld' expects argument of type 'long
>> int', but argument 3 has type '__kernel_size_t {aka unsigned int}'
>> [-Wformat=]
printk("do_loop_readv_writev: iter->count=%ld iovec.iov_len=%ld\n",
iter->count, iovec.iov_len);
~~^
~
%d
>> fs/read_write.c:725:39: warning: format '%ld' expects argument of type 'long
>> int', but argument 2 has type 'ssize_t {aka int}' [-Wformat=]
printk("do_loop_readv_writev: nr=%ld\n", nr);
~~^
%d
vim +715 fs/read_write.c
699
700 /* Do it by hand, with file-ops */
701 static ssize_t do_loop_readv_writev(struct file *filp, struct iov_iter
*iter,
702 loff_t *ppos, int type, rwf_t flags)
703 {
704 ssize_t ret = 0;
705
706 if (flags & ~RWF_HIPRI)
707 return -EOPNOTSUPP;
708
709 while (iov_iter_count(iter)) {
710 struct iovec iovec = iov_iter_iovec(iter);
711 ssize_t nr;
712
713 if (IS_ENABLED(CONFIG_DEBUG_AID_FOR_SYZBOT) &&
714 fatal_signal_pending(current))
> 715 printk("do_loop_readv_writev: iter->count=%ld
> iovec.iov_len=%ld\n", iter->count, iovec.iov_len);
716 if (type == READ) {
717 nr = filp->f_op->read(filp, iovec.iov_base,
718iovec.iov_len, ppos);
719 } else {
720 nr = filp->f_op->write(filp, iovec.iov_base,
721 iovec.iov_len, ppos);
722 }
723 if (IS_ENABLED(CONFIG_DEBUG_AID_FOR_SYZBOT) &&
724 fatal_signal_pending(current))
> 725 printk("do_loop_readv_writev: nr=%ld\n", nr);
726
727 if (nr < 0) {
728 if (!ret)
729 ret = nr;
730 break;
731 }
732 ret += nr;
733 if (nr != iovec.iov_len)
734 break;
735 iov_iter_advance(iter, nr);
736 }
737
738 return ret;
739 }
740
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH v6 5/8] KVM: VMX: Load Guest CET via VMCS when CET is enabled in Guest
On Thu, Jul 25, 2019 at 11:12:43AM +0800, Yang Weijiang wrote:
> "Load Guest CET state" bit controls whether Guest CET states
> will be loaded at Guest entry. Before doing that, KVM needs
> to check if CPU CET feature is enabled on host and available
> to Guest.
>
> Note: SHSTK and IBT features share one control MSR:
> MSR_IA32_{U,S}_CET, which means it's difficult to hide
> one feature from another in the case of SHSTK != IBT,
> after discussed in community, it's agreed to allow Guest
> control two features independently as it won't introduce
> security hole.
>
> Co-developed-by: Zhang Yi Z
> Signed-off-by: Zhang Yi Z
> Signed-off-by: Yang Weijiang
> ---
> arch/x86/kvm/vmx/vmx.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index ce5d1e45b7a5..fbf9c335cf7b 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -44,6 +44,7 @@
> #include
> #include
> #include
> +#include
>
> #include "capabilities.h"
> #include "cpuid.h"
> @@ -2923,6 +2924,18 @@ int vmx_set_cr4(struct kvm_vcpu *vcpu, unsigned long
> cr4)
> if (!nested_vmx_allowed(vcpu) || is_smm(vcpu))
> return 1;
> }
> + if (cpu_x86_cet_enabled() &&
It'd probably be better to check a KVM function here, e.g. a wrapper of
kvm_supported_xss(). I don't think it will ever matter, but it'd be nice
to have a single kill switch given the variety of different enable bits
for CET.
> + (guest_cpuid_has(vcpu, X86_FEATURE_SHSTK) ||
> + guest_cpuid_has(vcpu, X86_FEATURE_IBT))) {
> + if (cr4 & X86_CR4_CET)
> + vmcs_set_bits(VM_ENTRY_CONTROLS,
> + VM_ENTRY_LOAD_GUEST_CET_STATE);
> + else
> + vmcs_clear_bits(VM_ENTRY_CONTROLS,
> + VM_ENTRY_LOAD_GUEST_CET_STATE);
> + } else if (cr4 & X86_CR4_CET) {
> + return 1;
> + }
>
> if (to_vmx(vcpu)->nested.vmxon && !nested_cr4_valid(vcpu, cr4))
> return 1;
> --
> 2.17.2
>
Re: [PATCH v5 08/18] thermal: sun8i: support mod clocks
On Mon, Aug 12, 2019 at 4:46 PM Frank Lee wrote:
>
> HI Vasily,
>
> On Sat, Aug 10, 2019 at 2:17 PM Vasily Khoruzhick wrote:
> >
> > On Fri, Aug 9, 2019 at 10:31 PM Yangtao Li wrote:
> > >
> > > H3 has extra clock, so introduce something in ths_thermal_chip/ths_device
> > > and adds the process of the clock.
> > >
> > > This is pre-work for supprt it.
> > >
> > > Signed-off-by: Yangtao Li
> > > ---
> > > drivers/thermal/sun8i_thermal.c | 17 -
> > > 1 file changed, 16 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/thermal/sun8i_thermal.c
> > > b/drivers/thermal/sun8i_thermal.c
> > > index b934bc81eba7..6f4294c2aba7 100644
> > > --- a/drivers/thermal/sun8i_thermal.c
> > > +++ b/drivers/thermal/sun8i_thermal.c
> > > @@ -54,6 +54,7 @@ struct tsensor {
> > > };
> > >
> > > struct ths_thermal_chip {
> > > + boolhas_mod_clk;
> > > int sensor_num;
> > > int offset;
> > > int scale;
> > > @@ -69,6 +70,7 @@ struct ths_device {
> > > struct regmap *regmap;
> > > struct reset_control*reset;
> > > struct clk *bus_clk;
> > > + struct clk *mod_clk;
> > > struct tsensor sensor[MAX_SENSOR_NUM];
> > > };
> > >
> > > @@ -274,6 +276,12 @@ static int sun8i_ths_resource_init(struct ths_device
> > > *tmdev)
> > > if (IS_ERR(tmdev->bus_clk))
> > > return PTR_ERR(tmdev->bus_clk);
> > >
> > > + if (tmdev->chip->has_mod_clk) {
> > > + tmdev->mod_clk = devm_clk_get(>dev, "mod");
> > > + if (IS_ERR(tmdev->mod_clk))
> > > + return PTR_ERR(tmdev->mod_clk);
> > > + }
> > > +
> > > ret = reset_control_deassert(tmdev->reset);
> > > if (ret)
> > > return ret;
> > > @@ -282,12 +290,18 @@ static int sun8i_ths_resource_init(struct
> > > ths_device *tmdev)
> > > if (ret)
> > > goto assert_reset;
> > >
> > > - ret = sun50i_ths_calibrate(tmdev);
> > > + ret = clk_prepare_enable(tmdev->mod_clk);
> >
> > You have to set rate of modclk before enabling it since you can't rely
> > on whatever bootloader left for you.
> >
> > Also I found that parameters you're using for PC_TEMP_PERIOD, ACQ0 and
> > ACQ1 are too aggressive and may result in high interrupt rate to the
> > point when it may stall RCU. I changed driver a bit to use params from
> > Philipp Rossak's work (modclk set to 4MHz, PC_TEMP_PERIOD is 7, ACQ0
> > is 255, ACQ1 is 63) and it fixed RCU stalls for me, see [1] for
> > details.
>
> Why is the RCU stall happening, is it caused by a deadlock?
> Can you provide log information and your configuration?
> I am a bit curious.
It's not deadlock, I believe it just can't handle that many interrupts
when running at lowest CPU frequency. Even with Philipp's settings
there's ~20 interrupts a second from ths. I don't remember how many
interrupts were there with your settings.
Unfortunately there's nothing interesting in backtraces, I'm using
Pine64-LTS board.
> Thx,
> Yangtao
>
> >
> > [1]
> > https://github.com/anarsoul/linux-2.6/commit/46b8bb0fe2ccd1cd88fa9181a2ecbf79e8d513b2
> >
> >
> > > if (ret)
> > > goto bus_disable;
> > >
> > > + ret = sun50i_ths_calibrate(tmdev);
> > > + if (ret)
> > > + goto mod_disable;
> > > +
> > > return 0;
> > >
> > > +mod_disable:
> > > + clk_disable_unprepare(tmdev->mod_clk);
> > > bus_disable:
> > > clk_disable_unprepare(tmdev->bus_clk);
> > > assert_reset:
> > > @@ -395,6 +409,7 @@ static int sun8i_ths_remove(struct platform_device
> > > *pdev)
> > > {
> > > struct ths_device *tmdev = platform_get_drvdata(pdev);
> > >
> > > + clk_disable_unprepare(tmdev->mod_clk);
> > > clk_disable_unprepare(tmdev->bus_clk);
> > > reset_control_assert(tmdev->reset);
> > >
> > > --
> > > 2.17.1
> > >
> > >
> > > ___
> > > linux-arm-kernel mailing list
> > > linux-arm-ker...@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH v6 4/8] KVM: VMX: Pass through CET related MSRs to Guest
On Thu, Jul 25, 2019 at 11:12:42AM +0800, Yang Weijiang wrote:
> CET MSRs pass through Guest directly to enhance performance.
> CET runtime control settings are stored in MSR_IA32_{U,S}_CET,
> Shadow Stack Pointer(SSP) are stored in MSR_IA32_PL{0,1,2,3}_SSP,
> SSP table base address is stored in MSR_IA32_INT_SSP_TAB,
> these MSRs are defined in kernel and re-used here.
>
> MSR_IA32_U_CET and MSR_IA32_PL3_SSP are used for user mode protection,
> the contents could differ from process to process, therefore,
> kernel needs to save/restore them during context switch, it makes
> sense to pass through them so that the guest kernel can
> use xsaves/xrstors to operate them efficiently. Other MSRs are used
> for non-user mode protection. See CET spec for detailed info.
>
> The difference between CET VMCS state fields and xsave components is that,
> the former used for CET state storage during VMEnter/VMExit,
> whereas the latter used for state retention between Guest task/process
> switch.
>
> Co-developed-by: Zhang Yi Z
> Signed-off-by: Zhang Yi Z
> Signed-off-by: Yang Weijiang
> ---
> arch/x86/kvm/vmx/vmx.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index ce1d6fe21780..ce5d1e45b7a5 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -6952,6 +6952,7 @@ static void update_intel_pt_cfg(struct kvm_vcpu *vcpu)
> static void vmx_cpuid_update(struct kvm_vcpu *vcpu)
> {
> struct vcpu_vmx *vmx = to_vmx(vcpu);
> + unsigned long *msr_bitmap;
>
> if (cpu_has_secondary_exec_ctrls()) {
> vmx_compute_secondary_exec_control(vmx);
> @@ -6973,6 +6974,19 @@ static void vmx_cpuid_update(struct kvm_vcpu *vcpu)
> if (boot_cpu_has(X86_FEATURE_INTEL_PT) &&
> guest_cpuid_has(vcpu, X86_FEATURE_INTEL_PT))
> update_intel_pt_cfg(vcpu);
> +
> + msr_bitmap = vmx->vmcs01.msr_bitmap;
> +
> + if (guest_cpuid_has(vcpu, X86_FEATURE_SHSTK) ||
> + guest_cpuid_has(vcpu, X86_FEATURE_IBT)) {
These should be exposed to the guest if and only if they're supported in
the host and guest, i.e. kvm_supported_xss() needs to be checked. And,
again assuming USER and KERNEL can be virtualized independently, the logic
needs to account for exposting USER but KERNEL and vice versa.
> + vmx_disable_intercept_for_msr(msr_bitmap, MSR_IA32_U_CET,
> MSR_TYPE_RW);
> + vmx_disable_intercept_for_msr(msr_bitmap, MSR_IA32_S_CET,
> MSR_TYPE_RW);
> + vmx_disable_intercept_for_msr(msr_bitmap, MSR_IA32_INT_SSP_TAB,
> MSR_TYPE_RW);
> + vmx_disable_intercept_for_msr(msr_bitmap, MSR_IA32_PL0_SSP,
> MSR_TYPE_RW);
> + vmx_disable_intercept_for_msr(msr_bitmap, MSR_IA32_PL1_SSP,
> MSR_TYPE_RW);
> + vmx_disable_intercept_for_msr(msr_bitmap, MSR_IA32_PL2_SSP,
> MSR_TYPE_RW);
> + vmx_disable_intercept_for_msr(msr_bitmap, MSR_IA32_PL3_SSP,
> MSR_TYPE_RW);
The SSP MSRs should only be passed through if the guest has SHSTK, e.g.
KVM should intercept RDMSR and WRMSR to inject #GP in those cases.
> + }
> }
>
> static void vmx_set_supported_cpuid(u32 func, struct kvm_cpuid_entry2 *entry)
> --
> 2.17.2
>
Re: [PATCH 1/5] power: reset: Add UART-based MCU poweroff DT bindings
On Mon, Jul 22, 2019 at 09:53:01PM +0200, Evgeny Kolesnikov wrote: > This adds device tree bindings of the poweroff driver > for power managing micro controller units that are connected > to a board via the UART interface. > > Signed-off-by: Evgeny Kolesnikov > --- > .../bindings/power/reset/uart-poweroff.txt| 38 +++ > 1 file changed, 38 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/power/reset/uart-poweroff.txt > > diff --git a/Documentation/devicetree/bindings/power/reset/uart-poweroff.txt > b/Documentation/devicetree/bindings/power/reset/uart-poweroff.txt > new file mode 100644 > index ..86d036271b51 > --- /dev/null > +++ b/Documentation/devicetree/bindings/power/reset/uart-poweroff.txt > @@ -0,0 +1,38 @@ > +* UART-based PM MCU power off driver > + > +Some devices have a microcontroller controlling the main power > +supply. This microcontroller is connected to UART of the SoC. > +Sending a sequence of characters tells the MCU to turn > +the power off. IMO, you should have a node representing the specific microcontroller. Generic binding attempts like this generally don't work well because you need a never ending addition of properties to deal with h/w (and f/w in this case) differences. The properties you already have are evidence of this. Now, if you want a common driver, then that is a separate issue. You can have multiple, specific bindings map to a common driver (or not, it's up to the OS). Rob
Re: [RFC PATCH 2/2] mm/gup: introduce vaddr_pin_pages_remote()
On Sun, Aug 11, 2019 at 06:50:44PM -0700, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> This is the "vaddr_pin_pages" corresponding variant to
> get_user_pages_remote(), but with FOLL_PIN semantics: the implementation
> sets FOLL_PIN. That, in turn, means that the pages must ultimately be
> released by put_user_page*()--typically, via vaddr_unpin_pages*().
>
> Note that the put_user_page*() requirement won't be truly
> required until all of the call sites have been converted, and
> the tracking of pages is actually activated.
>
> Also introduce vaddr_unpin_pages(), in order to have a simpler
> call for the error handling cases.
>
> Use both of these new calls in the Infiniband drive, replacing
> get_user_pages_remote() and put_user_pages().
>
> Signed-off-by: John Hubbard
> ---
> drivers/infiniband/core/umem_odp.c | 15 +
> include/linux/mm.h | 7 +
> mm/gup.c | 50 ++
> 3 files changed, 66 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/infiniband/core/umem_odp.c
> b/drivers/infiniband/core/umem_odp.c
> index 53085896d718..fdff034a8a30 100644
> --- a/drivers/infiniband/core/umem_odp.c
> +++ b/drivers/infiniband/core/umem_odp.c
> @@ -534,7 +534,7 @@ static int ib_umem_odp_map_dma_single_page(
> }
>
> out:
> - put_user_page(page);
> + vaddr_unpin_pages(, 1, _odp->umem.vaddr_pin);
>
> if (remove_existing_mapping) {
> ib_umem_notifier_start_account(umem_odp);
> @@ -635,9 +635,10 @@ int ib_umem_odp_map_dma_pages(struct ib_umem_odp
> *umem_odp, u64 user_virt,
>* complex (and doesn't gain us much performance in most use
>* cases).
>*/
> - npages = get_user_pages_remote(owning_process, owning_mm,
> + npages = vaddr_pin_pages_remote(owning_process, owning_mm,
> user_virt, gup_num_pages,
> - flags, local_page_list, NULL, NULL);
> + flags, local_page_list, NULL, NULL,
> + _odp->umem.vaddr_pin);
Thinking about this part of the patch... is this pin really necessary? This
code is not doing a long term pin. The page just needs a reference while we
map it into the devices page tables. Once that is done we should get notifiers
if anything changes and we can adjust. right?
Ira
> up_read(_mm->mmap_sem);
>
> if (npages < 0) {
> @@ -657,7 +658,8 @@ int ib_umem_odp_map_dma_pages(struct ib_umem_odp
> *umem_odp, u64 user_virt,
> ret = -EFAULT;
> break;
> }
> - put_user_page(local_page_list[j]);
> + vaddr_unpin_pages(_page_list[j], 1,
> + _odp->umem.vaddr_pin);
> continue;
> }
>
> @@ -684,8 +686,9 @@ int ib_umem_odp_map_dma_pages(struct ib_umem_odp
> *umem_odp, u64 user_virt,
>* ib_umem_odp_map_dma_single_page().
>*/
> if (npages - (j + 1) > 0)
> - put_user_pages(_page_list[j+1],
> -npages - (j + 1));
> + vaddr_unpin_pages(_page_list[j+1],
> + npages - (j + 1),
> + _odp->umem.vaddr_pin);
> break;
> }
> }
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 61b616cd9243..2bd76ad8787e 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1606,6 +1606,13 @@ int __account_locked_vm(struct mm_struct *mm, unsigned
> long pages, bool inc,
> long vaddr_pin_pages(unsigned long addr, unsigned long nr_pages,
>unsigned int gup_flags, struct page **pages,
>struct vaddr_pin *vaddr_pin);
> +long vaddr_pin_pages_remote(struct task_struct *tsk, struct mm_struct *mm,
> + unsigned long start, unsigned long nr_pages,
> + unsigned int gup_flags, struct page **pages,
> + struct vm_area_struct **vmas, int *locked,
> + struct vaddr_pin *vaddr_pin);
> +void vaddr_unpin_pages(struct page **pages, unsigned long nr_pages,
> +struct vaddr_pin *vaddr_pin);
> void vaddr_unpin_pages_dirty_lock(struct page **pages, unsigned long
> nr_pages,
> struct vaddr_pin *vaddr_pin, bool make_dirty);
> bool mapping_inode_has_layout(struct vaddr_pin *vaddr_pin, struct page
> *page);
> diff --git a/mm/gup.c b/mm/gup.c
> index 85f09958fbdc..bb95adfaf9b6 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -2518,6 +2518,38 @@ long
