* [PATCH 1/2] spi-nor: intel-spi: Add support for Intel Elkhart Lake SPI serial flash
From: Mika Westerberg @ 2019-06-20 12:26 UTC (permalink / raw)
To: Marek Vasut, Tudor Ambarus
Cc: Vignesh Raghavendra, Richard Weinberger, linux-mtd, Miquel Raynal,
Brian Norris, Mika Westerberg, David Woodhouse
Intel Elkhart Lake has the same SPI serial flash controller as Ice Lake.
Add Elkhart Lake PCI ID to the driver list of supported devices.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
---
drivers/mtd/spi-nor/intel-spi-pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/spi-nor/intel-spi-pci.c b/drivers/mtd/spi-nor/intel-spi-pci.c
index bfbfc17ed6aa..578f0c74e536 100644
--- a/drivers/mtd/spi-nor/intel-spi-pci.c
+++ b/drivers/mtd/spi-nor/intel-spi-pci.c
@@ -67,6 +67,7 @@ static const struct pci_device_id intel_spi_pci_ids[] = {
{ PCI_VDEVICE(INTEL, 0x18e0), (unsigned long)&bxt_info },
{ PCI_VDEVICE(INTEL, 0x19e0), (unsigned long)&bxt_info },
{ PCI_VDEVICE(INTEL, 0x34a4), (unsigned long)&bxt_info },
+ { PCI_VDEVICE(INTEL, 0x4b24), (unsigned long)&bxt_info },
{ PCI_VDEVICE(INTEL, 0xa1a4), (unsigned long)&bxt_info },
{ PCI_VDEVICE(INTEL, 0xa224), (unsigned long)&bxt_info },
{ },
--
2.20.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related
* Re: [PATCH RFC 0/5] x86/KVM/svm: get rid of hardcoded instructions lengths
From: Vitaly Kuznetsov @ 2019-06-20 12:26 UTC (permalink / raw)
To: Paolo Bonzini, kvm
Cc: linux-kernel, Radim Krčmář, Joerg Roedel,
Jim Mattson
In-Reply-To: <3515d812-e5dd-4436-b73f-1d64bc93b079@redhat.com>
Paolo Bonzini <pbonzini@redhat.com> writes:
> On 20/06/19 13:02, Vitaly Kuznetsov wrote:
>>
>> P.S. If you'd like to test the series you'll have to have a CPU without
>> NRIP_SAVE feature or forcefully disable it, something like:
>>
>> index 8d4e50428b68..93c7eaad7915 100644
>> --- a/arch/x86/kernel/cpu/amd.c
>> +++ b/arch/x86/kernel/cpu/amd.c
>> @@ -922,6 +922,9 @@ static void init_amd(struct cpuinfo_x86 *c)
>> /* AMD CPUs don't reset SS attributes on SYSRET, Xen does. */
>> if (!cpu_has(c, X86_FEATURE_XENPV))
>> set_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS);
>> +
>> + /* No nrips */
>> + clear_cpu_cap(c, X86_FEATURE_NRIPS);
>> }
>>
>> #ifdef CONFIG_X86_32
>
> Let's add a module parameter instead. Patch sent (forgot to Cc you).
>
Sure, I thought I'm the only interested person around but if there's
hope for more this definitely sounds like a good idea)
--
Vitaly
^ permalink raw reply
* Re: [RFC PATCH] acpi/arm64: ignore 5.1 FADTs that are reported as 5.0
From: Lee Jones @ 2019-06-20 12:25 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Ard Biesheuvel, catalin.marinas, will.deacon, leif.lindholm,
linux-acpi, Sudeep Holla, linux-arm-kernel
In-Reply-To: <20190620094937.GB20872@e121166-lin.cambridge.arm.com>
On Thu, 20 Jun 2019, Lorenzo Pieralisi wrote:
> On Thu, Jun 20, 2019 at 08:57:32AM +0100, Lee Jones wrote:
> > On Wed, 19 Jun 2019, Sudeep Holla wrote:
> >
> > > On Wed, Jun 19, 2019 at 02:18:31PM +0200, Ard Biesheuvel wrote:
> > > > Some Qualcomm Snapdragon based laptops built to run Microsoft Windows
> > > > are clearly ACPI 5.1 based, given that that is the first ACPI revision
> > > > that supports ARM, and introduced the FADT 'arm_boot_flags' field,
> > > > which has a non-zero field on those systems.
> > > >
> > > > So in these cases, infer from the ARM boot flags that the FADT must be
> > > > 5.1 or later, and treat it as 5.1.
> > > >
> > >
> > > Makes sense and looks simple to me.
> > >
> > > Acked-by: Sudeep Holla <sudeep.holla@arm.com>
> >
> > Could we pleeeeease have this in for v5.3?
> >
> > We have available, consumer-level platforms that rely on this change.
>
> But we do not have the kernel infrastructure to support them so
> I am fine with it but urgency is questionable as far as I am
> concerned.
Yes we do. At least, we will in v5.3.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] spi/acpi: fix incorrect ACPI parent check
From: Ard Biesheuvel @ 2019-06-20 12:25 UTC (permalink / raw)
To: Jarkko Nikula
Cc: Mika Westerberg, linux-spi, Mark Brown, kbuild test robot,
Dan Carpenter, Andy Shevchenko, Masahisa Kojima,
Rafael J. Wysocki, ACPI Devel Maling List, Lukas Wunner
In-Reply-To: <efe4ab27-61eb-af89-f023-c0208253fc69@linux.intel.com>
On Thu, 20 Jun 2019 at 14:21, Jarkko Nikula
<jarkko.nikula@linux.intel.com> wrote:
>
> On 6/20/19 1:33 PM, Ard Biesheuvel wrote:
> > Jarkko, does this help?
> >
> > diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> > index 50d230b33c42..d072efdd65ba 100644
> > --- a/drivers/spi/spi.c
> > +++ b/drivers/spi/spi.c
> > @@ -1914,6 +1914,7 @@ static acpi_status
> > acpi_register_spi_device(struct spi_controller *ctlr,
> > return AE_OK;
> >
> > lookup.ctlr = ctlr;
> > + lookup.max_speed_hz = 0;
> > lookup.mode = 0;
> > lookup.bits_per_word = 0;
> > lookup.irq = -1;
> >
> Yes it does.
>
> I guess you have some cleanups or changes on top of your b5e3cf410b48
> ("spi/acpi: fix incorrect ACPI parent check") since for me change go
> around lines @@ -1981,6 +1981,7 @@ ?
>
Thanks,
This is my own tree with just my own 2 patches, not what's in
broonie's tree for spi-next
^ permalink raw reply
* Re: [RFC PATCH] acpi/arm64: ignore 5.1 FADTs that are reported as 5.0
From: Lee Jones @ 2019-06-20 12:25 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Sudeep Holla, Ard Biesheuvel, linux-arm-kernel, linux-acpi,
catalin.marinas, will.deacon, leif.lindholm
In-Reply-To: <20190620094937.GB20872@e121166-lin.cambridge.arm.com>
On Thu, 20 Jun 2019, Lorenzo Pieralisi wrote:
> On Thu, Jun 20, 2019 at 08:57:32AM +0100, Lee Jones wrote:
> > On Wed, 19 Jun 2019, Sudeep Holla wrote:
> >
> > > On Wed, Jun 19, 2019 at 02:18:31PM +0200, Ard Biesheuvel wrote:
> > > > Some Qualcomm Snapdragon based laptops built to run Microsoft Windows
> > > > are clearly ACPI 5.1 based, given that that is the first ACPI revision
> > > > that supports ARM, and introduced the FADT 'arm_boot_flags' field,
> > > > which has a non-zero field on those systems.
> > > >
> > > > So in these cases, infer from the ARM boot flags that the FADT must be
> > > > 5.1 or later, and treat it as 5.1.
> > > >
> > >
> > > Makes sense and looks simple to me.
> > >
> > > Acked-by: Sudeep Holla <sudeep.holla@arm.com>
> >
> > Could we pleeeeease have this in for v5.3?
> >
> > We have available, consumer-level platforms that rely on this change.
>
> But we do not have the kernel infrastructure to support them so
> I am fine with it but urgency is questionable as far as I am
> concerned.
Yes we do. At least, we will in v5.3.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [Ksummit-discuss] [media-submaintainers] [MAINTAINERS SUMMIT] Pull network and Patch Acceptance Consistency
From: Geert Uytterhoeven @ 2019-06-20 12:24 UTC (permalink / raw)
To: Mark Brown
Cc: ksummit, James Bottomley, media-submaintainers, kbuild,
Mauro Carvalho Chehab, Dan Carpenter
In-Reply-To: <20190619162359.GV5316@sirena.org.uk>
Hi Mark,
On Wed, Jun 19, 2019 at 6:24 PM Mark Brown <broonie@kernel.org> wrote:
> On Wed, Jun 19, 2019 at 08:46:19AM -0700, James Bottomley wrote:
> > On Wed, 2019-06-19 at 17:48 +0300, Laurent Pinchart wrote:
> > > It's not automatic though, if it depends on a Kconfig option that is
> > > disabled by default. The built bots can enable it, while users would
> > > ignore it. That being said, having it as a per-tree build bot option
> > > should work as well.
>
> > I really don't think well made build bots would enable this. The
> > problem with -Werror is it's single threaded on the first problem.
> > What a generic build bot wants to do is compile the entire tree and
> > then diff the output to find the additional warnings for everything. I
> > could see a tree specific build bot being more interested (until the
> > build fails on an unrelated subsystem).
>
> If you're doing build coverage you can always use make -k and still
> build everything but yeah.
While that does allow building most individual components, you will
fail to catch link errors and section mismatches.
Still better than nothing, of course....
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] KVM: VMX: Raise #GP when guest read/write forbidden IA32_XSS
From: Paolo Bonzini @ 2019-06-20 12:24 UTC (permalink / raw)
To: Wanpeng Li, linux-kernel, kvm; +Cc: Radim Krčmář, stable
In-Reply-To: <1561021202-13789-1-git-send-email-wanpengli@tencent.com>
On 20/06/19 11:00, Wanpeng Li wrote:
> From: Wanpeng Li <wanpengli@tencent.com>
>
> Raise #GP when guest read/write forbidden IA32_XSS.
>
> Fixes: 203000993de5 (kvm: vmx: add MSR logic for XSAVES)
> Reported-by: Xiaoyao Li <xiaoyao.li@linux.intel.com>
> Reported-by: Tao Xu <tao3.xu@intel.com>
> Cc: Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Radim Krčmář <rkrcmar@redhat.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: Wanpeng Li <wanpengli@tencent.com>
Queued, thanks.
Paolo
> ---
> arch/x86/kvm/vmx/vmx.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index b939a68..d174b62 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -1732,7 +1732,10 @@ static int vmx_get_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
> return vmx_get_vmx_msr(&vmx->nested.msrs, msr_info->index,
> &msr_info->data);
> case MSR_IA32_XSS:
> - if (!vmx_xsaves_supported())
> + if (!vmx_xsaves_supported() ||
> + (!msr_info->host_initiated &&
> + !(guest_cpuid_has(vcpu, X86_FEATURE_XSAVE) &&
> + guest_cpuid_has(vcpu, X86_FEATURE_XSAVES))))
> return 1;
> msr_info->data = vcpu->arch.ia32_xss;
> break;
> @@ -1962,7 +1965,10 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
> return 1;
> return vmx_set_vmx_msr(vcpu, msr_index, data);
> case MSR_IA32_XSS:
> - if (!vmx_xsaves_supported())
> + if (!vmx_xsaves_supported() ||
> + (!msr_info->host_initiated &&
> + !(guest_cpuid_has(vcpu, X86_FEATURE_XSAVE) &&
> + guest_cpuid_has(vcpu, X86_FEATURE_XSAVES))))
> return 1;
> /*
> * The only supported bit as of Skylake is bit 8, but
> -- 2.7.4
>
^ permalink raw reply
* Re: [Xen-devel] [PATCH 3/4] xen/link: Fold .data.read_mostly into .data
From: Julien Grall @ 2019-06-20 12:24 UTC (permalink / raw)
To: Andrew Cooper, Xen-devel
Cc: Stefano Stabellini, Wei Liu, Jan Beulich, Roger Pau Monné
In-Reply-To: <5cb62752-e2a1-444e-e3e4-98b25dcfb626@citrix.com>
Hi Andrew,
On 6/19/19 10:48 PM, Andrew Cooper wrote:
> On 19/06/2019 22:28, Julien Grall wrote:
>> On 6/19/19 9:11 PM, Andrew Cooper wrote:
>>> .data.read_mostly only needs separating from adjacent data by one
>>> cache line
>>> to be effective, and placing it adjacent to .data.page_aligned
>>> fulfills this
>>> requirement.
>>>
>>> For ARM, .ex_table appears to be a vestigial remnant. Nothing in the
>>> resulting build ever inspects or acts on the contents of the table.
>>> The arm32
>>> build does however have some assembly routines which fill .ex_table.
>>>
>>> Drop all of ARM's .ex_table infrastructure, to reduce the size of the
>>> compiled
>>> binary, and avoid giving the illusion of exception handling working.
>>
>> I am not in favor of this change. assembler.h is meant to be a
>> verbatim copy of the Linux counterpart.
>
> What alternative do you propose then, because having infrastructure that
> gives the illusion of exception recovery working is a far worse option
> than deviating from Linux.
I learnt the hard way before that trying to adapt a Linux file to Xen
makes very difficult to keep track what's going on.
So my preference here is to just disable the section if they exists.
>>
>> [...]
>>
>>> diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
>>> index 2b44e5d..3dc5117 100644
>>> --- a/xen/arch/arm/xen.lds.S
>>> +++ b/xen/arch/arm/xen.lds.S
>>> @@ -94,27 +94,13 @@ SECTIONS
>>> _erodata = .; /* End of read-only data */
>>> .data : { /* Data */
>>> + *(.data.read_mostly)
>>
>> Before, .data.read_mostly was SMP_CACHE_BYTES aligned. Now, it seems
>> there are no alignment.
>>
>> This may end up to have _erodata and .data.read_mostly to be part of
>> the same page. As Arm enforce read-only, you may crash on access to
>> .data.read_mostly.
>>
>> So I think you have
>> . = ALIGN(PAGE_SIZE)
>> *(.data.read_mostly)
>> .align(SMP_CACHE_BYTES).
>
> These both need to be PAGE_SIZE, or .data.page_aligned can end up having
> problems.
Good point, I missed the .data.page_aligned.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH V3 1/5] perf: Disable extended registers for non-support PMUs
From: Peter Zijlstra @ 2019-06-20 12:24 UTC (permalink / raw)
To: kan.liang
Cc: mingo, acme, vincent.weaver, linux-kernel, alexander.shishkin, ak,
jolsa, eranian
In-Reply-To: <1559081314-9714-1-git-send-email-kan.liang@linux.intel.com>
On Tue, May 28, 2019 at 03:08:30PM -0700, kan.liang@linux.intel.com wrote:
> From: Kan Liang <kan.liang@linux.intel.com>
Ok, have them now.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v17 02/10] ACPI: add some GHES structures and macros definition
From: Igor Mammedov @ 2019-06-20 12:10 UTC (permalink / raw)
To: Dongjiu Geng
Cc: peter.maydell, ehabkost, kvm, mst, mtosatti, qemu-devel, linuxarm,
shannon.zhaosl, zhengxiang9, qemu-arm, james.morse, xuwei5,
jonathan.cameron, pbonzini, lersek, rth
In-Reply-To: <1557832703-42620-3-git-send-email-gengdongjiu@huawei.com>
On Tue, 14 May 2019 04:18:15 -0700
Dongjiu Geng <gengdongjiu@huawei.com> wrote:
> Add Generic Error Status Block structures and some macros
> definitions, which is referred to the ACPI 4.0 or ACPI 6.2. The
> HEST table generation and CPER record will use them.
>
> Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
> ---
> include/hw/acpi/acpi-defs.h | 52 +++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 52 insertions(+)
>
> diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h
> index f9aa4bd..d1996fb 100644
> --- a/include/hw/acpi/acpi-defs.h
> +++ b/include/hw/acpi/acpi-defs.h
> @@ -224,6 +224,25 @@ typedef struct AcpiMultipleApicTable AcpiMultipleApicTable;
> #define ACPI_APIC_RESERVED 16 /* 16 and greater are reserved */
>
> /*
> + * Values for Hardware Error Notification Type field
> + */
> +enum AcpiHestNotifyType {
> + ACPI_HEST_NOTIFY_POLLED = 0,
> + ACPI_HEST_NOTIFY_EXTERNAL = 1,
> + ACPI_HEST_NOTIFY_LOCAL = 2,
> + ACPI_HEST_NOTIFY_SCI = 3,
> + ACPI_HEST_NOTIFY_NMI = 4,
> + ACPI_HEST_NOTIFY_CMCI = 5, /* ACPI 5.0: 18.3.2.7, Table 18-290 */
> + ACPI_HEST_NOTIFY_MCE = 6, /* ACPI 5.0: 18.3.2.7, Table 18-290 */
> + ACPI_HEST_NOTIFY_GPIO = 7, /* ACPI 6.0: 18.3.2.7, Table 18-332 */
> + ACPI_HEST_NOTIFY_SEA = 8, /* ACPI 6.1: 18.3.2.9, Table 18-345 */
> + ACPI_HEST_NOTIFY_SEI = 9, /* ACPI 6.1: 18.3.2.9, Table 18-345 */
> + ACPI_HEST_NOTIFY_GSIV = 10, /* ACPI 6.1: 18.3.2.9, Table 18-345 */
> + ACPI_HEST_NOTIFY_SDEI = 11, /* ACPI 6.2: 18.3.2.9, Table 18-383 */
> + ACPI_HEST_NOTIFY_RESERVED = 12 /* 12 and greater are reserved */
> +};
> +
> +/*
> * MADT sub-structures (Follow MULTIPLE_APIC_DESCRIPTION_TABLE)
> */
> #define ACPI_SUB_HEADER_DEF /* Common ACPI sub-structure header */\
> @@ -400,6 +419,39 @@ struct AcpiSystemResourceAffinityTable {
> } QEMU_PACKED;
> typedef struct AcpiSystemResourceAffinityTable AcpiSystemResourceAffinityTable;
>
> +/*
> + * Generic Error Status Block
> + */
> +struct AcpiGenericErrorStatus {
> + /* It is a bitmask composed of ACPI_GEBS_xxx macros */
> + uint32_t block_status;
> + uint32_t raw_data_offset;
> + uint32_t raw_data_length;
> + uint32_t data_length;
> + uint32_t error_severity;
> +} QEMU_PACKED;
> +typedef struct AcpiGenericErrorStatus AcpiGenericErrorStatus;
there shouldn't be packed structures,
is it a leftover from previous version?
> +
> +/*
> + * Masks for block_status flags above
> + */
> +#define ACPI_GEBS_UNCORRECTABLE 1
> +
> +/*
> + * Values for error_severity field above
> + */
> +enum AcpiGenericErrorSeverity {
> + ACPI_CPER_SEV_RECOVERABLE,
> + ACPI_CPER_SEV_FATAL,
> + ACPI_CPER_SEV_CORRECTED,
> + ACPI_CPER_SEV_NONE,
> +};
> +
> +/*
> + * Generic Hardware Error Source version 2
> + */
> +#define ACPI_HEST_SOURCE_GENERIC_ERROR_V2 10
> +
> #define ACPI_SRAT_PROCESSOR_APIC 0
> #define ACPI_SRAT_MEMORY 1
> #define ACPI_SRAT_PROCESSOR_x2APIC 2
^ permalink raw reply
* [PATCH v2 net-next 1/2] net: ethernet: mediatek: Add MT7621 TRGMII mode support
From: René van Dorst @ 2019-06-20 12:21 UTC (permalink / raw)
To: frank-w, sean.wang, f.fainelli, davem, matthias.bgg, andrew,
vivien.didelot
Cc: netdev, john, linux-mediatek, linux-mips, René van Dorst
In-Reply-To: <20190620122155.32078-1-opensource@vdorst.com>
MT7621 SOC also supports TRGMII.
TRGMII speed is 1200MBit.
Signed-off-by: René van Dorst <opensource@vdorst.com>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 38 ++++++++++++++++++---
drivers/net/ethernet/mediatek/mtk_eth_soc.h | 11 ++++++
2 files changed, 45 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index f27efe4110cc..066712f2e985 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -134,6 +134,28 @@ static int mtk_mdio_read(struct mii_bus *bus, int phy_addr, int phy_reg)
return _mtk_mdio_read(eth, phy_addr, phy_reg);
}
+static int mt7621_gmac0_rgmii_adjust(struct mtk_eth *eth,
+ phy_interface_t interface)
+{
+ u32 val;
+
+ /* Check DDR memory type. Currently DDR2 is not supported. */
+ regmap_read(eth->ethsys, ETHSYS_SYSCFG, &val);
+ if (val & SYSCFG_DRAM_TYPE_DDR2) {
+ dev_err(eth->dev,
+ "TRGMII mode with DDR2 memory is not supported!\n");
+ return -EOPNOTSUPP;
+ }
+
+ val = (interface == PHY_INTERFACE_MODE_TRGMII) ?
+ ETHSYS_TRGMII_MT7621_DDR_PLL : 0;
+
+ regmap_update_bits(eth->ethsys, ETHSYS_CLKCFG0,
+ ETHSYS_TRGMII_MT7621_MASK, val);
+
+ return 0;
+}
+
static void mtk_gmac0_rgmii_adjust(struct mtk_eth *eth, int speed)
{
u32 val;
@@ -183,9 +205,17 @@ static void mtk_phy_link_adjust(struct net_device *dev)
break;
}
- if (MTK_HAS_CAPS(mac->hw->soc->caps, MTK_GMAC1_TRGMII) &&
- !mac->id && !mac->trgmii)
- mtk_gmac0_rgmii_adjust(mac->hw, dev->phydev->speed);
+ if (MTK_HAS_CAPS(mac->hw->soc->caps, MTK_GMAC1_TRGMII) && !mac->id) {
+ if (MTK_HAS_CAPS(mac->hw->soc->caps, MTK_TRGMII_MT7621_CLK)) {
+ if (mt7621_gmac0_rgmii_adjust(mac->hw,
+ dev->phydev->interface))
+ return;
+ } else {
+ if (!mac->trgmii)
+ mtk_gmac0_rgmii_adjust(mac->hw,
+ dev->phydev->speed);
+ }
+ }
if (dev->phydev->link)
mcr |= MAC_MCR_FORCE_LINK;
@@ -2607,7 +2637,7 @@ static const struct mtk_soc_data mt2701_data = {
};
static const struct mtk_soc_data mt7621_data = {
- .caps = MTK_SHARED_INT,
+ .caps = MT7621_CAPS,
.required_clks = MT7621_CLKS_BITMAP,
.required_pctl = false,
};
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 85e3144f1af5..876ce6798709 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -363,6 +363,10 @@
#define MT7622_ETH 7622
#define MT7621_ETH 7621
+/* ethernet system control register */
+#define ETHSYS_SYSCFG 0x10
+#define SYSCFG_DRAM_TYPE_DDR2 BIT(4)
+
/* ethernet subsystem config register */
#define ETHSYS_SYSCFG0 0x14
#define SYSCFG0_GE_MASK 0x3
@@ -377,6 +381,9 @@
/* ethernet subsystem clock register */
#define ETHSYS_CLKCFG0 0x2c
#define ETHSYS_TRGMII_CLK_SEL362_5 BIT(11)
+#define ETHSYS_TRGMII_MT7621_MASK (BIT(5) | BIT(6))
+#define ETHSYS_TRGMII_MT7621_APLL BIT(6)
+#define ETHSYS_TRGMII_MT7621_DDR_PLL BIT(5)
/* ethernet reset control register */
#define ETHSYS_RSTCTRL 0x34
@@ -616,6 +623,7 @@ enum mtk_eth_path {
#define MTK_SHARED_SGMII BIT(7)
#define MTK_HWLRO BIT(8)
#define MTK_SHARED_INT BIT(9)
+#define MTK_TRGMII_MT7621_CLK BIT(10)
/* Supported path present on SoCs */
#define MTK_PATH_BIT(x) BIT((x) + 10)
@@ -667,6 +675,9 @@ enum mtk_eth_path {
#define MTK_HAS_CAPS(caps, _x) (((caps) & (_x)) == (_x))
+#define MT7621_CAPS (MTK_GMAC1_RGMII | MTK_GMAC1_TRGMII | \
+ MTK_GMAC2_RGMII | MTK_SHARED_INT | MTK_TRGMII_MT7621_CLK)
+
#define MT7622_CAPS (MTK_GMAC1_RGMII | MTK_GMAC1_SGMII | MTK_GMAC2_RGMII | \
MTK_GMAC2_SGMII | MTK_GDM1_ESW | \
MTK_MUX_GDM1_TO_GMAC1_ESW | \
--
2.20.1
^ permalink raw reply related
* [PATCH v2 net-next 2/2] net: dsa: mt7530: Add MT7621 TRGMII mode support
From: René van Dorst @ 2019-06-20 12:21 UTC (permalink / raw)
To: frank-w, sean.wang, f.fainelli, davem, matthias.bgg, andrew,
vivien.didelot
Cc: netdev, john, linux-mediatek, linux-mips, René van Dorst
In-Reply-To: <20190620122155.32078-1-opensource@vdorst.com>
This patch add support TRGMII mode for MT7621 internal MT7530 switch.
MT7621 TRGMII has only one fix speed mode of 1200MBit.
Also adding support for mt7530 25MHz and 40MHz crystal clocksource.
Values are based on Banana Pi R2 bsp [1].
Don't change MT7623 registers on a MT7621 device.
[1] https://github.com/BPI-SINOVOIP/BPI-R2-bsp/blob/master/linux-mt/drivers/net/ethernet/mediatek/gsw_mt7623.c#L769
Signed-off-by: René van Dorst <opensource@vdorst.com>
---
drivers/net/dsa/mt7530.c | 46 +++++++++++++++++++++++++++++++---------
drivers/net/dsa/mt7530.h | 4 ++++
2 files changed, 40 insertions(+), 10 deletions(-)
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index c7d352da5448..3181e95586d6 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -428,24 +428,48 @@ static int
mt7530_pad_clk_setup(struct dsa_switch *ds, int mode)
{
struct mt7530_priv *priv = ds->priv;
- u32 ncpo1, ssc_delta, trgint, i;
+ u32 ncpo1, ssc_delta, trgint, i, xtal;
+
+ xtal = mt7530_read(priv, MT7530_MHWTRAP) & HWTRAP_XTAL_MASK;
+
+ if (xtal == HWTRAP_XTAL_20MHZ) {
+ dev_err(priv->dev,
+ "%s: MT7530 with a 20MHz XTAL is not supported!\n",
+ __func__);
+ return -EINVAL;
+ }
switch (mode) {
case PHY_INTERFACE_MODE_RGMII:
trgint = 0;
+ /* PLL frequency: 125MHz */
ncpo1 = 0x0c80;
- ssc_delta = 0x87;
break;
case PHY_INTERFACE_MODE_TRGMII:
trgint = 1;
- ncpo1 = 0x1400;
- ssc_delta = 0x57;
+ if (priv->id == ID_MT7621) {
+ /* PLL frequency: 150MHz: 1.2GBit */
+ if (xtal == HWTRAP_XTAL_40MHZ)
+ ncpo1 = 0x0780;
+ if (xtal == HWTRAP_XTAL_25MHZ)
+ ncpo1 = 0x0a00;
+ } else { /* PLL frequency: 250MHz: 2.0Gbit */
+ if (xtal == HWTRAP_XTAL_40MHZ)
+ ncpo1 = 0x0c80;
+ if (xtal == HWTRAP_XTAL_25MHZ)
+ ncpo1 = 0x1400;
+ }
break;
default:
dev_err(priv->dev, "xMII mode %d not supported\n", mode);
return -EINVAL;
}
+ if (xtal == HWTRAP_XTAL_25MHZ)
+ ssc_delta = 0x57;
+ else
+ ssc_delta = 0x87;
+
mt7530_rmw(priv, MT7530_P6ECR, P6_INTF_MODE_MASK,
P6_INTF_MODE(trgint));
@@ -507,7 +531,9 @@ mt7530_pad_clk_setup(struct dsa_switch *ds, int mode)
mt7530_rmw(priv, MT7530_TRGMII_RD(i),
RD_TAP_MASK, RD_TAP(16));
else
- mt7623_trgmii_set(priv, GSW_INTF_MODE, INTF_MODE_TRGMII);
+ if (priv->id != ID_MT7621)
+ mt7623_trgmii_set(priv, GSW_INTF_MODE,
+ INTF_MODE_TRGMII);
return 0;
}
@@ -613,13 +639,13 @@ static void mt7530_adjust_link(struct dsa_switch *ds, int port,
struct mt7530_priv *priv = ds->priv;
if (phy_is_pseudo_fixed_link(phydev)) {
- if (priv->id == ID_MT7530) {
- dev_dbg(priv->dev, "phy-mode for master device = %x\n",
- phydev->interface);
+ dev_dbg(priv->dev, "phy-mode for master device = %x\n",
+ phydev->interface);
- /* Setup TX circuit incluing relevant PAD and driving */
- mt7530_pad_clk_setup(ds, phydev->interface);
+ /* Setup TX circuit incluing relevant PAD and driving */
+ mt7530_pad_clk_setup(ds, phydev->interface);
+ if (priv->id == ID_MT7530) {
/* Setup RX circuit, relevant PAD and driving on the
* host which must be placed after the setup on the
* device side is all finished.
diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h
index 4331429969fa..bfac90f48102 100644
--- a/drivers/net/dsa/mt7530.h
+++ b/drivers/net/dsa/mt7530.h
@@ -244,6 +244,10 @@ enum mt7530_vlan_port_attr {
/* Register for hw trap status */
#define MT7530_HWTRAP 0x7800
+#define HWTRAP_XTAL_MASK (BIT(10) | BIT(9))
+#define HWTRAP_XTAL_25MHZ (BIT(10) | BIT(9))
+#define HWTRAP_XTAL_40MHZ (BIT(10))
+#define HWTRAP_XTAL_20MHZ (BIT(9))
/* Register for hw trap modification */
#define MT7530_MHWTRAP 0x7804
--
2.20.1
^ permalink raw reply related
* [PATCH v2 net-next 0/2] net: mediatek: Add MT7621 TRGMII mode support
From: René van Dorst @ 2019-06-20 12:21 UTC (permalink / raw)
To: frank-w, sean.wang, f.fainelli, davem, matthias.bgg, andrew,
vivien.didelot
Cc: netdev, john, linux-mediatek, linux-mips, René van Dorst
Like many other mediatek SOCs, the MT7621 SOC and the internal MT7530
switch both supports TRGMII mode. MT7621 TRGMII speed is fix 1200MBit.
v1->v2:
- Fix breakage on non MT7621 SOC
- Support 25MHz and 40MHz XTAL as MT7530 clocksource
René van Dorst (2):
net: ethernet: mediatek: Add MT7621 TRGMII mode support
net: dsa: mt7530: Add MT7621 TRGMII mode support
drivers/net/dsa/mt7530.c | 46 ++++++++++++++++-----
drivers/net/dsa/mt7530.h | 4 ++
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 38 +++++++++++++++--
drivers/net/ethernet/mediatek/mtk_eth_soc.h | 11 +++++
4 files changed, 85 insertions(+), 14 deletions(-)
--
2.20.1
^ permalink raw reply
* [Qemu-arm] [PATCH v5 0/3] fw_cfg: Add edk2_add_host_crypto_policy()
From: Philippe Mathieu-Daudé @ 2019-06-20 12:19 UTC (permalink / raw)
To: Laszlo Ersek, qemu-devel
Cc: Peter Maydell, Andrew Jones, Eduardo Habkost, Michael S. Tsirkin,
qemu-arm, Paolo Bonzini, Philippe Mathieu-Daudé
Hi,
This series add edk2_add_host_crypto_policy() and the Edk2Crypto object.
The Edk2Crypto object is used to hold configuration values specific
to EDK2.
So far only the 'https' policy is supported.
A usercase example is the 'HTTPS Boof' feature of OVMF [*].
Usage example:
$ qemu-system-x86_64 \
--object edk2_crypto,id=https,\
ciphers=/etc/crypto-policies/back-ends/openssl.config,\
cacerts=/etc/pki/ca-trust/extracted/edk2/cacerts.bin
(On Fedora these files are provided by the ca-certificates and
crypto-policies packages).
[*]: https://github.com/tianocore/edk2/blob/master/OvmfPkg/README
Since v4:
- Addressed Laszlo comments (see patch#1 description)
Since v3:
- Addressed Markus' comments (do not care about heap)
Since v2:
- Split of
Since v1:
- Addressed Michael and Laszlo comments.
Please review,
Phil.
$ git backport-diff -u fw_cfg_edk2_crypto_policies-v3
Key:
[####] : number of functional differences between upstream/downstream patch
The flags [FC] indicate (F)unctional and (C)ontextual differences, respectively
001/3:[0164] [FC] 'hw/firmware: Add Edk2Crypto and edk2_add_host_crypto_policy()'
002/3:[----] [--] 'hw/i386: Use edk2_add_host_crypto_policy()'
003/3:[----] [--] 'hw/arm/virt: Use edk2_add_host_crypto_policy()'
v4: https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg04300.html
v3: https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg02965.html
v2: https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg02522.html
v1: https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg01598.html
Philippe Mathieu-Daudé (3):
hw/firmware: Add Edk2Crypto and edk2_add_host_crypto_policy()
hw/i386: Use edk2_add_host_crypto_policy()
hw/arm/virt: Use edk2_add_host_crypto_policy()
MAINTAINERS | 2 +
hw/Makefile.objs | 1 +
hw/arm/virt.c | 7 +
hw/firmware/Makefile.objs | 1 +
hw/firmware/uefi_edk2_crypto_policies.c | 209 ++++++++++++++++++++++++
hw/i386/pc.c | 7 +
include/hw/firmware/uefi_edk2.h | 30 ++++
7 files changed, 257 insertions(+)
create mode 100644 hw/firmware/Makefile.objs
create mode 100644 hw/firmware/uefi_edk2_crypto_policies.c
create mode 100644 include/hw/firmware/uefi_edk2.h
--
2.20.1
^ permalink raw reply
* Re: [PATCH v2 0/3] ceph: don't NULL terminate virtual xattr values
From: Geert Uytterhoeven @ 2019-06-20 12:22 UTC (permalink / raw)
To: Jeff Layton
Cc: Andy Shevchenko, Linux Kernel Mailing List, ceph-devel,
Ilya Dryomov, Zheng Yan, sage, agruenba, Joe Perches, Petr Mladek,
Steven Rostedt, Geert Uytterhoeven
In-Reply-To: <7c12abe8a7e6cd3cfe9129a1e74d9c788ff2f1a9.camel@kernel.org>
Hi Jeff,
On Thu, Jun 20, 2019 at 1:41 PM Jeff Layton <jlayton@kernel.org> wrote:
> On Thu, 2019-06-20 at 13:24 +0300, Andy Shevchenko wrote:
> > On Wed, Jun 19, 2019 at 12:45:25PM -0400, Jeff Layton wrote:
> > > v2: drop bogus EXPORT_SYMBOL of static function
> > >
> > > The only real difference between this set and the one I sent originally
> > > is the removal of a spurious EXPORT_SYMBOL in the snprintf patch.
> > >
> > > I'm mostly sending this with a wider cc list in an effort to get a
> > > review from the maintainers of the printf code. Basically ceph needs a
> > > snprintf variant that does not NULL terminate in order to handle its
> > > virtual xattrs.
> > >
> > > Joe Perches had expressed some concerns about stack usage in vsnprintf
> > > with this, but I'm not sure I really understand the basis of that
> > > concern. If it is problematic, then I could use suggestions as to how
> > > best to fix that up.
> >
> > It might be problematic, since vsnprintf() can be called recursively.
> >
>
> So the concern is that we'd have extra call/ret activity in the stack?
> That seems like a lot of hand-wringing over very little, but ok if so.
>
> > > ----------------------------8<-----------------------------
> > >
> > > kcephfs has several "virtual" xattrs that return strings that are
> > > currently populated using snprintf(), which always NULL terminates the
> > > string.
> > >
> > > This leads to the string being truncated when we use a buffer length
> > > acquired by calling getxattr with a 0 size first. The last character
> > > of the string ends up being clobbered by the termination.
> >
> > So, then don't use snprintf() for this, simple memcpy() designed for that kind
> > of things.
> >
>
> memcpy from what? For many of these xattrs, we need to format integer
> data into strings. I could roll my own routine to do this formatting,
> but that's sort of what sprintf and its variants are for and I'd rather
> not reimplement all of it from scratch.
snprintf() to a temporary buffer, and memcpy() to the final destination.
These are all fairly small buffers (most are single integer values),
so the overhead should be minimal, right?
In fact the two largest strings are already formatted in a temporary
buffer, so there is no reason ceph_vxattrcb_layout() cannot just use
snprintf() now.
Or perhaps this can use the existing seq_*() interface in some form?
BTW, while at it, please get rid of the casts when calling snprintf(), and
use the correct format specifiers instead.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 16/16] mm: pass get_user_pages_fast iterator arguments in a structure
From: Nicholas Piggin @ 2019-06-20 12:18 UTC (permalink / raw)
To: Linus Torvalds
Cc: Rich Felker, Yoshinori Sato, Linux-sh list, James Hogan,
the arch/x86 maintainers, Linux List Kernel Mailing,
David S. Miller, Linux-MM, Khalid Aziz, Paul Burton,
Andrey Konovalov, sparclinux, Paul Mackerras, linux-mips,
linuxppc-dev, Christoph Hellwig
In-Reply-To: <CAHk-=wjSo+TzkvYnAqrp=eFgzzc058DhSMTPr4-2quZTbGLfnw@mail.gmail.com>
Linus Torvalds's on June 12, 2019 11:09 am:
> On Tue, Jun 11, 2019 at 2:55 PM Nicholas Piggin <npiggin@gmail.com> wrote:
>>
>> What does this do for performance? I've found this pattern can be
>> bad for store aliasing detection.
>
> I wouldn't expect it to be noticeable, and the lack of argument
> reloading etc should make up for it. Plus inlining makes it a
> non-issue when that happens.
Maybe in isolation. Just seems like a strange pattern to sprinkle
around randomly, I wouldn't like it to proliferate.
I understand in some cases where a big set of parameters or
basically state gets sent around through a lot of interfaces.
Within one file to make lines a bit shorter or save a few bytes
isn't such a strong case.
>
> But I guess we could also at least look at using "restrict", if that
> ends up helping. Unlike the completely bogus type-based aliasing rules
> (that we disable because I think the C people were on some bad bad
> drugs when they came up with them), restricted pointers are a real
> thing that makes sense.
>
> That said, we haven't traditionally used it, and I don't know how much
> it helps gcc. Maybe gcc ignores it entirely? S
Ahh, it's not compiler store alias analysis I'm talking about, but
processor (but you raise an interesting point about compiler too,
would be nice if we could improve that in general).
The processor aliasing problem happens because the struct will
be initialised with stores using one base register (e.g., stack
register), and then same memory is loaded using a different
register (e.g., parameter register). Processor's static heuristics
for determining a load doesn't alias with an earlier store doesn't
do so well in that case.
Just about everywhere I've seen those kind of misspeculation and
flushes in the kernel has been this pattern, so I'm wary of it in
performance critical code.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH] spi/acpi: fix incorrect ACPI parent check
From: Jarkko Nikula @ 2019-06-20 12:21 UTC (permalink / raw)
To: Ard Biesheuvel, Mika Westerberg
Cc: linux-spi, Mark Brown, kbuild test robot, Dan Carpenter,
Andy Shevchenko, Masahisa Kojima, Rafael J. Wysocki,
ACPI Devel Maling List, Lukas Wunner
In-Reply-To: <CAKv+Gu82UcBcj_cjfEDpEyQyGzPvtGnVJN22hCroHKyudhk=8w@mail.gmail.com>
On 6/20/19 1:33 PM, Ard Biesheuvel wrote:
> Jarkko, does this help?
>
> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> index 50d230b33c42..d072efdd65ba 100644
> --- a/drivers/spi/spi.c
> +++ b/drivers/spi/spi.c
> @@ -1914,6 +1914,7 @@ static acpi_status
> acpi_register_spi_device(struct spi_controller *ctlr,
> return AE_OK;
>
> lookup.ctlr = ctlr;
> + lookup.max_speed_hz = 0;
> lookup.mode = 0;
> lookup.bits_per_word = 0;
> lookup.irq = -1;
>
Yes it does.
I guess you have some cleanups or changes on top of your b5e3cf410b48
("spi/acpi: fix incorrect ACPI parent check") since for me change go
around lines @@ -1981,6 +1981,7 @@ ?
--
Jarkko
^ permalink raw reply
* Re: [PATCH 5/5] usb: xhci: allow multiple firmware versions
From: Greg Kroah-Hartman @ 2019-06-20 12:20 UTC (permalink / raw)
To: Vinod Koul
Cc: Mathias Nyman, linux-arm-msm, Bjorn Andersson, linux-usb,
linux-kernel, Yoshihiro Shimoda, Christian Lamparter
In-Reply-To: <20190620102154.20805-6-vkoul@kernel.org>
On Thu, Jun 20, 2019 at 03:51:54PM +0530, Vinod Koul wrote:
> Allow multiple firmware file versions in table and load them in
> increasing order as we find them in the file system.
>
> Signed-off-by: Vinod Koul <vkoul@kernel.org>
> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Cc: Christian Lamparter <chunkeey@googlemail.com>
> ---
> drivers/usb/host/xhci-pci.c | 39 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
>
> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> index 3574afac44c5..2ee9e6bbabcb 100644
> --- a/drivers/usb/host/xhci-pci.c
> +++ b/drivers/usb/host/xhci-pci.c
> @@ -333,9 +333,12 @@ static const struct renesas_fw_entry {
> * - uPD720201 ES 2.0 sample whose revision ID is 2.
> * - uPD720201 ES 2.1 sample & CS sample & Mass product, ID is 3.
> * - uPD720202 ES 2.0 sample & CS sample & Mass product, ID is 2.
> + *
> + * Entry expected_version should be kept in increasing order
Why?
> */
> { "K2013080.mem", 0x0014, 0x02, 0x2013 },
> { "K2013080.mem", 0x0014, 0x03, 0x2013 },
> + { "K2026090.mem", 0x0014, 0x03, 0x2026 },
> { "K2013080.mem", 0x0015, 0x02, 0x2013 },
Just put a { } entry here at the end and then you don't care about the
order at all. Much simpler and easier to maintain over time.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/5] usb: xhci: add firmware loader for uPD720201 and uPD720202 w/o ROM
From: Greg Kroah-Hartman @ 2019-06-20 12:19 UTC (permalink / raw)
To: Vinod Koul
Cc: Mathias Nyman, linux-arm-msm, Bjorn Andersson,
Christian Lamparter, linux-usb, linux-kernel, Yoshihiro Shimoda
In-Reply-To: <20190620102154.20805-2-vkoul@kernel.org>
On Thu, Jun 20, 2019 at 03:51:50PM +0530, Vinod Koul wrote:
> From: Christian Lamparter <chunkeey@googlemail.com>
>
> This patch adds a firmware loader for the uPD720201K8-711-BAC-A
> and uPD720202K8-711-BAA-A variant. Both of these chips are listed
> in Renesas' R19UH0078EJ0500 Rev.5.00 "User's Manual: Hardware" as
> devices which need the firmware loader on page 2 in order to
> work as they "do not support the External ROM".
>
> The "Firmware Download Sequence" is describe in chapter
> "7.1 FW Download Interface" R19UH0078EJ0500 Rev.5.00 page 131.
>
> The firmware "K2013080.mem" is available from a USB3.0 Host to
> PCIe Adapter (PP2U-E card) "Firmware download" archive. An
> alternative version can be sourced from Netgear's WNDR4700 GPL
> archives.
>
> The release notes of the PP2U-E's "Firmware Download" ver 2.0.1.3
> (2012-06-15) state that the firmware is for the following devices:
> - uPD720201 ES 2.0 sample whose revision ID is 2.
> - uPD720201 ES 2.1 sample & CS sample & Mass product, ID is 3.
> - uPD720202 ES 2.0 sample & CS sample & Mass product, ID is 2.
>
> If someone from Renesas is listening: It would be great, if these
> firmwares could be added to linux-firmware.git.
That paragraph does not need to be in the changelog :)
> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Vinod Koul <vkoul@kernel.org>
> ---
> drivers/usb/host/xhci-pci.c | 480 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 480 insertions(+)
>
> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> index c2fe218e051f..a400cf7b39da 100644
> --- a/drivers/usb/host/xhci-pci.c
> +++ b/drivers/usb/host/xhci-pci.c
> @@ -12,6 +12,8 @@
> #include <linux/slab.h>
> #include <linux/module.h>
> #include <linux/acpi.h>
> +#include <linux/firmware.h>
> +#include <asm/unaligned.h>
asm/ in a driver? Are you sure???
>
> #include "xhci.h"
> #include "xhci-trace.h"
> @@ -279,6 +281,458 @@ static void xhci_pme_acpi_rtd3_enable(struct pci_dev *dev)
> static void xhci_pme_acpi_rtd3_enable(struct pci_dev *dev) { }
> #endif /* CONFIG_ACPI */
>
> +static const struct renesas_fw_entry {
> + const char *firmware_name;
> + u16 device;
> + u8 revision;
> + u16 expected_version;
> +} renesas_fw_table[] = {
> + /*
> + * Only the uPD720201K8-711-BAC-A or uPD720202K8-711-BAA-A
> + * are listed in R19UH0078EJ0500 Rev.5.00 as devices which
> + * need the software loader.
> + *
> + * PP2U/ReleaseNote_USB3-201-202-FW.txt:
> + *
> + * Note: This firmware is for the following devices.
> + * - uPD720201 ES 2.0 sample whose revision ID is 2.
> + * - uPD720201 ES 2.1 sample & CS sample & Mass product, ID is 3.
> + * - uPD720202 ES 2.0 sample & CS sample & Mass product, ID is 2.
> + */
> + { "K2013080.mem", 0x0014, 0x02, 0x2013 },
> + { "K2013080.mem", 0x0014, 0x03, 0x2013 },
> + { "K2013080.mem", 0x0015, 0x02, 0x2013 },
> +};
No MODULE_FIRMWARE() entries as well?
> +static const struct renesas_fw_entry *renesas_needs_fw_dl(struct pci_dev *dev)
> +{
> + const struct renesas_fw_entry *entry;
> + size_t i;
> +
> + /* This loader will only work with a RENESAS device. */
> + if (!(dev->vendor == PCI_VENDOR_ID_RENESAS))
> + return NULL;
> +
> + for (i = 0; i < ARRAY_SIZE(renesas_fw_table); i++) {
> + entry = &renesas_fw_table[i];
> + if (entry->device == dev->device &&
> + entry->revision == dev->revision)
> + return entry;
> + }
> +
> + return NULL;
> +}
> +
> +static int renesas_fw_download_image(struct pci_dev *dev,
> + const u32 *fw,
> + size_t step)
> +{
> + size_t i;
> + int err;
> + u8 fw_status;
> + bool data0_or_data1;
> +
> + /*
> + * The hardware does alternate between two 32-bit pages.
> + * (This is because each row of the firmware is 8 bytes).
> + *
> + * for even steps we use DATA0, for odd steps DATA1.
> + */
> + data0_or_data1 = (step & 1) == 1;
> +
> + /* step+1. Read "Set DATAX" and confirm it is cleared. */
> + for (i = 0; i < 10000; i++) {
> + err = pci_read_config_byte(dev, 0xF5, &fw_status);
> + if (err)
> + return pcibios_err_to_errno(err);
> + if (!(fw_status & BIT(data0_or_data1)))
> + break;
> +
> + udelay(1);
> + }
> + if (i == 10000)
> + return -ETIMEDOUT;
> +
> + /*
> + * step+2. Write FW data to "DATAX".
> + * "LSB is left" => force little endian
> + */
> + err = pci_write_config_dword(dev, data0_or_data1 ? 0xFC : 0xF8,
> + (__force u32) cpu_to_le32(fw[step]));
> + if (err)
> + return pcibios_err_to_errno(err);
> +
> + udelay(100);
> +
> + /* step+3. Set "Set DATAX". */
> + err = pci_write_config_byte(dev, 0xF5, BIT(data0_or_data1));
> + if (err)
> + return pcibios_err_to_errno(err);
> +
Shouldn't you just do a read after the write to be sure the write
actually went out on the wire? Then you shouldn't have to do the
udelay, right?
> + return 0;
> +}
> +
> +static int renesas_fw_verify(struct pci_dev *dev,
> + const void *fw_data,
> + size_t length)
> +{
> + const struct renesas_fw_entry *entry = renesas_needs_fw_dl(dev);
> + u16 fw_version_pointer;
> + u16 fw_version;
> +
> + if (!entry)
> + return -EINVAL;
> +
> + /*
> + * The Firmware's Data Format is describe in
> + * "6.3 Data Format" R19UH0078EJ0500 Rev.5.00 page 124
> + */
> +
> + /* "Each row is 8 bytes". => firmware size must be a multiple of 8. */
> + if (length % 8 != 0) {
> + dev_err(&dev->dev, "firmware size is not a multipe of 8.");
"multiple"
> + return -EINVAL;
> + }
> +
> + /*
> + * The bootrom chips of the big brother have sizes up to 64k, let's
> + * assume that's the biggest the firmware can get.
> + */
> + if (length < 0x1000 || length >= 0x10000) {
> + dev_err(&dev->dev, "firmware is size %zd is not (4k - 64k).",
> + length);
> + return -EINVAL;
> + }
> +
> + /* The First 2 bytes are fixed value (55aa). "LSB on Left" */
> + if (get_unaligned_le16(fw_data) != 0x55aa) {
> + dev_err(&dev->dev, "no valid firmware header found.");
> + return -EINVAL;
> + }
> +
> + /* verify the firmware version position and print it. */
> + fw_version_pointer = get_unaligned_le16(fw_data + 4);
> + if (fw_version_pointer + 2 >= length) {
> + dev_err(&dev->dev, "firmware version pointer is outside of the firmware image.");
> + return -EINVAL;
> + }
> +
> + fw_version = get_unaligned_le16(fw_data + fw_version_pointer);
> + dev_dbg(&dev->dev, "got firmware version: %02x.", fw_version);
> +
> + if (fw_version != entry->expected_version) {
> + dev_err(&dev->dev, "firmware version mismatch, expected version: %02x.",
> + entry->expected_version);
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static int renesas_hw_check_run_stop_busy(struct pci_dev *pdev)
> +{
> +#if 0
> + u32 val;
> +
> + /*
> + * 7.1.3 Note 3: "... must not set 'FW Download Enable' when
> + * 'RUN/STOP' of USBCMD Register is set"
> + */
> + val = readl(hcd->regs + 0x20);
> + if (val & BIT(0)) {
> + dev_err(&pdev->dev, "hardware is busy and can't receive a FW.");
> + return -EBUSY;
> + }
> +#endif
> + return 0;
> +}
> +
Is this function still really needed anymore?
> + /*
> + * 11. After finishing writing the last data of FW, the
> + * System Software must clear "FW Download Enable"
> + */
> + err = pci_write_config_byte(pdev, 0xF4, 0);
> + if (err)
> + return pcibios_err_to_errno(err);
> +
> + /* 12. Read "Result Code" and confirm it is good. */
> + for (i = 0; i < 10000; i++) {
> + err = pci_read_config_byte(pdev, 0xF4, &fw_status);
> + if (err)
> + return pcibios_err_to_errno(err);
> + if (fw_status & BIT(4))
> + break;
> +
> + udelay(1);
> + }
1000 reads??? I've heard of having to read a few times to ensure
something "latched" in the device, but not 1000. Why so many?
> + if (i == 10000) {
> + /* Timed out / Error - let's see if we can fix this */
> + err = renesas_fw_check_running(pdev);
> + switch (err) {
> + case 0: /*
> + * we shouldn't end up here.
> + * maybe it took a little bit longer.
> + * But all should be well?
> + */
> + break;
> +
> + case 1: /* (No result yet? - we can try to retry) */
> + if (retry_counter < 10) {
> + retry_counter++;
> + dev_warn(&pdev->dev, "Retry Firmware download: %d try.",
> + retry_counter);
> + return renesas_fw_download(pdev, fw,
> + retry_counter);
recursion?
> + }
> + return -ETIMEDOUT;
> +
> + default:
> + return err;
> + }
> + }
> + /*
> + * Optional last step: Engage Firmware Lock
> + *
> + * err = pci_write_config_byte(pdev, 0xF4, BIT(2));
> + * if (err)
> + * return pcibios_err_to_errno(err);
> + */
> +
> + return 0;
> +}
> +
> +struct renesas_fw_ctx {
> + struct pci_dev *pdev;
> + const struct pci_device_id *id;
> + bool resume;
> +};
> +
> +static int xhci_pci_probe(struct pci_dev *pdev,
> + const struct pci_device_id *id);
> +
> +static void renesas_fw_callback(const struct firmware *fw,
> + void *context)
> +{
> + struct renesas_fw_ctx *ctx = context;
> + struct pci_dev *pdev = ctx->pdev;
> + struct device *parent = pdev->dev.parent;
> + int err = -ENOENT;
> +
> + if (fw) {
> + err = renesas_fw_verify(pdev, fw->data, fw->size);
> + if (!err) {
> + err = renesas_fw_download(pdev, fw, 0);
> + release_firmware(fw);
> + if (!err) {
> + if (ctx->resume)
> + return;
> +
> + err = xhci_pci_probe(pdev, ctx->id);
> + if (!err) {
> + /* everything worked */
> + devm_kfree(&pdev->dev, ctx);
> + return;
> + }
> +
> + /* in case of an error - fall through */
> + } else {
> + dev_err(&pdev->dev, "firmware failed to download (%d).",
> + err);
> + }
> + }
> + } else {
> + dev_err(&pdev->dev, "firmware failed to load (%d).", err);
> + }
This can be cleaned up a lot by just erroring out when something
happens, and then jumping to the end. Not this nested if mess.
> +
> + dev_info(&pdev->dev, "Unloading driver");
> +
> + if (parent)
> + device_lock(parent);
> +
> + device_release_driver(&pdev->dev);
> +
> + if (parent)
> + device_unlock(parent);
> +
> + pci_dev_put(pdev);
> +}
> +
> +static int renesas_fw_alive_check(struct pci_dev *pdev)
> +{
> + const struct renesas_fw_entry *entry;
> + int err;
> +
> + /* check if we have a eligible RENESAS' uPD720201/2 w/o FW. */
> + entry = renesas_needs_fw_dl(pdev);
> + if (!entry)
> + return 0;
> +
> + err = renesas_fw_check_running(pdev);
> + /* Also go ahead, if the firmware is running */
> + if (err == 0)
> + return 0;
> +
> + /* At this point, we can be sure that the FW isn't ready. */
> + return err;
Why not just:
return renesas_fw_check_running(pdev);
?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 16/16] mm: pass get_user_pages_fast iterator arguments in a structure
From: Nicholas Piggin @ 2019-06-20 12:18 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andrey Konovalov, Benjamin Herrenschmidt, Rich Felker,
David S. Miller, Christoph Hellwig, James Hogan, Khalid Aziz,
Linux List Kernel Mailing, linux-mips, Linux-MM, linuxppc-dev,
Linux-sh list, Michael Ellerman, Paul Burton, Paul Mackerras,
sparclinux, the arch/x86 maintainers, Yoshinori Sato
In-Reply-To: <CAHk-=wjSo+TzkvYnAqrp=eFgzzc058DhSMTPr4-2quZTbGLfnw@mail.gmail.com>
Linus Torvalds's on June 12, 2019 11:09 am:
> On Tue, Jun 11, 2019 at 2:55 PM Nicholas Piggin <npiggin@gmail.com> wrote:
>>
>> What does this do for performance? I've found this pattern can be
>> bad for store aliasing detection.
>
> I wouldn't expect it to be noticeable, and the lack of argument
> reloading etc should make up for it. Plus inlining makes it a
> non-issue when that happens.
Maybe in isolation. Just seems like a strange pattern to sprinkle
around randomly, I wouldn't like it to proliferate.
I understand in some cases where a big set of parameters or
basically state gets sent around through a lot of interfaces.
Within one file to make lines a bit shorter or save a few bytes
isn't such a strong case.
>
> But I guess we could also at least look at using "restrict", if that
> ends up helping. Unlike the completely bogus type-based aliasing rules
> (that we disable because I think the C people were on some bad bad
> drugs when they came up with them), restricted pointers are a real
> thing that makes sense.
>
> That said, we haven't traditionally used it, and I don't know how much
> it helps gcc. Maybe gcc ignores it entirely? S
Ahh, it's not compiler store alias analysis I'm talking about, but
processor (but you raise an interesting point about compiler too,
would be nice if we could improve that in general).
The processor aliasing problem happens because the struct will
be initialised with stores using one base register (e.g., stack
register), and then same memory is loaded using a different
register (e.g., parameter register). Processor's static heuristics
for determining a load doesn't alias with an earlier store doesn't
do so well in that case.
Just about everywhere I've seen those kind of misspeculation and
flushes in the kernel has been this pattern, so I'm wary of it in
performance critical code.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH RFC 4/5] x86: KVM: add xsetbv to the emulator
From: Paolo Bonzini @ 2019-06-20 12:18 UTC (permalink / raw)
To: Vitaly Kuznetsov, kvm
Cc: linux-kernel, Radim Krčmář, Joerg Roedel,
Jim Mattson
In-Reply-To: <20190620110240.25799-5-vkuznets@redhat.com>
On 20/06/19 13:02, Vitaly Kuznetsov wrote:
> To avoid hardcoding xsetbv length to '3' we need to support decoding it in
> the emulator.
>
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Can you also emulate it properly? The code from QEMU's
target/i386/fpu_helper.c can help. :)
Paolo
> ---
> arch/x86/include/asm/kvm_emulate.h | 1 +
> arch/x86/kvm/emulate.c | 9 ++++++++-
> arch/x86/kvm/svm.c | 1 +
> 3 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/kvm_emulate.h b/arch/x86/include/asm/kvm_emulate.h
> index feab24cac610..478f76b0122d 100644
> --- a/arch/x86/include/asm/kvm_emulate.h
> +++ b/arch/x86/include/asm/kvm_emulate.h
> @@ -429,6 +429,7 @@ enum x86_intercept {
> x86_intercept_ins,
> x86_intercept_out,
> x86_intercept_outs,
> + x86_intercept_xsetbv,
>
> nr_x86_intercepts
> };
> diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
> index d0d5dd44b4f4..ff25d94df684 100644
> --- a/arch/x86/kvm/emulate.c
> +++ b/arch/x86/kvm/emulate.c
> @@ -4393,6 +4393,12 @@ static const struct opcode group7_rm1[] = {
> N, N, N, N, N, N,
> };
>
> +static const struct opcode group7_rm2[] = {
> + N,
> + DI(SrcNone | Priv, xsetbv),
> + N, N, N, N, N, N,
> +};
> +
> static const struct opcode group7_rm3[] = {
> DIP(SrcNone | Prot | Priv, vmrun, check_svme_pa),
> II(SrcNone | Prot | EmulateOnUD, em_hypercall, vmmcall),
> @@ -4482,7 +4488,8 @@ static const struct group_dual group7 = { {
> }, {
> EXT(0, group7_rm0),
> EXT(0, group7_rm1),
> - N, EXT(0, group7_rm3),
> + EXT(0, group7_rm2),
> + EXT(0, group7_rm3),
> II(SrcNone | DstMem | Mov, em_smsw, smsw), N,
> II(SrcMem16 | Mov | Priv, em_lmsw, lmsw),
> EXT(0, group7_rm7),
> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index f980fc43372d..39e61029f401 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -6041,6 +6041,7 @@ static const struct __x86_intercept {
> [x86_intercept_ins] = POST_EX(SVM_EXIT_IOIO),
> [x86_intercept_out] = POST_EX(SVM_EXIT_IOIO),
> [x86_intercept_outs] = POST_EX(SVM_EXIT_IOIO),
> + [x86_intercept_xsetbv] = PRE_EX(SVM_EXIT_XSETBV),
> };
>
> #undef PRE_EX
>
^ permalink raw reply
* Re: [PATCH 16/16] mm: pass get_user_pages_fast iterator arguments in a structure
From: Nicholas Piggin @ 2019-06-20 12:18 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andrey Konovalov, Benjamin Herrenschmidt, Rich Felker,
David S. Miller, Christoph Hellwig, James Hogan, Khalid Aziz,
Linux List Kernel Mailing, linux-mips, Linux-MM, linuxppc-dev,
Linux-sh list, Michael Ellerman, Paul Burton, Paul Mackerras,
sparclinux, the arch/x86 maintainers, Yoshinori Sato
In-Reply-To: <CAHk-=wjSo+TzkvYnAqrp=eFgzzc058DhSMTPr4-2quZTbGLfnw@mail.gmail.com>
Linus Torvalds's on June 12, 2019 11:09 am:
> On Tue, Jun 11, 2019 at 2:55 PM Nicholas Piggin <npiggin@gmail.com> wrote:
>>
>> What does this do for performance? I've found this pattern can be
>> bad for store aliasing detection.
>
> I wouldn't expect it to be noticeable, and the lack of argument
> reloading etc should make up for it. Plus inlining makes it a
> non-issue when that happens.
Maybe in isolation. Just seems like a strange pattern to sprinkle
around randomly, I wouldn't like it to proliferate.
I understand in some cases where a big set of parameters or
basically state gets sent around through a lot of interfaces.
Within one file to make lines a bit shorter or save a few bytes
isn't such a strong case.
>
> But I guess we could also at least look at using "restrict", if that
> ends up helping. Unlike the completely bogus type-based aliasing rules
> (that we disable because I think the C people were on some bad bad
> drugs when they came up with them), restricted pointers are a real
> thing that makes sense.
>
> That said, we haven't traditionally used it, and I don't know how much
> it helps gcc. Maybe gcc ignores it entirely? S
Ahh, it's not compiler store alias analysis I'm talking about, but
processor (but you raise an interesting point about compiler too,
would be nice if we could improve that in general).
The processor aliasing problem happens because the struct will
be initialised with stores using one base register (e.g., stack
register), and then same memory is loaded using a different
register (e.g., parameter register). Processor's static heuristics
for determining a load doesn't alias with an earlier store doesn't
do so well in that case.
Just about everywhere I've seen those kind of misspeculation and
flushes in the kernel has been this pattern, so I'm wary of it in
performance critical code.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH] KVM: nVMX: reorganize initial steps of vmx_set_nested_state
From: Vitaly Kuznetsov @ 2019-06-20 12:18 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Aaron Lewis, linux-kernel, kvm
In-Reply-To: <1560959396-13969-1-git-send-email-pbonzini@redhat.com>
Paolo Bonzini <pbonzini@redhat.com> writes:
> Commit 332d079735f5 ("KVM: nVMX: KVM_SET_NESTED_STATE - Tear down old EVMCS
> state before setting new state", 2019-05-02) broke evmcs_test because the
> eVMCS setup must be performed even if there is no VMXON region defined,
> as long as the eVMCS bit is set in the assist page.
>
> While the simplest possible fix would be to add a check on
> kvm_state->flags & KVM_STATE_NESTED_EVMCS in the initial "if" that
> covers kvm_state->hdr.vmx.vmxon_pa == -1ull, that is quite ugly.
>
> Instead, this patch moves checks earlier in the function and
> conditionalizes them on kvm_state->hdr.vmx.vmxon_pa, so that
> vmx_set_nested_state always goes through vmx_leave_nested
> and nested_enable_evmcs.
>
> Fixes: 332d079735f5
checkpatch.pl will likely complain here asking for full description, e.g.
Fixes: 332d079735f5 ("KVM: nVMX: KVM_SET_NESTED_STATE - Tear down old EVMCS state before setting new state")
There's also something wrong with the patch as it fails to apply because
of (not only?) whitespace issues or maybe I'm just applying it to the
wrong tree...
> Cc: Aaron Lewis <aaronlewis@google.com>
> Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Enlightened VMCS migration is just a 'theoretical' feature atm, we don't
know if it actually works but it's good we have a selftest for it so we
know when it definitely doesn't :-)
Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> ---
> arch/x86/kvm/vmx/nested.c | 26 ++++++++++--------
> .../kvm/x86_64/vmx_set_nested_state_test.c | 32 ++++++++++++++--------
> 2 files changed, 35 insertions(+), 23 deletions(-)
>
> diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
> index fb6d1f7b43f3..5f9c1a200201 100644
> --- a/arch/x86/kvm/vmx/nested.c
> +++ b/arch/x86/kvm/vmx/nested.c
> @@ -5343,9 +5343,6 @@ static int vmx_set_nested_state(struct kvm_vcpu *vcpu,
> if (kvm_state->format != KVM_STATE_NESTED_FORMAT_VMX)
> return -EINVAL;
>
> - if (!nested_vmx_allowed(vcpu))
> - return kvm_state->hdr.vmx.vmxon_pa == -1ull ? 0 : -EINVAL;
> -
> if (kvm_state->hdr.vmx.vmxon_pa == -1ull) {
> if (kvm_state->hdr.vmx.smm.flags)
> return -EINVAL;
> @@ -5353,12 +5350,15 @@ static int vmx_set_nested_state(struct kvm_vcpu *vcpu,
> if (kvm_state->hdr.vmx.vmcs12_pa != -1ull)
> return -EINVAL;
>
> - vmx_leave_nested(vcpu);
> - return 0;
> - }
> + if (kvm_state->flags & ~KVM_STATE_NESTED_EVMCS)
> + return -EINVAL;
> + } else {
> + if (!nested_vmx_allowed(vcpu))
> + return -EINVAL;
>
> - if (!page_address_valid(vcpu, kvm_state->hdr.vmx.vmxon_pa))
> - return -EINVAL;
> + if (!page_address_valid(vcpu, kvm_state->hdr.vmx.vmxon_pa))
> + return -EINVAL;
> + }
>
> if ((kvm_state->hdr.vmx.smm.flags & KVM_STATE_NESTED_SMM_GUEST_MODE) &&
> (kvm_state->flags & KVM_STATE_NESTED_GUEST_MODE))
> @@ -5381,11 +5381,15 @@ static int vmx_set_nested_state(struct kvm_vcpu *vcpu,
> return -EINVAL;
>
> vmx_leave_nested(vcpu);
> - if (kvm_state->hdr.vmx.vmxon_pa == -1ull)
> - return 0;
> + if (kvm_state->flags & KVM_STATE_NESTED_EVMCS) {
> + if (!nested_vmx_allowed(vcpu))
> + return -EINVAL;
>
> - if (kvm_state->flags & KVM_STATE_NESTED_EVMCS)
> nested_enable_evmcs(vcpu, NULL);
> + }
> +
> + if (kvm_state->hdr.vmx.vmxon_pa == -1ull)
> + return 0;
>
> vmx->nested.vmxon_ptr = kvm_state->hdr.vmx.vmxon_pa;
> ret = enter_vmx_operation(vcpu);
> diff --git a/tools/testing/selftests/kvm/x86_64/vmx_set_nested_state_test.c b/tools/testing/selftests/kvm/x86_64/vmx_set_nested_state_test.c
> index 0648fe6df5a8..e64ca20b315a 100644
> --- a/tools/testing/selftests/kvm/x86_64/vmx_set_nested_state_test.c
> +++ b/tools/testing/selftests/kvm/x86_64/vmx_set_nested_state_test.c
> @@ -123,36 +123,44 @@ void test_vmx_nested_state(struct kvm_vm *vm)
> /*
> * We cannot virtualize anything if the guest does not have VMX
> * enabled. We expect KVM_SET_NESTED_STATE to return 0 if vmxon_pa
> - * is set to -1ull.
> + * is set to -1ull, but the flags must be zero.
> */
> set_default_vmx_state(state, state_sz);
> state->hdr.vmx.vmxon_pa = -1ull;
> + test_nested_state_expect_einval(vm, state);
> +
> + state->hdr.vmx.vmcs12_pa = -1ull;
> + state->flags = KVM_STATE_NESTED_EVMCS;
> + test_nested_state_expect_einval(vm, state);
> +
> + state->flags = 0;
> test_nested_state(vm, state);
>
> /* Enable VMX in the guest CPUID. */
> vcpu_set_cpuid(vm, VCPU_ID, kvm_get_supported_cpuid());
>
> - /* It is invalid to have vmxon_pa == -1ull and SMM flags non-zero. */
> + /*
> + * Setting vmxon_pa == -1ull and vmcs_pa == -1ull exits early without
> + * setting the nested state but flags other than eVMCS must be clear.
> + */
> set_default_vmx_state(state, state_sz);
> state->hdr.vmx.vmxon_pa = -1ull;
> + state->hdr.vmx.vmcs12_pa = -1ull;
> + test_nested_state_expect_einval(vm, state);
> +
> + state->flags = KVM_STATE_NESTED_EVMCS;
> + test_nested_state(vm, state);
> +
> + /* It is invalid to have vmxon_pa == -1ull and SMM flags non-zero. */
> state->hdr.vmx.smm.flags = 1;
> test_nested_state_expect_einval(vm, state);
>
> /* It is invalid to have vmxon_pa == -1ull and vmcs_pa != -1ull. */
> set_default_vmx_state(state, state_sz);
> state->hdr.vmx.vmxon_pa = -1ull;
> - state->hdr.vmx.vmcs12_pa = 0;
> + state->flags = 0;
> test_nested_state_expect_einval(vm, state);
>
> - /*
> - * Setting vmxon_pa == -1ull and vmcs_pa == -1ull exits early without
> - * setting the nested state.
> - */
> - set_default_vmx_state(state, state_sz);
> - state->hdr.vmx.vmxon_pa = -1ull;
> - state->hdr.vmx.vmcs12_pa = -1ull;
> - test_nested_state(vm, state);
> -
> /* It is invalid to have vmxon_pa set to a non-page aligned address. */
> set_default_vmx_state(state, state_sz);
> state->hdr.vmx.vmxon_pa = 1;
--
Vitaly
^ permalink raw reply
* No invalid histogram error
From: Masami Hiramatsu @ 2019-06-20 12:17 UTC (permalink / raw)
To: Tom Zanussi; +Cc: linux-kernel, Steven Rostedt
Hi Tom,
I'm trying to use histogram on a synthetic event, but faced an odd situation.
There is a synthetic event, which has foo and bar.
/sys/kernel/debug/tracing # cat synthetic_events
testevent int foo; int bar
And when I tried to add hist on trigger, both foo and bar can be used as below.
/sys/kernel/debug/tracing # echo "hist:keys=bar" > events/synthetic/testevent/trigger
/sys/kernel/debug/tracing # echo "hist:keys=foo" > events/synthetic/testevent/trigger
And, when I missed to specify the sort key, it failed
/sys/kernel/debug/tracing # echo "hist:keys=foo:sort=bar" > events/synthetic/testevent/trigger
sh: write error: Invalid argument
But no error on error_log file.
/sys/kernel/debug/tracing # cat error_log
/sys/kernel/debug/tracing #
Could you add some error message? What about below?
[ 5422.134656] hist:synthetic:testevent: error: Sort key must be one of keys.
Command: keys=foo;sort=bar
^
Thank you,
--
Masami Hiramatsu <mhiramat@kernel.org>
^ permalink raw reply
* [GIT PULL] s390 updates for 5.2-rc6
From: Heiko Carstens @ 2019-06-20 12:17 UTC (permalink / raw)
To: Linus Torvalds
Cc: Vasily Gorbik, Christian Borntraeger, linux-kernel, linux-s390
Hello Linus,
The following changes since commit d1fdb6d8f6a4109a4263176c84b899076a5f8008:
Linux 5.2-rc4 (2019-06-08 20:24:46 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git tags/s390-5.2-5
for you to fetch changes up to 11aff183225c5cf48fae074cd99d8f18ba84ed34:
vfio-ccw: Destroy kmem cache region on module exit (2019-06-13 15:52:28 +0200)
----------------------------------------------------------------
s390 updates for 5.2-rc6
- Disable address-of-packed-member warning in s390 specific boot code
to get rid of a gcc9 warning which otherwise is already disabled
for the whole kernel.
- Fix yet another compiler error seen with CONFIG_OPTIMIZE_INLINING
enabled.
- Fix memory leak in vfio-ccw code on module exit.
----------------------------------------------------------------
Farhan Ali (1):
vfio-ccw: Destroy kmem cache region on module exit
Guenter Roeck (1):
s390/ctl_reg: mark __ctl_set_bit and __ctl_clear_bit as __always_inline
Heiko Carstens (1):
s390/boot: disable address-of-packed-member warning
arch/s390/Makefile | 1 +
arch/s390/include/asm/ctl_reg.h | 4 ++--
drivers/s390/cio/vfio_ccw_drv.c | 1 +
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/s390/Makefile b/arch/s390/Makefile
index de8521f..e48013c 100644
--- a/arch/s390/Makefile
+++ b/arch/s390/Makefile
@@ -30,6 +30,7 @@ KBUILD_CFLAGS_DECOMPRESSOR += -DDISABLE_BRANCH_PROFILING -D__NO_FORTIFY
KBUILD_CFLAGS_DECOMPRESSOR += -fno-delete-null-pointer-checks -msoft-float
KBUILD_CFLAGS_DECOMPRESSOR += -fno-asynchronous-unwind-tables
KBUILD_CFLAGS_DECOMPRESSOR += $(call cc-option,-ffreestanding)
+KBUILD_CFLAGS_DECOMPRESSOR += $(call cc-disable-warning, address-of-packed-member)
KBUILD_CFLAGS_DECOMPRESSOR += $(if $(CONFIG_DEBUG_INFO),-g)
KBUILD_CFLAGS_DECOMPRESSOR += $(if $(CONFIG_DEBUG_INFO_DWARF4), $(call cc-option, -gdwarf-4,))
UTS_MACHINE := s390x
diff --git a/arch/s390/include/asm/ctl_reg.h b/arch/s390/include/asm/ctl_reg.h
index 4600453..3bda757 100644
--- a/arch/s390/include/asm/ctl_reg.h
+++ b/arch/s390/include/asm/ctl_reg.h
@@ -55,7 +55,7 @@
: "i" (low), "i" (high)); \
} while (0)
-static inline void __ctl_set_bit(unsigned int cr, unsigned int bit)
+static __always_inline void __ctl_set_bit(unsigned int cr, unsigned int bit)
{
unsigned long reg;
@@ -64,7 +64,7 @@ static inline void __ctl_set_bit(unsigned int cr, unsigned int bit)
__ctl_load(reg, cr, cr);
}
-static inline void __ctl_clear_bit(unsigned int cr, unsigned int bit)
+static __always_inline void __ctl_clear_bit(unsigned int cr, unsigned int bit)
{
unsigned long reg;
diff --git a/drivers/s390/cio/vfio_ccw_drv.c b/drivers/s390/cio/vfio_ccw_drv.c
index ee8767f..9125f7f 100644
--- a/drivers/s390/cio/vfio_ccw_drv.c
+++ b/drivers/s390/cio/vfio_ccw_drv.c
@@ -299,6 +299,7 @@ static void __exit vfio_ccw_sch_exit(void)
css_driver_unregister(&vfio_ccw_sch_driver);
isc_unregister(VFIO_CCW_ISC);
kmem_cache_destroy(vfio_ccw_io_region);
+ kmem_cache_destroy(vfio_ccw_cmd_region);
destroy_workqueue(vfio_ccw_work_q);
}
module_init(vfio_ccw_sch_init);
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.