* Re: [PATCH v6 05/14] mmc: sdhci-msm: Update DLL reset sequence
From: Ritesh Harjani @ 2016-11-09 12:06 UTC (permalink / raw)
To: Stephen Boyd
Cc: ulf.hansson, linux-mmc, adrian.hunter, shawn.lin, devicetree,
linux-clk, david.brown, andy.gross, linux-arm-msm, georgi.djakov,
alex.lemberg, mateusz.nowak, Yuliy.Izrailov, asutoshd, kdorfman,
david.griego, stummala, venkatg, rnayak, pramod.gurav
In-Reply-To: <20161108230622.GN16026@codeaurora.org>
Hi Stephen,
On 11/9/2016 4:36 AM, Stephen Boyd wrote:
> On 11/07, Ritesh Harjani wrote:
>>
>> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
>> index 42f42aa..32b0b79 100644
>> --- a/drivers/mmc/host/sdhci-msm.c
>> +++ b/drivers/mmc/host/sdhci-msm.c
>> @@ -58,11 +58,17 @@
>> #define CORE_DLL_CONFIG 0x100
>> #define CORE_DLL_STATUS 0x108
>>
>> +#define CORE_DLL_CONFIG_2 0x1b4
>> +#define CORE_FLL_CYCLE_CNT BIT(18)
>> +#define CORE_DLL_CLOCK_DISABLE BIT(21)
>> +
>> #define CORE_VENDOR_SPEC 0x10c
>> #define CORE_CLK_PWRSAVE BIT(1)
>>
>> #define CORE_VENDOR_SPEC_CAPABILITIES0 0x11c
>>
>> +#define TCXO_FREQ 19200000
>
> TCXO_FREQ could change based on the board. For example, IPQ has
> it as 25 MHz.
Actually not sure of the proper way on how to get this freq in driver
today. We may use xo_board clock but, it is not available for all boards
except 8996/8916 I guess.
Also, there is no sdhc for IPQ board and for all other boards TCXO_FREQ
is same where sdhci-msm driver is used. For that purpose this was
defined here for sdhci-msm driver.
Do you think in that case we should keep it this way for now and later
change if a need arise to change the TCXO_FREQ ?
>
>> +
>> #define CDR_SELEXT_SHIFT 20
>> #define CDR_SELEXT_MASK (0xf << CDR_SELEXT_SHIFT)
>> #define CMUX_SHIFT_PHASE_SHIFT 24
>> @@ -330,6 +349,24 @@ static int msm_init_cm_dll(struct sdhci_host *host)
>> writel_relaxed(config, host->ioaddr + CORE_DLL_CONFIG);
>> msm_cm_dll_set_freq(host);
>>
>> + if (msm_host->use_14lpp_dll_reset) {
>> + u32 mclk_freq = 0;
>> +
>> + if ((readl_relaxed(host->ioaddr + CORE_DLL_CONFIG_2)
>> + & CORE_FLL_CYCLE_CNT))
>
> I suggest you grow a local variable.
Ok.
>
>> + mclk_freq = (u32)((host->clock / TCXO_FREQ) * 8);
>
> Is the cast necessary?
Will remove it.
>
>> + else
>> + mclk_freq = (u32)((host->clock / TCXO_FREQ) * 4);
>
> Ditto
Will remove it.
>
>> +
>> + config = readl_relaxed(host->ioaddr + CORE_DLL_CONFIG_2);
>> + config &= ~(0xFF << 10);
>> + config |= mclk_freq << 10;
>> +
>> + writel_relaxed(config, host->ioaddr + CORE_DLL_CONFIG_2);
>> + /* wait for 5us before enabling DLL clock */
>
> Usually there's a barrier between writel_relaxed() and delay
> because we don't know when the writel will be posted out and the
> delay is there to wait for the operation to happen. Probably
> should change this to be a writel() instead.
Arnd, already explained here.
We do need the udelay here as per the HW sequence itself.
>
>> + udelay(5);
>> + }
>> +
>> /* Write 0 to DLL_RST bit of DLL_CONFIG register */
>> config = readl_relaxed(host->ioaddr + CORE_DLL_CONFIG);
>> config &= ~CORE_DLL_RST;
>> @@ -340,6 +377,14 @@ static int msm_init_cm_dll(struct sdhci_host *host)
>> config &= ~CORE_DLL_PDN;
>> writel_relaxed(config, host->ioaddr + CORE_DLL_CONFIG);
>>
>> + if (msm_host->use_14lpp_dll_reset) {
>> + msm_cm_dll_set_freq(host);
>> + /* Enable the DLL clock */
>> + config = readl_relaxed(host->ioaddr + CORE_DLL_CONFIG_2);
>> + config &= ~CORE_DLL_CLOCK_DISABLE;
>> + writel_relaxed(config, host->ioaddr + CORE_DLL_CONFIG_2);
>> + }
>> +
>> /* Set DLL_EN bit to 1. */
>> config = readl_relaxed(host->ioaddr + CORE_DLL_CONFIG);
>> config |= CORE_DLL_EN;
>> @@ -641,6 +686,9 @@ static int sdhci_msm_probe(struct platform_device *pdev)
>> dev_dbg(&pdev->dev, "MCI Version: 0x%08x, major: 0x%04x, minor: 0x%02x\n",
>> core_version, core_major, core_minor);
>>
>> + if ((core_major == 1) && (core_minor >= 0x42))
>
> Why so many parenthesis?
Sure, will remove it.
>
>> + msm_host->use_14lpp_dll_reset = true;
>> +
>> /*
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [Qemu-devel] [kvm-unit-tests PATCH v4 06/11] arm/arm64: add initial gicv2 support
From: Andrew Jones @ 2016-11-09 12:06 UTC (permalink / raw)
To: Andre Przywara
Cc: kvm, kvmarm, qemu-devel, qemu-arm, peter.maydell, marc.zyngier,
eric.auger, pbonzini, alex.bennee, christoffer.dall
In-Reply-To: <4d741c3b-a4b4-39e5-232e-99ba9f19dd65@arm.com>
On Wed, Nov 09, 2016 at 11:53:39AM +0000, Andre Przywara wrote:
[...]
> > diff --git a/lib/arm/asm/gic.h b/lib/arm/asm/gic.h
> > new file mode 100644
> > index 000000000000..ec92f1064dc0
> > --- /dev/null
> > +++ b/lib/arm/asm/gic.h
> > @@ -0,0 +1,44 @@
> > +/*
> > + * Copyright (C) 2016, Red Hat Inc, Andrew Jones <drjones@redhat.com>
> > + *
> > + * This work is licensed under the terms of the GNU LGPL, version 2.
> > + */
> > +#ifndef _ASMARM_GIC_H_
> > +#define _ASMARM_GIC_H_
> > +
> > +#include <asm/gic-v2.h>
> > +
> > +#define GIC_CPU_CTRL 0x00
> > +#define GIC_CPU_PRIMASK 0x04
> > +
> > +#define GICC_ENABLE 0x1
> > +#define GICC_INT_PRI_THRESHOLD 0xf0
> > +
> > +#define GIC_DIST_CTRL 0x000
> > +#define GIC_DIST_CTR 0x004
>
> I think we shouldn't copy this old name here, which stems from pre-GICv2
> times (PL390?), IIUC. Both GIC specs talk of TYPER here.
>
> Also if we now use the same defines for both the GICv2 and GICv3
> distributor, we should really stick with the (modern) spec naming, which
> is GICD_CTRL, GICD_TYPER and so on. Same for the CPU interface (GICC_CTRL).
> In the kernel these names are used for GICv3, but we didn't bother to
> adjust the existing GICv2 names to avoid pointless churn.
> Also that would line up with the bit field defines below.
>
Yeah, I noticed the CTR vs. TYPER naming weirdness. I considered
exclusively defining the gicv3/modern/better name, but wasn't sure
I should deviate from the kernel names. Keeping the names consistent
is nice for grepping kernel sources, which needs to be done when a
test fails and we want to find the bug.
I'd personally prefer "pointless" churn in the kernel to get it
straightened out there. If it ever is, then I'd obviously update
this code too. Until then, I think maintaining easy greppability
is the better choice.
Thanks,
drew
^ permalink raw reply
* Re: [PATCH] usbnet: prevent device rpm suspend in usbnet_probe function
From: Oliver Neukum @ 2016-11-09 11:58 UTC (permalink / raw)
To: Alan Stern; +Cc: bjorn, Kai-Heng Feng, linux-kernel, linux-usb, netdev
In-Reply-To: <Pine.LNX.4.44L0.1611081339060.1499-100000@iolanthe.rowland.org>
On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote:
> These problems could very well be caused by running at SuperSpeed
> (USB-3) instead of high speed (USB-2).
>
> Is there any way to test what happens when the device is attached to
> the computer by a USB-2 cable? That would prevent it from operating at
> SuperSpeed.
>
> The main point, however, is that the proposed patch doesn't seem to
> address the true problem, which is that the device gets suspended
> between probes. The patch only tries to prevent it from being
> suspended during a probe -- which is already prevented by the USB core.
But why doesn't it fail during normal operation?
I suspect that its firmware requires the altsetting
/* should we change control altsetting on a NCM/MBIM function? */
if (cdc_ncm_select_altsetting(intf) == CDC_NCM_COMM_ALTSETTING_MBIM) {
data_altsetting = CDC_NCM_DATA_ALTSETTING_MBIM;
ret = cdc_mbim_set_ctrlalt(dev, intf, CDC_NCM_COMM_ALTSETTING_MBIM);
to be set before it accepts a suspension.
Regards
Oliver
^ permalink raw reply
* Re: [Qemu-devel] [RFC 15/17] ppc: Check that CPU model stays consistent across migration
From: David Gibson @ 2016-11-09 6:40 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: nikunj, mdroth, thuth, lvivier, qemu-ppc, qemu-devel
In-Reply-To: <74024fe8-dde4-07a3-201d-ce6249411ab3@ozlabs.ru>
[-- Attachment #1: Type: text/plain, Size: 6352 bytes --]
On Wed, Nov 09, 2016 at 05:06:23PM +1100, Alexey Kardashevskiy wrote:
> On 09/11/16 15:24, David Gibson wrote:
> > On Tue, Nov 08, 2016 at 05:03:49PM +1100, Alexey Kardashevskiy wrote:
> >> On 08/11/16 16:29, David Gibson wrote:
> >>> On Fri, Nov 04, 2016 at 06:54:48PM +1100, Alexey Kardashevskiy wrote:
> >>>> On 30/10/16 22:12, David Gibson wrote:
> >>>>> When a vmstate for the ppc cpu was first introduced (a90db15 "target-ppc:
> >>>>> Convert ppc cpu savevm to VMStateDescription"), a VMSTATE_EQUAL was used
> >>>>> to ensure that identical CPU models were used at source and destination
> >>>>> as based on the PVR (Processor Version Register).
> >>>>>
> >>>>> However this was a problem for HV KVM, where due to hardware limitations
> >>>>> we always need to use the real PVR of the host CPU. So, to allow
> >>>>> migration between hosts with "similar enough" CPUs, the PVR check was
> >>>>> removed in 569be9f0 "target-ppc: Remove PVR check from migration". This
> >>>>> left the onus on user / management to only attempt migration between
> >>>>> compatible CPUs.
> >>>>>
> >>>>> Now that we've reworked the handling of compatiblity modes, we have the
> >>>>> information to actually determine if we're making a compatible migration.
> >>>>> So this patch partially restores the PVR check. If the source was running
> >>>>> in a compatibility mode, we just make sure that the destination cpu can
> >>>>> also run in that compatibility mode. However, if the source was running
> >>>>> in "raw" mode, we verify that the destination has the same PVR value.
> >>>>>
> >>>>> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> >>>>> ---
> >>>>> target-ppc/machine.c | 15 +++++++++++----
> >>>>> 1 file changed, 11 insertions(+), 4 deletions(-)
> >>>>>
> >>>>> diff --git a/target-ppc/machine.c b/target-ppc/machine.c
> >>>>> index 5d87ff6..62b9e94 100644
> >>>>> --- a/target-ppc/machine.c
> >>>>> +++ b/target-ppc/machine.c
> >>>>> @@ -173,10 +173,12 @@ static int cpu_post_load(void *opaque, int version_id)
> >>>>> target_ulong msr;
> >>>>>
> >>>>> /*
> >>>>> - * We always ignore the source PVR. The user or management
> >>>>> - * software has to take care of running QEMU in a compatible mode.
> >>>>> + * If we're operating in compat mode, we should be ok as long as
> >>>>> + * the destination supports the same compatiblity mode.
> >>>>> + *
> >>>>> + * Otherwise, however, we require that the destination has exactly
> >>>>> + * the same CPU model as the source.
> >>>>> */
> >>>>> - env->spr[SPR_PVR] = env->spr_cb[SPR_PVR].default_value;
> >>>>>
> >>>>> #if defined(TARGET_PPC64)
> >>>>> if (cpu->compat_pvr) {
> >>>>> @@ -188,8 +190,13 @@ static int cpu_post_load(void *opaque, int version_id)
> >>>>> error_free(local_err);
> >>>>> return -1;
> >>>>> }
> >>>>> - }
> >>>>> + } else
> >>>>> #endif
> >>>>> + {
> >>>>> + if (env->spr[SPR_PVR] != env->spr_cb[SPR_PVR].default_value) {
> >>>>> + return -1;
> >>>>> + }
> >>>>> + }
> >>>>
> >>>> This should break migration from host with PVR=004d0200 to host with
> >>>> PVR=004d0201, what is the benefit of such limitation?
> >>>
> >>> There probably isn't one. But the point is it also blocks migration
> >>> from a host with PVR=004B0201 (POWER8) to one with PVR=00201400
> >>> (403GCX) and *that* has a clear benefit. I don't see a way to block
> >>> the second without the first, except by creating a huge compatibility
> >>> matrix table, which would require inordinate amounts of time to
> >>> research carefully.
> >>
> >>
> >> This is pcc->pvr_match() for this purpose.
> >
> > Hmm.. thinking about this. Obviously requiring an exactly matching
> > PVR is the architecturally "safest" approach. For TCG and PR KVM, it
> > really should be sufficient - if you can select "close" PVRs at each
> > end, you should be able to select exactly matching ones just as well.
> >
> > For HV KVM, we should generally be using compatibility modes to allow
> > migration between a relatively wide range of CPUs. My intention was
> > basically to require moving to that model, rather than "approximate
> > matching" real PVRs.
>
> So the management stack (libvirt) will need to know that if it is HV KVM,
> then -cpu host,compat=xxxx; if it is PR KVM, then -cpu XXXX and no compat.
> That was really annoying when we had exact PVR matching.
>
>
> > I'm still convinced using compat modes is the right way to go medium
> > to long term. However, allowing the approximate matches could make
> > for a more forgiving transition, if people have existing hosts in
> > "raw" mode.
>
> Within the family, CPUs behave exactly (not slightly but exactly) the same
> even though 3 of 4 bytes of the PVR value are different so enforcing PVR to
> match or enforcing compatibility (which as a feature was not a great idea
> from the day one) does not sound compelling.
Ah, ok. pvr_match sounds reasonable then - I've already implemented
that.
> Does x86 have anything like this compatibility thingy?
It's better thought out on x86. AIUI compatibility options are set in
the VM control block, so it is under host control even though the
guest is not para-virtualized. I believe CPUID (unlike mfpvr) *is*
virtualized so the guest simply sees the compatible CPU, not something
else running in a compatibility mode. So, there's no need for
compatibility modes as such, you just set the CPU to an older one, and
qemu and KVM between them make it appear that way to the guest.
It helps that compatibility is 1 dimensional on x86 - basically
any model can be run to be compatible with any older model. That's
true for sufficiently recent Power server CPUs, but not across Power
in general.
Actually, I'm not sure where Atom and AMD vs. Intel fit into that
picture, but at any rate, I believe they're closer to 1 dimensional
compatibility than Power / PowerPC is.
> > Ok, I'll add pvr_match checking to this.
> >
>
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [U-Boot] [PATCH] driver: net: fsl-mc: Use aligned address for MC FW load
From: Ashish Kumar @ 2016-11-09 12:03 UTC (permalink / raw)
To: u-boot
In-Reply-To: <AM4PR0401MB1732B4A871172EEFC39FA0889AA60@AM4PR0401MB1732.eurprd04.prod.outlook.com>
Hello York,
Please see inline.
Regards
-----Original Message-----
From: york sun
Sent: Tuesday, November 08, 2016 11:38 PM
To: Ashish Kumar <ashish.kumar@nxp.com>; Priyanka Jain <priyanka.jain@nxp.com>; u-boot at lists.denx.de
Cc: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
Subject: Re: [PATCH] driver: net: fsl-mc: Use aligned address for MC FW load
On 11/07/2016 09:37 PM, Ashish Kumar wrote:
> Hello York,
>
> Please see inline.
>
> Regards
> Ashish
>
> -----Original Message-----
> From: york sun
> Sent: Tuesday, November 08, 2016 12:23 AM
> To: Priyanka Jain <priyanka.jain@nxp.com>; u-boot at lists.denx.de
> Cc: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; Ashish Kumar
> <ashish.kumar@nxp.com>
> Subject: Re: [PATCH] driver: net: fsl-mc: Use aligned address for MC
> FW load
>
> On 10/24/2016 01:05 AM, Priyanka Jain wrote:
>> Firmware of Management Complex (MC) should be loaded at 512MB aligned
>> address.
>> So use aligned address for firmware load.
>>
>> Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
>> Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
>> Signed-off-by: Ashish Kumar <Ashish.Kumar@nxp.com>
>> ---
>> drivers/net/fsl-mc/mc.c | 62 ++++++++++++++++++++++++++--------------------
>> 1 files changed, 35 insertions(+), 27 deletions(-)
>>
>> diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c index
>> 1811b0f..c66340b 100644
>> --- a/drivers/net/fsl-mc/mc.c
>> +++ b/drivers/net/fsl-mc/mc.c
>> @@ -29,6 +29,7 @@
>> DECLARE_GLOBAL_DATA_PTR;
>> static int mc_boot_status = -1;
>> static int mc_dpl_applied = -1;
>> +static u64 mc_ram_aligned_base_addr;
>
> Why do you need this static variable? You didn't use it.
> [Ashish Kumar] following two function uses global static variable
> -357,7 +369,6 @@ static unsigned long get_mc_boot_timeout_ms(void)
> #ifdef CONFIG_SYS_LS_MC_DRAM_AIOP_IMG_OFFSET
> static int load_mc_aiop_img(u64 aiop_fw_addr) {
> - u64 mc_ram_addr = mc_get_dram_addr();
> #ifndef CONFIG_SYS_LS_MC_DPC_IN_DDR
> void *aiop_img;
> #endif
>
>
> @@ -440,7 +451,6 @@ int mc_init(u64 mc_fw_addr, u64 mc_dpc_addr)
> size_t raw_image_size = 0;
> #endif
> struct mc_version mc_ver_info;
> - u64 mc_ram_aligned_base_addr;
> u8 mc_ram_num_256mb_blocks;
> size_t mc_ram_size = mc_get_dram_block_size();
>
You showed the deletion of local variable. You added a static variable, but also use local variable within function. The only place where this static variable gets assigned is by a pointer in calculate_mc_private_ram_params(). I don't see the need to declare it as a global variable.
[Ashish Kumar] Yes true, it is first set here then used from global instance in func: mc_apply_dpl(64 mc_dpl_addr) { ... error = load_mc_dpl(mc_ram_aligned_base_addr, mc_ram_size, mc_dpl_addr);... } and
Then in func: load_mc_aiop_img((u64 aiop_fw_addr) {... mc_copy_image(...) ...}
>> #ifdef CONFIG_SYS_LS_MC_DRAM_AIOP_IMG_OFFSET
>> static int mc_aiop_applied = -1;
>> #endif
>> @@ -87,12 +88,15 @@ void dump_mc_ccsr_regs(struct mc_ccsr_registers
>> __iomem *mc_ccsr_regs)
>> /**
>> * Copying MC firmware or DPL image to DDR
>> */
>> -static int mc_copy_image(const char *title,
>> - u64 image_addr, u32 image_size, u64 mc_ram_addr)
>> +static int mc_copy_image(const char *title, u64 image_addr,
>> + u32 image_size, u64 mc_ram_aligned_base_addr)
>> {
>> - debug("%s copied to address %p\n", title, (void *)mc_ram_addr);
>> - memcpy((void *)mc_ram_addr, (void *)image_addr, image_size);
>> - flush_dcache_range(mc_ram_addr, mc_ram_addr + image_size);
>> + debug("%s copied to address %p\n", title,
>> + (void *)mc_ram_aligned_base_addr);
>> + memcpy((void *)mc_ram_aligned_base_addr,
>> + (void *)image_addr, image_size);
>> + flush_dcache_range(mc_ram_aligned_base_addr,
>> + mc_ram_aligned_base_addr + image_size);
>> return 0;
>> }
>>
>> @@ -224,7 +228,8 @@ static int mc_fixup_dpc(u64 dpc_addr)
>> return 0;
>> }
>>
>> -static int load_mc_dpc(u64 mc_ram_addr, size_t mc_ram_size, u64
>> mc_dpc_addr)
>> +static int load_mc_dpc(u64 mc_ram_aligned_base_addr, size_t mc_ram_size,
>> + u64 mc_dpc_addr)
>> {
>> u64 mc_dpc_offset;
>> #ifndef CONFIG_SYS_LS_MC_DPC_IN_DDR
>> @@ -246,7 +251,8 @@ static int load_mc_dpc(u64 mc_ram_addr, size_t mc_ram_size, u64 mc_dpc_addr)
>> * Load the MC DPC blob in the MC private DRAM block:
>> */
>> #ifdef CONFIG_SYS_LS_MC_DPC_IN_DDR
>> - printf("MC DPC is preloaded to %#llx\n", mc_ram_addr + mc_dpc_offset);
>> + printf("MC DPC is preloaded to %#llx\n",
>> + mc_ram_aligned_base_addr + mc_dpc_offset);
>> #else
>> /*
>> * Get address and size of the DPC blob stored in flash:
>> @@ -270,18 +276,20 @@ static int load_mc_dpc(u64 mc_ram_addr, size_t mc_ram_size, u64 mc_dpc_addr)
>> return -EINVAL;
>> }
>>
>> - mc_copy_image("MC DPC blob",
>> - (u64)dpc_fdt_hdr, dpc_size, mc_ram_addr + mc_dpc_offset);
>> + mc_copy_image("MC DPC blob", (u64)dpc_fdt_hdr, dpc_size,
>> + mc_ram_aligned_base_addr + mc_dpc_offset);
>> #endif /* not defined CONFIG_SYS_LS_MC_DPC_IN_DDR */
>>
>> - if (mc_fixup_dpc(mc_ram_addr + mc_dpc_offset))
>> + if (mc_fixup_dpc(mc_ram_aligned_base_addr + mc_dpc_offset))
>> return -EINVAL;
>>
>> - dump_ram_words("DPC", (void *)(mc_ram_addr + mc_dpc_offset));
>> + dump_ram_words("DPC",
>> + (void *)(mc_ram_aligned_base_addr + mc_dpc_offset));
>> return 0;
>> }
>>
>> -static int load_mc_dpl(u64 mc_ram_addr, size_t mc_ram_size, u64
>> mc_dpl_addr)
>> +static int load_mc_dpl(u64 mc_ram_aligned_base_addr, size_t mc_ram_size,
>> + u64 mc_dpl_addr)
>> {
>> u64 mc_dpl_offset;
>> #ifndef CONFIG_SYS_LS_MC_DPL_IN_DDR
>> @@ -303,7 +311,8 @@ static int load_mc_dpl(u64 mc_ram_addr, size_t mc_ram_size, u64 mc_dpl_addr)
>> * Load the MC DPL blob in the MC private DRAM block:
>> */
>> #ifdef CONFIG_SYS_LS_MC_DPL_IN_DDR
>> - printf("MC DPL is preloaded to %#llx\n", mc_ram_addr + mc_dpl_offset);
>> + printf("MC DPL is preloaded to %#llx\n",
>> + mc_ram_aligned_base_addr + mc_dpl_offset);
>> #else
>> /*
>> * Get address and size of the DPL blob stored in flash:
>> @@ -323,11 +332,12 @@ static int load_mc_dpl(u64 mc_ram_addr, size_t mc_ram_size, u64 mc_dpl_addr)
>> return -EINVAL;
>> }
>>
>> - mc_copy_image("MC DPL blob",
>> - (u64)dpl_fdt_hdr, dpl_size, mc_ram_addr + mc_dpl_offset);
>> + mc_copy_image("MC DPL blob", (u64)dpl_fdt_hdr, dpl_size,
>> + mc_ram_aligned_base_addr + mc_dpl_offset);
>> #endif /* not defined CONFIG_SYS_LS_MC_DPL_IN_DDR */
>>
>> - dump_ram_words("DPL", (void *)(mc_ram_addr + mc_dpl_offset));
>> + dump_ram_words("DPL",
>> + (void *)(mc_ram_aligned_base_addr + mc_dpl_offset));
>> return 0;
>> }
>>
>> @@ -364,7 +374,6 @@ __weak bool soc_has_aiop(void)
>>
>> static int load_mc_aiop_img(u64 aiop_fw_addr) {
>> - u64 mc_ram_addr = mc_get_dram_addr();
>> #ifndef CONFIG_SYS_LS_MC_DPC_IN_DDR
>> void *aiop_img;
>> #endif
>> @@ -377,13 +386,14 @@ static int load_mc_aiop_img(u64 aiop_fw_addr)
>> */
>>
>> #ifdef CONFIG_SYS_LS_MC_DPC_IN_DDR
>> - printf("MC AIOP is preloaded to %#llx\n", mc_ram_addr +
>> + printf("MC AIOP is preloaded to %#llx\n", mc_ram_aligned_base_addr
>> ++
>> CONFIG_SYS_LS_MC_DRAM_AIOP_IMG_OFFSET);
>> #else
>> aiop_img = (void *)aiop_fw_addr;
>> mc_copy_image("MC AIOP image",
>> (u64)aiop_img, CONFIG_SYS_LS_MC_AIOP_IMG_MAX_LENGTH,
>> - mc_ram_addr + CONFIG_SYS_LS_MC_DRAM_AIOP_IMG_OFFSET);
>> + mc_ram_aligned_base_addr +
>> + CONFIG_SYS_LS_MC_DRAM_AIOP_IMG_OFFSET);
>> #endif
>> mc_aiop_applied = 0;
>>
>> @@ -450,7 +460,6 @@ int mc_init(u64 mc_fw_addr, u64 mc_dpc_addr)
>> size_t raw_image_size = 0;
>> #endif
>> struct mc_version mc_ver_info;
>> - u64 mc_ram_aligned_base_addr;
>> u8 mc_ram_num_256mb_blocks;
>> size_t mc_ram_size = mc_get_dram_block_size();
>>
>> @@ -478,7 +487,7 @@ int mc_init(u64 mc_fw_addr, u64 mc_dpc_addr)
>> dmb();
>>
>> #ifdef CONFIG_SYS_LS_MC_FW_IN_DDR
>> - printf("MC firmware is preloaded to %#llx\n", mc_ram_addr);
>> + printf("MC firmware is preloaded to %#llx\n",
>> +mc_ram_aligned_base_addr);
>> #else
>> error = parse_mc_firmware_fit_image(mc_fw_addr, &raw_image_addr,
>> &raw_image_size);
>> @@ -487,12 +496,12 @@ int mc_init(u64 mc_fw_addr, u64 mc_dpc_addr)
>> /*
>> * Load the MC FW at the beginning of the MC private DRAM block:
>> */
>> - mc_copy_image("MC Firmware",
>> - (u64)raw_image_addr, raw_image_size, mc_ram_addr);
>> + mc_copy_image("MC Firmware", (u64)raw_image_addr, raw_image_size,
>> + mc_ram_aligned_base_addr);
>> #endif
>> - dump_ram_words("firmware", (void *)mc_ram_addr);
>> + dump_ram_words("firmware", (void *)mc_ram_aligned_base_addr);
>>
>> - error = load_mc_dpc(mc_ram_addr, mc_ram_size, mc_dpc_addr);
>> + error = load_mc_dpc(mc_ram_aligned_base_addr, mc_ram_size,
>> +mc_dpc_addr);
>> if (error != 0)
>> goto out;
>>
>> @@ -569,10 +578,9 @@ int mc_apply_dpl(u64 mc_dpl_addr)
>> struct mc_ccsr_registers __iomem *mc_ccsr_regs = MC_CCSR_BASE_ADDR;
>> int error = 0;
>> u32 reg_gsr;
>> - u64 mc_ram_addr = mc_get_dram_addr();
>> size_t mc_ram_size = mc_get_dram_block_size();
>>
>> - error = load_mc_dpl(mc_ram_addr, mc_ram_size, mc_dpl_addr);
>> + error = load_mc_dpl(mc_ram_aligned_base_addr, mc_ram_size,
>> +mc_dpl_addr);
>> if (error != 0)
>> return error;
>>
>>
>
> Do you have substantial change beside the changing name from mc_ram_addr to mc_ram_aligned_base_addr?
> [Ashish Kumar] It is not exactly name change. Here intent is to use userdefine memory size for MC before this only 512MB of memory can be allocated to MC since it incorrectly used mc_ram_addr in place of mc_aligned_base_addr.
> Ok, Name changes are there only in the function parameters to avoid confusion and retain the function signatures.
Actually your change is more confusing. Let us try another way, for example not changing the name, shall we?
[Ashish Kumar] If we do not rename function params "mc_ram_addr" to this "mc_ram_aligned_base_addr", we will be actually using aligned_base_addr but in function params it will be denoted as mc_ram_addr will that be correct?
York
^ permalink raw reply
* [PATCH] pinctrl: amd: Add support for additional GPIO
From: Shah, Nehal-bakulchandra @ 2016-11-09 10:28 UTC (permalink / raw)
To: linus.walleij@linaro.org, gnurou@gmail.com
Cc: linux-gpio@vger.kernel.org, S-k, Shyam-sundar
This Provide IRQ sharing for AMD's GPIO devices.And set IRQCHIP_SKIP_SET_WAKE flag.
Also, fix the build issue for devm_request_irq()
Reviewed-by: S-k, Shyam-sundar <Shyam-sundar.S-k@amd.com>
Signed-off-by: Nehal Shah <Nehal-bakulchandra.Shah@amd.com>
---
drivers/pinctrl/pinctrl-amd.c | 50 ++++++++++++++++++++++++++-----------------
drivers/pinctrl/pinctrl-amd.h | 8 ++++---
2 files changed, 35 insertions(+), 23 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-amd.c b/drivers/pinctrl/pinctrl-amd.c
index aea310a..29ad8e1 100644
--- a/drivers/pinctrl/pinctrl-amd.c
+++ b/drivers/pinctrl/pinctrl-amd.c
@@ -186,7 +186,7 @@ static void amd_gpio_dbg_show(struct seq_file *s, struct gpio_chip *gc)
char *output_value;
char *output_enable;
- for (bank = 0; bank < AMD_GPIO_TOTAL_BANKS; bank++) {
+ for (bank = 0; bank < gpio_dev->hwbank_num; bank++) {
seq_printf(s, "GPIO bank%d\t", bank);
switch (bank) {
@@ -202,6 +202,10 @@ static void amd_gpio_dbg_show(struct seq_file *s, struct gpio_chip *gc)
i = 128;
pin_num = AMD_GPIO_PINS_BANK2 + i;
break;
+ case 3:
+ i = 192;
+ pin_num = AMD_GPIO_PINS_BANK3 + i;
+ break;
}
for (; i < pin_num; i++) {
@@ -244,17 +248,17 @@ static void amd_gpio_dbg_show(struct seq_file *s, struct gpio_chip *gc)
interrupt_mask =
"interrupt is masked|";
- if (pin_reg & BIT(WAKE_CNTRL_OFF))
+ if (pin_reg & BIT(WAKE_CNTRL_OFF_S0I3))
wake_cntrl0 = "enable wakeup in S0i3 state|";
else
wake_cntrl0 = "disable wakeup in S0i3 state|";
- if (pin_reg & BIT(WAKE_CNTRL_OFF))
+ if (pin_reg & BIT(WAKE_CNTRL_OFF_S3))
wake_cntrl1 = "enable wakeup in S3 state|";
else
wake_cntrl1 = "disable wakeup in S3 state|";
- if (pin_reg & BIT(WAKE_CNTRL_OFF))
+ if (pin_reg & BIT(WAKE_CNTRL_OFF_S4))
wake_cntrl2 = "enable wakeup in S4/S5 state|";
else
wake_cntrl2 = "disable wakeup in S4/S5 state|";
@@ -479,9 +483,10 @@ static struct irq_chip amd_gpio_irqchip = {
.irq_unmask = amd_gpio_irq_unmask,
.irq_eoi = amd_gpio_irq_eoi,
.irq_set_type = amd_gpio_irq_set_type,
+ .flags = IRQCHIP_SKIP_SET_WAKE,
};
-static void amd_gpio_irq_handler(struct irq_desc *desc)
+static irqreturn_t amd_gpio_irq_handler(int irq, void *data)
{
u32 i;
u32 off;
@@ -489,13 +494,9 @@ static void amd_gpio_irq_handler(struct irq_desc *desc)
u32 pin_reg;
u64 reg64;
int handled = 0;
- unsigned int irq;
unsigned long flags;
- struct irq_chip *chip = irq_desc_get_chip(desc);
- struct gpio_chip *gc = irq_desc_get_handler_data(desc);
- struct amd_gpio *gpio_dev = gpiochip_get_data(gc);
+ struct amd_gpio *gpio_dev = data;
- chained_irq_enter(chip, desc);
/*enable GPIO interrupt again*/
spin_lock_irqsave(&gpio_dev->lock, flags);
reg = readl(gpio_dev->base + WAKE_INT_STATUS_REG1);
@@ -517,8 +518,9 @@ static void amd_gpio_irq_handler(struct irq_desc *desc)
(off * 4 + i) * 4);
if ((pin_reg & BIT(INTERRUPT_STS_OFF)) ||
(pin_reg & BIT(WAKE_STS_OFF))) {
- irq = irq_find_mapping(gc->irqdomain,
- off * 4 + i);
+ irq = irq_find_mapping(
+ gpio_dev->gc.irqdomain,
+ off * 4 + i);
generic_handle_irq(irq);
writel(pin_reg,
gpio_dev->base
@@ -529,16 +531,13 @@ static void amd_gpio_irq_handler(struct irq_desc *desc)
}
}
- if (handled == 0)
- handle_bad_irq(desc);
-
spin_lock_irqsave(&gpio_dev->lock, flags);
reg = readl(gpio_dev->base + WAKE_INT_MASTER_REG);
reg |= EOI_MASK;
writel(reg, gpio_dev->base + WAKE_INT_MASTER_REG);
spin_unlock_irqrestore(&gpio_dev->lock, flags);
- chained_irq_exit(chip, desc);
+ return 0;
}
static int amd_get_groups_count(struct pinctrl_dev *pctldev)
@@ -727,10 +726,14 @@ static struct pinctrl_desc amd_pinctrl_desc = {
static int amd_gpio_probe(struct platform_device *pdev)
{
+ int hwnum;
int ret = 0;
int irq_base;
struct resource *res;
struct amd_gpio *gpio_dev;
+ struct acpi_device *adev = ACPI_COMPANION(&pdev->dev);
+
+ ret = kstrtoint(acpi_device_uid(adev), 2, &hwnum);
gpio_dev = devm_kzalloc(&pdev->dev,
sizeof(struct amd_gpio), GFP_KERNEL);
@@ -763,16 +766,17 @@ static int amd_gpio_probe(struct platform_device *pdev)
gpio_dev->gc.set = amd_gpio_set_value;
gpio_dev->gc.set_debounce = amd_gpio_set_debounce;
gpio_dev->gc.dbg_show = amd_gpio_dbg_show;
+ gpio_dev->gc.base = gpio_dev->gc.ngpio * hwnum;
- gpio_dev->gc.base = 0;
gpio_dev->gc.label = pdev->name;
gpio_dev->gc.owner = THIS_MODULE;
gpio_dev->gc.parent = &pdev->dev;
- gpio_dev->gc.ngpio = TOTAL_NUMBER_OF_PINS;
+ gpio_dev->gc.ngpio = resource_size(res) / 4;
#if defined(CONFIG_OF_GPIO)
gpio_dev->gc.of_node = pdev->dev.of_node;
#endif
+ gpio_dev->hwbank_num = gpio_dev->gc.ngpio / 64;
gpio_dev->groups = kerncz_groups;
gpio_dev->ngroups = ARRAY_SIZE(kerncz_groups);
@@ -789,7 +793,7 @@ static int amd_gpio_probe(struct platform_device *pdev)
return ret;
ret = gpiochip_add_pin_range(&gpio_dev->gc, dev_name(&pdev->dev),
- 0, 0, TOTAL_NUMBER_OF_PINS);
+ 0, 0, gpio_dev->gc.ngpio);
if (ret) {
dev_err(&pdev->dev, "Failed to add pin range\n");
goto out2;
@@ -809,7 +813,12 @@ static int amd_gpio_probe(struct platform_device *pdev)
gpiochip_set_chained_irqchip(&gpio_dev->gc,
&amd_gpio_irqchip,
irq_base,
- amd_gpio_irq_handler);
+ NULL);
+
+ ret = devm_request_irq(&pdev->dev, irq_base, amd_gpio_irq_handler,
+ IRQF_SHARED, dev_name(&pdev->dev), gpio_dev);
+ if (ret)
+ goto out2;
platform_set_drvdata(pdev, gpio_dev);
@@ -829,6 +838,7 @@ static int amd_gpio_remove(struct platform_device *pdev)
gpio_dev = platform_get_drvdata(pdev);
gpiochip_remove(&gpio_dev->gc);
+ pinctrl_unregister(gpio_dev->pctrl);
return 0;
}
diff --git a/drivers/pinctrl/pinctrl-amd.h b/drivers/pinctrl/pinctrl-amd.h
index 7bfea47..c03f778 100644
--- a/drivers/pinctrl/pinctrl-amd.h
+++ b/drivers/pinctrl/pinctrl-amd.h
@@ -13,13 +13,12 @@
#ifndef _PINCTRL_AMD_H
#define _PINCTRL_AMD_H
-#define TOTAL_NUMBER_OF_PINS 192
#define AMD_GPIO_PINS_PER_BANK 64
-#define AMD_GPIO_TOTAL_BANKS 3
#define AMD_GPIO_PINS_BANK0 63
#define AMD_GPIO_PINS_BANK1 64
#define AMD_GPIO_PINS_BANK2 56
+#define AMD_GPIO_PINS_BANK3 32
#define WAKE_INT_MASTER_REG 0xfc
#define EOI_MASK (1 << 29)
@@ -35,7 +34,9 @@
#define ACTIVE_LEVEL_OFF 9
#define INTERRUPT_ENABLE_OFF 11
#define INTERRUPT_MASK_OFF 12
-#define WAKE_CNTRL_OFF 13
+#define WAKE_CNTRL_OFF_S0I3 13
+#define WAKE_CNTRL_OFF_S3 14
+#define WAKE_CNTRL_OFF_S4 15
#define PIN_STS_OFF 16
#define DRV_STRENGTH_SEL_OFF 17
#define PULL_UP_SEL_OFF 19
@@ -93,6 +94,7 @@ struct amd_gpio {
u32 ngroups;
struct pinctrl_dev *pctrl;
struct gpio_chip gc;
+ unsigned int hwbank_num;
struct resource *res;
struct platform_device *pdev;
};
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v8 3/3] fpga: Add support for Lattice iCE40 FPGAs
From: Marek Vasut @ 2016-11-09 12:01 UTC (permalink / raw)
To: Joel Holdsworth, Moritz Fischer
Cc: Alan Tull, Geert Uytterhoeven, Rob Herring, Devicetree List,
Linux Kernel Mailing List, linux-spi, Clifford Wolf
In-Reply-To: <feae0954-7e85-3946-defe-ce252869786d@airwebreathe.org.uk>
On 11/08/2016 06:30 PM, Joel Holdsworth wrote:
>>>> On the whole, I don't think the zero-length transfers are too
>>>> egregiously bad, and all the alternatives seem worse to me.
>>>
>>> So why not turn the CS line into GPIO and just toggle the GPIO?
>>
>> Does that work with *all* SPI controllers?
>>
>
> It does not - no. See my other email.
And is that line an actual CS of that lattice chip or a generic input
which almost works like CS?
--
Best regards,
Marek Vasut
^ permalink raw reply
* question: is it a CVE in relinquish_memory()[xen/arch/x86/domain.c]
From: Xuquan (Quan Xu) @ 2016-11-09 12:01 UTC (permalink / raw)
To: xen-devel@lists.xen.org
Cc: Tian, Kevin, Liuxiaojian (alex), George.Dunlap@eu.citrix.com,
Andrew Cooper, Tim Deegan, Xuquan (Quan Xu), JBeulich@suse.com,
dgdegra@tycho.nsa.gov
Hi,
Based on CVE-2015-7814 and commit 1ef01396fdff, ' arm: handle races between relinquish_memory and free_domheap_pages'..
relinquish_memory() [xen/arch/arm/domain.c, arm code],
when couldn't get a reference -- someone is freeing this page and has already committed to doing so, so no more to do here, continue.
But in relinquish_memory()[xen/arch/x86/domain.c, __x86__ code], when couldn't get a reference -- someone is freeing this page,
Why adding this page to d->arch.relmem_list again.
Is it a CVE to double free page, then hit the ''" alloc_heap_pages() : BUG_ON(pg[i].count_info != PGC_state_free)"" in creating guests later..
========
[1] CVE-2015-7814
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7814
[2] commit 1ef01396fdff
commit 1ef01396fdff88b1c3331a09ca5c69619b90f4ea
Author: Ian Campbell <ian.campbell@citrix.com>
Date: Thu Oct 29 13:34:17 2015 +0100
arm: handle races between relinquish_memory and free_domheap_pages
Primarily this means XENMEM_decrease_reservation from a toolstack
domain.
Unlike x86 we have no requirement right now to queue such pages onto
a separate list, if we hit this race then the other code has already
fully accepted responsibility for freeing this page and therefore
there is no more for relinquish_memory to do.
This is CVE-2015-7814 / XSA-147.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 683e769..880d0a6 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -772,8 +772,15 @@ static int relinquish_memory(struct domain *d, struct page_list_head *list)
{
/* Grab a reference to the page so it won't disappear from under us. */
if ( unlikely(!get_page(page, d)) )
- /* Couldn't get a reference -- someone is freeing this page. */
- BUG();
+ /*
+ * Couldn't get a reference -- someone is freeing this page and
+ * has already committed to doing so, so no more to do here.
+ *
+ * Note that the page must be left on the list, a list_del
+ * here will clash with the list_del done by the other
+ * party in the race and corrupt the list head.
+ */
+ continue;
if ( test_and_clear_bit(_PGC_allocated, &page->count_info) )
put_page(page);
~
Quan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related
* Re: [Qemu-devel] [kvm-unit-tests PATCH v4 03/11] arm/arm64: smp: support more than 8 cpus
From: Andre Przywara @ 2016-11-09 12:01 UTC (permalink / raw)
To: Andrew Jones
Cc: kvm, kvmarm, qemu-devel, qemu-arm, pbonzini, peter.maydell,
alex.bennee, marc.zyngier, eric.auger, christoffer.dall
In-Reply-To: <20161109115732.hpiaiigtgfgnrybt@kamzik.brq.redhat.com>
Hi,
On 09/11/16 11:57, Andrew Jones wrote:
> On Wed, Nov 09, 2016 at 11:12:03AM +0000, Andre Przywara wrote:
> [...]
>>> diff --git a/lib/arm/setup.c b/lib/arm/setup.c
>>> index 7e7b39f11dde..b6e2d5815e72 100644
>>> --- a/lib/arm/setup.c
>>> +++ b/lib/arm/setup.c
>>> @@ -24,12 +24,22 @@ extern unsigned long stacktop;
>>> extern void io_init(void);
>>> extern void setup_args_progname(const char *args);
>>>
>>> -u32 cpus[NR_CPUS] = { [0 ... NR_CPUS-1] = (~0U) };
>>> +u64 cpus[NR_CPUS] = { [0 ... NR_CPUS-1] = (~0U) };
>>
>> This should be ~0UL.
>
> Indeed. Thanks.
>
>> Also I think the type should be unsigned long to match the types used
>> everywhere else.
>
> I'll change mpidr_to_cpu to return u64 instead of unsigned long.
I am not sure this is the right direction. unsigned long is really the
natural type for MPIDR, since this is a system register with exactly the
native register size.
I think we use it this way in the kernel.
Cheers,
Andre
> Actually I think Alex suggested that. I'm not sure why I haven't
> done it...
>
>>
>>> int nr_cpus;
>>>
>>> struct mem_region mem_regions[NR_MEM_REGIONS];
>>> phys_addr_t __phys_offset, __phys_end;
>>>
>>> +int mpidr_to_cpu(unsigned long mpidr)
>>> +{
>>> + int i;
>>> +
>>> + for (i = 0; i < nr_cpus; ++i)
>>> + if (cpus[i] == (mpidr & MPIDR_HWID_BITMASK))
>>> + return i;
>>> + return -1;
>>> +}
>>> +
>>> static void cpu_set(int fdtnode __unused, u32 regval, void *info __unused)
>>
>> I guess this needs to be extended as well, including
>> dt_for_each_cpu_node() to cope with 64-bit reg properties in the CPU
>> node (where the upper word is not 0).
>> But this is not really crucial atm, so can be fixed in a follow-up patch.
>
> Yeah, I'll do it as a followup series, because it'll affect powerpc too.
>
> drew
>
^ permalink raw reply
* Re: [kvm-unit-tests PATCH v4 03/11] arm/arm64: smp: support more than 8 cpus
From: Andre Przywara @ 2016-11-09 12:01 UTC (permalink / raw)
To: Andrew Jones
Cc: kvm, kvmarm, qemu-devel, qemu-arm, pbonzini, peter.maydell,
alex.bennee, marc.zyngier, eric.auger, christoffer.dall
In-Reply-To: <20161109115732.hpiaiigtgfgnrybt@kamzik.brq.redhat.com>
Hi,
On 09/11/16 11:57, Andrew Jones wrote:
> On Wed, Nov 09, 2016 at 11:12:03AM +0000, Andre Przywara wrote:
> [...]
>>> diff --git a/lib/arm/setup.c b/lib/arm/setup.c
>>> index 7e7b39f11dde..b6e2d5815e72 100644
>>> --- a/lib/arm/setup.c
>>> +++ b/lib/arm/setup.c
>>> @@ -24,12 +24,22 @@ extern unsigned long stacktop;
>>> extern void io_init(void);
>>> extern void setup_args_progname(const char *args);
>>>
>>> -u32 cpus[NR_CPUS] = { [0 ... NR_CPUS-1] = (~0U) };
>>> +u64 cpus[NR_CPUS] = { [0 ... NR_CPUS-1] = (~0U) };
>>
>> This should be ~0UL.
>
> Indeed. Thanks.
>
>> Also I think the type should be unsigned long to match the types used
>> everywhere else.
>
> I'll change mpidr_to_cpu to return u64 instead of unsigned long.
I am not sure this is the right direction. unsigned long is really the
natural type for MPIDR, since this is a system register with exactly the
native register size.
I think we use it this way in the kernel.
Cheers,
Andre
> Actually I think Alex suggested that. I'm not sure why I haven't
> done it...
>
>>
>>> int nr_cpus;
>>>
>>> struct mem_region mem_regions[NR_MEM_REGIONS];
>>> phys_addr_t __phys_offset, __phys_end;
>>>
>>> +int mpidr_to_cpu(unsigned long mpidr)
>>> +{
>>> + int i;
>>> +
>>> + for (i = 0; i < nr_cpus; ++i)
>>> + if (cpus[i] == (mpidr & MPIDR_HWID_BITMASK))
>>> + return i;
>>> + return -1;
>>> +}
>>> +
>>> static void cpu_set(int fdtnode __unused, u32 regval, void *info __unused)
>>
>> I guess this needs to be extended as well, including
>> dt_for_each_cpu_node() to cope with 64-bit reg properties in the CPU
>> node (where the upper word is not 0).
>> But this is not really crucial atm, so can be fixed in a follow-up patch.
>
> Yeah, I'll do it as a followup series, because it'll affect powerpc too.
>
> drew
>
^ permalink raw reply
* Re: [kvm-unit-tests PATCH v4 03/11] arm/arm64: smp: support more than 8 cpus
From: Andre Przywara @ 2016-11-09 12:01 UTC (permalink / raw)
To: Andrew Jones; +Cc: kvm, marc.zyngier, qemu-devel, qemu-arm, pbonzini, kvmarm
In-Reply-To: <20161109115732.hpiaiigtgfgnrybt@kamzik.brq.redhat.com>
Hi,
On 09/11/16 11:57, Andrew Jones wrote:
> On Wed, Nov 09, 2016 at 11:12:03AM +0000, Andre Przywara wrote:
> [...]
>>> diff --git a/lib/arm/setup.c b/lib/arm/setup.c
>>> index 7e7b39f11dde..b6e2d5815e72 100644
>>> --- a/lib/arm/setup.c
>>> +++ b/lib/arm/setup.c
>>> @@ -24,12 +24,22 @@ extern unsigned long stacktop;
>>> extern void io_init(void);
>>> extern void setup_args_progname(const char *args);
>>>
>>> -u32 cpus[NR_CPUS] = { [0 ... NR_CPUS-1] = (~0U) };
>>> +u64 cpus[NR_CPUS] = { [0 ... NR_CPUS-1] = (~0U) };
>>
>> This should be ~0UL.
>
> Indeed. Thanks.
>
>> Also I think the type should be unsigned long to match the types used
>> everywhere else.
>
> I'll change mpidr_to_cpu to return u64 instead of unsigned long.
I am not sure this is the right direction. unsigned long is really the
natural type for MPIDR, since this is a system register with exactly the
native register size.
I think we use it this way in the kernel.
Cheers,
Andre
> Actually I think Alex suggested that. I'm not sure why I haven't
> done it...
>
>>
>>> int nr_cpus;
>>>
>>> struct mem_region mem_regions[NR_MEM_REGIONS];
>>> phys_addr_t __phys_offset, __phys_end;
>>>
>>> +int mpidr_to_cpu(unsigned long mpidr)
>>> +{
>>> + int i;
>>> +
>>> + for (i = 0; i < nr_cpus; ++i)
>>> + if (cpus[i] == (mpidr & MPIDR_HWID_BITMASK))
>>> + return i;
>>> + return -1;
>>> +}
>>> +
>>> static void cpu_set(int fdtnode __unused, u32 regval, void *info __unused)
>>
>> I guess this needs to be extended as well, including
>> dt_for_each_cpu_node() to cope with 64-bit reg properties in the CPU
>> node (where the upper word is not 0).
>> But this is not really crucial atm, so can be fixed in a follow-up patch.
>
> Yeah, I'll do it as a followup series, because it'll affect powerpc too.
>
> drew
>
^ permalink raw reply
* Re: [PATCH] curl: Upgrade 7.50.1.bb -> curl_7.51.0.bb
From: Sona Sarmadi @ 2016-11-09 11:58 UTC (permalink / raw)
To: Richard Purdie (richard.purdie@linuxfoundation.org),
Armin Kuster (akuster808@gmail.com)
Cc: openembedded-core@lists.openembedded.org
In-Reply-To: <1478601718-12481-1-git-send-email-sona.sarmadi@enea.com>
Hi guys,
curl 7.51.0-r0 addresses all these CVEs. I wonder if we can upgrade krogoth and morty to curl 7.51.0-r0 as well? Both package versions are using same share library version i.e. libcurl.so.4.4.0 so I assume full ABI compatibility.
tmp/work/i586-poky-linux/curl/7.47.1-r0/sysroot-destdir/usr/lib/libcurl.so.4.4.0
tmp/work/i586-poky-linux/curl/7.51.0-r0/sysroot-destdir/usr/lib/libcurl.so.4.4.0
For more info see:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10617
Thanks
//Sona
-----Original Message-----
From: openembedded-core-bounces@lists.openembedded.org [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of Sona Sarmadi
Sent: den 8 november 2016 11:42
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH] curl: Upgrade 7.50.1.bb -> curl_7.51.0.bb
The upgrade addresses following CVEs:
CVE-2016-8615: cookie injection for other servers
CVE-2016-8616: case insensitive password comparison
CVE-2016-8617: OOB write via unchecked multiplication
CVE-2016-8618: double-free in curl_maprintf
CVE-2016-8619: double-free in krb5 code
CVE-2016-8620: glob parser write/read out of bounds
CVE-2016-8621: curl_getdate read out of bounds
CVE-2016-8622: URL unescape heap overflow via integer truncation
CVE-2016-8623: Use-after-free via shared cookies
CVE-2016-8624: invalid URL parsing with '#'
CVE-2016-8625: IDNA 2003 makes curl use wrong host
Reference:
https://curl.haxx.se/docs/security.html
Fixes [Yocto #10617]
Signed-off-by: Sona Sarmadi <sona.sarmadi@enea.com>
---
meta/recipes-support/curl/{curl_7.50.1.bb => curl_7.51.0.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-support/curl/{curl_7.50.1.bb => curl_7.51.0.bb} (94%)
diff --git a/meta/recipes-support/curl/curl_7.50.1.bb b/meta/recipes-support/curl/curl_7.51.0.bb
similarity index 94%
rename from meta/recipes-support/curl/curl_7.50.1.bb
rename to meta/recipes-support/curl/curl_7.51.0.bb
index a21419a..e1a996b 100644
--- a/meta/recipes-support/curl/curl_7.50.1.bb
+++ b/meta/recipes-support/curl/curl_7.51.0.bb
@@ -14,8 +14,8 @@ SRC_URI = "http://curl.haxx.se/download/curl-${PV}.tar.bz2 \ # SRC_URI += " file://configure_ac.patch"
-SRC_URI[md5sum] = "015f6a0217ca6f2c5442ca406476920b"
-SRC_URI[sha256sum] = "3c12c5f54ccaa1d40abc65d672107dcc75d3e1fcb38c267484334280096e5156"
+SRC_URI[md5sum] = "09a7c5769a7eae676d5e2c86d51f167e"
+SRC_URI[sha256sum] = "7f8240048907e5030f67be0a6129bc4b333783b9cca1391026d700835a788dde"
inherit autotools pkgconfig binconfig multilib_header
--
1.9.1
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
^ permalink raw reply related
* Re: [Qemu-devel] virsh dump (qemu guest memory dump?): KASLR enabled linux guest support
From: Daniel P. Berrange @ 2016-11-09 11:58 UTC (permalink / raw)
To: Andrew Jones
Cc: Laszlo Ersek, Dave Young, qiaonuohan, bhe, anderson, qemu-devel
In-Reply-To: <20161109114809.cawi6tpsxwn5vfql@kamzik.brq.redhat.com>
On Wed, Nov 09, 2016 at 12:48:09PM +0100, Andrew Jones wrote:
> On Wed, Nov 09, 2016 at 11:37:35AM +0000, Daniel P. Berrange wrote:
> > On Wed, Nov 09, 2016 at 12:26:17PM +0100, Laszlo Ersek wrote:
> > > On 11/09/16 11:40, Andrew Jones wrote:
> > > > On Wed, Nov 09, 2016 at 11:01:46AM +0800, Dave Young wrote:
> > > >> Hi,
> > > >>
> > > >> Latest linux kernel enabled kaslr to randomiz phys/virt memory
> > > >> addresses, we had some effort to support kexec/kdump so that crash
> > > >> utility can still works in case crashed kernel has kaslr enabled.
> > > >>
> > > >> But according to Dave Anderson virsh dump does not work, quoted messages
> > > >> from Dave below:
> > > >>
> > > >> """
> > > >> with virsh dump, there's no way of even knowing that KASLR
> > > >> has randomized the kernel __START_KERNEL_map region, because there is no
> > > >> virtual address information -- e.g., like "SYMBOL(_stext)" in the kdump
> > > >> vmcoreinfo data to compare against the vmlinux file symbol value.
> > > >> Unless virsh dump can export some basic virtual memory data, which
> > > >> they say it can't, I don't see how KASLR can ever be supported.
> > > >> """
> > > >>
> > > >> I assume virsh dump is using qemu guest memory dump facility so it
> > > >> should be first addressed in qemu. Thus post this query to qemu devel
> > > >> list. If this is not correct please let me know.
> > > >>
> > > >> Could you qemu dump people make it work? Or we can not support virt dump
> > > >> as long as KASLR being enabled. Latest Fedora kernel has enabled it in x86_64.
> > > >>
> > > >
> > > > When the -kernel command line option is used, then it may be possible
> > > > to extract some information that could be used to supplement the memory
> > > > dump that dump-guest-memory provides. However, that would be a specific
> > > > use. In general, QEMU knows nothing about the guest kernel. It doesn't
> > > > know where it is in the disk image, and it doesn't even know if it's
> > > > Linux.
> > > >
> > > > Is there anything a guest userspace application could probe from e.g.
> > > > /proc that would work? If so, then the guest agent could gain a new
> > > > feature providing that.
> > >
> > > I fully agree. This is exactly what I suggested too, independently, in
> > > the downstream thread, before arriving at this upstream thread. Let me
> > > quote that email:
> > >
> > > On 11/09/16 12:09, Laszlo Ersek wrote:
> > > > [...] the dump-guest-memory QEMU command supports an option called
> > > > "paging". Here's its documentation, from the "qapi-schema.json" source
> > > > file:
> > > >
> > > >> # @paging: if true, do paging to get guest's memory mapping. This allows
> > > >> # using gdb to process the core file.
> > > >> #
> > > >> # IMPORTANT: this option can make QEMU allocate several gigabytes
> > > >> # of RAM. This can happen for a large guest, or a
> > > >> # malicious guest pretending to be large.
> > > >> #
> > > >> # Also, paging=true has the following limitations:
> > > >> #
> > > >> # 1. The guest may be in a catastrophic state or can have corrupted
> > > >> # memory, which cannot be trusted
> > > >> # 2. The guest can be in real-mode even if paging is enabled. For
> > > >> # example, the guest uses ACPI to sleep, and ACPI sleep state
> > > >> # goes in real-mode
> > > >> # 3. Currently only supported on i386 and x86_64.
> > > >> #
> > > >
> > > > "virsh dump --memory-only" sets paging=false, for obvious reasons.
> > > >
> > > > [...] the dump-guest-memory command provides a raw snapshot of the
> > > > virtual machine's memory (and of the registers of the VCPUs); it is
> > > > not enlightened about the guest.
> > > >
> > > > If the additional information you are looking for can be retrieved
> > > > within the running Linux guest, using an appropriately privieleged
> > > > userspace process, then I would recommend considering an extension to
> > > > the qemu guest agent. The management layer (libvirt, [...]) could
> > > > first invoke the guest agent (a process with root privileges running
> > > > in the guest) from the host side, through virtio-serial. The new guest
> > > > agent command would return the information necessary to deal with
> > > > KASLR. Then the management layer would initiate the dump like always.
> > > > Finally, the extra information would be combined with (or placed
> > > > beside) the dump file in some way.
> > > >
> > > > So, this proposal would affect the guest agent and the management
> > > > layer (= libvirt).
> > >
> > > Given that we already dislike "paging=true", enlightening
> > > dump-guest-memory with even more guest-specific insight is the wrong
> > > approach, IMO. That kind of knowledge belongs to the guest agent.
> >
> > If you're trying to debug a hung/panicked guest, then using a guest
> > agent to fetch info is a complete non-starter as it'll be dead.
>
> So don't wait. Management software can make this query immediately
> after the guest agent goes live. The information needed won't change.
That doesn't help with trying to diagnose a crash during boot up, since
the guest agent isn't running till fairly late. I'm also concerned that
the QEMU guest agent is likely to be far from widely deployed in guests,
so reliance on the guest agent will mean the dump facility is no longer
reliably available.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
^ permalink raw reply
* Re: [RFC] mem-hotplug: shall we skip unmovable node when doing numa balance?
From: Mel Gorman @ 2016-11-09 11:58 UTC (permalink / raw)
To: Xishi Qiu
Cc: Vlastimil Babka, Andrew Morton, Tang Chen, Linux MM, LKML,
robert.liu@huawei.com
In-Reply-To: <582157E5.8000106@huawei.com>
On Tue, Nov 08, 2016 at 12:43:17PM +0800, Xishi Qiu wrote:
> On mem-hotplug system, there is a problem, please see the following case.
>
> memtester xxG, the memory will be alloced on a movable node. And after numa
> balancing, the memory may be migrated to the other node, it may be a unmovable
> node. This will reduce the free memory of the unmovable node, and may be oom
> later.
>
How would it OOM later? It's movable memmory that is moving via
automatic NUMA balancing so at the very least it can be reclaimed. If
the memory is mlocked or unable to migrate then it's irrelevant if
automatic balancing put it there.
> My question is that shall we skip unmovable node when doing numa balance?
> or just let the manager set some numa policies?
>
If the unmovable node must be protected from automatic NUMA balancing
then policies are the appropriate step to prevent the processes running
on that node or from allocating memory on that node.
Either way, protecting unmovable nodes in the name of hotplug is pretty
much guaranteed to be a performance black hole because at the very
least, page table pages will always be remote accesses for processes
running on the unmovable node.
> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
> index 057964d..f0954ac 100644
> --- a/mm/mempolicy.c
> +++ b/mm/mempolicy.c
> @@ -2334,6 +2334,13 @@ int mpol_misplaced(struct page *page, struct vm_area_struct *vma, unsigned long
> out:
> mpol_cond_put(pol);
>
> + /* Skip unmovable nodes when do numa balancing */
> + if (movable_node_enabled && ret != -1) {
> + zone = NODE_DATA(ret)->node_zones + MAX_NR_ZONES - 1;
> + if (!populated_zone(zone))
> + ret = -1;
> + }
> +
> return ret;
> }
Nak.
--
Mel Gorman
SUSE Labs
^ permalink raw reply
* Re: [RFC] mem-hotplug: shall we skip unmovable node when doing numa balance?
From: Mel Gorman @ 2016-11-09 11:58 UTC (permalink / raw)
To: Xishi Qiu
Cc: Vlastimil Babka, Andrew Morton, Tang Chen, Linux MM, LKML,
robert.liu@huawei.com
In-Reply-To: <582157E5.8000106@huawei.com>
On Tue, Nov 08, 2016 at 12:43:17PM +0800, Xishi Qiu wrote:
> On mem-hotplug system, there is a problem, please see the following case.
>
> memtester xxG, the memory will be alloced on a movable node. And after numa
> balancing, the memory may be migrated to the other node, it may be a unmovable
> node. This will reduce the free memory of the unmovable node, and may be oom
> later.
>
How would it OOM later? It's movable memmory that is moving via
automatic NUMA balancing so at the very least it can be reclaimed. If
the memory is mlocked or unable to migrate then it's irrelevant if
automatic balancing put it there.
> My question is that shall we skip unmovable node when doing numa balance?
> or just let the manager set some numa policies?
>
If the unmovable node must be protected from automatic NUMA balancing
then policies are the appropriate step to prevent the processes running
on that node or from allocating memory on that node.
Either way, protecting unmovable nodes in the name of hotplug is pretty
much guaranteed to be a performance black hole because at the very
least, page table pages will always be remote accesses for processes
running on the unmovable node.
> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
> index 057964d..f0954ac 100644
> --- a/mm/mempolicy.c
> +++ b/mm/mempolicy.c
> @@ -2334,6 +2334,13 @@ int mpol_misplaced(struct page *page, struct vm_area_struct *vma, unsigned long
> out:
> mpol_cond_put(pol);
>
> + /* Skip unmovable nodes when do numa balancing */
> + if (movable_node_enabled && ret != -1) {
> + zone = NODE_DATA(ret)->node_zones + MAX_NR_ZONES - 1;
> + if (!populated_zone(zone))
> + ret = -1;
> + }
> +
> return ret;
> }
Nak.
--
Mel Gorman
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [Ksummit-discuss] Including images on Sphinx documents
From: Jani Nikula @ 2016-11-09 11:58 UTC (permalink / raw)
To: Markus Heiser
Cc: ksummit-discuss, linux-doc, linux-kernel, Mauro Carvalho Chehab,
linux-media
In-Reply-To: <DC27B5F7-D69E-4F22-B184-B7B029392959@darmarit.de>
On Wed, 09 Nov 2016, Markus Heiser <markus.heiser@darmarit.de> wrote:
> Am 09.11.2016 um 12:16 schrieb Jani Nikula <jani.nikula@linux.intel.com>:
>>> So I vote for :
>>>
>>>> 1) copy (or symlink) all rst files to Documentation/output (or to the
>>>> build dir specified via O= directive) and generate the *.pdf there,
>>>> and produce those converted images via Makefile.;
>>
>> We're supposed to solve problems, not create new ones.
>
> ... new ones? ...
Handle in-tree builds without copying.
Make dependency analysis with source rst and "intermediate" rst work.
Make sure your copying gets the timestamps right.
Make Sphinx dependency analysis look at the right copies depending on
in-tree vs. out-of-tree. Generally make sure it doesn't confuse Sphinx's
own dependency analysis.
The stuff I didn't think of.
Sure, it's all supposed to be basic Makefile stuff, but don't make the
mistake of thinking just one invocation of 'cp' will solve all the
problems. It all adds to the complexity we were trying to avoid when
dumping DocBook. It adds to the complexity of debugging stuff. (And hey,
there's still the one rebuilding-stuff-for-no-reason issue open.)
If you want to keep the documentation build sane, try to avoid the
Makefile preprocessing. And same old story, if you fix this for real,
even if as a Sphinx extension, *other* people than kernel developers
will be interested, and *we* don't have to do so much ourselves.
BR,
Jani.
>
>>> IMO placing 'sourcedir' to O= is more sane since this marries the
>>> Linux Makefile concept (relative to $PWD) with the sphinx concept
>>> (in or below 'sourcedir').
>
> -- Markus --
--
Jani Nikula, Intel Open Source Technology Center
^ permalink raw reply
* Re: [Ksummit-discuss] Including images on Sphinx documents
From: Jani Nikula @ 2016-11-09 11:58 UTC (permalink / raw)
To: Markus Heiser
Cc: Josh Triplett, Mauro Carvalho Chehab, Jonathan Corbet,
linux-kernel, linux-media, ksummit-discuss, linux-doc
In-Reply-To: <DC27B5F7-D69E-4F22-B184-B7B029392959@darmarit.de>
On Wed, 09 Nov 2016, Markus Heiser <markus.heiser@darmarit.de> wrote:
> Am 09.11.2016 um 12:16 schrieb Jani Nikula <jani.nikula@linux.intel.com>:
>>> So I vote for :
>>>
>>>> 1) copy (or symlink) all rst files to Documentation/output (or to the
>>>> build dir specified via O= directive) and generate the *.pdf there,
>>>> and produce those converted images via Makefile.;
>>
>> We're supposed to solve problems, not create new ones.
>
> ... new ones? ...
Handle in-tree builds without copying.
Make dependency analysis with source rst and "intermediate" rst work.
Make sure your copying gets the timestamps right.
Make Sphinx dependency analysis look at the right copies depending on
in-tree vs. out-of-tree. Generally make sure it doesn't confuse Sphinx's
own dependency analysis.
The stuff I didn't think of.
Sure, it's all supposed to be basic Makefile stuff, but don't make the
mistake of thinking just one invocation of 'cp' will solve all the
problems. It all adds to the complexity we were trying to avoid when
dumping DocBook. It adds to the complexity of debugging stuff. (And hey,
there's still the one rebuilding-stuff-for-no-reason issue open.)
If you want to keep the documentation build sane, try to avoid the
Makefile preprocessing. And same old story, if you fix this for real,
even if as a Sphinx extension, *other* people than kernel developers
will be interested, and *we* don't have to do so much ourselves.
BR,
Jani.
>
>>> IMO placing 'sourcedir' to O= is more sane since this marries the
>>> Linux Makefile concept (relative to $PWD) with the sphinx concept
>>> (in or below 'sourcedir').
>
> -- Markus --
--
Jani Nikula, Intel Open Source Technology Center
^ permalink raw reply
* Re: [PATCH/RFC v2] tools/leds: Add led_notify_mon program for monitoring brightness changes
From: Jacek Anaszewski @ 2016-11-09 11:57 UTC (permalink / raw)
To: Hans de Goede, linux-leds; +Cc: linux-kernel
In-Reply-To: <60631830-50a3-7215-15f5-d47cd73d2fc0@redhat.com>
On 11/09/2016 12:50 PM, Hans de Goede wrote:
> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Applied, thanks.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* Re: [Qemu-devel] [kvm-unit-tests PATCH v4 03/11] arm/arm64: smp: support more than 8 cpus
From: Andrew Jones @ 2016-11-09 11:57 UTC (permalink / raw)
To: Andre Przywara
Cc: kvm, kvmarm, qemu-devel, qemu-arm, pbonzini, peter.maydell,
alex.bennee, marc.zyngier, eric.auger, christoffer.dall
In-Reply-To: <f5509dd7-594b-04c8-20b0-2986fe1bcc41@arm.com>
On Wed, Nov 09, 2016 at 11:12:03AM +0000, Andre Przywara wrote:
[...]
> > diff --git a/lib/arm/setup.c b/lib/arm/setup.c
> > index 7e7b39f11dde..b6e2d5815e72 100644
> > --- a/lib/arm/setup.c
> > +++ b/lib/arm/setup.c
> > @@ -24,12 +24,22 @@ extern unsigned long stacktop;
> > extern void io_init(void);
> > extern void setup_args_progname(const char *args);
> >
> > -u32 cpus[NR_CPUS] = { [0 ... NR_CPUS-1] = (~0U) };
> > +u64 cpus[NR_CPUS] = { [0 ... NR_CPUS-1] = (~0U) };
>
> This should be ~0UL.
Indeed. Thanks.
> Also I think the type should be unsigned long to match the types used
> everywhere else.
I'll change mpidr_to_cpu to return u64 instead of unsigned long.
Actually I think Alex suggested that. I'm not sure why I haven't
done it...
>
> > int nr_cpus;
> >
> > struct mem_region mem_regions[NR_MEM_REGIONS];
> > phys_addr_t __phys_offset, __phys_end;
> >
> > +int mpidr_to_cpu(unsigned long mpidr)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < nr_cpus; ++i)
> > + if (cpus[i] == (mpidr & MPIDR_HWID_BITMASK))
> > + return i;
> > + return -1;
> > +}
> > +
> > static void cpu_set(int fdtnode __unused, u32 regval, void *info __unused)
>
> I guess this needs to be extended as well, including
> dt_for_each_cpu_node() to cope with 64-bit reg properties in the CPU
> node (where the upper word is not 0).
> But this is not really crucial atm, so can be fixed in a follow-up patch.
Yeah, I'll do it as a followup series, because it'll affect powerpc too.
drew
^ permalink raw reply
* Re: [kvm-unit-tests PATCH v4 03/11] arm/arm64: smp: support more than 8 cpus
From: Andrew Jones @ 2016-11-09 11:57 UTC (permalink / raw)
To: Andre Przywara
Cc: kvm, kvmarm, qemu-devel, qemu-arm, pbonzini, peter.maydell,
alex.bennee, marc.zyngier, eric.auger, christoffer.dall
In-Reply-To: <f5509dd7-594b-04c8-20b0-2986fe1bcc41@arm.com>
On Wed, Nov 09, 2016 at 11:12:03AM +0000, Andre Przywara wrote:
[...]
> > diff --git a/lib/arm/setup.c b/lib/arm/setup.c
> > index 7e7b39f11dde..b6e2d5815e72 100644
> > --- a/lib/arm/setup.c
> > +++ b/lib/arm/setup.c
> > @@ -24,12 +24,22 @@ extern unsigned long stacktop;
> > extern void io_init(void);
> > extern void setup_args_progname(const char *args);
> >
> > -u32 cpus[NR_CPUS] = { [0 ... NR_CPUS-1] = (~0U) };
> > +u64 cpus[NR_CPUS] = { [0 ... NR_CPUS-1] = (~0U) };
>
> This should be ~0UL.
Indeed. Thanks.
> Also I think the type should be unsigned long to match the types used
> everywhere else.
I'll change mpidr_to_cpu to return u64 instead of unsigned long.
Actually I think Alex suggested that. I'm not sure why I haven't
done it...
>
> > int nr_cpus;
> >
> > struct mem_region mem_regions[NR_MEM_REGIONS];
> > phys_addr_t __phys_offset, __phys_end;
> >
> > +int mpidr_to_cpu(unsigned long mpidr)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < nr_cpus; ++i)
> > + if (cpus[i] == (mpidr & MPIDR_HWID_BITMASK))
> > + return i;
> > + return -1;
> > +}
> > +
> > static void cpu_set(int fdtnode __unused, u32 regval, void *info __unused)
>
> I guess this needs to be extended as well, including
> dt_for_each_cpu_node() to cope with 64-bit reg properties in the CPU
> node (where the upper word is not 0).
> But this is not really crucial atm, so can be fixed in a follow-up patch.
Yeah, I'll do it as a followup series, because it'll affect powerpc too.
drew
^ permalink raw reply
* [PATCH v4 2/3] arm64: dts: marvell: Add I2C definitions for the Armada 3700
From: Romain Perier @ 2016-11-09 11:57 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c
Cc: devicetree, Rob Herring, Ian Campbell, Pawel Moll, Mark Rutland,
Kumar Gala, Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Gregory Clement, linux-arm-kernel, Thomas Petazzoni, Nadav Haklai,
Omri Itach, Shadi Ammouri, Yahuda Yitschak, Hanna Hawa,
Neta Zur Hershkovits, Igal Liberman, Marcin Wojtas <mw>
In-Reply-To: <20161109115715.2557-1-romain.perier@free-electrons.com>
The Armada 3700 has two i2c bus interface units, this commit adds the
definitions of the corresponding device nodes. It also enables the node
on the development board for this SoC.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 4 ++++
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 18 ++++++++++++++++++
2 files changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-db.dts b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
index 1372e9a6..16d84af 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
@@ -62,6 +62,10 @@
};
};
+&i2c0 {
+ status = "okay";
+};
+
/* CON3 */
&sata {
status = "okay";
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index c476253..bf2d73d 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -98,6 +98,24 @@
/* 32M internal register @ 0xd000_0000 */
ranges = <0x0 0x0 0xd0000000 0x2000000>;
+ i2c0: i2c@11000 {
+ compatible = "marvell,armada-3700-i2c";
+ reg = <0x11000 0x24>;
+ clocks = <&nb_perih_clk 10>;
+ interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+ mrvl,i2c-fast-mode;
+ status = "disabled";
+ };
+
+ i2c1: i2c@11080 {
+ compatible = "marvell,armada-3700-i2c";
+ reg = <0x11080 0x24>;
+ clocks = <&nb_perih_clk 9>;
+ interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+ mrvl,i2c-fast-mode;
+ status = "disabled";
+ };
+
uart0: serial@12000 {
compatible = "marvell,armada-3700-uart";
reg = <0x12000 0x400>;
--
2.9.3
^ permalink raw reply related
* Re: [kvm-unit-tests PATCH v4 03/11] arm/arm64: smp: support more than 8 cpus
From: Andrew Jones @ 2016-11-09 11:57 UTC (permalink / raw)
To: Andre Przywara; +Cc: kvm, marc.zyngier, qemu-devel, qemu-arm, pbonzini, kvmarm
In-Reply-To: <f5509dd7-594b-04c8-20b0-2986fe1bcc41@arm.com>
On Wed, Nov 09, 2016 at 11:12:03AM +0000, Andre Przywara wrote:
[...]
> > diff --git a/lib/arm/setup.c b/lib/arm/setup.c
> > index 7e7b39f11dde..b6e2d5815e72 100644
> > --- a/lib/arm/setup.c
> > +++ b/lib/arm/setup.c
> > @@ -24,12 +24,22 @@ extern unsigned long stacktop;
> > extern void io_init(void);
> > extern void setup_args_progname(const char *args);
> >
> > -u32 cpus[NR_CPUS] = { [0 ... NR_CPUS-1] = (~0U) };
> > +u64 cpus[NR_CPUS] = { [0 ... NR_CPUS-1] = (~0U) };
>
> This should be ~0UL.
Indeed. Thanks.
> Also I think the type should be unsigned long to match the types used
> everywhere else.
I'll change mpidr_to_cpu to return u64 instead of unsigned long.
Actually I think Alex suggested that. I'm not sure why I haven't
done it...
>
> > int nr_cpus;
> >
> > struct mem_region mem_regions[NR_MEM_REGIONS];
> > phys_addr_t __phys_offset, __phys_end;
> >
> > +int mpidr_to_cpu(unsigned long mpidr)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < nr_cpus; ++i)
> > + if (cpus[i] == (mpidr & MPIDR_HWID_BITMASK))
> > + return i;
> > + return -1;
> > +}
> > +
> > static void cpu_set(int fdtnode __unused, u32 regval, void *info __unused)
>
> I guess this needs to be extended as well, including
> dt_for_each_cpu_node() to cope with 64-bit reg properties in the CPU
> node (where the upper word is not 0).
> But this is not really crucial atm, so can be fixed in a follow-up patch.
Yeah, I'll do it as a followup series, because it'll affect powerpc too.
drew
^ permalink raw reply
* [PATCH v4 3/3] dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
From: Romain Perier @ 2016-11-09 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109115715.2557-1-romain.perier@free-electrons.com>
This commit documents the compatible string to have the compatibility for
the I2C unit found in the Armada 3700.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
Changes in v2:
- Fixed wrong compatible string, it should be "marvell,armada-3700-i2c"
and not "marvell,armada-3700".
Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
index 12b78ac..d30f0b1 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
@@ -7,6 +7,7 @@ Required properties :
compatible processor, e.g. pxa168, pxa910, mmp2, mmp3.
For the pxa2xx/pxa3xx, an additional node "mrvl,pxa-i2c" is required
as shown in the example below.
+ For the Armada 3700, the compatible should be "marvell,armada-3700-i2c".
Recommended properties :
--
2.9.3
^ permalink raw reply related
* [PATCH v4 3/3] dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
From: Romain Perier @ 2016-11-09 11:57 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Nadav Haklai, Omri Itach, Shadi Ammouri,
Yahuda Yitschak, Hanna Hawa, Neta Zur Hershkovits, Igal Liberman,
Marcin Wojtas <mw>
In-Reply-To: <20161109115715.2557-1-romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
This commit documents the compatible string to have the compatibility for
the I2C unit found in the Armada 3700.
Signed-off-by: Romain Perier <romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
Changes in v2:
- Fixed wrong compatible string, it should be "marvell,armada-3700-i2c"
and not "marvell,armada-3700".
Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
index 12b78ac..d30f0b1 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
@@ -7,6 +7,7 @@ Required properties :
compatible processor, e.g. pxa168, pxa910, mmp2, mmp3.
For the pxa2xx/pxa3xx, an additional node "mrvl,pxa-i2c" is required
as shown in the example below.
+ For the Armada 3700, the compatible should be "marvell,armada-3700-i2c".
Recommended properties :
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v4 2/3] arm64: dts: marvell: Add I2C definitions for the Armada 3700
From: Romain Perier @ 2016-11-09 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109115715.2557-1-romain.perier@free-electrons.com>
The Armada 3700 has two i2c bus interface units, this commit adds the
definitions of the corresponding device nodes. It also enables the node
on the development board for this SoC.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 4 ++++
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 18 ++++++++++++++++++
2 files changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-db.dts b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
index 1372e9a6..16d84af 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
@@ -62,6 +62,10 @@
};
};
+&i2c0 {
+ status = "okay";
+};
+
/* CON3 */
&sata {
status = "okay";
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index c476253..bf2d73d 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -98,6 +98,24 @@
/* 32M internal register @ 0xd000_0000 */
ranges = <0x0 0x0 0xd0000000 0x2000000>;
+ i2c0: i2c at 11000 {
+ compatible = "marvell,armada-3700-i2c";
+ reg = <0x11000 0x24>;
+ clocks = <&nb_perih_clk 10>;
+ interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+ mrvl,i2c-fast-mode;
+ status = "disabled";
+ };
+
+ i2c1: i2c at 11080 {
+ compatible = "marvell,armada-3700-i2c";
+ reg = <0x11080 0x24>;
+ clocks = <&nb_perih_clk 9>;
+ interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+ mrvl,i2c-fast-mode;
+ status = "disabled";
+ };
+
uart0: serial at 12000 {
compatible = "marvell,armada-3700-uart";
reg = <0x12000 0x400>;
--
2.9.3
^ 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.